High RAM consumption from Node MCP subprocesses on Windows (many plugins + 1M context)

Disclosure: This issue was drafted and filed by Claude (Anthropic's Claude Code CLI, model claude-opus-4-6[1m]) acting on behalf of the account owner (@johnkitch, johnnykitchener7@gmail.com) with their explicit approval. The diagnostics below were collected by Claude from the user's own machine during a live Claude Code session on 2026-04-21. The account holder has reviewed and authorized this submission.

---

High RAM consumption by Node subprocesses (Windows, many plugins + 1M context)

Product: Claude Code (CLI on Windows)
Platform: Windows 11 Pro 10.0.26200
Model in use: claude-opus-4-6[1m] (1M context)
Date observed: 2026-04-21

Summary

When running Claude Code with multiple plugins/MCP servers enabled and the 1M-context Opus model, cumulative RAM consumption of the Claude Code processes plus spawned Node MCP subprocesses reaches levels that saturate a 16 GB machine, occasionally pushing total system memory use to ~100%.

Environment snapshot at time of report

• Total RAM: 16,092 MB
• System memory used: 78.2% (3.5 GB free) while mostly idle
• Claude processes: top three at 663 MB + 583 MB + 239 MB = ~1.5 GB
• Node subprocesses: 17 running, totaling ~1.23 GB
• Enabled plugins (15): agent-sdk-dev, chrome-devtools-mcp, clangd-lsp, claude-code-setup, code-simplifier, context7, frontend-design, hookify, pr-review-toolkit, playwright, code-review, superpowers, skill-creator, plugin-dev, feature-dev
• Additional user MCP servers configured: ~25 (clinical-db, psychometric, obsidian-bridge, claude-memory, ollama-agent, meta-cognitive, notification-hub, etc.)

Reproduction

1. Install Claude Code on Windows with the 1M-context Opus model selected.
2. Enable a typical pro-user plugin bundle (≥10 plugins that ship MCP servers).
3. Configure additional project-level MCP servers in .mcp.json / settings.
4. Open a long-running session (≥1 hour) with heavy tool use.
5. Observe Node heap growth and Claude Code process RSS creep monotonically. RAM does not return to baseline when tool calls finish.

Observed behavior

• Each Node subprocess holds steady memory but does not shrink after large tool results (e.g., Playwright / chrome-devtools snapshots, large Grep/Read results).
• The main Claude Code process (Electron-style) grows with conversation length on the 1M model — this appears expected for 1M context, but it is not surfaced to the user anywhere.
• No configurable per-subprocess heap cap is documented. Setting NODE_OPTIONS=--max-old-space-size=<N> via settings.json > env works but is not discoverable.

Expected behavior

1. Inactive MCP subprocesses should be lazily spawned / hibernated when idle, not resident for the full session.
2. Documentation (or a settings UI) should surface the memory cost of 1M context and number of enabled plugins, so users can make informed trade-offs.
3. A built-in per-MCP heap cap default (e.g., 512 MB) would prevent any single misbehaving MCP from dominating system memory.

Suggested fixes / mitigations

• Ship a sensible default NODE_OPTIONS=--max-old-space-size=512 (or 1024) for child MCP processes.
• Add claude doctor --memory that lists MCP subprocess RSS, owning plugin, and idle time.
• Lazily start MCP servers on first use per session instead of at startup when many are configured.
• Warn at startup when enabledPlugins count × estimated per-MCP footprint exceeds a fraction of system RAM.
• Offer a "low-memory mode" that auto-disables plugins tagged as heavy (playwright, chrome-devtools-mcp, frontend-design) unless explicitly invoked.

Workaround applied locally

Added to ~/.claude/settings.json:

"env": { "NODE_OPTIONS": "--max-old-space-size=1024" }

This caps each Node MCP child process at 1 GB heap. Effective after Claude Code restart.