Tencent WorkBuddy API key is rejected with 401

Description

Summary

Calling the OpenCode Go endpoint from Tencent WorkBuddy (desktop app, v5.5.3 — same product line as CodeBuddy IDE) as a generic OpenAI-compatible model fails on every chat request:

• Base URL: https://opencode.ai/zen/go/v1/chat/completions
• Model: deepseek-v4-flash
• Auth: OpenCode Go API key (sk-..., issued via https://opencode.ai/auth)

The client shows an auth-style error instead of a response:

API Key 无效或没有权限访问该模型
(≈ "Invalid API key or no permission to access this model")

Raw endpoint tests with the same key (see table below) confirm the key is rejected with 401 {"type":"error","error":{"type":"AuthError","message":"Invalid API key."}} on every POST path — while GET /zen/go/v1/models returns 200 with or without credentials, so it cannot validate a key. The failure started recently (the exact trigger is under investigation; note OpenCode began enforcing the x-opencode-session header around 2026-09-06, but adding the header does not change the result — see tests #2 vs #3).

Original hypothesis — superseded by direct tests (see below)

Earlier I suspected the key was fine and the gateway was rejecting unidentified clients (missing x-opencode-session / custom User-Agent, as enforced since ~2026-09-06 per the Go docs and lobehub/lobehub#19123). Direct curl tests now show the key is rejected with a plain AuthError even with the header present, so the session-header theory does not explain this case; the current evidence points to a server-side 401 classification issue.

Other third-party clients had the same issue and fixed it by sending that header:

• lobehub/lobehub#19123 — "opencode-go: send required x-opencode-session header (vendor enforcing from 2026-09-06)"
• earendil-works/pi#4847
• openclaw/openclaw#137165

Cross-references

• #47735 — another user's earlier report of the same failure (https://opencode.ai/zen/go/v1/chat/completions failing from WorkBuddy), filed without the required details. This issue provides the missing evidence (repro steps + endpoint tests).
• #40453 / #37056 / #35906 — related opencode-go gateway issues. This one differs from those Cloudflare-edge HTTP 500 reports: the failure here is a credential-level 401 (AuthError) on every POST path with a key the user believes is active (see endpoint tests above). If the 401 turns out to share a server-side root cause with the 500s, feel free to link them.

Request

• Confirm whether requests from OpenAI-compatible clients that do not send x-opencode-session / a custom User-Agent are intentionally rejected with an "invalid API key"-style error after 2026-09-06, and whether a clearer error message is planned.
• If this is expected/known, please point CodeBuddy-class clients at the correct way to authenticate (or mark this as a duplicate of the tracking issue).

Direct endpoint tests with the same key (2026-09-08, macOS 26.5.1)

All calls below use the same active sk-... key from https://opencode.ai/auth (key itself is clean: 65 chars, no hidden whitespace; xxd-verified):

#	Request	Headers	HTTP	Response body
1	GET /zen/go/v1/models	Authorization: Bearer <key>	200	Full model list (list is public — also 200 without any key)
2	POST /zen/go/v1/chat/completions (deepseek-v4-flash)	Authorization only (plain OpenAI-compatible, what WorkBuddy sends)	401	{"type":"error","error":{"type":"AuthError","message":"Invalid API key."}}
3	POST /zen/go/v1/chat/completions (deepseek-v4-flash)	Authorization + x-opencode-session: <uuid> + User-Agent: workbuddy-agent/1.0 (test)	401	{"type":"error","error":{"type":"AuthError","message":"Invalid API key."}} (same)
4	POST /zen/go/v1/messages (Anthropic path, minimax-m3)	x-api-key: <key> + anthropic-version: 2023-06-01	401	{"type":"error","error":{"type":"AuthError","message":"Invalid API key."}}
5	POST /zen/v1/chat/completions (non-go Zen path)	Authorization	401	{"type":"error","error":{"type":"AuthError","message":"Invalid API key."}}
6	GET /zen/go/v1/usage	Authorization	401	{"type":"error","error":{"type":"AuthError","message":"Unauthorized"}}

Control: a deliberately typo'd key returns the identical 401 {"type":"AuthError","message":"Invalid API key."} — so the server cannot be distinguishing "invalid key" from "valid key rejected for another reason" at the HTTP layer.

Key observations:

1. GET /models returns 200 even with no credentials, so it cannot be used to validate a key — the earlier "the key works" impression was a false positive.
2. Every POST endpoint rejects this key with the same AuthError, even with correct x-opencode-session / User-Agent / x-api-key headers.
3. The error is a credential-level 401, not the Cloudflare-edge 500 seen in #40453/#37056 and not a missing-header/429 message.

This suggests the key itself is being rejected server-side at the moment of testing (e.g. key rotation/revocation, subscription-state gating, regional gating collapsed into AuthError, or an active gateway issue since ~2026-09-06), rather than a client-side x-opencode-session problem — please investigate the 401 classification server-side. If the key is truly invalid, the Go dashboard should show a corresponding state.

Plugins

N/A — not the OpenCode client. The caller is WorkBuddy (Tencent CodeBuddy desktop, v5.5.3) configured as a generic OpenAI-compatible provider.

OpenCode version

N/A (server-side behavior of opencode.ai/zen/go; not using the OpenCode CLI/TUI).

Steps to reproduce

1. In WorkBuddy v5.5.3 add a custom OpenAI-compatible model provider:
   • Base URL: https://opencode.ai/zen/go/v1/chat/completions
   • API key: active OpenCode Go key (sk-..., from https://opencode.ai/auth)
   • Model: deepseek-v4-flash
2. Start a chat with that model and send any message.
3. The request fails immediately with: API Key 无效或没有权限访问该模型.
4. Reproduce from a shell with the same key and observe the 401 (auth-class error, no x-opencode-session dependency confirmed):

   curl -i https://opencode.ai/zen/go/v1/chat/completions \
     -H "Authorization: Bearer <KEY>" \
     -H "Content-Type: application/json" \
     -d '{"model":"deepseek-v4-flash","messages":[{"role":"user","content":"ping"}],"max_tokens":16}'
   # -> HTTP 401  {"type":"error","error":{"type":"AuthError","message":"Invalid API key."}}
   

5. Note: GET /zen/go/v1/models returns 200 with or without a key — it does not validate the key.

Environment of the tests: macOS 26.5.1 (arm64), plain curl 8.x, tested 2026-09-08 00:10–00:16 (UTC+8).

Screenshot and/or share link

Screenshot of the WorkBuddy error dialog is attached.

Operating System

macOS 26.5.1 (Apple Silicon / arm64)

Terminal

N/A — desktop GUI app: WorkBuddy 5.5.3 (Tencent CodeBuddy product line)

PS:My OpenCode Go account logs in normally — I can sign in at https://opencode.ai/auth and the subscription/API key are visible and active on my account. The 401 Invalid API key therefore does not reflect an account-level problem on my side; the key is rejected by the gateway despite the account being in good standing.

Start by reproducing the reported POST requests to /zen/go/v1/chat/completions, /zen/go/v1/messages, and /zen/v1/chat/completions with the documented headers and a control key. Trace the server-side authentication handling for these entry points and compare it with GET /zen/go/v1/models and /zen/go/v1/usage. Done means identifying the cause of the uniform 401 classification or confirming the expected behavior and providing a clear resolution path.