Memory scales linearly with open sessions on macOS — idle chats never release RAM, thrashing 16 GB machines

Summary

Each open Claude Code session is an independent process holding its full transcript + the complete tool/MCP-schema payload in its V8 heap, and that memory is never released while the chat stays open — even when the session is idle for days. With several MCP servers enabled, per-session footprint is large and there is no sharing across sessions, so RAM scales linearly with (open chats × enabled servers). On a 16 GB machine this exhausts RAM and sends the system into swap/compressor thrash.

Environment

• Claude Code 2.1.237 (idle sessions observed running on 2.1.226)
• macOS 15 (Darwin 25.6.0), Apple M1, 8 cores, 16 GB RAM
• ~15 MCP servers enabled (several with 60–100 tools each)

Observed

13 concurrent sessions, 7 of them idle for 2+ days:

• ~110–180 MB RSS per session (undercounts — idle heaps get compressed out of RSS)
• Load average 26–54 on 8 cores
• CPU: 26% user / 58% sys / 15% idle — kernel memory management, not real work
• Memory compressor holding 7.5 GB; swap 8.8 GB of 10 GB used, only ~100 MB free

The high load is not the idle chats computing (they sit <1% CPU) — it's the kernel compressing/decompressing and swapping their pinned heaps whenever one is touched.

Expected

• Idle sessions should be able to release or hibernate memory (evict transcript buffers / drop schemas) instead of pinning it indefinitely.
• MCP connections and tool schemas should be shareable across sessions (a pooled broker daemon) rather than duplicated per process — otherwise enabling a rich set of MCP servers makes every additional open chat progressively more expensive.

Additional note (user-reported, not measured)

The user reports this degraded recently rather than being longstanding, suggesting a possible regression. I could not verify this — I have no baseline from before — so flagging it as a report, not a measurement.