claude.ai connector lost in Claude Code only after one failed token refresh; Reconnect in claude.ai does not restore it; `claude mcp list` still says Connected

What's Wrong?

A claude.ai connector (a remote OAuth MCP server I run, reached from Claude Code through the claude.ai proxy at api.anthropic.com/v2/ccr-sessions/<cse>/mcp?mcp_server_id=…) stopped working in every Claude Code session on the machine after the MCP server answered one token refresh with 401 invalid_client (a transient fault on my server, since fixed). From that moment on, each Claude Code session, including brand-new ones started hours later, offered only mcp__claude_ai_<Name>__authenticate and complete_authentication for that connector, while claude.ai web and cloud sessions kept using the same connector without interruption (my server log shows ~176 successful calls from claude.ai in the three hours the CLI was locked out).

Three things made this hard to diagnose and recover from:

1. Reconnecting the connector in claude.ai Settings did not restore it in Claude Code. The Reconnect ran a full OAuth sign-in against my server (authorize → Google → token), yet a brand-new Claude Code session 34 minutes later still had only the authenticate stub. The docs' setup steps for connectors say "Complete any required authentication steps in claude.ai", which suggests the web authorization is what Claude Code uses; nothing documents a separate per-surface state.
2. claude mcp list and claude mcp get reported ✔ Connected for the connector the whole time, and the in-session authenticate tool answered "This is a claude.ai MCP connector. Ask the user to run /mcp and select 'claude.ai <Name>' to authenticate." /mcp is a terminal-only dialog, unusable in sessions driven through Remote Control. This is the same symptom as #62479 (closed by the stale bot without a reply) and #72914.
3. The only thing that worked was undocumented: claude mcp login "claude.ai <Name>" --no-browser printed a claude.ai URL of the form https://claude.ai/api/organizations/<org>/mcp/start-auth/<mcpsrv id>?product_surface=sdk-cli. Opening it ran a second full OAuth flow with the identical client_id (https://claude.ai/oauth/mcp-oauth-client-metadata) and redirect_uri (https://claude.ai/api/mcp/auth_callback) as the web Reconnect, after which new Claude Code sessions got all the connector's tools. The 34 already-running sessions each needed a restart to pick it up.

So claude.ai appears to keep a per-surface "needs authentication" state for a connector: one failed refresh on a Claude Code request flagged the sdk-cli surface persistently, the web stayed fine, the web Reconnect did not clear the flag, and only the sdk-cli start-auth page did.

What Should Happen?

1. Re-authorizing a connector in claude.ai should restore it for every surface, or claude.ai Settings should show the per-surface state and offer the Claude Code re-enable there.
2. claude mcp list / /mcp should show Needs authentication (the real state) rather than Connected when the session only has the auth stubs.
3. One transient 401 on a token refresh should not drop the Claude Code surface permanently. Claude Code already tolerates this for OAuth servers it manages itself (docs: since v2.1.206 it "refreshes the stored token, reconnects, and retries the request once" before flagging); the claude.ai proxy path has no such tolerance.
4. For headless / Remote Control sessions, the authenticate stub or the startup notice should point at claude mcp login <name> --no-browser instead of /mcp, and the docs should say that this is the recovery for a claude.ai connector flagged on the Claude Code surface.

Error Messages/Logs

In-session tool list for the connector (every session, including new ones, for ~4 hours):

mcp__claude_ai_Stackshot__authenticate
mcp__claude_ai_Stackshot__complete_authentication

Calling authenticate:

This is a claude.ai MCP connector. Ask the user to run /mcp and select 'claude.ai Stackshot' to authenticate.

claude mcp list at the same time:

claude.ai Stackshot: … - ✔ Connected

claude mcp login "claude.ai Stackshot" --no-browser output (ids elided):

https://claude.ai/api/organizations/<org>/mcp/start-auth/mcpsrv_…?product_surface=sdk-cli
… available the next time you start Claude Code

My MCP server's access log (times KST, Sat/Sun Oct 3–4 2026), the two sign-ins carrying the same client_id and redirect_uri:

00:02:28  POST /token            401   (one failed refresh from claude.ai; transient server-side fault)
03:10:39  GET  /authorize        302   (Reconnect pressed in claude.ai Settings)
03:11:02  POST /token            200
03:44     new Claude Code session: still authenticate-only
03:54:38  GET  /authorize        302   (the sdk-cli start-auth link from `claude mcp login`)
03:54:50  POST /token            200
03:57     new Claude Code session: all 11 tools present

~/.claude/.credentials.json → mcpOAuth never held an entry for this connector, before or after (other claude.ai connectors do have entries).

Steps to Reproduce

1. Add an OAuth remote MCP server as a connector in claude.ai; authorize it there; confirm it appears in Claude Code as claude.ai <Name> with its tools (works, no CLI sign-in needed).
2. Make the MCP server answer one token refresh (POST /token, grant_type=refresh_token) with 401 invalid_client, then behave normally again.
3. Start a new Claude Code session → the connector offers only authenticate / complete_authentication; claude mcp list says ✔ Connected. claude.ai web keeps working with the connector.
4. In claude.ai Settings → Connectors, Reconnect the connector (full OAuth flow completes). Start a new Claude Code session → still authenticate only.
5. Run claude mcp login "claude.ai <Name>" --no-browser, open the printed product_surface=sdk-cli link, complete it. Start a new Claude Code session → tools are back. Already-running sessions stay broken until restarted.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

n/a

Platform

Linux (Ubuntu Server), Claude Code 2.1.288, claude.ai subscription login (Team plan), sessions driven via Remote Control. Related: #62479, #72914. Also sent via /feedback (receipt 7bbbbf04-6827-4f9d-9b1f-d3421fc99832).