Critical Memory Leak: Claude Code Consumed 129GB RAM and Caused System Freeze

Summary

Claude Code experienced a severe memory leak that consumed 129GB of virtual memory, exhausted all available system RAM (16GB), and caused a complete system freeze requiring a hard reboot.

Environment

Claude Code Version: 2.0.36
OS: Ubuntu 24.04.3 LTS
Kernel: 6.14.0-35-generic
Total RAM: 16GB
CPU: 12 cores
GPU: NVIDIA GeForce GTX 1070

Incident Details

Timeline (from sysstat data)

11:00:10 AM - Memory used: 11.17% (11 GB free)
11:10:08 AM - Memory used: 19.63% (8.5 GB free)
11:20:10 AM - Memory used: 55.87% (5.5 GB free)  <- Rapid increase
11:30:10 AM - Memory used: 78.34% (1.1 GB free)  <- Critical
11:33:16 AM - LINUX RESTART (complete system freeze)

Memory consumption increased from ~2GB to ~12GB in just 30 minutes, with no other resource-intensive applications running.

Process Memory Statistics (Post-Restart)

Name:      claude
Pid:       3740
VmPeak:    135508316 kB  (129 GB!)
VmSize:    75721528 kB   (72 GB)
VmHWM:     569132 kB     (556 MB peak resident)
VmRSS:     425416 kB     (415 MB current resident)
VmData:    71003864 kB   (68 GB data segment)
Threads:   19

Symptoms

Gradual memory consumption over ~30 minutes
Virtual memory peaked at 129GB (8x available physical RAM)
System became completely unresponsive
No kernel panic or OOM killer activation - just a hard freeze
No swap usage (swap was at 0B throughout)
Required hard power reset

System Logs

No warnings or errors before the freeze - the system just stopped logging at 11:31:19 AM. This indicates a complete kernel/hardware lockup due to memory exhaustion.

Last Activity Before Freeze

Nov 09 11:31:19 nick-System-Product-Name anacron[5742]: Normal exit (0 jobs run)
[No further logs until forced reboot at 11:33:16]

Expected Behavior

Claude Code should:

Have reasonable memory bounds
Implement memory management/garbage collection
Not consume more than a few GB of RAM during normal operation
Release memory when not actively processing

Actual Behavior

Virtual memory ballooned to 129GB
Physical memory consumption grew from ~2GB to ~12GB in 30 minutes
System froze completely with no recovery possible

Reproduction

Unknown - this occurred during normal Claude Code usage. User reports this has happened multiple times.

Impact

Severity: Critical
Complete system lockup
Data loss risk (requires hard reboot)
System unusable until reboot

Additional Context

After reboot, the Claude Code process still shows 72GB virtual memory allocation, suggesting the leak condition persists and could recur at any time.

Suggested Investigation

Memory profiling of the Claude Code process
Check for circular references or unreleased resources
Review context/conversation history storage (might be accumulating)
Check if there's unbounded caching
Review event listener cleanup

Workaround

Currently monitoring with: watch -n 1 'ps aux --sort=-%mem | head -5'
Plan to restart Claude Code when memory usage exceeds safe threshold.

Hello guys! Isn't there a permanent fix for this issue? Or a workaround?

I'm experiencing this as well.

Also experiencing this, Debian 13. Same symptoms and issue as described in original post. Has happened to me 20+ times, and frequently happens when calling subtasks or when working with multiple CC agents at once.

Experiencing this as well. It's taking down other services on my Ubuntu server with 64gb of RAM.

Same issue here. It usually happened when I restarted cursor with multiple windows of different projects opened, that had a claude session running. Seems claude tries to restore the session and then runs into a memory leak.

This is critical bug. Just installing claude code with command curl -fsSL https://claude.ai/install.sh | bash froze entire ec2 t3.small instance (aws linux OS). It's no longer accessible using ssh unless rebooted.

Same issue here with Version 2.0.61 (Claude Code), But it spiked to 11 GB, then dropped to 5 GB, then back to 200 MB (without any interaction) while normal usage (not installation)

Critical Memory Leak in Claude Code - Comprehensive Analysis

For Anthropic Engineers: Jump to Root Cause Analysis and What Needs to Be Fixed

Executive Summary

Claude Code has a severe memory management bug that causes each process to allocate 26-129GB of virtual memory regardless of actual usage. On systems with 16GB RAM, this leads to:

Complete swap exhaustion
System-wide freezes requiring hard reboot
Total loss of work in progress

This bug has been documented since July 2025 and remains unfixed as of December 2025.

The Problem Visualized

┌─────────────────────────────────────────────────────────────────────┐
│                    MEMORY ALLOCATION vs REALITY                      │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│   What Claude Code Allocates (per process):                         │
│   ████████████████████████████████████████████████████  26-129 GB   │
│                                                                      │
│   What It Actually Uses (RSS):                                      │
│   ██░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  400MB-2GB   │
│                                                                      │
│   Typical System RAM:                                                │
│   ████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  16 GB       │
│                                                                      │
│   Multiple Sessions (11 instances):                                  │
│   ██████████████████████████████████████████████...(286 GB demand)  │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Exposed Symptoms

Symptom	Severity	User Impact
Swap fills to 100%	High	System becomes sluggish
Terminal freezes completely	Critical	Cannot Ctrl+C, no response
System hard-locks	Critical	Requires power cycle
Orphaned processes after crash	Medium	Manual cleanup required
Work loss from crashed sessions	High	Hours of context lost
False rate limit dialog appears	Medium	Precursor warning sign

Critical Discovery: The Rate Limit → Freeze Chain

Key Finding: A false rate limit dialog often appears immediately before the freeze. This is not coincidental.

The Trigger Sequence

┌─────────────────────────────────────────────────────────────────────┐
│              RATE LIMIT → SERIALIZATION → FREEZE                    │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  1. Rate limit dialog appears (even when NOT near limit)            │
│                         ↓                                            │
│  2. Claude triggers state/context serialization                     │
│     (to save progress before potential interruption)                │
│                         ↓                                            │
│  3. JSON.stringify hits circular refs or deep nesting               │
│     in conversation history / context objects                       │
│                         ↓                                            │
│  4. V8 enters 2000+ recursive serialization calls                   │
│                         ↓                                            │
│  5. Memory thrashing begins: mmap/munmap at 98% CPU                 │
│     Memory oscillates: 1GB → 278MB → 1GB → ...                      │
│                         ↓                                            │
│  6. COMPLETE FREEZE - Ctrl+C ignored, terminal dead                 │
│                         ↓                                            │
│  7. Swap fills as kernel backs virtual allocations                  │
│                         ↓                                            │
│  8. System hard-lock (if earlyoom not installed)                    │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Evidence from GitHub Issue #4580

Process sampling during freeze shows V8 stuck in JSON serialization:

v8::internal::JsonStringifier::Serialize_<false>    ← 2000+ recursive calls
v8::internal::JsonStringifier::SerializeArrayLikeSlow
v8::internal::IncrementalStringBuilder::Extend

Strace output reveals pathological memory behavior:

% time     seconds    syscall
------  -----------  ---------
 98.18    1.010657    munmap     ← Memory deallocation thrashing
  0.87    0.008924    futex
  0.42    0.004315    mmap       ← Continuous remapping

Why False Rate Limits Matter

The rate limit dialog (even when incorrect) triggers defensive state serialization - Claude tries to save your work before a potential interruption. If your conversation context:

Has circular references (objects referencing each other)
Has deep nesting (long conversation with many tool calls)
Contains large embedded data (file contents, search results)

...then JSON.stringify() enters an infinite-like recursion, consuming CPU and thrashing memory.

Warning Signs (Observed Pattern)

/rate-limit-options dialog appears unexpectedly
You're not actually near your rate limit (check usage dashboard)
Terminal becomes sluggish within seconds
Complete freeze follows shortly after

If you see this pattern: immediately run /clear or kill the session before it freezes.

Reproduction Case Study

System: Ubuntu 24.04 LTS, 16GB RAM, 4GB swap, kernel 6.8.0-88-generic
Claude Code Version: 2.0.64
Workload: 11 concurrent Claude Code sessions (normal development workflow)

Memory State When Frozen

$ free -h
              total    used    free    shared  buff/cache   available
Mem:           15Gi    8.3Gi   2.5Gi    1.2Gi       5.1Gi       6.3Gi
Swap:         4.0Gi    4.0Gi   7.1Mi      # <-- 100% FULL

Process Analysis

$ ps aux | grep claude | awk '{sum += $6} END {print sum/1024 " MB"}'
7372.8 MB   # RSS across 11 sessions

$ ps aux | grep claude | head -1
USER    PID   %CPU  %MEM    VSZ      RSS    STAT  COMMAND
user  12345   2.1   4.2   26812636  533752  Sl    claude  # 26GB VSZ!

The Smoking Gun

Each Claude process shows:

VSZ (Virtual): 26,812,636 KB (~26 GB)
RSS (Resident): 533,752 KB (~520 MB)
Ratio: 50:1 virtual-to-resident

This is not normal. A healthy Node.js application should have VSZ:RSS ratios of 2-5:1, not 50:1.

Related GitHub Issues

Issue	Date	Title	Status
#8382	Oct 2025	26GB allocation per process on 16GB system	Closed (dup)
#11315	Nov 2025	129GB consumption, complete system freeze	Open
#11377	Nov 2025	23GB RAM + 143% CPU after 14 hours	Open
#4953	Aug 2025	120GB growth before OOM kill	Open
#10505	Oct 2025	28GB from `--continue`, 13GB swap	Open
#7020	Sep 2025	Sub-agent orchestration: 450MB → 30GB+	Open
#3282	Jul 2025	Frozen at startup, memory leak	Open
#4580	Jul 2025	JSON serialization freeze at 100% CPU	Open
#12542	Nov 2025	False rate limit at <50% actual usage	Closed (dup)

Pattern: Every issue involves massive virtual memory allocation disproportionate to actual usage.

New Pattern Identified: False rate limit → state serialization → JSON.stringify freeze → memory thrash → system lock.

Root Cause Analysis

Primary Issue: Unbounded Virtual Memory Reservation

Claude Code (or its dependencies) is calling mmap() or equivalent with massive size requests without corresponding memory usage. This creates huge virtual address space reservations that:

Don't immediately consume RAM (hence low RSS)
Do consume swap backing when the kernel tries to ensure pages can be satisfied
Accumulate across sessions until swap is exhausted

Likely Code Locations

Based on the symptoms, investigate these areas:

┌─────────────────────────────────────────────────────────────────────┐
│  SUSPECTED LEAK SOURCES                                             │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  1. V8 Heap Configuration                                           │
│     └─ Node.js may be configured with unlimited heap growth         │
│     └─ Check: --max-old-space-size not set or set too high         │
│                                                                      │
│  2. Task() Agent Spawning                                           │
│     └─ Each sub-agent may inherit/duplicate memory reservations    │
│     └─ Parallel agents multiply the problem                         │
│                                                                      │
│  3. Conversation History Caching                                    │
│     └─ Unbounded context accumulation                               │
│     └─ No eviction policy for old conversation data                │
│                                                                      │
│  4. Native Module Memory                                            │
│     └─ N-API or native addons with their own allocators            │
│     └─ May not respect Node.js heap limits                         │
│                                                                      │
│  5. Worker Threads                                                  │
│     └─ Each worker gets its own V8 isolate                         │
│     └─ Memory not properly released on worker termination          │
│                                                                      │
│  6. JSON Serialization (CONFIRMED - Issue #4580)                   │
│     └─ State serialization triggered by rate limit events          │
│     └─ Circular references cause infinite recursion                │
│     └─ No depth limit or timeout on JSON.stringify()               │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

Evidence Supporting Each Theory

Theory	Supporting Evidence
V8 Heap	VSZ grows unbounded; `--max-old-space-size` workaround helps
Task() Agents	Issue #8382 specifically triggered by parallel Task() calls
History Cache	Issue #12221 mentions 500+ sessions, 488MB conversation data
Native Modules	Gap between VSZ and RSS suggests non-JS allocations
Worker Threads	19 threads reported in Issue #11315 process stats
JSON Serialization	CONFIRMED: #4580 shows 2000+ recursive stringify calls, 98% CPU in munmap

What Needs to Be Fixed

For Anthropic Engineers

// REQUIRED FIXES (in priority order):

// 1. Set explicit V8 heap limits in package.json or startup
//    Current: unlimited (or excessively high)
//    Required: Reasonable limit based on expected workload
process.env.NODE_OPTIONS = '--max-old-space-size=4096'; // 4GB max

// 2. Implement memory pressure monitoring
const v8 = require('v8');
const heapStats = v8.getHeapStatistics();
if (heapStats.used_heap_size > THRESHOLD) {
    // Trigger garbage collection
    // Evict old conversation cache
    // Warn user
}

// 3. Bound conversation history cache
class ConversationCache {
    constructor(maxSizeMB = 100) {
        this.maxSize = maxSizeMB * 1024 * 1024;
        // Implement LRU eviction
    }
}

// 4. Clean up Task() agent resources
async function runTask(agent) {
    try {
        return await agent.execute();
    } finally {
        agent.cleanup();  // <-- THIS IS LIKELY MISSING
        global.gc?.();    // Hint to V8
    }
}

// 5. Add memory limits to spawned processes
const { fork } = require('child_process');
const child = fork(script, args, {
    execArgv: ['--max-old-space-size=2048'],  // Limit child too
    resourceLimits: {
        maxOldGenerationSizeMb: 2048,
        maxYoungGenerationSizeMb: 512
    }
});

// 6. FIX JSON SERIALIZATION (CRITICAL - Issue #4580)
//    Replace naive JSON.stringify with safe serializer
function safeStringify(obj, maxDepth = 50, maxSize = 10_000_000) {
    const seen = new WeakSet();
    let size = 0;

    return JSON.stringify(obj, function(key, value) {
        // Prevent circular references
        if (typeof value === 'object' && value !== null) {
            if (seen.has(value)) {
                return '[Circular]';
            }
            seen.add(value);
        }

        // Track size, abort if too large
        size += String(value).length;
        if (size > maxSize) {
            throw new Error('Serialization size limit exceeded');
        }

        return value;
    });
}

// 7. Add timeout wrapper for serialization operations
async function serializeWithTimeout(obj, timeoutMs = 5000) {
    return Promise.race([
        new Promise(resolve => resolve(safeStringify(obj))),
        new Promise((_, reject) =>
            setTimeout(() => reject(new Error('Serialization timeout')), timeoutMs)
        )
    ]);
}

Immediate Architectural Recommendations

Add --max-old-space-size to CLI launcher - Simple, immediate impact
Implement memory watchdog - Kill/restart before system freeze
Audit mmap() calls - Find what's reserving 26GB+ per process
Add resource limits to worker threads - Prevent unbounded growth
Implement conversation cache eviction - LRU with size limit
Replace JSON.stringify with safe serializer - CRITICAL: prevents freeze chain
Add serialization timeout - Abort after 5 seconds, not infinite loop
Decouple rate limit handling from serialization - Don't trigger full state save on rate limit events

Real Workarounds (Until Fixed)

These are actual technical mitigations, not "just restart constantly":

1. Limit Node.js Heap (Most Effective)

# Add to ~/.bashrc or ~/.zshrc
export NODE_OPTIONS="--max-old-space-size=4096"

# Or create a wrapper script
cat > ~/bin/claude-limited << 'EOF'
#!/bin/bash
export NODE_OPTIONS="--max-old-space-size=4096"
exec claude "$@"
EOF
chmod +x ~/bin/claude-limited

2. Install earlyoom (Prevents Hard Freeze)

# Kills memory hogs BEFORE system locks up
sudo apt install earlyoom
sudo systemctl enable --now earlyoom

# Configure thresholds in /etc/default/earlyoom
EARLYOOM_ARGS="-m 5 -s 5 --prefer '^(claude|node)$'"

3. Enable zswap (Compressed RAM-backed Swap)

# 2-3x effective swap, much faster than disk
echo lz4 | sudo tee /sys/module/zswap/parameters/compressor
echo 1 | sudo tee /sys/module/zswap/parameters/enabled
echo 25 | sudo tee /sys/module/zswap/parameters/max_pool_percent

# Make persistent in /etc/default/grub:
# GRUB_CMDLINE_LINUX="zswap.enabled=1 zswap.compressor=lz4"

4. cgroups Memory Limit (Hard Cap)

# Create systemd slice for Claude sessions
sudo mkdir -p /etc/systemd/system/user-.slice.d/
cat << 'EOF' | sudo tee /etc/systemd/system/claude.slice
[Slice]
MemoryMax=8G
MemorySwapMax=2G
EOF

# Run Claude under this slice
systemd-run --user --slice=claude.slice claude

5. Increase OOM Priority (Die First, Save System)

# Make Claude processes first to die under memory pressure
# Add to a cron job or run periodically
pgrep -f 'claude' | while read pid; do
    echo 500 | sudo tee /proc/$pid/oom_score_adj >/dev/null
done

6. Monitor and Auto-Kill Script

#!/bin/bash
# Save as ~/bin/claude-watchdog.sh

MAX_VSZ_GB=20
CHECK_INTERVAL=60

while true; do
    for pid in $(pgrep -f claude); do
        vsz_kb=$(ps -o vsz= -p $pid 2>/dev/null)
        vsz_gb=$((vsz_kb / 1024 / 1024))
        if [ "$vsz_gb" -gt "$MAX_VSZ_GB" ]; then
            echo "$(date): Killing claude PID $pid (VSZ: ${vsz_gb}GB)"
            kill -15 $pid
            sleep 5
            kill -9 $pid 2>/dev/null
        fi
    done
    sleep $CHECK_INTERVAL
done

7. Malloc Tuning (Reduces Thrashing - from Issue #4580)

# Add to ~/.bashrc or wrapper script
# Reduces mmap/munmap thrashing during JSON serialization

export MALLOC_TRIM_THRESHOLD_=-1        # Disable malloc trimming
export MALLOC_MMAP_THRESHOLD_=134217728 # 128MB threshold for mmap
export MALLOC_ARENA_MAX=4               # Limit memory arenas
export NODE_OPTIONS="--max-old-space-size=4096"

# Then run claude normally
claude

This reduces the 98% CPU spent on munmap calls but doesn't fix the root cause.

8. Emergency Response: When Rate Limit Dialog Appears

If you see /rate-limit-options and you're not near your limit:

# IMMEDIATELY in another terminal:
pgrep -f claude | xargs -I {} kill -15 {}

# Or use the escape hatch BEFORE freeze completes:
# Press Ctrl+C repeatedly (may still work in first 2-3 seconds)
# Then run: claude --resume

Recommended System Configuration

For systems running Claude Code regularly:

Setting	Recommended	Why
RAM	32GB+	Each session can spike to 2-4GB RSS
Swap	8-16GB	Buffer for memory spikes
zswap	Enabled (lz4)	3x effective swap, faster access
earlyoom	Installed	Prevents hard freeze
vm.swappiness	10	Prefer RAM, swap only when needed
NODE_OPTIONS	`--max-old-space-size=4096`	Hard cap on V8 heap

Call to Action

For Anthropic:

This bug has persisted for 6+ months across major versions
Users are losing work and experiencing system crashes
The workarounds should be built into the application, not user-applied
A CLI tool should never be able to hard-lock a system

For Users:

Apply the workarounds above
Report your specific crash conditions to help narrow the cause
Consider running fewer concurrent sessions until fixed

Appendix: Commands for Diagnosis

# Check current Claude memory usage
ps aux | grep -E 'PID|claude' | grep -v grep

# Detailed memory breakdown
for pid in $(pgrep -f claude); do
    echo "=== PID $pid ==="
    cat /proc/$pid/status | grep -E '^(Name|VmPeak|VmSize|VmRSS|VmData|Threads)'
done

# Watch memory in real-time
watch -n 1 'ps aux --sort=-%mem | head -10; echo "---"; free -h'

# Check swap usage breakdown
for pid in $(pgrep -f claude); do
    swap=$(awk '/VmSwap/{print $2}' /proc/$pid/status 2>/dev/null)
    echo "PID $pid: ${swap:-0} kB in swap"
done

# System memory pressure
cat /proc/pressure/memory

Report compiled: December 2025
Last updated: 2025-12-10
Environment: Ubuntu 24.04 LTS (kernel 6.8.0-88-generic), Claude Code v2.0.64

I started running out of diskspace as it filled it's virutal memory to 74gb per claude instance. this is clearly wrong.

This is becoming so annoying. Can't you ask your "famous" Mythos to fix this bug?

This happens to me even with a tiny conversation (~ 20 kB instructions in CLAUDE.md and ~ 20 mostly oneliner backs and forths). Claude Code, while sitting idle (!), allocating 50 MB/s of RAM.

I found temporary fix, disable claude self update, it occurs when claude update. at least using stable line for update

@/tmp/cc-reaper-comment-11315.md

In my case, I discovered that the real problem was Claude Desktop. Preventing Claude Desktop from automatically starting at system startup solved the problem. It seems that Claude Desktop consumes memory even when not in use, remaining idle.

On Linux, look into setting up earlyoom. It's been a life saver for me to prevent lock-ups. I have mine configured to keep at least 5% of RAM available and with its --prefer and --avoid arguments it can be pretty friendly.

@Ilya0527

@Ilya0527 the graphics driver angle is interesting -- that's what another LLM (Sonnet 4.6 -- not sure what you are) also suggested after showing it my journalctl output from right before the freeze. However, I'm on AMD and Radeon with the open-source drivers.

I keep seeing large virtual memory size (#11315 (comment)) on an old Intel i5-6300U machine, with Intel integrated graphics. However, the resident memory usage appears lower since Claude version 2.1.1XX. The high resident memory usage behavior seems random (it always was random), now it does not even appear during Claude installation or update, so it's hard to make conclusions.

In the past OOM killer was not preventing a hard freeze of the machine, maybe the freeze was due to something else than memory? Therefore for the past several months I'm running Claude Code confined to a limited resource (16GB) virtual machine in Vagrant, to it freeze instead, and indeed every few days the machine is unrecoverable. Unfortunately, Vagrant itself is known for freezes, so again no conclusions, except the improvement that since February I had only one hard host system freeze.

I can confirm that I've seen much reduced resident memory usage too as of late 💐 I dug through the Claude Code changelog but couldn't spontaneously find a mention of memory-related fixes though.

On the other hand, people report resident memory still growing with 2.1.143 #4953 (comment), and claude update itself being killed.

Another attempt (2.1.159 (Claude Code)) at an installation of curl -fsSL https://claude.ai/install.sh | bash on a fresh virtual machine (nothing under ~/.claude) still caused resident memory RES to grow to over 11GB and virtual machine to freeze (like in #11315 (comment)), but the host laptop did not freeze. Also linked here #4953 (comment).

Same here, claude --update eats whole available memory during an update process. Update installed but memory usage is terrible.

@SevenSystems

@SevenSystems

Improved background-session teardown (claude rm/stop, idle reap) to send SIGTERM to running shell subprocesses before SIGKILL, so cleanup handlers run

It was fixed in 2.1.160 according to the CHANGELOG.

I guess claude --update messing up is a new bug.

The memory usage during Claude Code installation (install.sh on Linux) is now reduced #79421, but 2.1.274 (Claude Code) still keeps exhausting the available RAM (RSS) on a 12GB Linux virtual machine, causing an unrecoverable freeze, and sometimes, where other memory heavy programs are runnung, also manages to freeze the 32GB Linux laptop hosting the virtual machine.

I am still having this problem despite upgrading to the latest version.

Used the systemd-run workaround to prevent my whole system from going down, but still get regular crashes, often at the very end of a complex task right after it generares a markdown report of what has been done.

Critical Memory Leak: Claude Code Consumed 129GB RAM and Caused System Freeze #11315

Description

Critical Memory Leak: Claude Code Consumed 129GB RAM and Caused System Freeze

Summary

Environment

Incident Details

Timeline (from sysstat data)

Process Memory Statistics (Post-Restart)

Symptoms

System Logs

Last Activity Before Freeze

Expected Behavior

Actual Behavior

Reproduction

Impact

Additional Context

Suggested Investigation

Workaround

Activity

mosabalhsseini commented on Nov 16, 2025

chrismgonzalez commented on Nov 21, 2025

Lincoln504 commented on Nov 27, 2025

isaaclyon commented on Nov 30, 2025

timobehrens commented on Dec 4, 2025

ShJavokhir commented on Dec 4, 2025

tom-010 commented on Dec 8, 2025

smconner commented on Dec 10, 2025

Critical Memory Leak in Claude Code - Comprehensive Analysis

Executive Summary

The Problem Visualized

Exposed Symptoms

Critical Discovery: The Rate Limit → Freeze Chain

The Trigger Sequence

Evidence from GitHub Issue #4580

Why False Rate Limits Matter

Warning Signs (Observed Pattern)

Reproduction Case Study

Memory State When Frozen

Process Analysis

The Smoking Gun

Related GitHub Issues

Root Cause Analysis

Primary Issue: Unbounded Virtual Memory Reservation

Likely Code Locations

Evidence Supporting Each Theory

What Needs to Be Fixed

For Anthropic Engineers

Immediate Architectural Recommendations

Real Workarounds (Until Fixed)

1. Limit Node.js Heap (Most Effective)

2. Install earlyoom (Prevents Hard Freeze)

3. Enable zswap (Compressed RAM-backed Swap)

4. cgroups Memory Limit (Hard Cap)

5. Increase OOM Priority (Die First, Save System)

6. Monitor and Auto-Kill Script

7. Malloc Tuning (Reduces Thrashing - from Issue #4580)

8. Emergency Response: When Rate Limit Dialog Appears

Recommended System Configuration

Call to Action

Appendix: Commands for Diagnosis

nklisch commented on Jan 8, 2026

41 remaining items

dom-cmyk commented on May 4, 2026

SevenSystems commented on May 7, 2026

RindraCoG commented on May 8, 2026

theQuert commented on May 14, 2026

ezin82 commented on May 14, 2026

vphantom commented on May 18, 2026

SevenSystems commented on May 19, 2026

marcindulak commented on May 19, 2026

SevenSystems commented on May 19, 2026

marcindulak commented on May 19, 2026

marcindulak commented on Jun 1, 2026

igor-vyatkin commented on Jun 9, 2026

parth-io commented on Jun 11, 2026

marcindulak commented on Sep 19, 2026

kgish commented on Oct 12, 2026

Metadata

Metadata

Assignees