Remote MCP OAuth tokens never refreshed; restart loses auth state (IBKR connector)

[lucaderosa2-jpg]

Remote MCP OAuth tokens never refreshed; restart loses auth state

What happens

• A remote MCP server (IBKR mcp-public, OAuth via browser flow) works right after activation, then starts failing minutes later with 401 after successful authentication on every endpoint — snapshots, search, everything.
• Restarting opencode flips the server back to needs_auth on its own.
• Re-authenticating does not reliably revive the running session.

Evidence from my machine (Windows, global opencode.jsonc, type: remote, no custom headers)

• ~/.local/share/opencode/mcp-auth.json holds the entry with dynamically registered clientInfo, serverUrl, and a tokens object containing accessToken, refreshToken, expiresAt, scope. So both tokens persist — the refresh just never fires.
• Stored access-token lifetimes are on the order of tens of minutes, so any session longer than that hits this wall.
• Same IBKR sessions stay alive fine when driven from other MCP clients, so this is the client's refresh handling, not the authorization server.

Expected

• Silent refresh_token grant before expiry; running session picks up the rotated token without re-auth or restart.

Related (same symptom family)

• Remote MCP OAuth: access token is not refreshed despite refresh token being present #34582 — refresh token present but never used, manual re-auth required after expiry
• MCP OAuth: opencode mcp auth doesn't refresh token in active sessions #21702 — running session keeps stale token after re-auth; only restart helps
• Remote MCP OAuth: browser never opens for re-authentication after session loss #16893 — restart loses OAuth state, no automatic re-auth flow

Happy to pull redacted mcp debug output if useful — token values stay with me.

[kgleason]

Adding a clean repro on OpenCode v2.0.18 that matches this issue and tightens the evidence: even a valid, freshly-refreshed access token on disk is not used by the running MCP connection — including after a full restart.

Server / auth setup

• Remote MCP: https://mcp.drata.com/mcp/
• OAuth via Auth0 (https://drata-prod.us.auth0.com/), OIDC
• Scope includes offline_access; access-token lifetime is 24h
• The Drata app authorization in the Drata UI is set to "Never expires" — that refers to the consent/grant, not the access token. The 24h access token still lapses and must be refreshed via the stored refresh token.

Timeline

1. Drata_listVendors started returning 401 Unauthorized (code: 10120) on every call.
2. Inspected ~/.local/share/opencode/mcp-auth.json: the cached accessToken had exp ~12 days in the past. The stored refreshToken (with offline_access) and clientInfo were intact.
3. Decoded the JWT: 24h lifetime, expired. So the symptom is an expired access token, not a revoked grant.
4. Ran a manual grant_type=refresh_token against Auth0's token endpoint using the stored refresh token + client credentials → HTTP 200, returned a fresh 24h access token. No refresh-token rotation; the original refresh token stayed valid.
5. Probed https://mcp.drata.com/mcp/ (MCP initialize) directly with the new bearer → HTTP 200. Same probe with the old expired bearer → 401. So the new token is valid and the old one is the sole problem.
6. Wrote the fresh token (new accessToken + expiresAt) back into mcp-auth.json, keeping the refresh token and client info unchanged.
7. Retried Drata_listVendors in the same session → still 401 (running connection holds the stale token in memory — matches MCP OAuth: opencode mcp auth doesn't refresh token in active sessions #21702).
8. Disabled and re-enabled the Drata MCP, then fully restarted OpenCode → still 401. The on-disk mcp-auth.json still contained the valid fresh token (exp 2026-09-29); OpenCode neither overwrote it nor consumed it.

opencode mcp list shows the server as ✓ connected while tool calls return 401
After the restart in step 8, opencode mcp list reports:

✓ drata       connected

…yet Drata_listVendors still returns 401 on every call. So mcp list's "connected" status only reflects the MCP-level handshake (which succeeds with the valid on-disk token for initialize), not whether the underlying API actually accepts the bearer for tool calls. This makes the failure invisible to any status check a user would reach for.

Diagnostic commands actually available on v2.0.18 (for anyone reproducing)

• opencode mcp list — server status (note: reports connected even when tool calls 401, per above)
• opencode mcp auth <server> — re-run the OAuth flow
• opencode mcp logout <server> — drop stored credentials
• opencode debug config / opencode debug paths — config sources and global paths (data/config/cache/state)
• Logs: opencode --log-level all --print-logs (server logs need --standalone)

(There is no opencode mcp debug subcommand on v2.0.18 — that command appeared in older issue reports.)

Two distinct failures visible in one repro

• No auto-refresh of the expired access token despite a valid refresh token + offline_access scope + client secret being present in mcp-auth.json (the Remote MCP OAuth: access token is not refreshed despite refresh token being present #34582 "fixed on V2" path — regressed or not covering this server).
• Running connection does not load the valid on-disk token, even after disable/re-enable and a full restart — stronger than the original report here, and implicating the never-actually-fixed MCP OAuth: opencode mcp auth doesn't refresh token in active sessions #21702 (stale-bot closed, no fix).

Environment: OpenCode v2.0.18, Linux, Drata MCP remote (Auth0 OIDC), 24h access-token lifetime, offline_access scope. Not posting tokens or credentials here; happy to provide redacted logs on request.

[holny]

I'll take this. The evidence lines up with the OAuth provider storing tokens at auth time but never wiring a refresh path: mcp-auth.json keeps both accessToken and refreshToken, the access token lives for tens of minutes, and nothing schedules or triggers a refresh when expiresAt passes — so every remote MCP session longer than one token lifetime hits the wall, and a restart re-reads the still-valid refresh token but surfaces needs_auth instead of using it.

Plan: on the remote MCP auth path, check expiresAt before (and on) 401, use the stored refresh token to mint a new access token, persist it back to mcp-auth.json, and retry the failed call once. Cover with a test that simulates expiry and asserts the refresh round-trip plus recovery without restart.

Fixes #49773

[manubhai04]

Another repro on v2.0.22 (macOS) with LaunchDarkly's remote MCP (https://mcp.launchdarkly.com/mcp/launchdarkly), plus one detail that matters for the fix.

What happens

• OAuth completes with hasRefreshToken=true expiresIn=7200 (credential row in opencode.db has refresh + expires).
• ~2h later every tool call fails, and opencode mcp logout launchdarkly, then manual re-auth via /mcps is the only fix. Happened 3× in one day.
• Log shows no refresh attempt between expiry (06:10Z) and my manual re-auth (09:07Z).

Detail: LaunchDarkly doesn't reject the request at the HTTP level. The JSON-RPC call succeeds and the tool result carries the error:

{"error":"LaunchDarkly access token has expired","code":"token_expired","status":401,"action":"reauthenticate"}

So OpenCode never sees an HTTP 401 and no refresh path triggers. A fix that only refreshes on a transport 401 (or only at connect time, as in the #34582 fix) won't cover servers like this. Refreshing proactively before expiresAt would.