Repository navigation
[BUG] Memory leak in long-running idle Claude Code sessions #18859
Description
Preflight Checklist
- I have searched existing issues and this hasn't been reported yet
- This is a single bug report (please file separate reports for different bugs)
- 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 charsSteps to Reproduce
- Run
claudein terminal - Use the session normally (file reads, bash commands, etc.)
- Stop interacting but keep the session open (don't
/exit) - Monitor memory usage in Activity Monitor over time
- 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
Activity
github-actions commentedon Jan 17, 2026
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
AojdevStudio commentedon Jan 18, 2026
Having a similar problem where it doesn't even start up, memory spikes!
kylesnowschwartz commentedon Jan 19, 2026
Additional data point: macOS ARM64, MCP server memory accumulation
Experienced similar memory growth in a
claude -c(continue) session.Environment:
Observations:
MCP server memory accumulation:
Notably, the session's MCP servers also accumulated memory over time:
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:
This supports your hypothesis that the leak may involve MCP connections rather than context accumulation.
alberduris commentedon Jan 21, 2026
Also seeing memory accumulation in idle sessions on v2.1.14 (macOS).
kuzmeech commentedon Feb 3, 2026
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:
Memory growth over time (Process A):
Key observations:
lsofshows 0 TCP/UDP connections - disconnected from APIsampleshows main thread 100% busy in JIT code (V8 GC thrashing pattern)<defunct>) - not being reapedFailure modes:
Both required SIGKILL. Happy to provide
sampleoutput if helpful.krystofbe commentedon Feb 5, 2026
I did some debugging on this today. The results are... sobering.
Memory comparison of AI coding CLIs (single session, idle):
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 commentedon Feb 9, 2026
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 commentedon Feb 19, 2026
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
__BUNMach-O segment)Before kill
phys_footprint--dangerously-skip-permissions -c)-c)-c)vm_statshowed ~10 billion decompressions (severe thrashing)footprint <pid>viaphys_footprintrevealed the true size.After kill + restart with
-c(same conversations)phys_footprintNotes
etimewas not captured before termination.kill(SIGTERM) did not terminate the bloated processes — requiredkill -9(SIGKILL).6 remaining items
DmitriyYukhanov commentedon Feb 27, 2026
Got this again in 2.1.61.
2.1.50 seems to be most stable.
dario-l commentedon Mar 1, 2026
How to lock that
2.1.50version and disable auto-update?rivershah commentedon Mar 3, 2026
After a long session with multiple Agent tool spawns (subagent research tasks), the single
claude -rprocess accumulates 52+ threads thatare never cleaned up after agents complete. htop shows ~12 rows of
claudeprocesses but they are threads of one PID sharing 700M-850M RESeach showing 71.7G VIRT.
/proc/<pid>/taskconfirms these are threads not child processes. Thread count grows with Agent tool usage and never shrinks back. Only fixis 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 commentedon Mar 3, 2026
kaansoral commentedon Mar 6, 2026
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 commentedon Mar 6, 2026
@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 commentedon Mar 6, 2026
@kaansoral https://github.com/qazaqninja/claude-cleanup check it out
qazaqninja commentedon Mar 6, 2026
@bcherny pls fix it🙏
feat(watchdog): memory-leak recycling and idle worker cleanup
yurukusa commentedon Mar 29, 2026
/tmp/issue-18859-comment.md
rodlunt commentedon Apr 10, 2026
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.
Session reaper, graceful shutdown, port hardening, and memory guard
Session reaper, graceful shutdown, port hardening, and memory guard
kejid commentedon Oct 1, 2026
Not a fix for the leak, but a workaround that helped me live with it: unload the idle sessions and resume them later.
I packaged that as an open-source plugin, https://github.com/kejid/ramsleeper. It shows how much memory each session's process tree holds, so you can spot the one that has grown, and it stops a session cleanly (SIGINT, then a forced stop only if needed). The conversation is kept in the transcript, so
claude --resume <id>, or simply sending a message in the desktop app, brings it back with fresh memory.Tested on Windows. Untested on macOS, which is what this report is about, so treat it as experimental there. Feedback from a Mac would be very welcome.
Session reaper, graceful shutdown, port hardening, and memory guard