[BUG] Runaway node fork storm (~43 procs/sec) from claude-code sessions exhausts 48GB RAM → 3 macOS kernel panics in 24h (forensic data included)

Summary

claude-code sessions on macOS trigger runaway node process fork storms (up to 43 new processes/second), exhausting 48 GB of RAM within minutes and causing 3 macOS kernel panics (watchdog timeout) within 24 hours. I have detailed forensic data from JetsamEvent reports, disk-writes resource diagnostics, and a 10-second-interval monitoring log that captured a storm in real time.

This appears to combine two known issues — MCP/child processes never reaped on session end (#33947, #40667, #36616) and unbounded process multiplication across concurrent sessions (#45880) — but escalates them to full kernel panics, with hard numbers.

Environment

• macOS 26.5.2 (25F84), MacBook Pro Mac17,8 (Apple Silicon T6050, 18 cores, 48 GB RAM)
• claude-code 2.1.217 (bundled with Claude desktop 1.24012.1; also used inside cmux 0.62.2→0.64.20)
• node v25.8.1 (homebrew)
• ~10 stdio MCP servers configured (npx-based), later reduced as mitigation
• Workload: agentic editing on a Next.js 16 project (subagent-driven), i.e. frequent file edits while next build/dev tooling spawns SWC workers

Incident timeline (all 2026-07, KST)

| When | Event |
|---|---|
| 07-19 08:19 | JetsamEvent — largest: Virtualization VM; Claude + node pressure |
| 07-22 06:18 | JetsamEvent + WindowServer watchdog timeout + shutdown stall |
| 07-22 08:18 | Kernel panic (watchdog) after OOM |
| 07-23 05:52 | JetsamEvent: 2,760 node processes, 111 GB combined rpages, inside a cmux-led coalition running claude-code 2.1.217. One node held 12,800 open fds (cpuTime 107 s). Free memory 261 MB at capture |
| 07-23 05:56 | Kernel panic (watchdog, wdog boot fault) |
| 07-23 07:24 | Storm captured live by my 10s watchdog log (below). Heaviest process: next-swc.darwin-arm64.node under coalition com.anthropic.claudefordesktop; single node dirtied 8.59 GB file-backed memory over 1,842 s (disk-writes diag) |
| 07-23 07:29 | Kernel panic (watchdog timeout: "no checkins from monitoring") |

Real-time capture of the storm (10s polling)

07:24:35 node=5    free=93%
07:24:55 node=867  free=63%   <- +862 processes in 20 seconds (~43/sec)
07:25:18 node=2149 free=30%   <- kill attempts could not keep up
(no further log entries possible — system unresponsive)
07:29    kernel panic, forced reboot

Notable: my cleanup script SIGKILLed matching nodes twice during the storm; respawn outpaced the kills, and once memory was exhausted the script itself could no longer be scheduled.

Evidence of the two contributing defects

1. Orphaned children: after sessions end, npx-launched MCP node processes remain alive reparented to launchd (PPID=1). Observed repeatedly; matches #33947 / #40667.
2. Unbounded multiplication: each claude session spawns its own full set of stdio MCP servers; concurrent sessions/subagents multiply them with no global cap or memory ceiling; matches #28860 / #45880. Combined with an agentic edit loop on a Next.js project (SWC/compile workers respawning per rebuild), spawn rate reached ~43 procs/sec.

Impact

Three full kernel panics (watchdog) in 24 h; total data-loss risk for anything unsaved; machine unusable during storms. This is not graceful degradation — macOS's Jetsam could not contain it.

Mitigations I had to apply (workarounds, not fixes)

• kern.maxprocperuid lowered 8000 → 800 via LaunchDaemon (kernel-enforced hard stop)
• 10-second watchdog LaunchAgent that SIGKILLs node/bun/next workers on count/rate triggers
• Reduced MCP server count; project CLAUDE.md rules forbidding watch-mode tools in sessions

Requests

1. Reap the entire process group (MCP servers, spawned build tools) reliably on session/subagent end — e.g. killpg on exit, PID tracking, or launching children in their own process group with cleanup.
2. A global cap / rate limit on child process spawning per session, and a memory ceiling.
3. Share MCP server processes across concurrent sessions (#28860) or at least de-duplicate identical stdio servers.

I can provide the full JetsamEvent .ips files, the disk-writes diag, and my monitoring logs on request.