MCP servers disconnect in one session when another session connects to the same MCP server

Resolved 💬 4 comments Opened Mar 26, 2026 by pavzagor Closed May 25, 2026

Problem

When running multiple Claude Code CLI sessions that use the same MCP server, opening a new session (or reconnecting MCP in one session) causes the MCP to silently disconnect in the other session. Tools that were working stop with "No such tool available" errors, and /mcp shows the server as disconnected.

Reproduction steps

  1. Open Claude Code session A with Notion MCP configured (via .mcp.json)
  2. Use Notion MCP tools successfully in session A (search, create pages, update pages)
  3. Open Claude Code session B in a separate terminal, same project, same .mcp.json
  4. Session B's Notion MCP connects successfully
  5. Return to session A and try any Notion MCP tool
  6. Result: Error: No such tool available: mcp__notion-medvidi__notion-update-page
  7. Running /mcp in session A confirms the server is now disconnected

Expected behavior

Both sessions should maintain independent MCP connections. Opening session B should not affect session A's active MCP connection.

Observed behavior

  • Affects Notion MCP (@anthropic-ai/notion-mcp-server) and PostHog MCP (mcp.posthog.com/mcp)
  • The disconnected session gets no warning or error -- tools silently vanish
  • /mcp reconnect in the affected session restores the connection, but may then disconnect the other session
  • Pattern suggests the MCP server process is being replaced rather than multiplexed

Environment

  • Claude Code CLI (latest)
  • macOS (Darwin 25.3.0)
  • MCP servers configured in project .mcp.json
  • Both stdio-based (Notion) and remote (PostHog) MCPs affected

Relation to existing issues

  • #21496 - Reports multiple CLI instances causing hangs from port contention, but focuses on startup, not mid-session disconnects
  • #15320 - Port conflict with mcp-remote at startup, closed as "not planned"
  • #15758 - Generic "MCP tools silently disappear" but doesn't identify multi-session as the trigger
  • #10071 - Auto-reconnect feature request (29 upvotes, open) -- would mitigate this but doesn't fix root cause
  • #27390 - Protocol instance reuse in Claude Desktop (59 upvotes, fixed Feb 2026) -- similar root cause but for Desktop, not CLI

Suggested fix

Each CLI session should spawn and manage its own independent MCP server process (for stdio MCPs) or maintain independent connections (for remote MCPs). Sessions should not share or replace each other's MCP connections.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗