claude-code - 💡(How to fix) Fix [BUG] Unbounded MCP server fan-out across Cowork/agent sessions exhausts RAM and kernel-panics macOS (4 panics + forced power-off on M2 Max / 32 GB)

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

With only 11 configured MCP servers, Claude Desktop (which hosts Claude Code sessions) spawns ~300 MCP server processes and pins ~24 GB of swap for 5+ hours, repeatedly driving a 32 GB M2 Max into total memory starvation — four kernel panics in four days plus a hard freeze requiring a 10-second forced power-off (login screen unresponsive, password rejected, Touch ID dead).

~300 procs ÷ 11 servers ≈ 27×, which indicates the full MCP set is instantiated per concurrent Cowork/worktree/agent session and never reaped on session close. There is no concurrency cap, no dedup, and no memory backpressure.

This is Claude Code surface area, not merely the Electron shell: the failure is driven by Claude Code's MCP server lifecycle and its Cowork/agent/worktree session management — the same MCP fan-out that runs under claude sessions. (Filing fresh because the closest report, #40249, was closed invalid/"not related to Claude Code"; on macOS this escalates from "high RAM" to repeated kernel panics, so I'm reporting with full kernel-level evidence.)

Environment

• Claude Desktop 1.9659.2 (hosting Claude Code sessions)
• macOS 26.5 (25F71)
• MacBook Pro 14" (Mac14,5), Apple M2 Max, 32 GB RAM
• Configured MCP servers: 11 total — 2 in claude_desktop_config.json (pulumi, mempalace) + 9 Desktop Extensions (chrome-control, filesystem, imessage, notes, ms_office word/excel/powerpoint, macos-mcp, desktopcommander)

Why this is a defect, not a misconfiguration

1. The config is already minimized to 11 servers; the freeze persists regardless.
2. The failure scales with session count (app-controlled), not configured-server count (user-controlled) — it is O(sessions × servers) with no upper bound. More RAM only delays the freeze.
3. Stale session/VM dirs (vm_bundles/, claude-code-sessions/, local-agent-mode-sessions/, Partitions/cowork-*) co-present with 300 live procs ⇒ MCP servers from closed sessions are not reaped.
4. No concurrency cap and no memory backpressure — the app marched 230 → 304 servers while the system was already >90 % memory pressure and thrashing swap.

Decisive control: with Claude quit, the machine sits at swap 0, ~14 GB available, 88 % memory-free, load ~2, indefinitely. Reopening it is the only thing that reproduces the climb. Hardware is clean: SSD SMART = Verified; no machine-check / DRAM-ECC / SError / GPU-reset signatures; no thermal events. This is not hardware and not macOS — it is the app.

A note on priorities: Anthropic has been increasingly strict about users running anything other than the official harness — fine, but then the official harness has to be engineered to a standard that doesn't take down the host OS. Shipping the client on Electron with no MCP-process reaping, no concurrency cap, and no memory backpressure is what's kernel-panicking a 32 GB M2 Max multiple times a day. A first-party app should not be capable of hard-locking the machine it runs on. I've used Macs for 20+ years and have never had a single application cause repeated kernel panics and forced power-offs like this — and it's entirely reproducible by quitting vs. launching this one app.

What Should Happen?

A minimal, fixed set of configured MCP servers should result in a bounded, roughly constant number of MCP processes — regardless of how many Cowork/worktree/agent sessions are opened over time. The app should never be able to exhaust system RAM or destabilize the host OS. Specifically:

• Reap a session's MCP servers when its session / worktree / Cowork VM closes (no orphaned servers from closed sessions).
• Deduplicate / pool identical MCP servers across concurrent sessions instead of spawning a full set per session.
• Cap concurrent MCP processes (configurable) and apply memory backpressure — stop spawning new servers and warn when system memory pressure is high, rather than marching from 230 → 304 servers while already thrashing swap.
• Surface live MCP process count + aggregate memory in the UI so the fan-out is visible to the user.

Expected outcome: with 11 configured servers, process count and memory stay bounded; the machine never reaches sustained swap exhaustion; no kernel panics or forced power-offs.

Error Messages/Logs

**5-hour build-up captured by an external 5-min monitor (LaunchAgent sampling load / swap / free RAM / MCP proc count / RootDomainUserClient; `desktop=1` = Claude running):**


15:44  load=40.75   swap=41788MB  free=10068MB  mcp=230  desktop=1   ← swap already 41 GB
20:14  load=8.22    swap=23606MB  free=114MB     mcp=304  desktop=1   ← 304 MCP procs, 114 MB free
20:19  load=4.60    swap=23590MB  free=58MB      mcp=300  desktop=1   ← 58 MB free, thrashing
20:23  load=180.99  swap→0        free=67MB      mcp→15   desktop=1   ← FREEZE → 10s forced power-off


- Swap pinned 23–42 GB continuously for ~5 h (sustained, not a spike).
- MCP process count climbed 230 → 304 while only 11 servers were configured.
- Free RAM chronically 56–600 MB for hours.
- At 20:23 load hit 181 → loginwindow/WindowServer/SecurityAgent/Touch ID all starved → unresponsive lock screen → 10 s forced power-off. macOS `ResetCounter` diag: `Boot faults: btn_rst, finger_reset force_off`.

**Per-MCP-server footprint (measured RSS):** prisma 313 MB, chrome-devtools 204 MB, aws-iac 167 MB, mempalace 89 MB (range ~90–313 MB). ~150 MB × 300 ≈ **45 GB demanded** on a 32 GB machine = the swap exhaustion observed.

**Four kernel panics in four days (local `panic-full-*.panic`, macOS 26.5):**

| When | Type |
|---|---|
| 2026-05-28 06:42 | WindowServer userspace watchdog timeout (render starvation under load) |
| 2026-05-30 12:36 | WindowServer userspace watchdog timeout |
| 2026-05-30 15:02 | WindowServer userspace watchdog timeout |
| 2026-05-31 00:18 | **IOKit registry busy-timeout** — `busy timeout (60s) … IOKit termination queue depth 12285: 'RootDomainUserClient'` (mass teardown of ~12.3K leaked power-assertion clients when a host process exited → `watchdogd` panic) |
| 2026-05-31 20:23 | Hard freeze / forced power-off (memory-exhaustion starvation; no panic written) |

All are software liveness/resource failures, not hardware (SSD SMART Verified; no machine-check/DRAM-ECC/SError/GPU-reset signatures; no thermal events).

Redacted `panic-full-*.panic` files, the full 5-hour monitor log, and a per-process RSS dump are available on request.

Steps to Reproduce

1. Configure ~10 MCP servers in Claude Desktop on a 32 GB Apple Silicon Mac.
2. Open multiple Cowork/worktree/agent sessions across a working day (or let scheduled/autonomous sessions accumulate); don't fully quit the app between them.
3. Watch the total MCP (node / uv / python) process count and sysctl vm.swapusage climb without bound — e.g. ~11 configured servers → ~300 live processes. Closed sessions' servers persist instead of being killed.
4. The system reaches sustained swap exhaustion (~24 GB swap, <100 MB free RAM for hours) → WindowServer / loginwindow / SecurityAgent starvation → unresponsive login screen → kernel panic or forced power-off.

Control (confirms it's the app): fully quit Claude Desktop → swap drains to 0, ~14 GB RAM becomes available, load drops to ~2, and the machine stays stable indefinitely. Relaunching is the only action that reproduces the climb.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

Claude 1.9659.2 (390d6c) 2026-05-28T21:50:01.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Hardware/OS ruled out (this is the app, not the machine):

• SSD SMART status = Verified; no machine check / DRAM-ECC / SError / GPU-reset / cache-parity signatures in any panic or diagnostic report; no thermal-pressure events (pmset -g thermlog clean).
• Apple Silicon panic classes confirm software liveness failures, not hardware traps: three are WindowServer userspace-watchdog timeouts; one is an IOKit registry busy-timeout (watchdogd). None are hardware exceptions.
• Control test: with Claude fully quit, the machine sits at swap 0, ~14 GB available, 88% memory-free, load ~2, indefinitely. Relaunching the app is the only action that reproduces the swap climb. This isolates the app as the sole variable.

Severity / frequency: 4 kernel panics + 1 forced power-off in 4 days (2026-05-28 → 2026-05-31), i.e. multiple full-system lockups per day. Each freeze renders the login screen unusable (password rejected, Touch ID dead, keyboard unresponsive) and requires a hard power-off — risking data loss and, in my case, leaving the machine unusable for several minutes each time.

The IOKit panic is a distinct, possibly separate bug worth its own attention: busy timeout (60s) … IOKit termination queue depth 12285: 'RootDomainUserClient'. ~12,285 leaked power-assertion clients (created via the app's keep-awake / power-assertion path) were torn down simultaneously when a host process exited, jamming the IOKit termination workloop past the 60s watchdog. RootDomainUserClient count was independently observed climbing ~33/hour during uptime — a slow power-assertion leak in addition to the MCP-process leak.

Config / scale context: This is a heavy but legitimate Claude Code workload — multiple concurrent Cowork/worktree/agent sessions plus scheduled/autonomous tasks, running ~24/7. The Mac is kept awake the entire time (Sleep:0/Wake:0) partly by the app's own NoIdleSleepAssertion ("Electron") and the CLI's caffeinate, which prevents macOS from ever draining swap or tearing down stale power-assertion clients — compounding both leaks. Configured MCP set was already deliberately minimized to 11 servers; the freezes persisted regardless.

Diagnostics available on request (redacted, no device identifiers):

• 4 × redacted panic-full-*.panic files
• the full ~5-hour external monitor log (load/swap/free/mcp/iopm/desktop, 5-min cadence)
• a per-process RSS dump of the MCP fleet
• macOS ResetCounter diag for the 20:23 forced power-off (Boot faults: btn_rst, finger_reset force_off)

Happy to run a sysdiagnose or any specific instrumentation the team wants — I have a standing 5-minute monitor capturing this and can reproduce on demand by relaunching the app.