Subagents inherit all MCP servers, causing Windows stdio saturation in parallel Task waves

Summary

Claude Code CLI on Windows crashes (UI process terminates, no error shown) during intensive subagent-spawning workflows when many home-scoped MCP servers are configured. Each subagent launched via the Task tool inherits all home-scoped MCP servers, re-running every stdio handshake on subagent startup. When a wave of 3–4 parallel Task calls fires simultaneously (common in orchestrator-driven workflows like get-shit-done), the Node.js stdio transport becomes saturated and the session dies silently.

Environment

• Claude Code: v2.1.107
• Platform: Windows 11 Home (10.0.26100)
• Shell: Git Bash 5.2.37 (C:\Program Files\Git\bin\bash.exe)
• Model: claude-opus-4-6[1m]
• MCP servers configured in home .mcp.json: 11 (supabase, whatsapp, shadcn, magicui, sentry, github, figma, n8n-mcp, playwright-edge, n8n-cloud, wp-mcp)
• MCP servers from enabled plugins: ~6 more (context7, unityMCP, playwright, vercel, gemini-mcp, etc.)
• Effective MCP count: ~17 servers inherited by every subagent

Debug log evidence

From ~/.claude/debug/e41d730a-1d4d-4351-ab98-71bd7b068e0e.txt (a GSD execute-phase session that crashed):

• 6,906 Processing message events across 400 Starting to process input stream cycles in ~2.5 hours.
• Bursts of 76 messages delivered to one streamInput in 50 ms, indicating full context replay on subagent spawn.
• Pattern repeats every time a parallel-wave orchestrator fires multiple Task() tool uses:
• T+0 ms: 4 subagent Task calls issued in the same assistant turn
• T+5 ms: 4 child Node processes begin ~17 MCP stdio handshakes each
• T+50 ms: 68 concurrent pipes writing to the parent; streaming input resumes with multi-MB context replay per child
• At some point: main Claude Code UI process dies. No isApiErrorMessage, no Windows crash log, no hook-failure record.

Minimal repro

1. Configure 10+ stdio-type MCP servers in home ~/.mcp.json on Windows.
2. Use any workflow that fires ≥3 parallel Task tool calls in a single assistant turn (e.g., get-shit-done execute-phase wave parallelization, or any orchestrator that delegates to 3+ subagents simultaneously).
3. Observe: UI terminates silently during or shortly after subagent wave completion. Session JSONL ends without an assistant terminator.

Expected: Subagents should only load MCP servers they actually need (declared in their tools: list, e.g., mcp__context7__*) — not all home-scoped servers.

Why this is a bug (not config hygiene)

Subagents declare the tools they can call in their agent definition (tools: Read, Write, Edit, Bash, Grep, Glob). The Task tool filters which tools the child model can invoke, but the child process still spawns every MCP server from the parent's resolved config. For an agent that declares no MCP tools (e.g. GSD's gsd-executor), spawning 17 MCP servers on every invocation is pure waste.

Amplification factor on a typical GSD execute-phase wave:

• 4 parallel gsd-executor subagents
• × 17 inherited MCP servers each
• = 68 stdio pipe handshakes racing on the parent's libuv event loop
• + full conversation replay through streamInput per child

On macOS/Linux, pipe buffers and select() limits are generous enough to survive. On Windows, named-pipe-backed stdio hits its ceiling and the parent process dies.

Suggested fixes (ordered by impact)

1. Only spawn MCP servers whose tools the subagent has declared access to. If tools: doesn't include any mcp__<server>__* glob, skip that server entirely for that subagent. This is the root-cause fix and preserves full quality for agents that do need MCP.
2. Rate-limit parallel subagent spawns on Windows — stagger child process launches by 100–200 ms so MCP handshakes don't race. Keeps parallelism, just desynchronizes startup.
3. Document the disabledMcpjsonServers setting as a workaround and recommend it when ≥10 MCP servers are configured.

Workaround I'm using now

Added to ~/.claude/settings.json:

"disabledMcpjsonServers": [
  "shadcn", "magicui", "sentry", "figma",
  "n8n-mcp", "n8n-cloud", "wp-mcp"
]

Reduced effective MCP count from ~17 → ~10. Will report back whether the crash recurs under the same workload.

Related

• #47931 (silent session termination after parallel tool_use) — possibly the same underlying failure mode, just a different trigger path.

Labels to consider

bug, windows, mcp, subagents, stability