[BUG] Multiple concurrent sessions multiply MCP server processes without memory limits, causing kernel panic

Description

Running multiple concurrent Claude Code sessions causes a multiplicative explosion of MCP server node processes, each with unbounded V8 heap growth. With N sessions and M configured MCP servers, the system spawns up to N×M node processes with no memory cap. On a 64 GB MacBook Pro, 15 concurrent sessions with 34 configured MCP servers caused a hardware watchdog kernel panic twice in one evening.

This is a repeat of the same failure mode from April 3, 2026 (12 sessions + 308 node processes = 111 GB total → kernel panic).

Environment

• Claude Code version: 2.1.97
• OS: macOS 26.1 (25B78), Apple Silicon (MacBookPro18,4, M1 Max)
• RAM: 64 GB
• MCP servers configured: 34
• Concurrent sessions at crash time: 15 (all in Ghostty terminals)

What happened

1. 15 Claude Code sessions running across different projects in Ghostty tabs
2. Each session spawns its own set of MCP server node processes
3. Node processes hit V8 OOM (node::OOMErrorHandler → v8::internal::Heap::FatalProcessOutOfMemory)
4. System became unresponsive → hardware watchdog reset at 19:08
5. Machine failed to recover cleanly → had to force power off at 20:23
6. Post-reboot: 74 crash reports generated, including 56 mcpbridge crashes, 4 node-runtime OOM crashes, 2 node OOM crashes

Crash evidence

Reset counter (hardware watchdog kill)

Boot faults: wdog,reset_in1

Second reset (force power off to recover)

Boot faults: btn_rst,finger_reset force_off
Boot failure count: 1

Claude Code disk write diagnostic (single process)

Writes: 2147.49 MB of file backed memory dirtied over 1929 seconds (1113.47 KB/s)

Node process V8 OOM stack (all 6 node crashes share this pattern)

node::OOMErrorHandler
  → v8::internal::V8::FatalProcessOutOfMemory
  → v8::internal::Heap::FatalProcessOutOfMemory
  → v8::internal::Heap::CollectGarbage (GC failed to reclaim enough)
  → v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath

One crashed during ArrayPrototypeFlatMap, another during ObjectGetOwnPropertySymbols → KeyAccumulator (enumerating properties of a massive accumulated object).

Post-reboot crash report tally

| Process | Crashes | Cause |
|---------|---------|-------|
| mcpbridge (Xcode MCP) | 56 | Cascade from session deaths |
| node-runtime (Homebrew) | 4 | V8 OOM |
| node (CC bundled) | 2 | V8 OOM |
| codex | 1 | Cascade |

The multiplicative problem

This isn't just "one session leaks memory" (covered by existing issues). The problem is structural multiplication:

• 15 sessions × 34 MCP servers = potentially 510 node processes
• Each node process has its own V8 heap with no --max-old-space-size limit
• CC does not deduplicate MCP servers across sessions (each session spawns its own)
• CC does not clean up MCP processes when sessions end (#33947)
• macOS has no cgroups to contain per-process memory
• 64 GB is insufficient for this many unbounded V8 heaps

Even if each node process only reaches 200 MB (modest), that's 510 × 200 MB = 102 GB — already exceeding physical RAM.

What should happen

Several possible mitigations (not mutually exclusive):

1. Set NODE_OPTIONS=--max-old-space-size=256 (or similar) on MCP server child processes — the single highest-impact fix. MCP servers don't need gigabytes of heap.
2. Share MCP server instances across sessions — if two sessions both need the GitHub MCP, use one process.
3. Lazy-start MCP servers — only spawn when a tool from that server is actually invoked, not at session startup.
4. Clean up MCP processes on session end — fix #33947.
5. Expose a global config setting for MCP server memory limits (e.g., mcpServerMaxHeapMB in settings.json).
6. Warn or refuse when the total MCP server process count would exceed a threshold.

Currently there is no user-facing config to cap MCP server memory. The only workaround is manually adding "env": {"NODE_OPTIONS": "--max-old-space-size=256"} to each of the 34 MCP server entries in ~/.claude.json, which is tedious and fragile.

Related issues

• #33947 — MCP server orphan processes never cleaned up on session end
• #18011 — V8 OOM crashes on extended sessions
• #4953 — Process grows to 120+ GB
• #30470 — 49 GB invisible kernel memory, OOM on 128 GB system
• #20412 — Claude.ai MCP servers auto-injected, OOM on constrained systems
• #3036 — Multiple MCP servers eat context window
• #25926 — Unbounded in-memory message accumulation
• #32892 — ArrayBuffer accumulation ~92 GB/hr