[BUG] MCP plugin install floods all sessions with OAuth prompts; new sessions always re-authenticate

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Installing an MCP plugin (OAuth-protected, deployed on GCP Cloud Run) immediately triggers OAuth browser popups in every active Claude Code / Cursor session — not just the session where the plugin was installed.

Additionally, each new Cursor session requires full re-authentication for every OAuth-protected MCP server. Tokens obtained in one session are not reusable in another.

This makes OAuth-protected MCP servers impractical for daily multi-session use.

Two behaviors cause this:

1. Eager connection: Claude Code connects to all enabled MCP servers on session startup (or plugin install), triggering auth immediately — before the user has invoked any tool.
2. Per-session credential isolation: Each session maintains its own credential store (~/.mcp-auth/). Tokens from one session cannot be reused by another, even for the same user on the same machine.

What Should Happen?

1. Lazy connection: MCP servers should not trigger OAuth until the user actually invokes a tool from that server. Tool metadata for autocomplete can be served from cache or from a prior connection.
2. Global token sharing: Credentials for user-scoped MCP servers should be shared across all sessions on the same machine (and ideally across remote-ssh sessions for the same user).
3. Auth queuing: When multiple sessions need auth for the same server, authenticate once and distribute the token — don't race N parallel OAuth flows.
4. Install-but-disabled state: Allow plugins to be installed without immediately connecting, letting the user enable and authenticate in a single session first. Why is there still no "disabled by default" option???

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

Scenario 1: Plugin install flood

1. Open 5 Cursor windows (5 projects) with >=1 Claude Code session per project
2. Install a new MCP plugin backed by an OAuth-protected Cloud Run server (e.g., FastMCP + Google OAuth)
3. All 5 Cursor and Claude Code sessions simultaneously open browser popups for authentication
4. User must complete or dismiss all separate OAuth flows for the same server; if the user dismisses, then the prompts are quickly repeated

Scenario 2: New remote-ssh session

1. Have 6 MCP plugins installed and authenticated in a local Cursor session
2. Open a new Cursor window via remote-ssh to the same machine
3. All 6 MCP servers prompt for re-authentication (6 browser popups)
4. Repeat for each new remote-ssh window opened

Scenario 3: Session startup re-auth

1. Have MCP plugins installed and previously authenticated
2. Close and reopen a Cursor window
3. MCP servers with expired tokens immediately trigger browser popups before the user types anything

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.91

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Cursor

Additional Information

Partial FastMCP contribution

Part of this problem stems from FastMCP's OAuthProxy design:

• Per-session DCR isolation: Each client session registers as a new OAuth client via Dynamic Client Registration, receiving a unique client_id. Tokens are bound to that client_id and cannot be reused. (We've filed a separate issue on PrefectHQ/fastmcp.)
• No lazy auth: FastMCP's RequireAuthMiddleware rejects all unauthenticated requests, forcing auth on connection rather than on tool use (PrefectHQ/fastmcp#3291).

However, the eager connection behavior on plugin install/session start and the per-session credential isolation are Claude Code behaviors that compound the problem.