[BUG] Memory leak in short, lightweight sessions (v2.1.104, macOS ARM64, 32GB)

Resolved 💬 3 comments Opened Apr 13, 2026 by astock33137 Closed Jun 12, 2026

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

  1. User entered plan mode
  2. Claude generated a small plan (5 file edits, all under 10 lines each)
  3. User approved the plan
  4. Claude began executing edits
  5. 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-size does NOT help — the leak is in external/arrayBuffers outside V8's managed heap
  • Changing Node.js version via NVM does NOT help — Claude Code bundles its own Bun runtime
  • /compact and /clear are 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.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗