[BUG] Severe Memory Leak (20GB+)

---

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/11377
2. https://github.com/anthropics/claude-code/issues/4953
3. 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

---

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.

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:

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

Long-term Fix (Needs Anthropic Team)

The proper fix is to:

1. Implement conversation trimming: Auto-remove old messages beyond N tokens
2. Stream large responses to disk: Don't keep full conversation in RAM
3. Garbage collect tool results: Clear bash output after N messages
4. 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.

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

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

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

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

Steps to Reproduce

1. Install Claude Code v2.0.56 native binary on Ubuntu 22.04
2. Launch claude from terminal
3. Monitor memory with htop or watch -n1 'ps -p $(pgrep claude) -o rss,vsz'
4. 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.

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.

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

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.