[BUG] VS Code extension host restart due to OOM caused by Claude Code loading histories of ALL sessions!
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?
Possibly related to https://github.com/anthropics/claude-code/issues/81493
Claude Code causes OOM of VS Code extension host resulting in the session getting stopped, the extension host restarting and a new empty Claude Code chat session getting opened.
Analysis by Claude Code itself via analysing CS code crash dumps and live memory dump identified Claude Code loading session history from ALL sessions into memory, quickly using multiple GB of RAM and as that's in use, the garbage collectors have nothing to clear. While working with Claude, this ends up causing VS Code to kill the session due to OOM. Restarting the session runs into the same issue. The frequency of the OOMs is increasing as the histories become longer.
What Should Happen?
Claude Code should not load the histories of ALL sessions into memory, but only the single session if re-opened or started.
Error Messages/Logs
vscode dmp files of repeated crashes attached as zip file.
This is VS Code 1.134.0 on Linux Mint 22.3. Claude Code for VS Code 2.1.241 and previous. The crash issue started happening about a week ago through multiple Claude Code updates.Steps to Reproduce
Not sure how to reproduce. I have lots of long sessions in my history in vscode, working on something, the crash happens again and again and again.
Claude Model
Sonnet (default)
Is this a regression?
Yes, this worked in a previous version
Last Working Version
unclear. Crashes started happening about a week ago, but probably just reached critical length of session history
Claude Code Version
2.1.240, 2.1.241 and earlier
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Other
Additional Information
Root cause found — confirmed directly from the crash dumps, not a guess.
What's happening: VS Code's extension host (the process that runs the Claude Code extension's JS code) is repeatedly hitting a V8 JavaScript heap out-of-memory abort, not a native segfault. Every one of the 12 .dmp files in /home/wuff/codecrash/pending/ contains the same signature:
FATAL ERROR: ... Allocation failed - JavaScript heap out of memory
[pid] NNNN ms: Mark-Compact (reduce) ... MB, ... last resort; GC in old space requested
electron/shell/common/....cc:189] OOM error
This matches main.log, which logs each event as:
Extension host with pid X exited with code: 133 ... crashed with code 133 and reason 'crashed'
(133 is Electron's OOM-abort exit code, not a signal-based crash.)
Key details:
12 crashes today (20:02–23:07), heap size at death ranged wildly: 1.4 GB up to 3.2 GB — there's no fixed ceiling, it just keeps climbing until something gives.
Every crash's exthost log shows it died mid-active-session (Bash tool dispatch / API streaming in progress) — consistent with your report that it happens "while Claude Code is working."
It's happening live right now: the current extension host (pid 196089, started at 23:07:22) is already at 2.76 GB RSS after only ~2 minutes, still climbing, at 92% CPU. That's a fast leak, not a slow one.
On pinning down the leaking object — I caught the live process in the act this time (window1's exthost, pid 203246, currently running):
Tried to attach Node's inspector (it exposes --inspect-port on 127.0.0.1) to pull a real heap snapshot and rank objects by retained size.
It refused to respond at all — not a timeout hiccup, but 28+ seconds of zero response while sitting at 100–112% CPU, RSS climbing by hundreds of MB every ~10–20s (1.4GB → 2.0GB → 2.7GB → 2.9GB while I watched).
gdb thread-samples on the live process caught the main thread inside madvise() — a page-management syscall V8's garbage collector calls during sweep/compaction. Combined with the crash dumps' repeated Mark-Compact (reduce) ... last resort; GC in old space requested lines, this means: V8 is running back-to-back full garbage collections and barely reclaiming anything, so it never returns control to the event loop — that's why even a basic HTTP handshake to the debugger port couldn't get through.
That last point is itself the useful finding: this isn't idle garbage sitting around that a GC would normally clean up — it's a genuinely huge live object graph. A real leak (unreleased listeners, growing cache) still lets GC succeed and the process breathe; this pattern (GC running constantly, failing to shrink the heap, event loop fully starved) means something is holding a strong reference to a data structure that's actively still growing while the crash unfolds.
Where I hit a wall: V8/Electron release builds are stripped of JS symbol info, so gdb can't show me which JS constructor is huge, and the process was too CPU-starved to ever answer the inspector for a proper heap snapshot. perf is blocked here too (perf_event_paranoid=4).
Found it — and I deleted the diagnostic dump afterward since it contained live session data/tokens.
The live process's Node inspector wouldn't respond to a scripted client either (same stall I hit before), so instead of a heap snapshot I took a full memory core dump (gcore) of the running extension host and searched it directly. That gave a definitive answer:
19 distinct past Claude Code sessions are all sitting fully in memory at once — not just the one you're actively using:
857 occurrences session 7b35008d...
554 occurrences session da34ee36...
422 occurrences session 6538cc8f...
312 occurrences session 641caf07...
295 occurrences session dd3e7bd6...
...(15 more, down to single digits)
Plus 3,184 "role":"assistant"/"role":"user" message blocks and 1,080 tool_use_id/tool_result pairs in Anthropic API JSON shape, floating in memory across all of them.
The key detail: your actual active session (c238bf62...) only accounts for 125 of those occurrences — mid-pack, not even the largest. So this isn't "one long conversation growing huge." It's the extension accumulating full transcripts for every session you've opened in this window since it started, and never releasing the old ones. The sidebar's session list (the repeated list_sessions_request / get_session_groups calls I saw earlier in the logs) appears to pull and cache complete message history for every session it lists, not just metadata or the active one.
This also explains something I noticed but hadn't tied together: the crash interval has been shrinking all evening — roughly every 15-45 min early on, down to 23:07 → 23:15 → 23:17 just now. Each fresh extension host starts empty, but as soon as the sidebar repopulates its session list it reloads the entire growing pile of historical sessions back into memory — and that pile only ever grows across the window's lifetime, so each restart hits OOM faster than the last.
Concrete things that should help right now:
Delete/clear old sessions you don't need from the Claude Code sidebar's session list, if there's a delete action — that's what's being kept resident.
Closing and reopening the VS Code window (not just the extension host) resets this accumulation to zero, since it's scoped to the window's session list.
This is a solid, reportable bug against Anthropic.claude-code 2.1.240: session-list/history retention holds full transcripts for all past sessions instead of the active one only. Worth filing with the session-count evidence above — much more actionable than "crashes sometimes."