Desktop app keeps every session's process tree alive — 183 idle sessions, ~2,600 MCP sidecars, ~160GB RSS

Summary

The Claude desktop app (macOS) keeps the full process tree of every Claude Code session alive long after the session goes idle. On a heavily used machine this accumulated to 183 live claude session processes with ~2,600 MCP sidecar processes between them — ~3,800 total processes and ~160 GB of RSS, driving the machine into memory compression (95 GB compressor) and swap exhaustion.

Environment

• Claude desktop app: 1.19367.0 (macOS)
• Bundled Claude Code runtime: 2.1.202 (~/Library/Application Support/Claude/claude-code/2.1.202/claude.app/Contents/MacOS/claude)
• macOS: Darwin 25.5.0, Mac Studio M3 Ultra, 256 GB unified memory
• Heavy MCP configuration (~15–20 stdio servers per session)

Observed

Process census (ps axo rss,comm aggregated):

| Process group | Count | RSS |
|---|---|---|
| claude session binaries (2.1.202) | 183 | 58.8 GB |
| node MCP sidecars | 953 | 44.9 GB |
| desktop-commander MCP | 368 | 17.9 GB |
| sequential-thinking / playwright / context7 MCPs | ~185 each | 26.7 GB |
| uv + Python MCP servers | ~730 | 13.0 GB |

• Every session process is parented by /Applications/Claude.app/Contents/Helpers/disclaimer — i.e., these are desktop-app-managed sessions, not orphans.
• Session age distribution at time of census: 10 under 1 hour, 132 between 1–24 hours, 41 between 1–7 days.
• System impact: 193 GB physical memory used, 95 GB in the compressor, swap 7.7 GB / 8 GB used.

Expected

Idle sessions' processes (and their MCP server children) should be reaped after a bounded idle window (the app appears to have an idle-lifecycle mechanism — previously observed rebooting idle sessions on a ~15 minute cadence), or at minimum the app should cap the number of warm session processes. A session that has been idle for days should not hold a live process tree with 15–20 MCP servers.

Impact

• Each warm session tree holds ~880 MB average (session process + MCP sidecars).
• MCP cost is multiplicative: N warm sessions × M configured servers. With a large MCP config the machine accumulates thousands of processes within a day of normal use.
• Memory pressure degrades the whole machine (compression, swap, UI stalls) until the app is force-quit.

Workaround

Manually killing idle session processes (SIGTERM to the claude session pid; MCP children exit with it). Sessions resume from transcripts on demand, so no data is lost — which suggests the warm processes are not load-bearing for idle sessions.

Suggested fix

Reap idle session process trees on the existing idle window (or make the warm-session pool size configurable). Tearing down MCP sidecars for idle sessions and respawning on resume would eliminate nearly all of this footprint.