[Bug]: Claude threads cannot use an MCP server again after it is re-authenticated mid-session#19471

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Closest existing reports: #5437 and #6162 (per-thread "Reload agent session"; the PR was closed until the V2 provider rewrite), #10955 (Stop kills the Claude CLI and --resumes), and anthropics/claude-code#81042 (the same limit in Claude Code, closed as not planned).

Area

apps/server

Steps to reproduce

1. Configure an OAuth HTTP MCP server for a project, for example https://mcp.linear.app/mcp in .mcp.json.
2. Start a Claude Code thread in that project while the server needs authentication. One way: let the OAuth grant expire. Linear's hosted MCP ends each grant 25 days after login.
3. In a terminal claude session that uses the same config directory, run /mcp and authenticate the server. The result is Authentication successful. Connected to <server>.
4. Send a new message in the T3 thread.

Expected behavior

The thread can use the server again without losing its conversation. For example, a thread action or an agent-callable tool reconnects one MCP server in the live session.

The Agent SDK that T3 bundles already supports this on the Query object: reconnectMcpServer(serverName), and mcpAuthenticate(serverName, redirectUri) with mcpSubmitOAuthCallbackUrl(serverName, callbackUrl) for a login from inside the thread. A reconnect in place also keeps the prompt cache, which a Stop and --resume rewrites (#10955).

Actual behavior

The thread does not get the server's tools back. The new tokens are in the shared credential store, and every new claude process connects with them. But the thread's running process connected its MCP servers once, at start, and nothing tells it to reconnect.

At main @ 7ac952c, apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts:788-797 sends T3's own MCP servers over the control channel with queryRuntime.setMcpServers(mcpServers). No code in the repository calls reconnectMcpServer, mcpAuthenticate, or mcpSubmitOAuthCallbackUrl. The bundled 0.0.46-nightly.20261013.3066 binary has the same three methods and no call sites.

This happens with each project that has its own Linear workspace server. Each grant lapses on its own 25-day schedule, so it happens regularly.

Impact

Major degradation or frequent failure

Version or commit

0.0.46-nightly.20261013.3066; code read at main @ 7ac952c

Environment

Ubuntu Linux (kernel 7.0.0), T3 Code server via the t3 CLI on Node 24.20.0, Claude Code 2.1.299, Claude Opus 5.5

Logs or stack traces

Claude Code MCP log (~/.cache/claude-cli-nodejs/<project>/mcp-logs-<server>/) of the process that lost the server. Its refresh failed when the grant expired, so it cleared the tokens:

A thread that T3 resumed in a new process (--resume=<session>) connects again at start:

Workaround

1. Authenticate the server in a terminal with /mcp.
2. In the T3 thread, send any message and press Stop while the turn runs. Stop closes the CLI (#10955).
3. Send the real message. T3 resumes the conversation in a new process, which connects with the new tokens.

Do the steps in this order. A thread that restarts before you authenticate skips the server again. The first turn after the Stop rewrites the full prompt cache.