[BUG] Desktop app crashes on launch (V8 heap OOM) when a project has oversized session transcripts
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?
What's Wrong?
The Claude Desktop app (which bundles Claude Code session support) crashes ~10–12 seconds after every launch — it shows the window briefly, then quits ("flashes and disappears"). It is fully reproducible and makes the app
unusable.
Root cause turned out to be the startup transcript scan. The log shows the app scanning local Claude Code transcripts:
[CCD] /stats scanning 300/300 transcript files since <date>
LocalSessions.checkGhAvailable: cwd=/Users/<user>/<project>
That focused project contained three abnormally large .jsonl transcript files (~726 MB, ~705 MB, ~704 MB; normal transcripts are a few MB). The Electron main process appears to read/parse these into the V8 heap, grows to ~3 GB,
does last-resort GCs, and then hard-crashes with an out-of-memory error.
After moving just those three oversized .jsonl files out of ~/.claude/projects/<project>/, the app launches and stays up indefinitely with no OOM. Putting them back reproduces the crash.
There are really two bugs here:
- Crash robustness: the desktop app should stream/bound transcript reads (or skip files above a size limit) instead of loading entire multi-hundred-MB transcripts into the JS heap on startup. One oversized file should not crash
the whole app.
- Runaway transcript growth: these .jsonl files should never have reached ~700 MB. Something in Claude Code is letting individual session transcripts grow unboundedly (likely very large tool outputs / pasted content being
appended repeatedly).
What Should Happen?
What Should Happen?
The desktop app should launch and remain running regardless of transcript file size — large or malformed transcripts should be streamed, truncated, or skipped gracefully rather than causing a V8 heap OOM crash. Separately,
individual session transcripts should not grow to hundreds of MB.
Error Messages/Logs
Error Messages/Logs
... 10488 ms: Mark-Compact (reduce) 3043.1 (3136.6) -> 3043.1 (3135.4) MB,
pooled: 0.0 MB, last resort; GC in old space requested
... 10518 ms: Mark-Compact (reduce) 3043.1 (3135.4) -> 3043.1 (3134.4) MB,
pooled: 0.0 MB, last resort; GC in old space requested
[ERROR:electron/shell/common/node_bindings.cc:189]
OOM error in V8: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
macOS DiagnosticReports also logged a "disk writes" event for the same crashes (a side effect of the OOM dump):
Writes: 2147.50 MB of file backed memory dirtied over 13 seconds, exceeding limit ...
Heaviest stack: ... uv_guess_handle (Electron Framework) -> write (libsystem_kernel)
Steps to Reproduce
Steps to Reproduce
- Have a Claude Code project directory under ~/.claude/projects/ whose transcript history contains one or more very large .jsonl files (in my case three files of ~700 MB each, accumulated over several months).
- Make sure that project is the most recently focused session for the desktop app.
- Launch the Claude Desktop app (open -a Claude or double-click).
- App window appears, runs ~10–12 s, then crashes with the V8 heap OOM above. Repeats on every launch.
- Workaround / confirmation: move the oversized .jsonl files out of ~/.claude/projects/<project>/, relaunch → app stays up; move them back → crash returns.
Claude Model
None
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Claude Desktop app version: 1.13576.0 (com.anthropic.claudefordesktop); bundled Claude Code: 2.1.177.
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
Additional Information
- Claude Desktop app version: 1.13576.0 (com.anthropic.claudefordesktop); bundled Claude Code: 2.1.177.
- Heap peaked at ~3,043 MB before the OOM, consistently dying around the 10–12 s mark.
- Total ~/.claude/projects size was ~3.1 GB, dominated by the three ~700 MB transcripts in a single project.
- Suggested fixes: (a) cap/stream transcript reads on startup and skip files over a threshold with a warning; (b) investigate why per-session .jsonl files grow to hundreds of MB and add a size guard or rotation.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗