[Feature]: Let Claude agents sign in to MCP servers that need authentication

[hieu-lee]

Problem

Claude Code's /mcp → Authenticate flow is interactive, and T3 Code drives Claude through the non-interactive Agent SDK. When an OAuth MCP server's login expires, or a claude.ai connector shows needs-auth, a Claude thread cannot sign in again. The user has to open a terminal, run claude, then /mcp, and restart the T3 Code thread. Related reports: #33755, #19471, #20298 (all closed) and the broader inspect-and-control request in #10535. The original issue for this proposal, #34117, was closed as a feature request.

Proposal

Let the agent sign in for the user. The user's only step is the browser login.

• One new T3 MCP tool, t3_mcp_server, with action: list (server names and status), authenticate (returns the sign-in link for the agent to show), callback (finishes sign-in from a pasted redirect URL, for when the user's browser cannot reach the machine running the CLI), and reconnect.
• It is a thin pass-through to control requests the Claude CLI already serves headlessly: mcp_status, mcp_authenticate, mcp_oauth_callback_url, mcp_reconnect. T3 Code keeps no OAuth state, tokens, or listeners. The CLI holds the pending sign-in and reconnects the server itself when it finishes.
• It follows the existing awaitBackgroundTasks and mcpApps shape: an optional operation on the provider session runtime, reached from a service method, so providers without it report "unsupported". Claude and Codex implement it. Cursor, Grok, OpenCode and Antigravity are out of scope here.
• Cost: no new work on the turn hot path, no polling, no new long-lived state. The tool is deferred behind ToolSearch in Claude, so each session pays for one extra tool name. list returns only name and status, not each server's tool list or error text, which can echo headers.
• Not included: a Settings or command-palette entry. This is agent-only. A UI for it could follow, and [Feature]: /mcp view to inspect and control each MCP server #10535 covers that direction.

Open questions for maintainers

1. Is an agent-facing tool the right direction, or would you rather have a UI surface first, or both?
2. mcpAuthenticate and mcpSubmitOAuthCallbackUrl exist at runtime in @anthropic-ai/claude-agent-sdk but are missing from its type declarations, so the adapter sends the control requests directly, as it already does for mcp_call. Is depending on that acceptable?

A working implementation with tests is open as a PR (below); direction is still open for discussion.

Update: Codex has the same problem

Codex threads are affected too: T3 drives the app-server and never calls its mcpServer/oauth/login, so a logged-out MCP server needs codex mcp login in a terminal. The same tool covers it, with mcpServerStatus/list, mcpServer/oauth/login and config/mcpServer/reload. Codex finishes sign-in in its own loopback listener, so it has no callback action (it needs a browser on the environment's machine), and reconnect reloads all servers for the next turn. The callback wording above is Claude-only.

Implementation: #34124

[hieu-lee]

PR is up and ready for review: #34124

It covers Claude and Codex (Codex has the same gap; its sign-in finishes in its own loopback listener, so no callback action there). The only red check is Agent context budget (+584 bytes for the new tool), which needs the agent-context-increase label. Direction feedback on the two open questions in the post above is still welcome.