[BUG] Memory leak in short, lightweight sessions (v2.1.104, macOS ARM64, 32GB)
Preflight Checklist
- [x] I have searched existing issues and this appears to be a continuation of #34967 / #33589 / #39531 still present in latest release
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code
What's Wrong?
Claude Code consumes all available memory on a 32GB Mac within minutes of lightweight usage, making the system completely unresponsive and requiring force-kill via Activity Monitor. This has been happening consistently across the last ~6 releases regardless of project or workload.
Key detail: This is NOT caused by long sessions or large context. The specific session that prompted this report was ~5 minutes old with minimal context — a plan-mode approval followed by a handful of small file edits. Claude crashed during the plan approval step itself.
Environment
- Claude Code: 2.1.104
- Platform: macOS Darwin 25.3.0 (Apple Silicon ARM64)
- RAM: 32 GB
- Runtime: Bun-based binary (not affected by NVM/system Node.js)
Memory snapshot during the session
Three Claude processes running simultaneously:
alex 465 MB claude
alex 464 MB claude
alex 384 MB claude
Total: ~1.3 GB after just a few minutes of a lightweight plan-mode + edit session. System became unresponsive shortly after.
Session activity at time of crash
- User entered plan mode
- Claude generated a small plan (5 file edits, all under 10 lines each)
- User approved the plan
- Claude began executing edits
- System became unresponsive — had to force-kill via Activity Monitor
No subagents were spawned. No large files were read. No web searches. Context window was minimal.
Relation to existing issues
This appears to be the same root cause as:
- #34967 — ArrayBuffers grow to 6.3GB in ~5 minutes (v2.1.72)
- #33589 — BytesInternalReadableStreamSource ArrayBuffer accumulation (3.3GB in 59s)
- #39531 — 61GB/hour growth rate (v2.1.76)
The ArrayBuffer/streaming buffer leak identified in those issues is still present in v2.1.104. Given the severity (renders 32GB machines unusable within minutes), this warrants priority attention.
What Should Happen?
A 5-minute session doing small file edits should not consume more than a few hundred MB total across all processes.
Workaround attempts
NODE_OPTIONS=--max-old-space-sizedoes NOT help — the leak is inexternal/arrayBuffersoutside V8's managed heap- Changing Node.js version via NVM does NOT help — Claude Code bundles its own Bun runtime
/compactand/clearare not viable workarounds when the leak occurs within the first few minutes of a fresh session- The only current workaround is force-killing Claude processes via Activity Monitor when the system becomes sluggish
Suggested investigation
The leak appears to be in streaming response buffer handling within the Bun runtime. The pattern from #34967 shows V8 heap at 65MB while external/arrayBuffers balloon to multi-GB — these buffers are allocated for streaming but never freed.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗