[Feature] Reconnect/restart MCP servers from Claude Code in Claude Desktop without Cmd+Q (expose /mcp UI or auto-reconnect)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/45399
2. https://github.com/anthropics/claude-code/issues/40059
3. https://github.com/anthropics/claude-code/issues/46426

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Not a duplicate of any of the three flagged issues. To save a maintainer the round-trip:

#45399 asks for general slash-command parity in Desktop (/btw, /compact, /diff, etc.). This issue isn't asking for /mcp as a slash command — it's asking for any MCP-reconnect affordance in Desktop. A button, a menu item, auto-reconnect, or a slash command would all close it. If #45399 ships tomorrow and /mcp becomes available as a slash command in Desktop, that's one possible fix here, but it's not the only one and not the broader ask. I cited #45399 in the body as related for exactly this reason.

#40059 and #46426 are both CLI-focused asks for a /mcp reload command that re-reads .mcp.json and picks up config changes (added/removed servers). This issue is about recovery from a failed/disconnected MCP server in the Desktop UI — a separate axis. A user hits this even when their config is fine: stdio transport closes after idle (#43177), OAuth token expires (#43789), server crashes. The CLI already has /mcp reconnect for these cases; the gap is that Desktop has no equivalent surface. Hot-reloading config (the #40059/#46426 ask) wouldn't fix a stuck-but-correctly-configured MCP, and exposing /mcp reconnect in Desktop wouldn't pick up new config entries.

Concretely, the three asks are orthogonal:

| Need | #45399 | #40059 / #46426 | This issue |
|---|---|---|---|
| Slash-command parity in Desktop | ✓ | | |
| Hot-reload .mcp.json config diffs (CLI) | | ✓ | |
| Reconnect a stuck/failed MCP from Desktop UI (no Cmd+Q) | | | ✓ |

Leaving open. 👎'd the auto-bot per its instructions to prevent auto-closure.

+1 — reproducing the same dispatch failure on macOS across three consecutive subprocess instances in a single log, including one after 18 hours idle and two within a single chat session. None of them received a tools/call despite tool calls being attempted from the UI. Corroborates #43177 as the root cause.

Setup

Custom stdio MCP for Gmail (@gongrzhe/server-gmail-autoauth-mcp via npx), used by a daily triage workflow that needs the label-write operations the built-in Gmail connector doesn't expose. Claude Desktop on macOS Apple Silicon (no Claude Code integration in the loop — confirms the bug isn't specific to that path), Node v18.20.8 (nvm). Client identifies as claude-ai v0.1.0 in the handshake; server as gmail v1.0.0.

• Claude Desktop version: Claude 1.7196.3 (ca0c62) 2026-05-16T23:42:08.000Z
• macOS version: 15.7.5

Reproduction — three subprocesses, zero tools/call dispatched to any of them

Sanitized excerpts from ~/Library/Logs/Claude/mcp-server-gmail.log:

````
=== HISTORICAL CONTEXT ===

May 15, ~03:16–03:33 UTC: 100-call triage run completed cleanly. Final entry:
2026-05-15T03:33:12.362Z [gmail] [info] Message from server: {"jsonrpc":"2.0","id":100,"result":{"content":[{"type":"text","text":"Batch label modification complete.\nSuccessfully processed: 1 messages\n"}]}} { metadata: undefined }

May 18, ~15:30–15:32 UTC: 7-call run completed cleanly. Final entry:
2026-05-18T15:32:35.942Z [gmail] [info] Message from server: {"jsonrpc":"2.0","id":7,"result":{"content":[{"type":"text","text":"Batch label modification complete.\nSuccessfully processed: 16 messages\n"}]}} { metadata: undefined }

=== SUBPROCESS #1 — alive ~18 hours, received zero tools/call ===

May 18 20:34:08.878 UTC — Initializing server...
May 18 20:34:08.954 UTC — Using MCP server command: /Users/[USER]/.nvm/versions/node/v18.20.8/bin/npx @gongrzhe/server-gmail-autoauth-mcp
May 18 20:34:08.954 UTC — Server started and connected successfully
May 18 20:34:09.275 UTC — Message from client: initialize (protocolVersion 2025-11-25)
May 18 20:34:10.445 UTC — Message from server: initialize response (protocolVersion 2024-11-05) — DOWNGRADE
May 18 20:34:10.450 UTC — Message from client: notifications/initialized
May 18 20:34:10.451 UTC — Message from client: tools/list (id 1)
May 18 20:34:10.460 UTC — Message from server: tools/list response (19 tools)

[silence from May 18 20:34:10 UTC to May 19 14:47:46 UTC — ~18 hours, 13 minutes, zero tools/call]

May 19 14:47:46.589 UTC — Client transport closed
May 19 14:47:46.589 UTC — Server transport closed (intentional shutdown)

=== SUBPROCESS #2 — fresh start, init + tools/list, then renderer disconnect; zero tools/call ===

May 19 14:47:54.090 UTC — Initializing server...
May 19 14:47:54.111 UTC — Server started and connected successfully
May 19 14:47:54.174 UTC — Message from client: initialize (protocolVersion 2025-11-25)
May 19 14:47:55.455 UTC — Message from server: initialize response (protocolVersion 2024-11-05) — DOWNGRADE
May 19 14:47:55.455 UTC — Message from client: notifications/initialized
May 19 14:47:55.456 UTC — Message from client: tools/list (id 1)
May 19 14:47:55.459 UTC — Message from server: tools/list response (19 tools)

[silence ~1m 21s. Tool call attempted from chat UI during this window; never appears in log.]

May 19 14:49:16.350 UTC — Client transport closed
May 19 14:49:16.350 UTC — Server transport closed (renderer released port) ← different from "intentional shutdown"

=== SUBPROCESS #3 — immediate respawn 250ms later, same pattern; zero tools/call ===

May 19 14:49:16.600 UTC — Initializing server...
May 19 14:49:16.601 UTC — Server started and connected successfully
May 19 14:49:16.655 UTC — Message from client: initialize (protocolVersion 2025-11-25)
May 19 14:49:17.812 UTC — Message from server: initialize response (protocolVersion 2024-11-05) — DOWNGRADE
May 19 14:49:17.813 UTC — Message from client: notifications/initialized
May 19 14:49:17.813 UTC — Message from client: tools/list (id 1)
May 19 14:49:17.816 UTC — Message from server: tools/list response (19 tools)

[end of log]

````

Smoking gun: grep tools/call across the full log after 2026-05-18 20:34:10 UTC returns no matches. Three subprocesses spawned successfully by Claude Desktop, all completing initialize + tools/list, none receiving a single tools/call. The dispatch failure reproduces on every fresh subprocess — not just after long idle.

Exact error in chat:

Gmail MCP hung on the first call — this is the known issue where the connector locks up and needs a Claude Desktop restart. I haven't been able to fetch a single label or any inbox data.
Quick fix: Cmd+Q on Claude Desktop, reopen, start a fresh chat, and run "triage my email" again. A clean session resets the connector.

cc #43177 (root cause + one-line fix identified)

Concrete use-case from a production deployment — adds reproducible signal for the missing capability.

Context

We run ~16 MCP servers (Cloudflare Workers + cloudflared-routed) via project-level .mcp.json. Today we shipped an architectural cleanup (PR removing per-brand URL suffix → routing brand/tenant via BEARER_BRAND_MAP KV inside the wrapper). The PR landed cleanly, but every running Claude Code CLI session held a stale MCP client connection to the OLD URL (now dead), and tools went silently unavailable mid-session.

What we tried

• /mcp panel manual retry — retries the cached URL, doesn't re-read .mcp.json
• /reload-plugins — N/A for project-level .mcp.json (only fires for plugin MCP servers)
• Auto-reconnect exponential backoff (5 attempts) — uses cached URL, marks server failed after 5
• Community workaround kill -HUP $PPID — risks conversation-state loss

What we needed

A /mcp reload (or /mcp reconnect <server>) that re-reads .mcp.json for the named server and re-initializes the client against the (possibly new) URL — without restarting the whole REPL or losing conversation state.

Why it matters in production

Stable URLs in .mcp.json is now an architectural rule we documented internally (treat URL changes as session-restart events). But:

1. Operational pain: in-flight subagent fan-outs (/skill-creator 6-runs eval, /feature-dev 3-explorer phase) can't be re-run cheaply on session restart. A 30-60min eval that just landed Phase 1 gets restarted from zero.
2. Recovery from misconfiguration: every team will eventually edit a .mcp.json URL by accident or for a real architectural cleanup. The blast radius is "kill every running session in the org" today.

A 5-line slash command + the existing MCP client init path closes this. Bundling it with /mcp panel surface ("[Failed: 5 retries exhausted] — re-read config from .mcp.json?") would be ideal UX.

Happy to test if you ship a prerelease.

+1. Confirming on Windows (Claude Desktop with embedded Claude Code, CC v2.1.156), with the config-change trigger rather than the idle-disconnect one:

My setup is several concurrent Claude Code sessions in the Desktop app. When I add an MCP server from one session, there's no per-pane way to pick up the new tools — in the terminal I'd just close and reopen that one tab and every other session kept running, but in Desktop the only reliable reset is fully quitting and relaunching the app, which tears down every session, including ones mid-task. So adding a server in one session blocks me from testing it until all my unrelated sessions happen to hit a stopping point.

What makes this especially frustrating: the CLI already does the right thing — v2.1.139 made /mcp Reconnect re-read .mcp.json without a restart. The gap is purely that /mcp (per your point, and #45399) isn't reachable from the Desktop pane, so that existing capability can't be used here. Option (1) — exposing /mcp / a clickable reconnect in the Desktop pane — would fully close this for me. #53298 is also in scope, since servers added at user scope (~/.claude.json) are common and currently have no reconnect path at all.

Adding a Windows data point too — this is currently labeled macOS-only, but the behavior is identical here.

Adding a data point that might help others hit this:

We ran into this exact pattern: local stdio MCP server (PHP, not Node, but same shape), process stays alive and healthy, but Claude Desktop tears down the transport after 60 seconds of no tool calls. Confirmed via logs that it's the client closing the connection, not the server crashing. The process is sitting there waiting on stdin the whole time.

We tried the usual suspects first (raising execution time limits, full binary paths, testing the exact launch command manually and via launchctl to rule out environment differences). None of those made a difference, since manually-run tests never hit the timeout in the first place... we were sending input ourselves, so there was never a real idle gap.

What fixed it for us was changing the server's main read loop from a blocking read to one with a timeout (something like select()/poll() on stdin, whatever your language's equivalent is), and when that timeout fires with no input, having the server proactively send a ping request to the client rather than staying silent, something like:

{"jsonrpc": "2.0", "id": "heartbeat-<timestamp>", "method": "ping"}

We set the timeout to 30 secs (comfortably under Desktop's 60 sec cutoff) and haven't seen a disconnect since, including sitting idle for 20+ minutes.

Note that this treats the disconnect as an idle/liveness check rather than a per-request timeout, since our heartbeat isn't a response to anything pending. It's unsolicited traffic sent purely to keep the connection alive. That theory held up for us, though not sure if it generalizes to every transport/SDK combo people are hitting in this thread. But if your server implementation controls its own read loop, it might be worth trying before resorting to Cmd+Q every time.

Configurable timeout or auto-reconnect on Desktop's side (per the feature request above) would be better than servers having to work around this, but this got us unblocked in the meantime.