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

Update: root mechanism identified — the app runs two concurrent initialization sequences per launch.

Further log analysis on the same machine (fresh boot, no VPN/network extensions, SIP enabled) shows this is not a teardown/respawn failure — main.log records the entire startup sequence executing twice in parallel within a single Desktop launch. Every init line at 21:44:48–49 PDT is duplicated:

2026-07-07 21:44:48 [info] [Chrome Extension MCP] Installed native host manifest for Chrome at <home>/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
2026-07-07 21:44:48 [info] [Chrome Extension MCP] Installed native host manifest for Chrome at <home>/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_browser_extension.json
2026-07-07 21:44:48 [info] [Chrome Extension MCP] Native host sync complete
2026-07-07 21:44:48 [info] [Chrome Extension MCP] Native host sync complete
2026-07-07 21:44:48 [info] [Chrome Extension MCP] Watching Chrome for extension changes
2026-07-07 21:44:48 [info] [Chrome Extension MCP] Watching Edge for extension changes
2026-07-07 21:44:48 [info] [claude-in-chrome] MCP server registered
2026-07-07 21:44:48 [info] [Chrome Extension MCP] Watching Chrome for extension changes
2026-07-07 21:44:48 [info] [Chrome Extension MCP] Watching Edge for extension changes
2026-07-07 21:44:48 [info] [claude-in-chrome] MCP server registered
2026-07-07 21:44:49 [info] Starting periodic extension update checks (interval: 21600000ms)
2026-07-07 21:44:49 [info] Starting periodic extension update checks (interval: 21600000ms)
2026-07-07 21:44:49 [info] [RemotePluginManager] Starting remote plugins sync
2026-07-07 21:44:49 [info] [RemotePluginManager] Starting remote plugins sync
2026-07-07 21:44:49 [info] [RemotePluginManager] Starting periodic sync (interval: 600000ms)
2026-07-07 21:44:49 [info] [RemotePluginManager] Sync already in progress, waiting...

Note the last line — one init path detecting its twin ("Sync already in progress, waiting..."). The two MCP server generations observed in the original report (spawned at 21:44:52 and 21:45:18, both parented by the same main process) are consistent with these two init sequences each spawning the full configured server set.

Mid-session accretion: the RemotePluginManager periodic sync runs every 600000ms (10 min). In the first documented instance, generation 2 spawned ~8.5 minutes after generation 1 — consistent with the first periodic sync respawning servers without reaping. Additional single MCP server processes continued to appear during the session (23:54, 00:12, 00:22, 00:24) while earlier generations stayed alive, so the process table grows monotonically with app uptime.

Suggested areas to check:

1. Why two initialization contexts run concurrently at launch (race between two windows/renderers triggering main-process init, or duplicated lifecycle event registration).
2. Whether RemotePluginManager periodic sync respawns local MCP servers without terminating the prior child process tree.

Same reproduction environment as the original report; full logs available on request.

This looks like a lifecycle ownership bug more than a transport bug: closing stdio/SSE transport is not the same thing as reaping the child process that owns the MCP server.

A robust fix would make each MCP server generation explicit:

• assign a generation id per Desktop launch / config reload
• keep pid + command + transport id together in one lifecycle record
• on reload, close transport, send SIGTERM to the old generation, wait, then SIGKILL after a short grace period
• only start the replacement generation after the old generation is gone, or mark intentional overlap as such

The downstream collisions here are exactly why duplicate MCP clients are dangerous: many servers hold external state (WordPress auth, browser sessions, local files, payment/API credentials) and are not idempotent when two identical clients initialize at once.

For debugging, a claude://mcp/processes or log section that prints active MCP generations would make this immediately visible: server name, pid, parent pid, start time, transport state, and config hash. Right now the logs prove the transport closed but not whether process ownership was cleaned up.

Confirming your read with process-table evidence: ownership is never cleaned up. After the transports closed (logged at 01:01:37Z), the prior generation's processes remained alive for hours, still parented by the live Desktop main process — not orphaned, not reaped. On the most recent launch, the duplicate pair spawned 13 seconds apart (00:47:20 / 00:47:33 local), and additional single server processes continued to accrete afterward (00:47:37, 00:48:15) with all earlier ones still running. Process count grows monotonically with app uptime.

Can also confirm the overlap is unintentional rather than a designed handoff: the two concurrent init sequences visibly collide in the log — [RemotePluginManager] Starting remote plugins sync twice, followed by Sync already in progress, waiting....

Agreed on the debugging surface — a generation-aware process view (server name, pid, ppid, start time, transport state, config hash) would have made this diagnosable in minutes instead of days. And the non-idempotent-server point is exactly how this manifested for me: duplicate mcp-wordpress-remote clients initializing simultaneously produced repeatable -32603 "WordPress connection failed during initialization" errors until I pinned package versions to narrow the race window.

Also occurs on windows os