MCP servers disconnect in one session when another session connects to the same MCP server
Status Fixed / completed
Maintainer reply ✓ Yes — localden
Workaround ✓ Mentioned in thread ↓
Activity 5 comments · opened Mar 26, 2026 · closed May 25, 2026
💡 Likely answer: A maintainer (localden, collaborator)
responded on this thread — see the highlighted reply below.
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
- Open Claude Code session A with Notion MCP configured (via
.mcp.json) - Use Notion MCP tools successfully in session A (search, create pages, update pages)
- Open Claude Code session B in a separate terminal, same project, same
.mcp.json - Session B's Notion MCP connects successfully
- Return to session A and try any Notion MCP tool
- Result:
Error: No such tool available: mcp__notion-medvidi__notion-update-page - Running
/mcpin 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
/mcpreconnect 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-remoteat 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.
5 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
hit this running parallel Claude sessions across git worktrees. two causes mixed together. for stdio MCPs the singleton lock is usually inside the server itself not claude code, many community servers write a pidfile or bind a named unix socket and the second instance either hijacks the fd or silently fails. for remote OAuth MCPs like posthog it's refresh token rotation, session B refreshes, server invalidates the prior access token, session A gets 401 which claude code reports as disconnect. workaround that worked for us is per-session MCP data dir via env var plus a local multiplexing proxy for the OAuth servers. notion specifically caches auth globally which makes the symptom worse.
Fixed — ships in v2.1.136.
Note: the stdio half of the report isn't covered by this fix — please reopen if a stdio-only repro persists on ≥2.1.136.
Thanks for the report. The remote/OAuth half of this shipped in v2.1.136 (per the comment above). Closing this; if you still see the multi-session disconnect with stdio-only servers on a current build, please open a new issue with the stdio repro.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.