[BUG] stdio MCP tool call hangs indefinitely under `claude -p` when the full MCP fleet is loaded — regression in 2.1.177, works under --strict-mcp-config

What's wrong

After the auto-update to 2.1.177, a single call to a local stdio MCP tool hangs indefinitely under claude -p when several MCP servers are configured. The tool call never returns. --debug shows:

[DEBUG] MCP server "X": Successfully connected (transport: stdio) in 3727ms
[DEBUG] MCP server "X": Calling MCP tool: my_tool
[DEBUG] MCP server "X": Tool 'my_tool' still running (30s elapsed)
[DEBUG] MCP server "X": Tool 'my_tool' still running (65s elapsed)
... (no response — only ends when the claude process itself is terminated) ...
[DEBUG] MCP server "X": Tool 'my_tool' failed after 68s: MCP error -32000: Connection closed

Connection/handshake succeeds; it's the tool call that wedges.

The same tool returns in ~5s when the session is launched with --strict-mcp-config limiting it to just that one MCP server. And driving the same MCP server directly with a standalone JSON-RPC stdio client (initialize → tools/call) returns a correct result in ~6s — so the server is healthy; the failure is client-side and correlates with the number of configured MCP servers.

Is this a regression?

Yes. The identical setup worked on the version immediately prior to 2.1.177. A nightly headless job that calls this tool ran fine through 2026-06-12; the first run after the 2.1.177 auto-update (2026-06-13) hung, and every run since hung until the workaround below.

Impact

Any automated/headless claude -p flow that calls a local stdio MCP tool while other MCP servers are also configured hangs until killed by the outer timeout. Flows that don't call the stdio tool are unaffected — which makes it look intermittent and hard to attribute.

Isolation already done

Holding the model/prompt constant and varying only the toolset, under the full fleet (~11 servers):

• Built-in tools (Read/Write/Bash): fine (~35–40s end-to-end).
• The local stdio MCP tool: hangs (>68s, killed).
• The same stdio MCP tool with only that server loaded (--strict-mcp-config): ~5s. ✅
• The MCP server driven by a standalone JSON-RPC stdio client (full fleet irrelevant): ~6s, correct result → server is healthy.
• Server startup is fine (Successfully connected (transport: stdio) in 3727ms); only the tool call hangs.

Reproduction

1. Configure ~10 MCP servers (mix of stdio + http/sse). At least one is a local stdio server with a CPU-bound tool taking a few seconds (in my case a FastMCP 3.2.0 server running a local ONNX embedding search, ~5s).
2. claude -p --allowedTools "mcp__X__my_tool" <<< "call my_tool, then stop"
3. The call hangs (>60s); on teardown: MCP error -32000: Connection closed.
4. Re-run with --strict-mcp-config --mcp-config server-X-only.json → returns in ~5s.

Environment

• Claude Code 2.1.177, Linux x86_64
• ~11 MCP servers configured (stdio + http/sse mix)
• Affected server: local FastMCP 3.2.0 stdio server, CPU-bound tool (~5s)
• Model: Opus

Workaround

Launch the affected flow with --strict-mcp-config --mcp-config <minimal> so only the needed MCP server loads. Restores ~5s tool latency.

Possibly related (but distinct)

• #40207 — CC SIGTERMs healthy stdio MCP servers on a wall-clock timer. Here the server is not killed mid-call; it's only torn down when the whole claude process exits, and the symptom is a hung tool call, not a proactively-killed idle server.
• #35287 — stdio MCPs hang when init fails. Here init succeeds and the hang is the tool call, cured by reducing the configured server count.

The discriminating signal: the hang scales with the number of concurrently-loaded MCP servers, and --strict-mcp-config (single server) eliminates it — suggesting a client-side stdio multiplexing / scheduling regression in 2.1.177 rather than a per-server lifecycle timeout.