›_ Claude Code Issues
Claude Code Issues / #18859

[BUG] Memory leak in long-running idle Claude Code sessions

Open 💬 23 comments Opened Jan 17, 2026 by diangao

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?

Multiple idle Claude Code sessions accumulated ~15GB memory each over an 18-hour period without any user interaction. 4 sessions combined used ~60GB, exceeding my 24GB RAM and triggering macOS jetsam (OOM killer), causing a complete system crash.

Key finding: Debug logs show context size remained constant at 6664 chars throughout the 18 hours, yet each process grew to ~15GB. This suggests the leak is NOT from context accumulation but from something else (V8 heap fragmentation, MCP connections, internal caching, etc.).

From jetsam report:

  • "largestProcess" : "2.1.7" (Claude Code)
  • 4 processes with rpages 950,000-980,000 (~15GB each)
  • Combined CPU time suggests processes were actively doing something despite being idle

What Should Happen?

Idle Claude Code sessions should:

  • Maintain a low memory footprint (<500MB when idle)
  • Release unused memory through garbage collection
  • Not grow unboundedly without active user interaction

Error Messages/Logs

From /Library/Logs/DiagnosticReports/JetsamEvent-2026-01-15-182249.ips:

"largestProcess" : "2.1.7"

Process memory details (name: "2.1.7"):
PID 10652: rpages=977,907 (~15GB), cpuTime=1805.89s
PID 11129: rpages=950,678 (~14.5GB), cpuTime=3364.34s
PID 11605: rpages=981,949 (~15GB), cpuTime=391.86s
PID 75191: rpages=976,069 (~15GB), cpuTime=1604.92s

(macOS page size = 16KB, so 977,907 pages × 16KB ≈ 15GB)

From ~/.claude/debug/ logs - context stayed constant:
2026-01-15T00:30:45.055Z [DEBUG] Auto tool search disabled: 6664 chars
...
2026-01-16T02:14:31.824Z [DEBUG] Auto tool search disabled: 6664 chars

Steps to Reproduce

  1. Run claude in terminal
  2. Use the session normally (file reads, bash commands, etc.)
  3. Stop interacting but keep the session open (don't /exit)
  4. Monitor memory usage in Activity Monitor over time
  5. Memory grows continuously even when idle

My specific case:

  • 4 sessions open for ~18 hours
  • Each grew to ~15GB despite being idle
  • Context size stayed constant at 6664 chars (verified in debug logs)

The core issue: idle sessions accumulate memory without releasing it, regardless of context size.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.7 (at time of crash), now on 2.1.12

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Environment:

  • macOS 15.7 (24G207)
  • Apple M2, 24GB RAM
  • iTerm2 with zsh

Session timeline:

  • Sessions started: 2026-01-15T00:01 UTC
  • Crash time: 2026-01-15T18:22 PST
  • Total runtime: ~18 hours
  • User idle time before crash: ~2 hours

MCP configuration:

  • claude-in-chrome MCP server was connected to some sessions

Available for debugging:

  • Full jetsam report at /Library/Logs/DiagnosticReports/JetsamEvent-2026-01-15-182249.ips
  • Debug logs in ~/.claude/debug/ from affected sessions
  • Willing to provide additional logs or test fixes

View original on GitHub ↗

23 Comments

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/18280
  2. https://github.com/anthropics/claude-code/issues/12987
  3. https://github.com/anthropics/claude-code/issues/18011

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

AojdevStudio · 5 months ago

Having a similar problem where it doesn't even start up, memory spikes!

kylesnowschwartz · 5 months ago

Additional data point: macOS ARM64, MCP server memory accumulation

Experienced similar memory growth in a claude -c (continue) session.

Environment:

  • Claude Code: 2.1.12
  • macOS (Apple M3 Max, 36GB RAM)
  • Terminal-based session

Observations:

| Metric | Value |
|--------|-------|
| Session duration | ~50 minutes |
| Claude process RSS | ~3GB (started much lower) |
| CPU | Peaked at 101%, later dropped to 3.4% |

MCP server memory accumulation:

Notably, the session's MCP servers also accumulated memory over time:

PID    RSS (MB)  Uptime   Process
37041  278MB     50min    mcp-server-playwright (old session)
53889  46MB      5min     mcp-server-playwright (fresh session)

The playwright MCP server from the long-running session grew to 6x the size of a freshly spawned one (278MB vs 46MB), suggesting MCP servers may be accumulating state without releasing it.

Process snapshot at ~50 min:

36698 2966160  7.9%  3.4%  50:37 claude -c
37041  278464  0.7%  0.1%  50:33 node mcp-server-playwright
37016   46432  0.1%  0.0%  50:33 node context7-mcp
36991   46416  0.1%  0.0%  50:33 node context7-mcp
36911   44720  0.1%  0.0%  50:34 node rollbar-mcp-server

This supports your hypothesis that the leak may involve MCP connections rather than context accumulation.

alberduris · 5 months ago

Also seeing memory accumulation in idle sessions on v2.1.14 (macOS).

kuzmeech · 5 months ago

Additional data point from macOS (2026-02-03)

Environment: macOS Sequoia, Apple Silicon M4, Claude Code 2.1.30

Observed two hung processes with different patterns:

| Metric | Process A | Process B |
|--------|-----------|-----------|
| CPU | 50% (spinning) | 0% (dead idle) |
| Memory | 604MB | 755MB |
| Network | disconnected | disconnected |
| Duration | 5h45m | 2h27m |

Memory growth over time (Process A):

| Age | RSS | CPU% | Status |
|-----|-----|------|--------|
| 3 min | 343 MB | 0.1% | healthy |
| 67 min | 493 MB | 43% | degrading |
| 120 min | 681 MB | 48% | degrading |
| 261 min | 4568 MB | 100% | hung |

Key observations:

  1. Both processes lost network connection and never recovered
  2. lsof shows 0 TCP/UDP connections - disconnected from API
  3. sample shows main thread 100% busy in JIT code (V8 GC thrashing pattern)
  4. One process had zombie child (<defunct>) - not being reaped
  5. MCP subprocesses (chrome-devtools-mcp) still alive but Claude unresponsive

Failure modes:

  • High CPU hang - spins on reconnect loop?
  • Zero CPU hang - gave up completely?

Both required SIGKILL. Happy to provide sample output if helpful.

krystofbe · 5 months ago

I did some debugging on this today. The results are... sobering.

Memory comparison of AI coding CLIs (single session, idle):

| Tool | Footprint | Peak | Language |
|-------------|-----------|--------|---------------|
| Codex | 15 MB | 15 MB | Rust |
| OpenCode | 130 MB | 130 MB | Go |
| Claude Code | 360 MB | 746 MB | Node.js/React |

That's a 24x to 50x difference for tools that do the same thing: send text to an API.

vmmap shows Claude Code reserves 32.8 GB virtual memory just for the V8 heap, has 45% malloc fragmentation, and a peak footprint of 746 MB that never gets released — classic leak pattern.

On my 16 GB Mac, a "normal" workload (2 Claude sessions + browser + terminal) pushes me into 9.5 GB swap within hours. My laptop genuinely runs slower with Claude Code than when I'm running local LLMs.

I get that shipping fast matters, but building a CLI with React and a full Node.js runtime is an architectural choice with consequences. Codex proves this can be done in 15 MB. Every Claude Code session costs me 360+ MB — and with MCP servers spawning per session, it multiplies fast.

Would love to see this taken seriously. A rewrite might not be realistic, but at minimum: fix the leaks, reduce the baseline, and maybe don't spin up a React renderer for a terminal app?

victortong-git · 5 months ago

I have the similar issue. Running CC in VM Ubuntu 24 Desktop. Version: 2.1.37. Since last week, it is very easy to having "No Response" issue as the system is keeping access to swap memory. I assigned 24GB memory to VM. Hard reboot and start the session again can work fine for few hours. No idea when this memory leakage will happen.

But my case is not idle, I am using it.

brainkim · 4 months ago

Additional data point: 16-20 GB phys_footprint on 8 GB machine (v2.1.44, Bun runtime)

Observed the same unbounded memory growth on long-running sessions. Killing and restarting with claude -c (same conversations) restored normal footprint, confirming process-level leak rather than context accumulation.

Environment

  • Claude Code: 2.1.44 (Bun standalone binary, confirmed via __BUN Mach-O segment)
  • OS: macOS Darwin 24.3.0 (Apple Silicon, 8 GB RAM)
  • Sessions: 3 concurrent via tmux

Before kill

| PID | Project | phys_footprint | Peak |
|-----|---------|----------------:|------:|
| 57662 | project A (--dangerously-skip-permissions -c) | 20 GB | 22 GB |
| 82124 | project B (-c) | 16 GB | 17 GB |
| 78732 | project C (-c) | 263 MB | 376 MB |

  • Swap: 23.3 GB used / 24 GB total
  • vm_stat showed ~10 billion decompressions (severe thrashing)
  • macOS displayed "you must quit applications" dialog attributing ~50 GB to Terminal (which was the parent of tmux → zsh → claude)
  • RSS massively underreported the problem (~500 MB per process) since most memory was swapped/compressed. footprint <pid> via phys_footprint revealed the true size.

After kill + restart with -c (same conversations)

| PID | phys_footprint | Age |
|-----|----------------:|-----|
| 64584 | 297 MB | 35s |
| 64620 | 246 MB | 29s |
| 64659 | 178 MB | 16s |

  • Swap: 883 MB used / 2 GB total

Notes

  • Process age unknown. Sessions were running in tmux sessions created 4-7 days prior, but may have been restarted within that window. Exact etime was not captured before termination.
  • No zombie processes found.
  • The first kill (SIGTERM) did not terminate the bloated processes — required kill -9 (SIGKILL).
DmitriyYukhanov · 4 months ago

Having a similar issue on 2.1.47. On a 65 GB laptop, the Claude process takes 32 GB of RAM in a few minutes of idle time after I did call /init in a project folder.

qazaqninja · 4 months ago

@DmitriyYukhanov https://github.com/qazaqninja/claude-cleanup check this thing out

DmitriyYukhanov · 4 months ago

Thanks @qazaqninja will have a look! I have much better mem usage in 2.1.50 btw, it doesn't fill all available ram anymore for me.

qazaqninja · 4 months ago

@DmitriyYukhanov I checked my activity monitor and it seemed like Claude was collecting all old processes, since 2.1.20 or smth, i had to write this shell tool to clean that up

vikyw89 · 4 months ago

OOM many times lately

DmitriyYukhanov · 4 months ago

Got this again in 2.1.61.
2.1.50 seems to be most stable.

dario-l · 4 months ago
Got this again in 2.1.61. 2.1.50 seems to be most stable.

How to lock that 2.1.50 version and disable auto-update?

rivershah · 4 months ago

After a long session with multiple Agent tool spawns (subagent research tasks), the single claude -r process accumulates 52+ threads that
are never cleaned up after agents complete. htop shows ~12 rows of claude processes but they are threads of one PID sharing 700M-850M RES
each showing 71.7G VIRT.

/proc/<pid>/task confirms these are threads not child processes. Thread count grows with Agent tool usage and never shrinks back. Only fix
is restarting the session.

The VIRT numbers are misleading (V8 address space reservation) but the thread accumulation is real and causes noticeable system sluggishness
over time. Machine becomes very laggy after extended use.

rivershah · 4 months ago
> Got this again in 2.1.61. 2.1.50 seems to be most stable. How to lock that 2.1.50 version and disable auto-update?
CLAUDE_VERSION=2.1.50
curl -fsSL https://claude.ai/install.sh | bash -s "${CLAUDE_VERSION}" >/dev/null 2>&1
kaansoral · 4 months ago

<img width="919" height="1244" alt="Image" src="https://github.com/user-attachments/assets/ca49f38e-4b81-4ee9-b27c-da8f41bb26a8" />

What a legend ... I had no idea using 210GB Ram was even possible

@qazaqninja - I want to integrate your script as a must-run script for each reply, as I never start or end sessions, I just keep them open like most people do. Which version is best for this use, startup or end version? And would it work while the claude command is alive? Otherwise I'd appreciate pointers for this use case

qazaqninja · 4 months ago

@kaansoral that's a good idea, i will try to do some changes to make it work like you described, and for the version it should work on any of them.

qazaqninja · 4 months ago

@kaansoral https://github.com/qazaqninja/claude-cleanup check it out

qazaqninja · 4 months ago

@bcherny pls fix it🙏

yurukusa · 3 months ago

/tmp/issue-18859-comment.md

rodlunt · 3 months ago

Windows 11 Pro data point to add platform diversity to this thread.

▎ Environment
▎ - Windows 11 Pro (26200.8037) on 32 GB physical RAM
▎ - Claude Desktop + Claude Cowork (agent-team dispatch from phone app → Windows Claude
Desktop as execution host)
▎ - 11.8 days of continuous host uptime

▎ Failure shape
▎ Three idle claude.exe processes accumulated to ~6.5 GB each, triggering Windows Event ID
2004 (Microsoft-Windows-Resource-Exhaustion-Detector) when commit charge exceeded the commit
limit. Full event text:

▎ Windows successfully diagnosed a low virtual memory condition.
▎ The following programs consumed the most virtual memory:
▎ claude.exe (PID 9996) consumed 6,576,287,744 bytes ≈ 6.58 GB
▎ claude.exe (PID 16824) consumed 6,541,664,256 bytes ≈ 6.54 GB
▎ claude.exe (PID 18428) consumed 6,409,613,312 bytes ≈ 6.41 GB

▎ Critical detail matching the "idle leak" hypothesis: these three processes were spawned 5
days earlier during a single heavy cowork task (installing a Minecraft server + updating
Caddy) and never terminated when the task completed. They sat idle — no new tasks, no new
context — for 5 days, slowly leaking to ~19.5 GB total commit charge before the host entered
a 68-minute zombie state (able to reply to some network packets but unable to spawn new
shells or accept new SSH sessions) and required a hard reset.

▎ This matches @diangao's finding of "context stays constant, memory grows regardless": the
cowork agent-team process count never changed, and the host was doing no new cowork work for
5 days, yet memory growth was monotonic.

▎ Windows-specific forensic primitive for this class of bug:
▎ Get-WinEvent -LogName System -ProviderName Microsoft-Windows-Resource-Exhaustion-Detector
-MaxEvents 20 | `
▎ Where-Object { $_.Id -eq 2004 } | Select-Object TimeCreated, Message | Format-List
▎ Event ID 2004 emits a top-consumers list that pinpoints the culprit processes even if the
host had to be hard-reset and the process state is gone — it's the Windows equivalent of the
jetsam reports earlier in this thread.

▎ Would be valuable to add platform:windows to the labels — the evidence pattern strongly
suggests the underlying leak is platform-agnostic (Electron/V8/MCP/something in the Claude
Desktop main-process-and-agents architecture), with just different OOM-signalling mechanisms
on each OS.