[BUG] Desktop app crashes on launch (V8 heap OOM) when a project has oversized session transcripts

[100401031]

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?

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
LocalSessions.checkGhAvailable: cwd=/Users//

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//, the app launches and stays up indefinitely with no OOM. Putting them back reproduces the crash.

There are really two bugs here:

1. 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.
2. 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

1. 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).
2. Make sure that project is the most recently focused session for the desktop app.
3. Launch the Claude Desktop app (open -a Claude or double-click).
4. App window appears, runs ~10–12 s, then crashes with the V8 heap OOM above. Repeats on every launch.
5. Workaround / confirmation: move the oversized .jsonl files out of ~/.claude/projects//, 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.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Desktop app crashes on launch with V8 heap OOM — single session .jsonl grew to 3.7 GB #48210
2. [BUG] Desktop Code tab: /stats scan materializes entire multi-GB transcripts (incl. subagents/) → browser-process V8 heap OOM kills app; CLI handles same sessions fine #67594
3. Desktop app OOM crash on large .jsonl transcripts — /stats scanner has no per-file size limit #50238

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

[junaidtitan]

You've correctly isolated both bugs: the startup scanner crash is an Anthropic-side fix (streaming/bounding the reads), and the 700MB transcripts are the root of both problems — both need addressing.

For the second part (the runaway growth), those files shouldn't be at 700MB. Normal tool use with large Read operations and long coding sessions produces files in the tens of MB at most. At 700MB each you almost certainly have very large tool-result payloads (full file contents, large bash outputs) that were written repeatedly through compaction cycles and never trimmed — each compaction pass re-embeds them rather than dropping them.

cozempic can reduce those files without losing conversation structure. cozempic treat current --rx aggressive targets exactly this kind of payload inflation — it trims oversized tool-result payloads, removes compaction metadata that got embedded back into the JSONL, and strips other provably-redundant content. A 700MB file is likely reducible to a few MB this way (I've seen 8.78MB → 606KB on a standard-complexity session). After treating, the files should be safe to put back in the project directory.

cozempic current --diagnose will show you the breakdown before treating — worth running first to confirm what's actually inflating them.

To prevent recurrence: cozempic guard is a daemon that monitors Claude's active session and auto-prunes + reloads when it hits a configurable threshold. The transcript stays bounded; the 700MB accumulation over several months doesn't happen again.

pip install cozempic / pipx install cozempic, runs as a Claude Code plugin automatically after install.