Bug: Claude Code 2.1.32 regression - allocates ~11GB RAM on launch, freezes terminal (2.1.30 works fine)

[tradesdontlie]

Description

Claude Code 2.1.32 allocates approximately 11GB of resident memory immediately upon launch (within 20 seconds), pegs CPU at 100%, and completely freezes the terminal — no typing or interaction possible. The memory does not grow over time — it appears to be a massive upfront allocation rather than a gradual leak. When multiple sessions are left running (which is easy to do since closing a terminal doesn't kill the process), memory compounds quickly. In my case, 5-6 sessions consumed ~55-60GB, leaving only 4GB free on a 64GB machine.

This is a regression — version 2.1.30 uses only ~820MB and works normally.

Environment

• Claude Code version: 2.1.32 (broken), 2.1.30 (works correctly)
• OS: macOS 14.6.1 (Build 23G93)
• Hardware: Mac Studio, Apple M1 Max, 64GB RAM
• Node.js: v24.1.0
• npm: 11.3.0
• Install method: Tested with BOTH npm install -g @anthropic-ai/claude-code AND native installer (curl -fsSL https://claude.ai/install.sh | bash)
• Install paths tested: /opt/homebrew/lib (npm) and ~/.local/bin/claude (native)

Version Comparison

Version	RSS Memory	%MEM	%CPU	Terminal	Status
2.1.30	~820 MB	1.2%	17-26%	Responsive	✅ Normal
2.1.32	~11 GB	17.1%	100%	Frozen	❌ Regression

2.1.30 memory samples (stable, responsive):

ELAPSED    RSS       %MEM   %CPU
05:11      810 MB    1.2%   9.6%
05:16      821 MB    1.2%   26.1%
05:21      822 MB    1.2%   17.8%

Steps to Reproduce

1. Install Claude Code 2.1.32: npm install -g @anthropic-ai/claude-code@2.1.32
2. Launch: claude --dangerously-skip-permissions
3. Observe: Terminal freezes immediately, cannot type or interact
4. Check memory from another terminal within 20 seconds: ps -o pid,rss,vsz,%mem,%cpu,etime,command -p <PID>

Observed Behavior (2.1.32)

A single Claude Code process immediately consumes ~11GB RSS (17.1% of 64GB) and the terminal becomes completely unresponsive:

  PID    RSS      VSZ     %MEM  %CPU  ELAPSED  COMMAND
16329  11485472  497161904  17.1  100.0  08:20  claude

Memory sampling confirms the allocation is immediate and flat — not a gradual leak:

Fresh process (PID 44502) sampled at 16s, 21s, and 26s after launch:

  PID      RSS    %MEM  ELAPSED
44502  11693840   17.4    00:16
44502  11693744   17.4    00:21
44502  11693408   17.4    00:26

~11.7GB allocated within the first 16 seconds, then stable. When the process is launched in the background (suspended before trust prompt), it only uses ~339MB — confirming the massive allocation happens during post-prompt initialization, not at process spawn.

When multiple sessions accumulate (processes persist after closing terminal), the system runs out of memory. I had 6 sessions running simultaneously:

PID    COMMAND  %CPU  MEM    CMPRS
41376  claude   99.9  11G    11G
44826  claude   99.2  11G    11G
32283  claude   99.4  11G    11G
37471  claude   99.2  11G    11G
50636  claude   99.2  11G    8135M
29155  claude   99.9  10G    10G

System state with 6 sessions running: 60GB used, 4GB unused (on a 64GB machine).

Expected Behavior

Claude Code should use ~800MB-1GB of RAM on startup with a responsive terminal, similar to version 2.1.30.

Workaround

• Downgrade to 2.1.30: npm install -g @anthropic-ai/claude-code@2.1.30
• Manually kill orphaned processes: pkill -f claude or killall claude

Additional Notes

• Terminal completely freezes — cannot type or interact at all in 2.1.32
• Affects both npm and native installer — reproduced with both install methods, confirming this is a code-level regression in 2.1.32
• Native installer test: Fresh native install (~/.local/bin/claude) initially showed 461MB at 15 seconds (before full init), but jumped to 11.6GB / 99.2% CPU within 39 seconds after accepting the trust prompt
• Each process pins a CPU core at ~100%, even when idle
• Closing the terminal window does NOT kill the claude process — it continues running in the background
• The --dangerously-skip-permissions flag was used, but this is unlikely to be related to memory allocation

[github-actions]

Found 3 possible duplicate issues:

1. Bug: Claude Code v2.1.27+ hangs with 100% CPU on macOS 26.2 Tahoe (arm64) #23008
2. [BUG] VSCode Extension 2.1.20 - Critical Memory Leak: 11.6GB per conversation window on macOS #21182
3. [Memory Leak] Claude Code 2.1.19 consuming ~12GB RAM on macOS 15.5 #23252

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[ai-is-here]

I am on arch linux. Since yesterday, maybe earlier i am getting 20Gb memory leaks that spin out of control instantly when Claude uses bash tools.
Pretty much unusable tbh.
Also in long sessions, even after closing and starting with --continue, once bash commands in parallel/bg start flying, it gets to infinity ram until OOM.

[0ATAT0]

Confirming this issue persists on Windows 11, v2.1.37 — so this has not been resolved.

Environment

• Claude Code version: 2.1.37
• OS: Windows 11 (win32)
• Hardware: 12 logical processors, 32 GB RAM
• Boot drive: Samsung SSD 980 PRO 500GB (NVMe)

Observed behavior

Fresh system reboot, four Claude Code processes spawned within 10 minutes. Two of them ballooned to multi-GB usage almost immediately with 0% CPU (idle, not doing any work):

~10 minutes after reboot:

PID	RAM	CPU
25892	4,518 MB	0%
28304	2,105 MB	0%
29276	551 MB	0%
23588	384 MB	0%

~20 minutes later (no interaction with the zombie processes):

PID	RAM	CPU
25892	6,663 MB	0%
28304	5,917 MB	0%
29276	1,173 MB	12.3%

Total Claude Code usage hit ~13.7 GB, pushing total system memory to 87% on a 32 GB machine. The two largest processes were idle zombies — 0% CPU, just leaking memory. Only PID 29276 was an active session.

Key observations:

• Memory grows continuously even on idle/zombie processes
• Closing the terminal does NOT kill the process (same as OP's observation on macOS)
• This is not a macOS-specific issue — reproduces on Windows
• /clear and /compact do not free memory (confirmed by CLI process memory accumulates across context resets, not freed until exit #21475)
• Only taskkill /PID <pid> /F reclaims the memory