[BUG] Critical memory leak on idle session — 12,396 MB/hour growth rate (v2.1.71, WSL2/Linux)

Resolved 💬 3 comments Opened Mar 10, 2026 by VikInks Closed Apr 7, 2026

Preflight Checklist

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

What's Wrong?

Bug Report: Critical Memory Leak — 12,396 MB/hour growth rate (v2.1.71)

Related issues: #27421, #22042, #15-1

---

Environment

| Property | Value |
|----------|-------|
| Claude Code version | 2.1.71 |
| Node.js version | v24.3.0 |
| Platform | Linux (WSL2) |
| Trigger | Manual /heapdump |
| Session uptime at dump | ~162 seconds |

---

What's Wrong?

Memory grows unboundedly from startup, even on idle sessions.
The growth rate measured at 162s uptime is already critical.

---

Diagnostics (/heapdump output)

Memory Usage at dump time

| Metric | Value |
|--------|-------|
| heapUsed | 7,749 MB |
| heapTotal | 42.7 MB |
| external | 7,715 MB |
| arrayBuffers | 7,352 MB ← anomaly |
| rss | 560 MB |

⚠️ arrayBuffers accounts for ~95% of heapUsed — strong indicator of a leak on unreleased buffers.

Growth Rate

| Metric | Value |
|--------|-------|
| Bytes/second | 3,610,615 |
| MB/hour | 12,396 MB/hour |

V8 Heap Stats

| Metric | Value |
|--------|-------|
| heapSizeLimit | 5,605 MB |
| mallocedMemory | 7,750 MB |
| peakMallocedMemory | 560 MB |
| detachedContexts | 0 |
| nativeContexts | 1 |

⚠️ mallocedMemory (7,750 MB) significantly exceeds heapSizeLimit (5,605 MB) — allocated memory is escaping V8 GC control.

smaps Rollup (RSS)

Rss:            573,468 kB
Pss_Dirty:      519,208 kB   ← 90% private dirty memory (non-shareable, unreleased)
Private_Dirty:  519,208 kB
Private_Clean:   51,816 kB
Swap:                 0 kB

---

Analysis

  • Probable root cause: leak on arrayBuffers — external buffers (e.g. streams, API responses) are allocated but never released by the GC
  • mallocedMemory > heapSizeLimit: memory grows outside the controlled V8 heap, GC cannot reclaim it
  • Private_Dirty at 90%: modified and unreleased memory pages at OS level — confirms structural memory retention

---

Steps to Reproduce

  1. Launch claude in a WSL2 terminal
  2. Do nothing (idle session)
  3. After ~3 minutes: High memory usage warning appears
  4. Run /heapdump

---

Expected vs Actual

| | Expected | Actual |
|-|----------|--------|
| RAM at startup | ~300 MB | ~1.8 GB |
| Growth | stable | +12,396 MB/hour |
| RAM after 10 min | ~400 MB | 6+ GB |

---

Workaround

systemd-run --user --scope -p MemoryMax=4G claude

---

Heapsnapshot

Attached file:

8aed5531-7ffe-4e7d-a6ce-366d850c36f8-diagnostics.json

What Should Happen?

What Should Happen

Claude Code should maintain a stable and reasonable memory footprint throughout a session.
On startup, memory usage should not exceed ~300–500 MB.
During an idle session with no active tasks, memory should remain flat with no measurable growth rate.
The GC should be able to reclaim external buffers and arrayBuffers after each API response is processed.

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

  1. Launch claude in a WSL2 terminal inside any project directory
  2. Wait ~2–3 minutes without sending any message (idle session)
  3. Observe the High memory usage (X.XGB) · /heapdump warning appearing in the UI
  4. Run /heapdump to confirm the growth rate
  5. Repeat after another 5 minutes — memory continues to grow unboundedly

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.71

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗