Claude Desktop spawns duplicate generations of local MCP server processes without terminating the previous generation

Claude Desktop spawns duplicate generations of local MCP server processes without terminating the previous generation

Summary

Claude Desktop (macOS) spawns a complete second generation of all configured local MCP server child processes shortly after launch, without killing the first generation. Both generations remain alive indefinitely. The app closes the first generation's transports (visible in mcp.log) but never terminates the underlying OS processes, leaking them. Duplicate live clients then collide on downstream resources — reproducibly breaking WordPress-based MCP servers with -32603 "WordPress connection failed during initialization" — and correlate with broader local-MCP unreliability (4-minute tool-call hangs across unrelated servers).

Environment

• macOS 26.5.1 (25F80), Apple Silicon (arm64)
• Claude Desktop (current as of 2026-07-07), Max plan
• Local MCP servers configured: podio (local node script), 3× @automattic/mcp-wordpress-remote (npx), chrome-devtools-mcp (npx), n8n-mcp (npx), @modelcontextprotocol/server-filesystem (npx), mcp-remote ×2 (Rocket.net, custom), plus bundled servers
• Node v22.22.0 via nvm
• No VPN or network system extensions present (systemextensionsctl list → 0 extensions), SIP enabled

Reproduction (observed on two separate boots, same day)

1. Cold boot the machine (or fully quit Claude Desktop).
2. Launch Claude Desktop with multiple local MCP servers configured.
3. Within ~30 seconds to a few minutes, inspect processes:

``
ps -eo pid,ppid,lstart,command | grep -E "podio-mcp|wordpress-remote|chrome-devtools-mcp|n8n-mcp" | grep -v grep
``

1. Observe two distinct start-time clusters of the same server set, all parented by the single Claude Desktop main process.

Instance A (first observation, same app launch)

Single Claude Desktop instance PID 57836 (launched 17:52:02 PDT). Two full child generations alive simultaneously:

• Generation 1: 17:53:11 (2× podio wrapper/node, 3× wordpress-remote, chrome-devtools, n8n, filesystem, 2× mcp-remote)
• Generation 2: 18:01:37–38 (complete duplicate set)

mcp.log shows the trigger moment — at 2026-07-08T01:01:37–40Z (18:01:37–40 PDT) every server logs Client transport closed / Server transport closed, immediately followed by generation 2 spawning. Transports were closed; processes were not killed.

Instance B (fresh cold boot, ~4 hours later, after full machine cleanup)

Claude Desktop launched 21:44 PDT after reboot:

• Generation 1: 21:44:52 — podio + 3× wordpress-remote (all disclaimer-wrapped, parented by the Desktop main process)
• Generation 2: 21:45:18 — 26 seconds later: duplicate podio + 1× wordpress-remote, gen 1 still alive

Full ps listings for both instances available on request.

Downstream breakage (why this matters)

1. WordPress MCP servers fail initialization when a duplicate client already holds the session. mcp-server-<name>.log shows repeated:

``
[ERROR] [CLIENT] ❌ Client Error: ListTools failed after 0ms
{ "error": "MCP error -32603: Cannot process tools/list: WordPress connection failed during initialization" }
``
In Instance B, the two WordPress servers that errored at 21:35–21:44 PDT are exactly the ones missing from generation 2 — consistent with gen-1 processes still holding their sessions.

1. Correlates with the "4-minute hang" failure mode. Across multiple sessions (July 2, July 7; detailed contemporaneous incident reports available), tool calls to unrelated local servers (Chrome extension bridge, Podio, Rocket.net) hung for a fixed ~4 minutes and returned "No result received from the Claude Desktop app," in a works-once-after-restart-then-dies pattern. A broker routing requests to a stale/leaked server generation would produce exactly this signature. Correlation, not yet proven causation — but the leak is the only anomaly found after eliminating all machine-local factors (VPN network extension removed, SIP cycle, clean reboot, no memory pressure).

1. Resource waste: every leaked generation holds node/npm processes and npx caches; users switching accounts (which forces server respawns) may accumulate multiple leaked generations per day.

Expected behavior

When Claude Desktop closes a server's transport and respawns it (config reload, account switch, or the post-launch respawn observed here), the previous child process tree should be terminated (SIGTERM, then SIGKILL after grace).

Additional diagnostic gap worth noting

While diagnosing this, we also hit the Claude for Chrome pairing service returning an empty browser list for ~30 minutes with zero diagnostics when the extension's signed-in account did not match the chat session's account. An explicit "browser connected under a different account" signal would have saved substantial time. Happy to file separately if preferred.

Support history

For the record: this was reported to Anthropic customer support with all five incident reports attached, across multiple contacts. The refund/credit request was declined per policy, and the response noted that the technical reports "may be valuable for our development teams to address these problems." Filing this issue myself so that they actually reach one. Three days of a paying customer's Max-plan tokens went into producing the diagnosis below — the least it can do is get triaged.

Attachments available on request

• Full ps -eo pid,ppid,lstart,command listings for both instances
• mcp.log excerpt showing the mass transport-close + respawn event
• mcp-server-fluent-crm.log / mcp-server-novamira-*.log -32603 excerpts (July 1–8)
• Five contemporaneous incident reports covering the July 2–7 failure sessions