Bug: Web UI reports "API key is invalid" while headless works with the same provider

[Zhong0118]

Bug: Web UI reports "API key is invalid" while headless works with the same provider

Environment

• DSH: @deepseek-ai/dsh@0.1.2-rc.1
• Node.js: v24.19.0
• OS: macOS
• Provider: custom third-party OpenAI-compatible provider
• Provider ID: micu-grok
• Model: grok-4.6

No API key is included in this report.

Problem

In the DSH Web UI, sending a new message sometimes fails with:

本轮运行失败
API 密钥无效
UNKNOWN

However, the same DSH installation, provider configuration, model, and API credential work correctly in headless mode.

For example:

dsh --profile headless "只回复 OK，不要调用工具"

returns successfully:

dsh: reasoning:
The user asked me to only reply "OK" and not call any tools. This is a straightforward instruction.

OK

This strongly suggests that the API credential itself is valid, and the failure may be specific to the Web profile/provider path or error classification.

Expected behavior

The Web profile and headless profile should resolve and use the same configured provider credentials consistently.

If the upstream provider returns a different authorization-related error, such as:

• 401 invalid credential
• 403 permission denied
• quota exhausted
• gateway policy rejection
• provider-specific authorization failure

the Web UI should expose the real sanitized error/status instead of always displaying:

API 密钥无效

Actual behavior

Headless:

same provider + same model + same credential
→ works

Web UI:

same provider + same model + same credential
→ API 密钥无效 / UNKNOWN

Additional context

This installation was recently upgraded from an older DSH RC version to:

0.1.2-rc.1

The Web profile also contains third-party plugins, some of which needed updates because of changes to the settings/client-runtime APIs in DSH 0.1.2.

However, since headless works correctly, the problem appears to be specific to the Web/profile execution path, provider credential resolution, or failure projection.

It would be very useful if DSH exposed the original sanitized upstream HTTP status and error message in this case.

[Mide69]

Dug into how "API 密钥无效" actually gets produced for a custom OpenAI-compatible provider like yours, and found two real, verified things worth knowing.

For a pi-ai-routed provider (which a custom third-party endpoint like micu-grok goes through), the AUTH classification comes from packages/llm/llm-pi-ai/src/stream.ts:43: /\b(?:401|403)\b/.test(message) — a bare regex looking for the digits 401 or 403 anywhere in the flattened error string. There's a code comment right above it explaining why: pi-ai itself discards the original Error and its cause chain before handing it back, leaving only error.message text to pattern-match on. This is acknowledged tech debt, not an oversight, but it means any upstream text that happens to contain "401" or "403" as a standalone token, even in an unrelated context, gets classified as AUTH.

Then it gets worse for diagnosing this: packages/client/ui-chat/src/client/conversation-nodes/event-projection.ts:157 does if (code === 'AUTH') return { code, message: '' } — once something is classified AUTH, the actual upstream message is thrown away before it reaches the UI. So even if this is a misclassification, there is currently no way to see the real text that triggered it. That matches your own ask exactly: exposing the original sanitized upstream status/message would let you tell a real 401 apart from a false-positive match.

Since this classifier is shared code (not Web-specific), the headless-vs-Web difference is probably not the classification logic itself, both would hit the same function for the same request. More likely explanations: the Web session is genuinely getting a different response intermittently (matches your own "sometimes fails" framing, could be a real transient auth/quota hiccup from the gateway), or one of the third-party plugins you mentioned updating is touching the request or response only on the Web profile path. Worth checking whether the failure correlates with anything plugin-related, and if you can get to the raw network response (even temporarily patching that message: '' line locally to keep it) that would settle whether this is a real 401 or a false-positive substring match.

[argszero]

Complementing the verified classification details above with the UI-side of the same chain (checked on master d347e70390), since it answers the "where does the exact string I saw come from" half:

1. The text you quoted is a client-side fallback, selected by error code. failureMessage() in packages/client/ui-chat/src/client/chat/MessageItem.tsx:56-63 renders the locale key message.failure.auth ("API 密钥无效") whenever code === 'AUTH', discarding whatever message text arrived. So the UI is not showing you a provider message at all — it is substituting a generic one based on the classification.

2. The blanking Mide69 found at event-projection.ts:157 has a sibling: packages/client/ui-trajectory/src/client/trajectory-event-projection.ts:135 does the same if (code === 'AUTH') return { code, message: '' }. Both projections deliberately drop AUTH message text because "provider AUTH messages may echo a masked or partially preserved credential" — a credential-leak guard, not an accident. This is why exposing the "real sanitized error" in the UI needs care: the raw text may itself contain key material.

3. The raw diagnostic is not lost — it is in the session log. The projection comment says it outright: keep the raw diagnostic in the Session log, never in UI state. So before patching the message: '' line (Mide69's suggestion), the cheaper step is to open the session's JSONL and read the durable failure record for the failing turn — it holds the original upstream text/status. That settles real-401 vs false-positive-substring without a local patch.

4. One discrepancy worth pinning down: your failure block showed UNKNOWN as the code line while the message line showed the AUTH fallback. If the terminal failure had code AUTH, the code line would read AUTH, not UNKNOWN — so the AUTH text you saw likely came from an intermediate retry failure while the final turn error carried UNKNOWN (an unclassified failure). That distinction matters: an UNKNOWN terminal code means the classifier never mapped the upstream error at all, which is a different (and more actionable) bug than a 401 false-positive. The session log's turn/end error record will show which one you actually hit.