[BUG] Remote HTTP MCP server's tools disappear after the access token expires and the client re-authorizes; only exiting and resuming restores them

What's wrong

During a long session with a remote MCP server connected over the native HTTP transport ("type": "http", OAuth with Dynamic Client Registration), the server's tools vanish from the session after its access token expires and the client re-authorizes.

• Re-authorization completes, and the session continues.
• The server's mcp__<server>__* tools are no longer in the session's tool list, and the model stops offering them. No error is shown, so the user notices only when the agent reasons about tools it can no longer call.
• Re-authorizing again does not bring them back.
• Exiting Claude Code and resuming the same conversation brings them back at once.

One user hit this repeatedly over several days of multi-hour Claude Code agent sessions. A second user of the same server reported a related case after a server-side change to the tool set: the new tools stayed invisible after a token refresh and appeared only after a full disconnect and reconnect of the MCP server (the client version was not recorded).

What should happen

After a successful re-authorization, the client fetches tools/list again (or keeps the tool list it already had) and the server's tools stay available in the running session, without exiting and resuming.

Why this looks client-side

The server cannot produce this state on its own:

• It runs stateless streamable HTTP: it issues no Mcp-Session-Id, keeps no session between requests, and has no server-to-client stream (GET on the MCP endpoint is 405).
• Its initialize result advertises {"tools": {}} with no listChanged, and it never sends notifications/tools/list_changed. The client therefore gets no signal from the server to re-fetch, and none to drop tools either.
• Its tools/list always answers with the full tool list, or with 401 when the bearer is missing or rejected. There is no path that returns an empty or partial list to an authenticated request.

So the tool surface appears to be dropped by the client when auth is refreshed, and tools/list is not called again until the process restarts.

A related cue: in the same client, a remote HTTP server whose authentication is pending shows only the client-synthesized mcp__<server>__authenticate and mcp__<server>__complete_authentication tools. The state described here looks like the client keeps that reduced surface after re-authorization succeeds, instead of replacing it with the server's tools/list.

Steps to reproduce

Works with any remote HTTP MCP server that uses OAuth and short-lived access tokens.

1. Configure a remote MCP server with "type": "http", OAuth (Dynamic Client Registration), and a short access-token lifetime (for example 5 to 15 minutes). A stateless server that does not advertise tools.listChanged makes the case clearest.
2. Start a Claude Code session, authenticate, and confirm the server's mcp__<server>__* tools are listed and callable.
3. Keep the session open past the token's expiry, then trigger a call to one of the server's tools. The server answers 401 with WWW-Authenticate: Bearer error="invalid_token".
4. Re-authorize when prompted (the synthesized authenticate tool, or /mcp then Authenticate) and let it complete.
5. Ask the agent to use the server's tools again, or inspect the tool list.
6. Exit Claude Code and resume the same conversation (claude --resume).

Expected: after step 4 the server's tools are available in the running session.

Actual: after step 4 the server's tools are missing from the session and stay missing across further re-authorizations. After step 6 they are back.

Environment

• Transport: native HTTP ("type": "http"), not mcp-remote.
• Auth: OAuth 2.0 with Dynamic Client Registration, short-lived access tokens.
• Server: stateless streamable HTTP, JSON responses, tools capability without listChanged.
• Claude Code version: not captured for the reports so far. The server now records the client's User-Agent on every request, including the 401 and the tools/list requests around a re-authorization, so the affected client versions and the request sequence after re-auth can be added here in a follow-up comment.

Related

• #10250 (closed): OAuth succeeds but MCP reconnection fails and requires a restart.
• #76939 (closed, not planned): HTTP MCP server drops to the bootstrap tools when the access token expires.
• #82246 (open): connector tools disappear during a long conversation and return only in a new conversation.