[BUG] VS Code extension crashes with OOM error: conversation history accumulates to 700MB+ causing infinite crash loop
Resolved 💬 17 comments Opened Oct 2, 2025 by peterchabs Closed Mar 11, 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?
The Claude Code VS Code extension crashes immediately on startup with an out-of-memory error and enters an infinite crash loop. The extension becomes completely unusable.
Root cause: The extension accumulates conversation history in ~/.claude/projects/ with no cleanup mechanism. In my case, a single project accumulated 738 MB of conversation data across 40+ .jsonl files, with the largest single file reaching 188 MB.
The extension appears to load all project conversation history into memory on startup, causing immediate crashes when the accumulated data exceeds available heap space.
Error from VS Code console:
What Should Happen?
- Conversation history should have automatic cleanup/retention policies (e.g., delete conversations older than 30 days)
- Individual conversation files should have size limits (e.g., 10 MB maximum)
- Total project data should be capped (e.g., 50-100 MB per project)
- Data should be loaded lazily on-demand rather than all at startup
- Users should receive warnings when approaching storage limits
- Extension should degrade gracefully rather than crash when limits are exceeded
Error Messages/Logs
[Extension Host] Spawning Claude Code process: node /Users/electrance/.vscode/extensions/anthropic.claude-code-2.0.3/resources/claude-code/cli.js ...
<--- Last few GCs --->
[2256:0x10c00300000] 29014 ms: Mark-Compact 2046.7 (2061.1) -> 2046.7 (2061.1) MB,
pooled: 0.0 MB, 26.38 / 0.00 ms (average mu = 0.424, current mu = 0.025)
allocation failure; scavenge might not succeed
[2256:1002/001230.303037:ERROR:electron/shell/common/node_bindings.cc:178]
OOM error in V8: Reached heap limit Allocation failed - JavaScript heap out of memory
Extension host (LocalProcess pid: 2256) terminated unexpectedly.
Code: 5, Signal: unknown
Automatically restarting the extension host.
Steps to Reproduce
- Install Claude Code VS Code extension (2.0.3)
- Use the extension extensively on a single project over weeks/months
- Have extended coding sessions with long conversations
- Allow conversation history to accumulate indefinitely in
~/.claude/projects/ - Restart VS Code
- Observe extension host crash within 30 seconds with OOM error
To verify the issue:
# Check project data size
du -sh ~/.claude/projects/*
# In my case:
# 738M ~/.claude/projects/-Users-electrance-YolkWebApp-working/
# Check individual conversation files
du -sh ~/.claude/projects/[your-project]/*
# Largest files in my case:
# 188M for a single .jsonl file
# Multiple 30-87 MB files
### Claude Model
Sonnet (default)
### Is this a regression?
Yes, this worked in a previous version
### Last Working Version
1.0.127
### Claude Code Version
anthropic.claude-code-2.0.3
### Platform
Anthropic API
### Operating System
macOS
### Terminal/Shell
Other
### Additional Information
Workaround to temporarily fix:
# Back up and remove the project directory
mv ~/.claude/projects/[your-project] ~/.claude/projects/[your-project].backup
# Restart VS Code - extension will work again with fresh project
**Additional Information**
```markdown
**Data accumulation details:**
~/.claude/ directory breakdown:
projects/: 744 MB total
Single project: 738 MB
40+ conversation .jsonl files
Largest single file: 188 MB
file-history/: 21 MB
todos/: 704 KB
shell-snapshots/: 456 KB
**Impact:**
- Extension becomes completely unusable after extended use
- No warning before catastrophic failure
- Requires file system intervention to fix
- Non-technical users cannot diagnose or resolve
- Risk of losing conversation history when forced to delete project data
**Observations:**
- Issue is silent - no indication of accumulating data
- No automatic cleanup mechanism exists
- Extension loads ALL project data into memory at startup
- Problem compounds over time with extended use
17 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is specific to Sonnet 4.5:
I am leaving this issue open even though I see some similar issues (Not through VS Code) submitted weeks ago due to this only becoming an issue for me on the v 2.x.x releases. Reverting to 1. 0.127 which was released a few days ago still works perfectly fine, this is the temporary fix for this issue until a permanent fix is committed.
Workaround to temporarily fix:
Back up and remove the project directory
mv ~/.claude/projects/[your-project] ~/.claude/projects/[your-project].backup
Restart VS Code - extension will work again with fresh project
I have exactly the same issue. It is unique to the VS Code extension, Claude Code in the terminal does not load all project history into memory at startup.
I worked around it by clearing my convo history ;-) I expect to have to repeatedly do this until this is fixed.
I'm not running the extension, I'm just running Claude code cli in cursor, and I got an out of memory today on 2.0.1:
ahh yes, seems to be specific to Sonnet 4.5. I'm shocked this is still unresolved.
this is still an issue with 2.0.55, i am running the extension, or trying to get it up and running.
Opening a chat causes the extension host to crash.
[[BUG] Claude code extension memory leak issue #12611](https://github.com/anthropics/claude-code/issues/12611)
Having same issue, I deleted the large jsonl from ~/.claude/projects/-project-dir caused the restart loop to stop! But it causes the history to go away - reading the files, they are the chat history.
did you delete all the json files in the project dir?
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
Just posting here again to confirm as of just now, this issue is still unresolved and continues happening.
I finally gave up on visual code/cursor. They can't handle the amount of agents/sessions I have open. Went back to ghostty/tmux. total game changer. Using 10% of the memory I was with the visual code/cursor ide's. Turns out it wasn't ever claudes or codexes fault (I was having issues with both the cli's). No the answer people probably want to hear, but I've gone a week straight of power coding with agents (probably 30+ sessions all running at once) and have yet to have a single cli crash, or have to restart anything on my system. That's proof enough for me what the real cause was...
Confirmed fix: The root cause was accumulated conversation history files.
In my case: 955 JSONL files totaling 2GB in
~/.claude/projects/[project-dir]/Solution:
After clearing, the VS Code extension works perfectly again. The extension tries to load all history into memory on startup, causing OOM when history accumulates.
Credit to @peterchabs and @sibidharan above for identifying this fix - just confirming it still works in v2.1.31 and adding the diagnostic commands.
Reproduced on:
Key finding: VS Code Copilot Chat's Archive feature doesn't prevent OOM
I archived 468/502 conversations via Chat sidebar. Confirmed archived in workspace state DB (
state.vscdb):VS Code Copilot Chat's archive feature is useless for preventing OOM crashes. It's purely cosmetic UI filtering that happens AFTER files are already loaded into memory.
I had the same issue. My Claude history folder grew to 2.6GB.
Fix: cleared history and kept only the latest 20 conversations (now ~466MB).
Credit to @lachlanhawthorne for identifying a solution.
Problem
Claude extension slow/fails to load due to large conversation history (~2GB+).
The Script
Create
scripts/cleanup-claude-history.js:Find Your Project Directory
Auto-Run Options
1. npm start
2. VSCode (on folder open) - Add to
.vscode/tasks.json:3. Daily (3 AM)
4. Manual
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.