OpenCode 1.4.11 (stock) returns "Forbidden: Invalid Token" against ucode-managed opencode.json — works against a Databricks-aware fork

[dgokeeffe]

Summary

The same ucode-managed opencode.json succeeds against a Databricks-aware OpenCode fork but returns Forbidden: Invalid Token against published stock OpenCode 1.4.11. The token itself is valid (the fork accepts it on the same wire, with the same opencode.json, in the same shell).

This points at one of two things:

1. Stock OpenCode strips or remaps the provider-level headers.Authorization that ucode writes, so the @ai-sdk/anthropic default x-api-key: <token> reaches the AI Gateway instead — and the gateway's Anthropic translator rejects x-api-key because Databricks bearer tokens are not Anthropic API keys.
2. The fork carries header-handling code that stock OpenCode lacks (the fork adds an explicit Databricks provider that injects Authorization: Bearer <token> deterministically; stock OpenCode may run @ai-sdk/anthropic with its default header pipeline).

Either way, the practical outcome for an end user is the same: ucode configure --agents opencode succeeds, OpenCode launches, and every request 401s.

Reproduction

Using a workspace with AI Gateway v2 enabled (Claude path):

# 1. Configure ucode
DATABRICKS_CONFIG_PROFILE=<profile> \
  uv run ucode configure --agents opencode \
                          --workspaces https://<workspace>

# 2. Confirm the managed opencode.json carries the bearer token at the
#    provider level (not just at the model level):
jq '.provider["databricks-anthropic"].options' \
   ~/.config/ucode/opencode-xdg/opencode/opencode.json
# Expected fields: { baseURL, apiKey, headers: { Authorization: "Bearer ..." } }

# 3. Install stock OpenCode 1.4.11 from npm
bun add -g opencode-ai@1.4.11
which opencode    # /<bun-bin>/opencode

# 4. Launch via ucode against stock opencode
ucode opencode run "say hi in 5 words or less"

Observed (stock 1.4.11):

Forbidden: Invalid Token

OpenCode exits non-zero. Bun process logs show the AI Gateway returning HTTP 403 to the POST /ai-gateway/anthropic/v1/messages call.

Re-running the same command pointed at a Databricks-aware OpenCode fork (same managed config, same token, same workspace, same shell) succeeds:

OPENCODE_BIN_PATH=/path/to/fork/dist/opencode-darwin-arm64/bin/opencode \
  ucode opencode run "say hi in 5 words or less"
# -> "Hi! Five words for you."

The fork carries an explicit Databricks provider that wires Authorization: Bearer deterministically; stock OpenCode runs the AI SDK provider with its default header pipeline.

Hypothesis (most likely)

@ai-sdk/anthropic reads the apiKey option from the provider config and uses it to set x-api-key: <token> on every outbound request, regardless of any headers block. The AI Gateway's /ai-gateway/anthropic translator only accepts Authorization: Bearer <Databricks token> — it rejects x-api-key because that header carries an Anthropic-issued key.

ucode currently writes both:

"options": {
  "baseURL": "https://<ws>/ai-gateway/anthropic/v1",
  "apiKey": "<databricks-token>",
  "headers": { "Authorization": "Bearer <databricks-token>" }
}

…on the assumption that one of the two will land. In the fork the explicit Databricks provider takes precedence and only ships Authorization. In stock OpenCode the @ai-sdk/anthropic provider runs end-to-end and x-api-key wins.

Proposed fix candidates (smallest first)

Option A — drop apiKey, keep only Authorization header

In src/ucode/agents/opencode.py:98–106 and the equivalent gemini block at :109–117:

 providers["databricks-anthropic"] = {
     "npm": "@ai-sdk/anthropic",
     "options": {
         "baseURL": opencode_base_urls["anthropic"],
-        "apiKey": token,
+        # Don't pass apiKey: @ai-sdk/anthropic uses it to set x-api-key,
+        # which the Databricks AI Gateway rejects (it expects a Databricks
+        # bearer, not an Anthropic-issued API key). The Authorization header
+        # below is what the gateway actually authenticates against.
         "headers": auth_headers,
     },
     "models": dict.fromkeys(anthropic_models, anthropic_model_overlay),
 }

This needs verification — @ai-sdk/anthropic may refuse to construct without an apiKey. If so, pass a sentinel ("unused-databricks-uses-bearer") and add a one-line comment.

Option B — wait for a stock OpenCode release that exposes a Databricks provider natively

If Option A doesn't land on stock OpenCode for unrelated reasons (provider validation, header-overwriting upstream), the alternative is ucode pinning to a Databricks-aware OpenCode fork until the upstream merges native Databricks support. That's the path the fork-maintaining team is on today.

Ask

We want to retire the Databricks-aware OpenCode fork and rely on ucode + stock OpenCode. This Forbidden: Invalid Token is the second of two blockers (the first is the missing GPT-5 / Codex provider — filed separately). Could a ucode maintainer:

1. Confirm whether the apiKey + headers.Authorization shape is intended to support stock OpenCode at all, and
2. Either apply Option A above (and validate on opencode-ai@1.4.11) or document the OpenCode version range ucode actually targets in README.md?

Verification evidence

• Token validity confirmed via direct curl against ${workspace}/ai-gateway/anthropic/v1/messages with Authorization: Bearer <token> — 200 OK.
• Same opencode.json + same token + same shell → fork succeeds, stock 1.4.11 fails.
• Codex-driven test run (timestamp 2026-05-25 22:38) captured the Invalid Token failure on opencode-ai@1.4.11; the local fork ran at commit cac7817a7 (feat/databricks-provider).

[rohita5l]

@dgokeeffe Do you mind submitting a PR for this ? Also would be worth looking at why the e2e test did not catch this. So would suggest enhancing the test as well

[dgokeeffe]

Update — cannot reproduce as of 2026-05-28.

Retesting today against the same workspace (logfood) and the same opencode-ai@1.4.11 binary that captured the original Forbidden: Invalid Token on 2026-05-25, the bearer-token flow now succeeds end-to-end. Claude responses come back cleanly with the exact same ucode-managed config shape (apiKey + headers.Authorization both present on databricks-anthropic.options).

Repro attempt

$ opencode --version
1.4.11

$ DATABRICKS_CONFIG_PROFILE=logfood databricks auth token | jq -r .access_token
<valid 860-char token>

# Render ucode's current opencode.json via the same code path the CLI walks:
$ uv run python -c "
from ucode.agents import opencode as oc
from ucode.databricks import build_opencode_base_urls, discover_claude_models
token = '<token>'
ws = 'https://adb-2548836972759138.18.azuredatabricks.net'
claude, _ = discover_claude_models(ws, token)
overlay, _ = oc.render_overlay(
    model='databricks-claude-sonnet-4-6',
    token=token,
    opencode_base_urls=build_opencode_base_urls(ws),
    opencode_models={'anthropic': list(claude.values())},
)
import json; print(json.dumps(overlay['provider']['databricks-anthropic']['options'], indent=2))
"
# Output: { baseURL, apiKey, headers: { Authorization: "Bearer ..." } } — same as the failing config from 2026-05-25.

$ XDG_CONFIG_HOME=$TMP OAUTH_TOKEN=$TOKEN opencode run \
    --model databricks-anthropic/databricks-claude-sonnet-4-6 "say hi in 5 words"
> build · databricks-claude-sonnet-4-6
Hi there, hope you're doing well!
[exit 0]

Identical result on the lakemeter workspace (databricks-claude-opus-4-7): clean 200, no 401.

Implication

The hypothesis in the original report was that @ai-sdk/anthropic was sending x-api-key: <databricks-token> (from the apiKey field) and the AI Gateway translator was rejecting it because Databricks bearer tokens are not Anthropic API keys. With Claude succeeding now under the same shape, either:

• The gateway's /ai-gateway/anthropic/v1 translator was server-side patched to accept either x-api-key or Authorization: Bearer (most likely — the cookie endpoint behaviour was a translator concern), or
• The 2026-05-25 failure was a transient/local-token issue rather than a structural one.

Either way, the proposed Option A patch (drop apiKey) is no longer justified by current evidence, and would break @ai-sdk/anthropic's provider construction without compensating breakage.

Recommendation

Close this issue pending a fresh reproduction. If it recurs I'll reopen with a captured request/response trace from the gateway side. The codex run that filed it can also be referenced via the conversation trace at thread 019e5e69-ae82-7d82-b098-f61e1d94bebe in my local codex logs.

Related: #97 (now #101) is unaffected by this — the GPT-5 / Codex provider gap is independent of the auth question.