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

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.

<img width="1593" height="507" alt="Image" src="https://github.com/user-attachments/assets/593c2c18-e674-43c4-a21c-0f34a3f69e1c" />

<img width="1564" height="719" alt="Image" src="https://github.com/user-attachments/assets/72a9b62e-0a02-4ed0-8c72-38d24b4ffd95" />

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](#root-cause-analysis) and [What Needs to Be Fixed](#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)

1. /rate-limit-options dialog appears unexpectedly
2. You're not actually near your rate limit (check usage dashboard)
3. Terminal becomes sluggish within seconds
4. 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:

1. Don't immediately consume RAM (hence low RSS)
2. Do consume swap backing when the kernel tries to ensure pages can be satisfied
3. 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

1. Add --max-old-space-size to CLI launcher - Simple, immediate impact
2. Implement memory watchdog - Kill/restart before system freeze
3. Audit mmap() calls - Find what's reserving 26GB+ per process
4. Add resource limits to worker threads - Prevent unbounded growth
5. Implement conversation cache eviction - LRU with size limit
6. Replace JSON.stringify with safe serializer - CRITICAL: prevents freeze chain
7. Add serialization timeout - Abort after 5 seconds, not infinite loop
8. 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.

I'm having similar issue on 2.1.2. Short session with python and pip bash commands and system locked down from ~500mb which spike quickly. Cloudflare container standard-1 instance.

I am having similar issue, it is persistent on all versions, I am on archlinux

Same issue, debian.

Seeing 72gb in WSL2

<html>
<body>
<!--StartFragment--><h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Same issue on WSL2 with Multi-Root Workspace - Detailed diagnosis</h2>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Environment</h3>
<ul class="[li_&amp;]:mb-0 [li_&amp;]:mt-1 [li_&amp;]:gap-1 [&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2"><strong>Claude Code Version</strong>: 2.1.9 (VS Code extension)</li>
<li class="whitespace-normal break-words pl-2"><strong>OS</strong>: Windows 11 + WSL2 Ubuntu 24.04</li>
<li class="whitespace-normal break-words pl-2"><strong>Kernel</strong>: 6.6.87.2-microsoft-standard-WSL2</li>
<li class="whitespace-normal break-words pl-2"><strong>RAM</strong>: 16GB physical, 12GB allocated to WSL2, 16GB swap</li>
<li class="whitespace-normal break-words pl-2"><strong>inotify limit</strong>: Already set to 524,288</li>
</ul>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Workspace Configuration</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Multi-root workspace with 4 projects totaling <strong>157,550 files</strong>:</p>
<ul class="[li_&amp;]:mb-0 [li_&amp;]:mt-1 [li_&amp;]:gap-1 [&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">React Native app (local): 110,480 files (mostly node_modules)</li>
<li class="whitespace-normal break-words pl-2">WordPress site (SSHFS mount): 47,070 files</li>
<li class="whitespace-normal break-words pl-2">2 small utility folders: ~80 files</li>
</ul>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Observed Behavior</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">When opening the multi-root workspace and starting a Claude Code conversation:</p>
<ul class="[li_&amp;]:mb-0 [li_&amp;]:mt-1 [li_&amp;]:gap-1 [&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">Memory immediately spikes to <strong>11GB RSS / 82GB+ VSZ</strong></li>
<li class="whitespace-normal break-words pl-2">System reaches <strong>98% memory usage</strong> within seconds</li>
<li class="whitespace-normal break-words pl-2">Swap usage climbs to 4-5GB</li>
<li class="whitespace-normal break-words pl-2">Extension crashes with "Reload Window" prompt</li>
</ul>
<div class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg"><div class="sticky opacity-0 group-hover/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"><button class="inline-flex
items-center
justify-center
relative
shrink-0
can-focus
select-none
disabled:pointer-events-none
disabled:opacity-50
disabled:shadow-none
disabled:drop-shadow-none border-transparent
transition
font-base
duration-300
ease-[cubic-bezier(0.165,0.85,0.45,1)] h-8 w-8 rounded-md active:scale-95 backdrop-blur-md Button_ghost__BUAoh" type="button" aria-label="Copier dans le presse-papiers" data-state="closed"><div class="relative"><div class="transition-all opacity-100 scale-100" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="transition-all opacity-100 scale-100" aria-hidden="true" style="flex-shrink: 0;"><path d="M12.5 3C13.3284 3 14 3.67157 14 4.5V6H15.5C16.3284 6 17 6.67157 17 7.5V15.5C17 16.3284 16.3284 17 15.5 17H7.5C6.67157 17 6 16.3284 6 15.5V14H4.5C3.67157 14 3 13.3284 3 12.5V4.5C3 3.67157 3.67157 3 4.5 3H12.5ZM14 12.5C14 13.3284 13.3284 14 12.5 14H7V15.5C7 15.7761 7.22386 16 7.5 16H15.5C15.7761 16 16 15.7761 16 15.5V7.5C16 7.22386 15.7761 7 15.5 7H14V12.5ZM4.5 4C4.22386 4 4 4.22386 4 4.5V12.5C4 12.7761 4.22386 13 4.5 13H12.5C12.7761 13 13 12.7761 13 12.5V4.5C13 4.22386 12.7761 4 12.5 4H4.5Z"></path></svg></div><div class="absolute top-0 left-0 transition-all opacity-0 scale-50" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="absolute top-0 left-0 transition-all opacity-0 scale-50" aria-hidden="true" style="flex-shrink: 0;"><path d="M15.1883 5.10908C15.3699 4.96398 15.6346 4.96153 15.8202 5.11592C16.0056 5.27067 16.0504 5.53125 15.9403 5.73605L15.8836 5.82003L8.38354 14.8202C8.29361 14.9279 8.16242 14.9925 8.02221 14.9989C7.88203 15.0051 7.74545 14.9526 7.64622 14.8534L4.14617 11.3533L4.08172 11.2752C3.95384 11.0811 3.97542 10.817 4.14617 10.6463C4.31693 10.4755 4.58105 10.4539 4.77509 10.5818L4.85321 10.6463L7.96556 13.7586L15.1161 5.1794L15.1883 5.10908Z"></path></svg></div></div></button></div></div><div><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed" style="background: transparent; color: rgb(171, 178, 191); text-shadow: rgba(0, 0, 0, 0.3) 0px 1px; font-family: var(--font-mono); direction: ltr; text-align: left; white-space: pre; word-spacing: normal; word-break: normal; line-height: 1.5; tab-size: 2; hyphens: none; padding: 1em; margin: 0.5em 0px; overflow: auto; border-radius: 0.3em;"><code style="background: transparent; color: rgb(171, 178, 191); text-shadow: rgba(0, 0, 0, 0.3) 0px 1px; font-family: var(--font-mono); direction: ltr; text-align: left; white-space: pre-wrap; word-spacing: normal; word-break: normal; line-height: 1.5; tab-size: 2; hyphens: none;"><span><span>USER PID %CPU %MEM VSZ RSS
</span></span><span>claude 995 194 91.1 98587860 11162396</span></code></pre></div></div>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Critical Finding: Non-linear memory explosion</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">I ran isolation tests on each project separately:</p>
<div class="overflow-x-auto w-full px-2 mb-6">
Configuration | Files | Claude Code RAM | Result
-- | -- | -- | --
React Native alone | 110,480 | 470 MB | ✅ Stable
WordPress alone (SSHFS) | 47,070 | 480 MB | ✅ Stable
Both combined (multi-root) | 157,550 | 11 GB | ❌ CRASH

</div>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Key insight about <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">permissions.deny</code></h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">I configured <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">.claude/settings.local.json</code> with extensive deny rules:</p>
<div class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg"><div class="sticky opacity-0 group-hover/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"><button class="inline-flex
items-center
justify-center
relative
shrink-0
can-focus
select-none
disabled:pointer-events-none
disabled:opacity-50
disabled:shadow-none
disabled:drop-shadow-none border-transparent
transition
font-base
duration-300
ease-[cubic-bezier(0.165,0.85,0.45,1)] h-8 w-8 rounded-md active:scale-95 backdrop-blur-md Button_ghost__BUAoh" type="button" aria-label="Copier dans le presse-papiers" data-state="closed"><div class="relative"><div class="transition-all opacity-100 scale-100" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="transition-all opacity-100 scale-100" aria-hidden="true" style="flex-shrink: 0;"><path d="M12.5 3C13.3284 3 14 3.67157 14 4.5V6H15.5C16.3284 6 17 6.67157 17 7.5V15.5C17 16.3284 16.3284 17 15.5 17H7.5C6.67157 17 6 16.3284 6 15.5V14H4.5C3.67157 14 3 13.3284 3 12.5V4.5C3 3.67157 3.67157 3 4.5 3H12.5ZM14 12.5C14 13.3284 13.3284 14 12.5 14H7V15.5C7 15.7761 7.22386 16 7.5 16H15.5C15.7761 16 16 15.7761 16 15.5V7.5C16 7.22386 15.7761 7 15.5 7H14V12.5ZM4.5 4C4.22386 4 4 4.22386 4 4.5V12.5C4 12.7761 4.22386 13 4.5 13H12.5C12.7761 13 13 12.7761 13 12.5V4.5C13 4.22386 12.7761 4 12.5 4H4.5Z"></path></svg></div><div class="absolute top-0 left-0 transition-all opacity-0 scale-50" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="absolute top-0 left-0 transition-all opacity-0 scale-50" aria-hidden="true" style="flex-shrink: 0;"><path d="M15.1883 5.10908C15.3699 4.96398 15.6346 4.96153 15.8202 5.11592C16.0056 5.27067 16.0504 5.53125 15.9403 5.73605L15.8836 5.82003L8.38354 14.8202C8.29361 14.9279 8.16242 14.9925 8.02221 14.9989C7.88203 15.0051 7.74545 14.9526 7.64622 14.8534L4.14617 11.3533L4.08172 11.2752C3.95384 11.0811 3.97542 10.817 4.14617 10.6463C4.31693 10.4755 4.58105 10.4539 4.77509 10.5818L4.85321 10.6463L7.96556 13.7586L15.1161 5.1794L15.1883 5.10908Z"></path></svg></div></div></button></div></div><div class="text-text-500 font-small p-3.5 pb-0">json</div><div><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed" style="background: transparent; color: rgb(171, 178, 191); text-shadow: rgba(0, 0, 0, 0.3) 0px 1px; font-family: var(--font-mono); direction: ltr; text-align: left; white-space: pre; word-spacing: normal; word-break: normal; line-height: 1.5; tab-size: 2; hyphens: none; padding: 1em; margin: 0.5em 0px; overflow: auto; border-radius: 0.3em;"><code class="language-json" style="background: transparent; color: rgb(171, 178, 191); text-shadow: rgba(0, 0, 0, 0.3) 0px 1px; font-family: var(--font-mono); direction: ltr; text-align: left; white-space: pre; word-spacing: normal; word-break: normal; line-height: 1.5; tab-size: 2; hyphens: none;"><span><span class="token" style="color: rgb(171, 178, 191);">{</span><span>
</span></span><span><span> </span><span class="token" style="color: rgb(224, 108, 117);">"permissions"</span><span class="token" style="color: rgb(97, 175, 239);">:</span><span> </span><span class="token" style="color: rgb(171, 178, 191);">{</span><span>
</span></span><span><span> </span><span class="token" style="color: rgb(224, 108, 117);">"deny"</span><span class="token" style="color: rgb(97, 175, 239);">:</span><span> </span><span class="token" style="color: rgb(171, 178, 191);">[</span><span>
</span></span><span><span> </span><span class="token" style="color: rgb(152, 195, 121);">"Read(./node_modules/)"</span><span class="token" style="color: rgb(171, 178, 191);">,</span><span>
</span></span><span><span> </span><span class="token" style="color: rgb(152, 195, 121);">"Read(./ios/Pods/)"</span><span class="token" style="color: rgb(171, 178, 191);">,</span><span>
</span></span><span><span> </span><span class="token" style="color: rgb(152, 195, 121);">"Read(./android/.gradle/)"</span><span class="token" style="color: rgb(171, 178, 191);">,</span><span>
</span></span><span><span> </span><span class="token" style="color: rgb(152, 195, 121);">"Read(./.expo/)"</span><span>
</span></span><span><span> </span><span class="token" style="color: rgb(171, 178, 191);">]</span><span>
</span></span><span><span> </span><span class="token" style="color: rgb(171, 178, 191);">}</span><span>
</span></span><span><span></span><span class="token" style="color: rgb(171, 178, 191);">}</span></span></code></pre></div></div>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><strong>This does NOT prevent the memory leak.</strong> The deny rules only control what Claude can read during a conversation - they don't prevent the initial indexing/scanning that causes the memory explosion at startup.</p>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Workaround</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">The only solution that works is <strong>abandoning the multi-root workspace</strong> and using separate VS Code windows for each project. Each window stays stable at ~480 MB.</p>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Additional context</h3>
<ul class="[li_&amp;]:mb-0 [li_&amp;]:mt-1 [li_&amp;]:gap-1 [&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">This worked fine on the morning of Jan 16, 2026 with the exact same workspace and version</li>
<li class="whitespace-normal break-words pl-2">Something changed (possibly server-side feature flag like <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">tengu_mcp_tool_search: true</code>) between morning and evening</li>
<li class="whitespace-normal break-words pl-2">The issue is 100% reproducible on every attempt with multi-root</li>
</ul>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Request</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Could Anthropic investigate:</p>
<ol class="[li_&amp;]:mb-0 [li_&amp;]:mt-1 [li_&amp;]:gap-1 [&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-decimal flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">Why multi-root indexing has non-linear memory scaling?</li>
<li class="whitespace-normal break-words pl-2">Why <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">permissions.deny</code> doesn't prevent initial file scanning?</li>
<li class="whitespace-normal break-words pl-2">Is there a way to limit indexing scope at startup?</li></ol><!--EndFragment-->
</body>
</html>

It just eats the whole memory!
The only thing I did was I ran claude in terminal and prompted greeting:

<img width="1478" height="717" alt="Image" src="https://github.com/user-attachments/assets/ebfc5791-bc96-49db-8fad-3776ba65f1f7" />

                          ./+o+-       
                  yyyyy- -yyyyyy+      OS: Ubuntu 22.04 jammy
               ://+//////-yyyyyyo      Kernel: x86_64 Linux 6.8.0-90-generic
           .++ .:/++++++/-.+sss/`      Uptime: 6m
         .:++o:  /++++++++/:--:/-      Packages: 2619
        o:+o+:++.`..```.-/oo+++++/     Shell: bash 5.1.16
       .:+o:+o/.          `+sssoo+/    Resolution: 1920x1080
  .++/+:+oo+o:`             /sssooo.   DE: GNOME 41.7
 /+++//+:`oo+o               /::--:.   WM: Mutter
 \+/+o+++`o++o               ++////.   WM Theme: Adwaita
  .++.o+++oo+:`             /dddhhh.   GTK Theme: Yaru-red-dark [GTK2/3]
       .+.o+oo:.          `oddhhhh+    Icon Theme: Yaru-red-dark
        \+.++o+o``-````.:ohdhhhhh+     Font: Ubuntu 11
         `:o+++ `ohhhhhhhhyo++os:      Disk: 290G / 469G (66%)
           .o:`.syhhhhhhh/.oo++o`      CPU: 11th Gen Intel Core i7-1165G7 @ 8x 4.7GHz [60.0°C]
               /osyyyyyyo++ooo+++/     GPU: NVIDIA GeForce MX450
                   ````` +oo+++o\:     RAM: 6229MiB / 15771MiB
                          `oo++.      

BTW, updating to latest 2.1.12 version (using npm rather than native installation) fixed the problem.
Now, just opening it consumes around ~200Mb

BTW, updating to latest 2.1.12 version (using npm rather than native installation) fixed the problem. Now, just opening it consumes around ~200Mb

NPM version is deprecated https://code.claude.com/docs/en/setup#npm-installation-deprecated.

Moreover, fixing this type of bug would be normally mentioned in the CHANGELOG.

<img width="1331" height="322" alt="Image" src="https://github.com/user-attachments/assets/0dd62d73-de30-457a-b272-d7a7cb4a1d0b" />

Anyway

I've observed the same problem with 2.1.12 installed by the native installer.

Claude Code used more than 20+ GB memory at peak, which is unreasonable. I'm not sure how to reproduce it but noticed that it increased when generating responses and decreased to about 1 - 2 GB when idling.

For me was happening because some of my session logs became quite large (1-10GB) and Claude seemed to be trying to process them on start, in some cases freezing my whole system. Deleting these large files resolved the issue.

~/.claude/[project]/*.jsonl

In my case the culprit was the Playwright MCP, which was taking hundreds of screenshots and storing them in the jsonl as base64 data. Suggestion for the team: don't do that 😅

Uninstall + Reinstall and deleting big files (logs, db dumps) in my working directory fixed the memory leak for me.

having this issue as well on a fresh install on macos
claude -v
2.1.14 (Claude Code)

just run the claude command, no further actions required
and see the memory usage increase little by little nonstop

Still happens on 2.1.17.
Easy way to reproduce:

1. Gradle project
2. Ask Claude to make some changes and then verify them by running ./gradlew assembleDebug (or any other command)
3. During the Bash command execution and waiting for the result, RAM usage increases from 700MB to 20GB
4. After the Bash command execution is finished, it clears the RAM back to its initial value

It shouldn't use 20GB of memory just to observe the command output.

Pretty annoying, but here's a small workaround to clear Claude Code sessions in the background in case anyone finds it helpful!

https://github.com/anthropics/claude-code/issues/4953#issuecomment-3792297455

Same issue in version v2.1.23

Seeing something similar here. I left Claude idle on Ubuntu for 27 days.

The machine is a fan less i9 with 32 GB ram.
You can literally cook an egg on it while Claude is running idle. (lmk if you want video evidence)
When Claude is not running it just a little warm.

SWP: 96%
CPU: 102.7%
OS: Ubuntu 24

Process Details

• Process Name: claude
• Memory Consumption: 8GB RAM (25.1% of total)
• Virtual Memory: 81.5G VIRT
• Multiple Instances: Several PIDs with identical resource patterns

Timeline

• System Uptime: 31+ days
• Process Runtime: 27+ days
• Issue Resolution: Significant improvement after process termination

Impact Measurement

• Swap Reduction: 2.4GB freed by closing the process
• Performance Improvement: Notable system responsiveness increase

Same here. Updated to 2.1.44 and resumed older sessions earlier today and for some reason 2.1.15 shown up in activity monitor in MacOS and consumed monstrous amount of memory!!

I am experiencing this on both; My Macbook Pro machine M4 using Warp Terminal and also on my Linux Ubuntu machine using Ghostty. I can see how the memory usage keeps increasing with every new prompt. Is this a big context window problem beyond the terminal we are using or just kind of memory leak from Claude Code end?

@m-ret Intriguingly I wam using the same set up as you with Warp terminal + m4 Pro + Claude Code. Same issue!

Can confirm this being an issue with current version on windows with powershell - 64gb ram system and usage was over 47GB on just claude code.exe

Same thing.
Running Claude in Win Git Bash, since the recent update to 2.1.47, starting to observe idle sessions eating up all the available RAM, causing the PC to freeze.

Now, knowing Claude writes itself, should we somehow tag Claude to fix itself right from these issues? xD

Same thing. Running Claude in Win Git Bash, since the recent update to 2.1.47, starting to observe idle sessions eating up all the available RAM, causing the PC to freeze. Now, knowing Claude writes itself, should we somehow tag Claude to fix itself right from these issues? xD

This is a very good idea 😂

Same issue here, Linux Oracle 9 VM running on Win 11, 8GM of RAM allocated to the VM.
Claude VSCode plugin version 2.1.56
Claude code version 2.1.47

VSCode just gets killed on OOM error.

Same issue here.
Claude Code v2.1.58
SO: Microsoft Windows 11 Home Single Language
Version: 10.0.26200 build 26200
It increases very quickly — it reaches 1GB of RAM in just 30 seconds and continues without stopping.

Reposting https://github.com/anthropics/claude-code/issues/12987#issuecomment-3969148746. The high memory usage happens during claude installation on a fresh virtual machine, similarly to https://github.com/anthropics/claude-code/issues/11315#issuecomment-3614164935.

The problem with high memory usage during install in a fresh virtual machine (no use of code at all yet) is still present in 2.1.39 with the 2.1.59 installer: curl -fsSL https://claude.ai/install.sh | bash -s stable. The installation freezes the virtual machine (Almalinux/9 in Vagrant/VirtualBox), without installation succeeding.

<img width="1181" height="378" alt="Image" src="https://github.com/user-attachments/assets/fa4ac689-daef-4976-a4d1-b3ee82a608e9" />

I've also the same issue on :
Claude code 2.1.59
SO : Ubuntu 22
I've updated claude code to 2.1.62 to fix that

Evidence update (artifact re-check, 2026-03-04)

After re-parsing my watchdog artifact bundle, I need to correct one point in my earlier comment.

Confirmed in the panic artifact

panic(cpu 0 caller 0xfffffe00534ac00c): watchdog timeout: no checkins from watchdogd in 90 seconds
Compressor Info: 31% of compressed pages limit (OK) and 100% of segments limit (BAD) with 38 swapfiles
0xfffffe252335cf40 codex-aarch64-apple-darwin 31 0
0xfffffe2526c75660 gmail-rag 31 4926186

Not confirmed for this specific crash

• No claude / anthropic process entry in the panic file.
• Jetsam event process lists in the incident window did not show Claude/Anthropic process names.
• Unified logs contained incidental string hits (for example /Volumes/Claude and LaunchServices lookup messages for com.anthropic.claude), but no claude-code process entries in the critical window.

Conclusion (for this incident)

This crash is clearly a watchdog timeout under severe memory pressure, but from the available artifacts I cannot attribute direct causality to a running Claude Code process in the panic/Jetsam critical path.

Posting this correction for accuracy. If maintainers want, I can provide a scrubbed timestamp/process summary from the same artifact set.

I noted something. After I updated claude to last version, the ram consuption don't increase anymore, but where there is new claude update, it reappear. And also with claude --update, its ram usage increase too and take all my available ram. May be that is the point

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

hey man, Rishabh this side. I am building hawk for this exact same issue our mass of developers is facing. would love to connect and work around the fixes for your problem. you can find me at linkedin https://www.linkedin.com/in/rishabh-sain/

Are there any eyes from the team on this issue? This is making the program unusable. Is anyone looking at this?

Still seeing reports of this in 2026. The root cause is often orphaned subagents and MCP servers that survive session exit — each one holds 180-400 MB, and they compound across sessions throughout the day.

Built cc-reaper specifically for this. Three-layer defense:

1. Stop hook — PGID-based group kill on session exit (catches all children in one kill -- -$PGID)
2. proc-janitor daemon — background scan every 30s for orphaned process groups, 60s grace period before SIGTERM→SIGKILL
3. Shell commands — claude-ram shows RAM/CPU breakdown per session + orphan category, claude-cleanup for manual kills

On Ubuntu/Linux, the proc-janitor layer is especially important since there's no launchd — it runs as a background daemon and catches orphans from crashed sessions where no Stop hook fires.

git clone https://github.com/theQuert/cc-reaper.git && cd cc-reaper && bash install.sh

Won't fix internal node.js memory leaks, but it prevents the multi-GB orphan process accumulation that triggers most OOM kills.

Same here:
RAM leak causes system freeze — possibly related to Playwright MCP plugin

After starting a Claude Code session, RAM usage grew linearly even with no user input,
eventually consuming ~8.5 GB out of 12 GB and pushing the system into swap. This froze the
laptop entirely.

After a restart, the same behavior occurred — memory climbed steadily without any interaction.
Running /plugin appeared to resolve the leak (RAM dropped from 3.3 GB to ~430 MB), possibly
triggering garbage collection.

System: 12 GB RAM, Linux Ubuntu
MCP plugin active: Playwright (npm exec @playwright)
Behavior: Linear memory growth with no user input
Workaround: Running /plugin stopped the leak mid-session
version: Claude Code v2.1.74

I found only one solution, disable the update until they fix it. It occurs only when installing or updating.

@Marc-Antoine-K Your Playwright MCP case is a textbook example of what cc-reaper's claude-guard was built for. MCP servers like Playwright spawn child processes that hold memory independently — when the parent session leaks or stalls, those children keep growing unchecked.

With cc-reaper's RSS threshold reaper (claude-guard), you can set a per-session memory ceiling:

export CC_MAX_RSS_MB=4096  # kill any session tree exceeding 4 GB
claude-guard              # auto-reaper: monitors all sessions + their MCP children

It calculates the full process tree RSS (session + all child MCP servers + subagents), so a Playwright process silently ballooning to 3 GB under a 430 MB parent session still gets caught. The kill uses PGID to take down the entire group cleanly — no orphaned Playwright processes left behind.

For your 12 GB system, I'd recommend:

export CC_MAX_RSS_MB=3072   # aggressive ceiling for low-RAM systems
export CC_MAX_SESSIONS=2    # keep max 2 concurrent sessions

claude-ram will also show you per-category breakdown (MCP servers vs subagents vs core) so you can see exactly where the memory is going before it becomes a problem.

Setup is one command: git clone https://github.com/theQuert/cc-reaper.git && cd cc-reaper && bash install.sh

The proc-janitor daemon layer is particularly useful on Linux — it catches orphans from crashed sessions where no Stop hook fires, scanning every 30s with a 60s grace period before cleanup.

Thank you so much for the thorough explanation! Great understanding of the issue and again thank you for letting me know!

for me, as @Marc-Antoine-K suggested, it seemed to be an issue with playwright mcp. I couldn't even run the /plugin command. Just calling claude in the terminal was making my ubuntu to freeze completely requiring a hard reboot. I just disabled the playwright mcp with claude plugin disable playwright@claude-plugins-official and then reenabled again.

After that, all seems to be working fine, for now.

Same issue:

Additional data: NtFC (NTFS File Cache) kernel NonPaged Pool leak on Windows 11

Environment

• OS: Windows 11 Enterprise 10.0.26200
• RAM: 32 GB
• Claude Code: CLI, latest version (April 2026)
• Shell: bash (Git Bash)
• Workload: normal Claude Code session (Read, Grep, Glob, Bash tools — no remote control, no sub-agents)

Observations

During a 38-minute Claude Code session, I monitored the kernel NonPaged Pool using performance counters. The pool grew linearly at ~5.9 GB/hour:

| Time | NonPaged Pool | Delta/5min | Free RAM |
|------|--------------|------------|----------|
| 11:01 | 4.93 GB | — | 6.20 GB |
| 11:06 | 5.40 GB | +0.47 GB | 5.60 GB |
| 11:11 | 5.90 GB | +0.50 GB | 4.91 GB |
| 11:15 | 6.31 GB | +0.41 GB | 4.80 GB |
| 11:20 | 6.79 GB | +0.48 GB | 3.88 GB |
| 11:25 | 7.21 GB | +0.42 GB | 4.68 GB |
| 11:30 | 7.66 GB | +0.45 GB | 4.94 GB |
| 11:35 | 8.20 GB | +0.54 GB | 3.76 GB |
| 11:39 | 8.66 GB | +0.46 GB | 3.69 GB |

Total: +3.73 GB in 38 minutes → ~5.9 GB/hour, perfectly linear.

Pool tag analysis

Using poolmon-equivalent analysis, the NtFC tag (NTFS File Cache) is responsible for 86.7% of all NonPaged Pool usage:

Tag         NonPaged MB    NP Allocs     NP Frees    Outstanding
NtFC           5,740.74   47,028,611          485     47,028,126
EtwB             141.82        2,369        1,352          1,017
ConT             124.49           40            0             40

Key finding: 47 million allocations, only 485 frees. The NtFC entries are never released — they accumulate until reboot.

What I ruled out

I tested each of these during the active session — none stopped the leak:

1. Stopped VPN services (ExpressVPN, Stormshield SSL VPN) → leak unchanged
2. Added Windows Defender exclusions for all Claude Code paths (D:\source, ~\.claude, ~\AppData\Roaming\Claude, ~\AppData\Local\Temp) → leak unchanged
3. Added Defender process exclusions for node.exe, claude.exe → leak unchanged
4. Only Claude Code was running — no other I/O-heavy processes active

Root cause hypothesis

Claude Code's I/O pattern (rapid scanning, reading, and executing commands via node.exe) triggers a Windows kernel bug where NTFS File Cache entries (NtFC pool tag) are allocated in NonPaged Pool but never freed. This is a kernel-space leak, not a userspace issue — it survives process termination and only clears on reboot.

The WdFilter (Defender minifilter) may amplify the issue by intercepting every I/O operation, but Defender exclusions alone don't fix it, suggesting the root cause is in ntfs.sys or the volume of NtQueryDirectoryFileEx calls.

Impact

On a 32 GB system, the NonPaged Pool reaches critical levels (~10 GB) within ~50 minutes of a Claude Code session, leading to system instability, heavy paging, and eventually BSOD (PAGE_FAULT_IN_NONPAGED_AREA).

Workaround

The only current workaround is periodic reboots during long Claude Code sessions. Defender exclusions and VPN service management may help prevent the leak from starting in fresh sessions (needs verification post-reboot).

Unfortunately at this time I just think this piece of software is unusable. A critical memory leaking bug that will absolutely hog your system to death and no one at the company would actually take a look at it because there are too many issues and too many spaghettis to even start a proper code audit. No QC, no review, nothing.

Yeah, "let Claude Code build itself", my ass lol

And updates on this? Claude Code just crashed my entire system again, this time consuming 370 GB (!!!) of virtual RAM.

I have a maxed-out MBP M4 Max, but it means nothing when CC starts to consume.

The worst thing is that sometimes, when building bigger features, I have 1-2 agents on for days, if not weeks, because I start planning with them, so they know the context of everything. And when I try to resume them later, the chats are gone, and I can't restore history anymore.

Unbelievable that this is still open 6 months after it was opened given how critical this issue is. I found an alternative - moved to Codex, it got too annoying.

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 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 (https://github.com/anthropics/claude-code/issues/11315#issuecomment-3969231532) 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 https://github.com/anthropics/claude-code/issues/4953#issuecomment-4488000838, 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 https://github.com/anthropics/claude-code/issues/11315#issuecomment-3614164935), but the host laptop did not freeze. Also linked here https://github.com/anthropics/claude-code/issues/4953#issuecomment-4594991557.

<img width="1178" height="294" alt="Image" src="https://github.com/user-attachments/assets/e5de93fb-cad5-4f26-99c9-72f5f76eb1a1" />

Literally have the same issue dude, on Fedora 44, it drove me insane. I code in Intellij and while coding i downloaded the thing and it completely freezed my pc, did it more times just to be sure and it took all of the ram and the OOM killed it, i cant even download the thing. !pastedfile_1.png

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

@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.