[bug]: auth login — workspace sk-ws- key + *.maas.aliyuncs.com always fails validation (probes /api/v1/models → 404, misreported as an invalid key)

The reporter pinpoints the functions by minified names: getApiKeyLoginKind() in bailian-cli-core classifies keys by prefix, and Ko() in bailian-cli-commands picks the models probe path, with Xo() handling explicit --base-url and Uo/Zo() swallowing the 404. Map those minified names to the TypeScript sources and read how key kind and base-URL host decide the probe path. Fix: probe /compatible-mode/v1/models for *.maas.aliyuncs.com hosts (or add a sk-ws- kind) and stop treating a 404 as an auth failure; done when the official console bootstrap step [3/3] succeeds and validation no longer misreports 404 as an invalid key.

CLI version

2.5.1

Skill version (optional)

2.5.1

Node version

v24.10.0

OS

darwin 27.0.0 (macOS 27.0.1, arm64)

Region

intl

Command to reproduce

# Official one-line bootstrap copied verbatim from the Bailian console for a
# Singapore (ap-southeast-1) Model Studio workspace. Key + workspace id redacted.
curl -fsSL 'https://bailian.aliyun.com/api-key.sh' | bash -s -- \
  'o1_[REDACTED]' -r ap-southeast-1 -w ws-[REDACTED]
# Steps [1/3] install CLI and [2/3] install skills succeed; [3/3] always fails.

# The bootstrap locally decodes the o1_ blob into an sk-ws-... key, then runs:
bl auth login --config default \
  --api-key 'sk-ws-[REDACTED]' \
  --base-url 'https://ws-[REDACTED].ap-southeast-1.maas.aliyuncs.com' \
  --verbose

# The wrong probe path is visible even without a valid key:
bl auth login \
  --api-key 'sk-dummy0000000000000000000000000000000000000000000000' \
  --base-url 'https://ws-[REDACTED].ap-southeast-1.maas.aliyuncs.com' \
  --verbose

Expected behavior

bl auth login should accept this key. The very same key against the very same base URL succeeds when the OpenAI-compatible path is used:

GET https://ws-[REDACTED].ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1/models
→ HTTP 200
  {"object":"list","data":[{"id":"qwen3.8-omni-flash",...},{"id":"glm-5.3",...}, ...]}

Workspace gateways at https://{workspace}.{region}.maas.aliyuncs.com only serve /compatible-mode/v1/*, so login validation should probe /compatible-mode/v1/models for them.

Actual behavior

Validation probes the DashScope-native path instead, gets a 404, and reports it as an authentication failure (exit code 3). No config is written, so a subsequent bl auth status says "Not authenticated" even though the key is fine.

GET https://ws-[REDACTED].ap-southeast-1.maas.aliyuncs.com/api/v1/models?page_no=1&page_size=1
→ HTTP 404 Not Found (empty body)

Root cause (bl 2.5.1, minified names)

1. getApiKeyLoginKind() (bailian-cli-core) classifies purely by prefix:

function Ft(e){
  let t = e.trim();
  return t.startsWith('sk-sp-') ? 'token-plan'
       : t.startsWith('sk-')    ? 'ordinary'
       :                          'unknown';
}

A workspace key sk-ws-... therefore lands in ordinary.

2. Ko(base, kind) (bailian-cli-commands) picks the models path from the kind:

function Ko(e, t){
  let n = new URL(t === 'token-plan' ? '/compatible-mode/v1/models' : '/api/v1/models', `${e}/`);
  if (t === 'ordinary') { n.searchParams.set('page_no','1'); n.searchParams.set('page_size','1'); }
  return n.toString();
}

3. Because --base-url was passed explicitly, Xo() short-circuits (if (t.explicitBaseUrl) { ...; return i; }) and never falls back to the Go.ordinary public DashScope endpoints — so exactly one candidate is probed, and it is the wrong path.

4. 404 is a member of the "endpoint responded" set Uo = new Set([200, 400, 401, 403, 404, 405]), so the routing failure is swallowed by Zo() and re-thrown as the generic AUTH error "the key was not accepted by any supported model endpoint."

Note also that Xo() auto-builds https://{workspaceId}.{region}.maas.aliyuncs.com for all six regions in Wo whenever workspace_id is configured — always with kind ordinary, i.e. always against /api/v1/models. So that discovery path is guaranteed to 404 as well. The CLI clearly intends to support these hosts but pairs them with an API path they do not serve.

Consequence: any workspace-scoped sk-ws- key combined with a *.maas.aliyuncs.com base URL can never pass bl auth login, in any region, regardless of network conditions. The official console bootstrap command therefore always fails at step [3/3].

Full output

> GET https://ws-[REDACTED].ap-southeast-1.maas.aliyuncs.com/api/v1/models?page_no=1&page_size=1
> Auth: sk-w...3-hc
> x-dashscope-source-config: {"channel":"bailian-cli","tags":{"t1":"public","t2":"bl","t3":"2.5.1"}}
< 404 Not Found
request_id: a62006a2-3979-938e-8121-ee8de07d69c9

Error:       API key validation failed: the key was not accepted by any supported model endpoint.
Hint:        Check that the API key belongs to this Base URL.

             bl auth login --api-key <your-key>
             bl auth status
             Get API Key: https://bailian.console.aliyun.com/cn-beijing/?tab=app#/api-key
Exit code:   3

--- as surfaced by the api-key.sh bootstrap wrapper ---

[3/3] Configuring credentials

Error: Bailian CLI authentication failed:
Error:       API key validation failed: the key was not accepted by any supported model endpoint.
Hint:        Check that the API key belongs to this Base URL.
Exit code:   3

JSON error (optional)

{
  "error": {
    "code": 3,
    "message": "API key validation failed: the key was not accepted by any supported model endpoint.",
    "hint": "Check that the API key belongs to this Base URL."
  }
}

Already tried

• bl update and skill version aligned with CLI
• bl auth status OK for this command
• Different network / region — still reproduces

How often does this happen?

Always

How was bl invoked?

Terminal (manual)

Notes (optional)

Evidence that this is not a credential, region or network problem

All probes from the same machine, same session. [REDACTED] = the real sk-ws-... key; workspace id redacted.

#	Probe	Result
1	DNS / TCP / TLS to ws-[REDACTED].ap-southeast-1.maas.aliyuncs.com	resolves, connect 0.26 s, TLS 0.46 s → network fine
2	GET {base}/compatible-mode/v1/models with the real key	200, real model list → the key is valid for this workspace
3	GET {base}/api/v1/models?page_no=1&page_size=1 with the real key	404, empty body, request_id a62006a2-3979-938e-8121-ee8de07d69c9
4	GET {base}/api/v1/models?page_no=1&page_size=1 with a deliberately invalid key	401 Unauthorized, request_id a2772a00-991d-95e6-9566-fe85503f391c
5	GET https://dashscope-intl.aliyuncs.com/api/v1/models?page_no=1&page_size=1 with the real key	200 (total: 170)
6	GET https://dashscope.aliyuncs.com/api/v1/models?page_no=1&page_size=1 with the real key	401 InvalidApiKey — expected, this is an international/Singapore workspace
7	GET https://token-plan.{cn-beijing,ap-southeast-1}.maas.aliyuncs.com/compatible-mode/v1/models with the real key	401 InvalidApiKey → not a Token Plan key

Rows 3 and 4 are the decisive pair: the gateway authenticates first and routes second. An invalid key yields 401; a valid key yields 404 on that path — i.e. /api/v1/models is simply not served on a workspace MaaS gateway. Row 2 confirms the key and workspace are correct. Row 5 explains why the ordinary classification is not unreasonable in general: the public intl endpoint does serve the native path. The bug only bites on *.maas.aliyuncs.com hosts.

Also worth noting: a genuinely broken network would not produce this message. Qo() rethrows the first candidate error for which Zo() is false (no api.httpStatus), so a DNS/TLS/timeout failure surfaces as a network error. Seeing "not accepted by any supported model endpoint" already implies the endpoint answered — which makes the message actively misleading in the 404 case.

Workaround (bypasses the validation path entirely)

bl config set --key api_key      --value 'sk-ws-...'
bl config set --key base_url     --value https://ws-[REDACTED].ap-southeast-1.maas.aliyuncs.com
bl config set --key workspace_id --value ws-[REDACTED]
bl auth status              # → API key (model): config  sk-w...
bl text chat --message hi   # → normal completion through the workspace gateway

bl config set performs no validation, and real model calls go through /compatible-mode/v1/..., so only the login self-check is affected. Confirmed working on 2.5.1.

No spelling of --base-url can work around this, because Ko() uses new URL('/api/v1/models', base + '/') and an absolute path replaces whatever path the user supplied (e.g. a base URL ending in /compatible-mode/v1).

Omitting --base-url entirely does "succeed" — but only because validation then falls through to Go.ordinary and finds https://dashscope-intl.aliyuncs.com (row 5), silently persisting the public endpoint instead of the workspace gateway the console asked for.

Suggested fix

1. In Ko(), choose the models path by host, not only by key kind: any base URL whose hostname ends in .maas.aliyuncs.com (or whose path already contains /compatible-mode) should be probed at /compatible-mode/v1/models.
2. Alternatively, add a workspace kind for the sk-ws- prefix in getApiKeyLoginKind() and map it to the compatible-mode path.
3. Cheap safety net: when the explicit base URL returns 404 on the probed path, retry the other kind's path before concluding the key is invalid.
4. Remove 404 from Uo, or at least distinguish it: a 404 on the models endpoint means "this base URL does not serve this API path", not "this key was rejected". Today it produces exit code 3 / AUTH, which also makes api-key.sh print Bailian CLI authentication failed and skip writing ~/.bailian/config.json.
5. Surface http_status and request_id in the JSON error for validation failures — the current JSON object has neither, so an agent or CI cannot tell a routing bug from a bad key.

Related

• #241 (closed) — same family: a wrong default endpoint producing HTTP 404 for every request (vision describe pinned to the Coding Plan host).
• #267 (open) — same Singapore workspace sk-ws- key + *.maas.aliyuncs.com setup, different symptom (local media upload pinned to the China endpoint).

Invoked via the terminal, through the official https://bailian.aliyun.com/api-key.sh bootstrap command copied from the Bailian console.