Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix Subagents spawn duplicate MCP server processes, multiplying kernel resource consumption [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#48649•Fetched 2026-04-16 06:54:43
View on GitHub
Comments
0
Participants
1
Timeline
6
Reactions
0
Author
JF10RJF10R
Participants
JF10RJF10R
Timeline (top)
labeled ×4cross-referenced ×2

Each subagent spawned by Claude Code runs as a separate claude.exe process that independently spawns its own set of MCP server child processes. With N concurrent sessions and M configured MCP servers, this creates N×M child processes, each with 3 stdio pipes (kernel objects), plus duplicated file watchers and memory allocations.

Root Cause

Each subagent spawned by Claude Code runs as a separate claude.exe process that independently spawns its own set of MCP server child processes. With N concurrent sessions and M configured MCP servers, this creates N×M child processes, each with 3 stdio pipes (kernel objects), plus duplicated file watchers and memory allocations.

RAW_BUFFERClick to expand / collapse

Summary

Each subagent spawned by Claude Code runs as a separate claude.exe process that independently spawns its own set of MCP server child processes. With N concurrent sessions and M configured MCP servers, this creates N×M child processes, each with 3 stdio pipes (kernel objects), plus duplicated file watchers and memory allocations.

Problem

When Claude Code spawns subagents (via the Agent tool), each subagent:

  1. Starts as a new claude.exe process
  2. Spawns its own MCP server child processes (StdioClientTransport)
  3. Creates its own set of chokidar file watchers
  4. Maintains its own message buffers and caches

For a typical setup with 5 configured MCP servers:

Scenarioclaude.exeMCP child procsstdio pipeschokidar watchers
1 session15158
1 session + 2 subagents3154524
3 sessions + 2 subagents each94513572

Each pipe is a kernel object consuming Non-Paged Pool. Each watcher set creates thousands of ReadDirectoryChangesW handles (see #48648).

Observed Impact

On a Windows 11 system with 64 GB RAM, 3 concurrent claude.exe instances (main + subagents) were observed with:

  • Combined private memory: ~15 GB
  • Non-Paged Pool: 35 GB (normal: few hundred MB)
  • System crash: DWM STATUS_NO_MEMORY (0xc00001ad)

Suggested Improvements

  1. Share MCP server connections: Subagents could connect to parent's MCP servers via IPC rather than spawning their own
  2. Lazy MCP startup: Only spawn MCP servers when a tool from that server is actually called
  3. MCP server pooling: Maintain a process-level pool of MCP server connections shared across all agents
  4. Watcher deduplication: Share file watchers across the process tree

Environment

  • claude.exe v2.1.109 (Bun binary)
  • Windows 11 Pro 10.0.26200, 64 GB RAM

Related Issues

  • #42169 (resource exhaustion with multiple claude.exe processes)
  • #48648 (chokidar watcher NPP exhaustion)
  • #20369 (orphaned subagent processes)
  • #48647 (Buffer.slice retention per MCP connection)

extent analysis

TL;DR

The most likely fix is to implement one of the suggested improvements, such as sharing MCP server connections or lazy MCP startup, to reduce the number of child processes and kernel objects.

Guidance

  • Investigate the feasibility of implementing MCP server pooling to maintain a process-level pool of MCP server connections shared across all agents, which could significantly reduce the number of child processes and kernel objects.
  • Consider implementing lazy MCP startup, where MCP servers are only spawned when a tool from that server is actually called, to reduce the number of unnecessary child processes.
  • Review the Watcher deduplication suggestion to share file watchers across the process tree, which could help reduce the number of ReadDirectoryChangesW handles and alleviate Non-Paged Pool consumption.
  • Analyze the trade-offs between these approaches, considering factors such as complexity, performance, and potential impact on existing functionality.

Example

No code snippet is provided, as the issue does not contain sufficient technical details to create a concrete example.

Notes

The suggested improvements may require significant changes to the existing architecture and implementation. It is essential to carefully evaluate the potential benefits and challenges of each approach before selecting a solution.

Recommendation

Apply a workaround by implementing MCP server pooling or lazy MCP startup, as these approaches seem to address the root cause of the issue and have the potential to significantly reduce resource consumption.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#memory leak#API versioning#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING