[BUG] Claude Desktop: shared-pool MCP process management causes synchronized failures across independent stdio servers

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

Two independent local MCP (stdio) servers configured in Claude Desktop consistently fail to complete initialization in near-perfect millisecond synchrony, even though they are completely unrelated processes (different executable instances, different remote targets on different networks in different countries). This rules out any server-specific or network-specific cause and points to a bug in Claude Desktop's shared-pool MCP process management.

Environment

• Claude Desktop (Windows, MSIX/Store install), version 1.32885.1 (a757f5), build 2026-08-18
• Windows 10/11, user profile with two configured local stdio MCP servers: homeassistant_STA and homeassistant_MUC
• Both servers launch the same executable (C:\Users\<user>\.local\bin\ha-mcp.exe) with different environment configs pointing at two independent Home Assistant instances (one on a Tailscale-connected Raspberry Pi, one via a separate webhook/public endpoint)
• Four other MCP connectors also configured (excel-pro, github, winget, windows-mcp)

Observed behavior

On 2026-08-26 between 06:15 and 06:20 UTC, both homeassistant_STA and homeassistant_MUC logs were captured for the same session. Every event in both logs — process start, initialize message sent, timeout errors, shutdown/restart cycles, final notifications/cancelled — occurs within 1–90 milliseconds of the corresponding event in the other server's log, across a full 5-minute window.

Timestamp comparison (excerpt)

| Event | homeassistant_STA | homeassistant_MUC | Diff |
|---|---|---|---|
| Server start #1 | 06:15:28.678 | 06:15:28.711 | 33 ms |
| initialize sent | 06:15:44.177 | 06:15:44.183 | 6 ms |
| Timeout error (shared-pool) | 06:16:23.805 | 06:16:23.824 | 19 ms |
| notifications/cancelled | 06:16:44.180 | 06:16:44.267 | 87 ms |
| Restart-burst begins | 06:18:19.113 | 06:18:19.115 | 2 ms |
| ~11 restart cycles in burst | in lockstep | in lockstep | few ms each |
| Last initialize in burst | 06:18:59.076 | 06:18:59.075 | 1 ms |
| Final notifications/cancelled | 06:19:59.108 | 06:19:59.093 | 15 ms |

Pattern 1 — 60-second hang (previously reported)

1. "Server started and connected successfully"
2. initialize message received by the server
3. Complete silence — no further log lines from either server process for exactly ~60 seconds
4. notifications/cancelled fires from the client
5. Error logged: Couldn't start for Cowork and Code sessions. Error: Request timed out with metadata: { context: 'shared-pool' }

Pattern 2 — rapid restart burst (new, not previously observed)

Immediately following pattern 1, both servers entered a burst of ~11 rapid restart cycles over ~40 seconds:

• "Server started and connected successfully" followed almost immediately (under 1–8 seconds) by "Shutting down server... (intentional shutdown)"
• Cycle timing is synchronized between the two independent servers to within a few milliseconds each time
• The burst ends with one more full 60-second hang (pattern 1) before the client finally gives up

Why this indicates a Claude Desktop bug, not a server/network issue

homeassistant_STA and homeassistant_MUC are independent processes connecting to independent Home Assistant instances over independent networks (one via Tailscale to a Raspberry Pi, one via a separate public/webhook endpoint) in different countries. There is no mechanism by which these two servers could organically fail in lockstep at the millisecond level unless a shared component in Claude Desktop (the "shared-pool" referenced in the error metadata) is managing both process lifecycles together and failing/restarting them as a batch.

Impact

• MCP tools for both Home Assistant connectors are frequently unavailable in normal chat sessions (not just Cowork/Code, despite the error text referencing "Cowork and Code sessions" — the context: 'shared-pool' value indicates this affects standard chat too)
• Requires repeated full restarts of Claude Desktop (including killing tray/background processes) to sometimes recover
• This is a recurring issue across multiple sessions over time; this report documents the clearest evidence yet, including a newly observed restart-burst pattern that suggests the underlying shared-pool retry logic may have become less stable, possibly coinciding with a recent Desktop update

mcp-server-homeassistant_MUC.log
mcp-server-homeassistant_STA.log

What Should Happen?

Please investigate the shared-pool MCP process management/lifecycle code path referenced in the context: 'shared-pool' error metadata, particularly around initialize handling and the timeout/restart logic that produces the rapid restart-burst pattern described above.

Error Messages/Logs

## Raw logs
Full logs for both servers covering 2026-08-26 06:15:28–06:20:01 UTC are attached

Steps to Reproduce

This is an intermittent failure, not a deterministic repro — it occurs
periodically without a specific user action triggering it. Based on
repeated observation across multiple sessions:

1. Configure two or more local stdio MCP servers in Claude Desktop

(claude_desktop_config.json), e.g. two instances of the same
executable pointing at different remote endpoints.

1. Start a normal Claude Desktop chat session (not Cowork/Code).
2. Observe the MCP server logs

(%LOCALAPPDATA%\Packages\...\logs\mcp-server-<name>.log or
%APPDATA%\Claude\logs\ depending on install type) for all
configured local stdio servers during session startup.

1. Intermittently (frequency varies by session), all local stdio

servers fail to complete initialize within the ~60s timeout
simultaneously, and/or enter a rapid restart-burst cycle
simultaneously — see timestamp comparison table above.

1. The synchrony across independent, unrelated servers (different

executables/targets/networks) is the key reproducible signal, not
any single deterministic user action.

No specific trigger has been identified on the user side (no config
change, network event, or user action precedes the failure in the
captured logs). Willing to capture additional log samples or test
specific hypotheses if the Claude Desktop team can suggest what to
look for.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

• Claude for Windows (formerly "Claude Desktop"), version 1.37937.1 (edbd3c)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_