[Bug]: Claude Code gateway-model cache never refreshes because the /v1/models fetch sends no auth token (401)

[rrmlima]

Summary

The Claude Code gateway-model cache writer (src/claude/gateway-cache.ts) fetches /v1/models?limit=1000&ids=cli from the local proxy without any authentication header. Since the proxy requires auth on /v1/models (401 without a key), the fetch always fails with !res.ok → the function returns null → the Claude Code model picker cache is never updated.

This silently breaks the Claude Code model list in every deployment where the proxy has API auth enabled (the default). The fetch is internal (loopback), but it still needs the admission token like every other internal call.

Reproduction

# 1. Start the proxy with API auth (default) and export OPENCODEX_API_AUTH_TOKEN
# 2. The gateway-cache refresh path runs (e.g. via ocx claude launch)

# The exact fetch the code makes:
curl -s -o /dev/null -w '%{http_code}\n' \
  "http://127.0.0.1:10100/v1/models?limit=1000&ids=cli"
# → 401 {"error":{"message":"opencodex API key required",...}}

# With the token it works:
curl -s -o /dev/null -w '%{http_code}\n' \
  -H "x-opencodex-api-key: $OPENCODEX_API_AUTH_TOKEN" \
  "http://127.0.0.1:10100/v1/models?limit=1000&ids=cli"
# → 200

Result: refreshGatewayModelCacheFromProxy returns null (401 → !res.ok → early return), so ~/.claude/cache/gateway-models.json is never refreshed and the Claude Code picker shows a stale/empty model list.

Logs and screenshots

No error is logged — the failure is silent (if (!res.ok) return null;). The only observable symptom is the Claude Code model picker not reflecting new models until a manual cache write happens.

Area

CLI

Version

2.17.0 (present on current main — verified: src/claude/gateway-cache.ts has no auth header on origin/main)

OS

Ubuntu 24.04 (VPS, root)

Config shape

Default API auth (service token via OPENCODEX_API_AUTH_TOKEN), Claude Code launched through the proxy.

Root cause

src/claude/gateway-cache.ts refreshGatewayModelCacheFromProxy (current main):

const res = await fetch(`http://127.0.0.1:${port}/v1/models?limit=1000&ids=cli`, {
  headers: { "anthropic-version": "2023-06-01" },
  signal: AbortSignal.timeout(timeoutMs),
});
if (!res.ok) return null;

The /v1/models endpoint enforces API auth (401 without key), so res.ok is always false when auth is enabled. Every other internal proxy call sends the admission token via x-opencodex-api-key — this fetch is the outlier.

Proposed fix

Add the admission token to the fetch headers:

   try {
     // ?ids=cli pins the readable claude-ocx id family deterministically (audit 051
     // #5): the cache prewrite must not depend on UA sniffing.
+    const headers: Record<string, string> = { "anthropic-version": "2023-06-01" };
+    const token = process.env.OPENCODEX_API_AUTH_TOKEN?.trim() || (loadConfig().apiKeys?.[0]?.key ?? "");
+    if (token) headers["x-opencodex-api-key"] = token;
     const res = await fetch(`http://127.0.0.1:${port}/v1/models?limit=1000&ids=cli`, {
-      headers: { "anthropic-version": "2023-06-01" },
+      headers,
       signal: AbortSignal.timeout(timeoutMs),
     });
     if (!res.ok) return null;

(loadConfig is already available from src/config — needs an import if not present.)

Alternatives considered

• Make /v1/models?ids=cli auth-exempt: weakens the API surface for a single internal caller; not desirable.
• Keep relying on the ?ids=cli query as implicit auth: no, the endpoint still 401s regardless of query params (verified).
• Do nothing: the Claude Code picker cache silently never updates on auth-enabled deployments.

Additional context

The same token pattern is used elsewhere in the codebase (e.g. x-opencodex-api-key on /v1/responses). This issue is part of a batch reported from a real deployment; siblings: #1686 (Bearer on /v1/responses), #1688 (IS_SANDBOX root bypass), #1690 (retainModels allow-list).

Test matrix:

• auth enabled + token present → fetch 200 → cache written with model list
• auth enabled + no token → fetch 401 → returns null (unchanged, graceful)
• auth disabled (loopback-only) → unchanged
• Claude Code picker shows the cached model list after a refresh

[coderabbitai]

🔗 Related PRs

#625 - [WRONG BRANCH] fix(claude): stabilize GPT/Codex prompt cache [open]
#626 - [WRONG BRANCH] fix: stabilize cache inputs [open]
#651 - fix(gui): dedupe dashboard API token prompts on concurrent 401s [merged]
#1360 - fix(claude): bind proxy admission tokens to local destinations [merged]
#1369 - fix(oauth): guard local token expiry parsing against NaN [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Ingwannu]

Confirmed as a configuration-specific bug on current dev.

The default loopback listener intentionally allows the local /v1/models request without credentials, so ordinary installs are unaffected. When the proxy is configured on a non-loopback hostname, however, the same data-plane endpoint requires admission and the cache refresh currently sends no accepted credential, producing the reported 401/stale picker behavior.

I will keep the fix inside the existing trust boundary:

• use the dedicated x-opencodex-api-key admission header, never an upstream Authorization bearer;
• prefer OPENCODEX_API_AUTH_TOKEN, then fall back to the first usable configured API key, matching server admission order;
• pass the already-loaded config from both Claude launch and macOS system-environment paths rather than re-reading config inside the cache writer;
• keep loopback/no-token behavior unchanged and add focused header-selection regressions.

[Ingwannu]

Implemented in #1755.

The refresh now uses the same dedicated data-plane admission channel as /v1/models: x-opencodex-api-key, with OPENCODEX_API_AUTH_TOKEN preferred over the first usable configured key. It does not place the proxy credential in Authorization, and callers pass their already-loaded config so the cache path does not take a second, potentially drifting config snapshot.

Validation on current dev:

• gateway cache tests: 5 passed, including environment-token precedence, configured-key fallback, and no Authorization header
• typecheck passed
• privacy scan passed
• diff check passed

The issue remains linked to the PR and will close only when the fix lands.

[lidge-jun]

Fixed on dev as 84ec092 (squash of #1755).

The pre-write fetch now attaches the admission credential in its own header domain — x-opencodex-api-key, never Authorization, which belongs to upstream providers on other data-plane surfaces — sent only to http://127.0.0.1:<port>. Precedence follows what the opencode launcher already established: environment token, then the hardened service-token file, then a configured admission key.

The service-token-file step was added on top of the original patch: a service install writes the token to disk rather than into the interactive environment, so an interactive ocx claude with no env token and no configured key would still have gotten a 401 and kept a stale picker.

Verified on the remote validation host: 98 pass / 0 fail across tests/claude-gateway-cache.test.ts, tests/server-management-auth.test.ts, tests/data-plane-admission-identity.test.ts, tests/opencode-cli.test.ts, plus a clean tsc --noEmit.

Thanks @Ingwannu.