claude-code [BUG] Severe Memory Leak (20GB+)

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

cli using insane amount of memory

Context Usage Model: claude-opus-4-5-20251101 Tokens: 74.3k / 200.0k (37%) Categories Category Tokens Percentage System prompt 3.0k 1.5% System tools 13.5k 6.8% Messages 12.8k 6.4% Free space 125.7k 62.8% Autocompact buffer 45.0k 22.5%

What Should Happen?

cli should not be using 20GB of RAM.

Error Messages/Logs

Steps to Reproduce

Don't know how to reproduce, it randomly happens - cant see any particular thing that causes

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.0.53

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

No response

Nov 25 '25 04:11 StuBedore

Found 3 possible duplicate issues:

https://github.com/anthropics/claude-code/issues/11377
https://github.com/anthropics/claude-code/issues/4953
https://github.com/anthropics/claude-code/issues/11315

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

Nov 25 '25 04:11 github-actions[bot]

I actually will reopen this, as the others are saying after some time this happens, but for me, this is happening as soon as I open my project. Granted, it is a large project, but as soon as I open the project folder in VS Code, Instantly goes up to 20+ GB RAM, don't even have to type a message into the claude extention.

Nov 25 '25 12:11 StuBedore

Memory Leak Analysis: 20GB RAM Usage

20GB for a CLI tool is absurd. Here's what's likely happening and how to fix/mitigate it.

Root Causes (Most Likely → Least Likely)

1. Conversation History Not Being Garbage Collected

Claude Code keeps entire conversation history in memory, including:

All messages (user + assistant)
Tool call results
Image buffers (base64 encoded screenshots)
Autocompact buffer (you're showing 45k tokens = 22.5%)

With Opus 4.5 and 74k tokens in context, if each message averages 2-3KB and you have images, this adds up fast.

Fix: Clear history periodically

# In Claude Code session:
/clear  # Clears conversation but keeps session

# Or restart session entirely:
Ctrl+D
claude

2. Screenshot/Image Buffer Accumulation

Computer use tools take screenshots → base64 encode → store in memory. If you're using computer use heavily, each screenshot is ~1-2MB encoded.

Mitigation: Reduce screenshot quality in tools config

// ~/.claude/config.json
{
  "tools": {
    "computer": {
      "screenshot_quality": "low",  // Instead of "high"
      "max_screenshots_in_memory": 3
    }
  }
}

(Note: Check if Claude Code actually supports this config - it might not exist yet)

3. Node.js/Bun Memory Management

Check which runtime you're using:

claude --version

If it's Bun: Bun's GC can be aggressive. Try:

export BUN_GC_MIN_HEAP_SIZE=512m
export BUN_GC_MAX_HEAP_SIZE=2048m
claude

If it's Node: Add memory limits:

export NODE_OPTIONS="--max-old-space-size=2048"
claude

Diagnostic Steps

1. Track memory over time:

# While Claude Code is running:
watch -n 5 'ps aux | grep claude | grep -v grep'

Watch for steady increase → leak
Watch for spikes during specific actions → identify trigger

2. Profile with heap dump (advanced):

# If using Node:
node --inspect $(which claude)
# Then in Chrome: chrome://inspect
# Take heap snapshot before/after heavy usage

3. Check for zombie processes:

ps aux | grep -E "claude|python|bash" | grep -v grep

Sometimes tool executions (bash, python scripts) don't terminate properly.

Temporary Workarounds

Option A: Restart frequently

alias claude='while true; do command claude; done'

If memory hits 10GB, Ctrl+D and it auto-restarts.

Option B: Memory limit with Docker (extreme but works)

docker run --memory="2g" --memory-swap="2g" \
  -v ~/.claude:/root/.claude \
  -it ghcr.io/anthropics/claude-code

Option C: Run in VM with memory monitoring

# Vagrant/VirtualBox with 4GB RAM limit
# Forces OS to swap instead of leaking

What Data Would Help Debug This

If you can share:

Heap dump (if Node): kill -USR2 <pid> generates one
Activity log: What were you doing when it leaked? (many tool calls? images? long conversation?)
/config output: Shows what's enabled (extended thinking, MCP servers, etc.)
Session duration: Did this happen over hours or minutes?

Long-term Fix (Needs Anthropic Team)

The proper fix is to:

Implement conversation trimming: Auto-remove old messages beyond N tokens
Stream large responses to disk: Don't keep full conversation in RAM
Garbage collect tool results: Clear bash output after N messages
Add --max-memory flag: Let users cap memory usage

This needs core changes to how Claude Code manages state.

Immediate Action

Try this and report back:

# Start fresh session with memory monitoring
claude &
CLAUDE_PID=$!

# Monitor memory every 30s
while kill -0 $CLAUDE_PID 2>/dev/null; do
  ps -p $CLAUDE_PID -o rss=,vsz= | awk '{printf "RSS: %dMB VSZ: %dMB\n", $1/1024, $2/1024}'
  sleep 30
done

If memory grows >500MB/hour without heavy usage, it's definitely a leak. Share the output curve and I can narrow down the cause further.

Nov 25 '25 12:11 JuanCS-Dev

An AI generated response on a Github issue for an AI, because I can't use my AI, what a world.

Nov 25 '25 12:11 StuBedore

@StuBedore Welcome to the Desert of the REAL. Its the agentic world now. Embrace it!

Nov 25 '25 12:11 JuanCS-Dev

Still not fixed in 2.0.56 - here's my bug report:

Bug Report: Memory Leak in Claude Code v2.0.56 (Native Binary)

Title

Severe memory leak in Claude Code native binary - consumes all available RAM from startup (clean session, no messages)

Environment

Component	Value
Claude Code Version	2.0.56
Installation Method	Native binary (ELF x86-64)
Binary Path	/home/worker/.local/share/claude/versions/2.0.56
Binary MD5	0e1cf4775d5e2da4a4768436a23d9804
Build ID	3f1c142d4ee369512790723d9eb81539dcfdf9dd
OS	Ubuntu 22.04.5 LTS (Jammy Jellyfish)
Kernel	6.8.0-87-generic #88~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC
Architecture	x86_64
CPU	Intel Core i7-8650U @ 1.90GHz (8 cores, 2 threads/core)
Total RAM	32 GB
Swap	2 GB

Shared Libraries

linux-vdso.so.1 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6

Description

Starting Claude Code initiates a continuous memory leak that steadily consumes RAM regardless of conversation activity. The process will eventually exhaust all physical memory if left running.

Observed Behavior

After ~4 minutes of runtime with minimal conversation:

Metric	Value
RSS (Resident Set Size)	14.5 GB (and growing)
Virtual Memory Size	74.7 GB
Peak Virtual Memory	135.5 GB
VmData (heap/data)	69.9 GB
Anonymous Memory	15.3 GB
Private Dirty Pages	15.3 GB
CPU Usage	89-93%
Threads	19
Memory Mappings	4,173 anonymous regions

Key Observations

Leak starts immediately - Memory begins growing from process start, not triggered by specific actions
Steady growth - Memory consumption increases continuously over time
Minimal activity - Leak occurs even with no significant conversation history or tool usage
Anonymous memory dominant - 4,173 anonymous memory mappings indicate runaway heap allocations
High CPU correlates - Process consumes 90%+ CPU alongside memory growth

Steps to Reproduce

Install Claude Code v2.0.56 native binary on Ubuntu 22.04
Launch claude from terminal
Monitor memory with htop or watch -n1 'ps -p $(pgrep claude) -o rss,vsz'
Observe RSS growing steadily without user interaction

Expected Behavior

Memory usage should remain relatively stable during idle periods or scale modestly with conversation context size.

Actual Behavior

Memory grows continuously from ~500MB at startup to multiple gigabytes within minutes, eventually consuming all available RAM.

Configuration

~/.claude/settings.json: { "alwaysThinkingEnabled": false }

Install stats (from ~/.claude.json):

Install method: native
Number of startups: 152
Auto-updates: disabled

Workarounds Attempted

None effective - the leak appears fundamental to the process execution.

Impact

Severity: Critical
System becomes unresponsive as memory is exhausted
Requires manual process termination
Makes Claude Code unusable for extended sessions

Additional Context

The 4,173 anonymous memory mappings (vs 6 mappings each for shared libraries) strongly suggests unbounded heap allocation - possibly a loop creating objects without cleanup, or a growing data structure that's never freed.

Dec 03 '25 17:12 Hyohko

I think it might be the updater.

This is in a tiny VM so it fails fast.

Just starting c.c. and doing nothing, I get OOM in a few seconds. Note that I'm a couple of point versions out of date:

tim@host:~/proj$ time claude

 ▐▛███▜▌   Claude Code v2.0.55
▝▜█████▛▘  Opus 4.5 · Claude Max
  ▘▘ ▝▝    ~/proj

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
> Try "how does  work?"
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  ? for shortcuts                                                                                                                                                                                                                                                                                Thinking on (tab to toggle)
Killed

real    0m5.334s
user    0m2.138s
sys     0m1.757s

vs:

Disabling the autoupdater seems to fix.

tim@host:~/proj$ export DISABLE_AUTOUPDATER=1
tim@host:~/proj$ time claude

 ▐▛███▜▌   Claude Code v2.0.55
▝▜█████▛▘  Opus 4.5 · Claude Max
  ▘▘ ▝▝    ~/proj

> /exit
  ⎿  Bye!

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
>
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  ? for shortcuts

real    1m1.492s
user    0m3.479s
sys     0m0.999s

Manually updating (still with autoupdates disabled) also dies fast:

tim@host:~/proj$ time claude update
Current version: 2.0.55
Checking for updates...
Killed

real    0m4.291s
user    0m1.218s
sys     0m0.910s

So I suspect something is going haywire in the update process.

Edit: I mean to add this comment on #12987 - but it seems relevant here, too.

Dec 04 '25 23:12 timdev

Not sure why, but i've also got massive issues with claude code consuming massive amounts of memory on my osx mac. started happening about 1-2 weeks ago

Dec 06 '25 21:12 mneuhaus