Desktop v1.8555.2 (macOS) crashes ~30s after launch during CCD `/stats` transcript scan on large session JSONL corpus

Status Fixed / completed

Maintainer reply None cached

Activity 4 comments · opened May 23, 2026 · closed Jun 22, 2026

Summary

After updating the Claude desktop app to v1.8555.2 on macOS, the app launches successfully but crashes consistently ~30 seconds later. Logs show the crash occurs during a background [CCD] /stats scan of local Claude Code transcript files. With ~1095 .jsonl files totaling ~9.8 GB on disk (largest single file ~5.5 GB), the scanner appears to OOM rather than completing the scan.

The app is otherwise unusable for me. I'm a heavy Claude Code user (VS Code extension) and rely on the desktop app for non-coding chat / project-management textual work. I've fallen back to the web app meanwhile.

Environment

App version: 1.8555.2 (auto-updated; previous version worked fine)
macOS: Darwin 25.5.0 (Apple Silicon, arm64)
Local transcript corpus under ~/.claude/projects/:
1095 .jsonl files / 9.8 GB total
1 × ~5.5 GB (current active VS Code extension session)
1 × ~2.8 GB (older session)
1 × ~313 MB
7 × ~80–100 MB (subagent transcripts)
Remainder: small
Claude Code surfaces in use: VS Code extension (heavy), desktop app (non-coding chat). I do not use Claude Code features inside the desktop app itself.

Steps to reproduce

Accumulate a multi-GB Claude Code transcript corpus under ~/.claude/projects/ (any heavy CLI / VS Code extension user will get there fast — single sessions can grow to multi-GB with large tool outputs persisted verbatim).
Update Claude desktop to v1.8555.2.
Launch the app.
Wait ~30s.

Result: app crashes. Reproducible across multiple launch attempts.

Diagnostic data

Last informative log line in ~/Library/Logs/Claude/main.log before the crash:

[CCD] /stats scanning 793/1095 transcript files since 2026-03-01

(Crash followed within a few seconds; progress counter never advances past this point in subsequent attempts either.)

A native crash dump was written to:

~/Library/Application Support/Claude/Crashpad/completed/<uuid>.dmp  (~1.9 MB)

I have not attached the dump because it may contain conversation content. Happy to share through a private channel if useful.

A Sentry event also fired during startup (before the scan; possibly unrelated):

[error] Sentry caught: { eventId: 'c3700b9e442d401c938aead4d2aa5c41',
                          type: 'Unknown', value: 'No message', stack: undefined }

Flagging in case it provides a correlation handle.

Hypothesis

The /stats CCD scanner appears to hold too much transcript data in memory while iterating files. Heavy Claude Code sessions legitimately reach multi-GB JSONL sizes (large tool outputs persist verbatim). A scanner that materializes file contents into the JS heap rather than streaming bounded summaries will OOM Electron's renderer or main process around the point we see in the log.

Suggested fixes (any one would unblock)

Stream parsing with bounded memory for per-file summary stats; never materialize a whole file.
Size-skip threshold: for files above some size (e.g., 500 MB), record a one-line \"transcript too large to summarize\" entry in the stats UI rather than scanning.
User-facing opt-out to disable the /stats scan entirely for users who don't use Claude Code integration inside the desktop app (my use case).

Workaround

None applied. I have deliberately not moved/archived any transcript files because the active 5.5 GB JSONL is the current VS Code extension session and preserving its on-disk persistence is more important to me than the desktop app working. Using web app for desktop-app workflows in the meantime.

Severity

Desktop app is unusable for me on this machine. Workaround (web app) is available, so personal impact is medium. If many users with large session corpora hit this, broader impact could be higher.

View original on GitHub ↗

4 Comments

jshaofa-ui · 4 months ago

Proposed Solution: CCD /stats Transcription Crash Fix

Root Cause

Desktop v1.8555.2 crashes ~30s after launch during CCD /stats transcription. Likely memory leak or Node.js heap limit hit during stats processing. macOS-specific regression in this version.

Fix

Short-term: Transcription timeout guard (30s) + memory check before processing
Medium-term: Incremental stats rendering with progress indicator
Long-term: CCD stats architecture refactor — separate collection from rendering, use web worker

Testing

Launch Desktop v1.8555.2 on macOS — verify no crash within 60s
Monitor memory during transcription
Verify graceful degradation on failure

Full solution: solutions/claude-code-61815-desktop-stats-transcription-crash-fix.md

Renhuai123 · 4 months ago

Same bug here, and it still reproduces on a much newer build — v1.12603.1 (Electron 42.4.0, macOS 15.7.1, Apple Silicon). Adding the crash-dump data this report was missing, plus a workaround that confirms causation.

Crash is in the MAIN (browser) process, not a renderer — from the Crashpad minidump:

process_type      : browser
v8-oom.heap.limit : 4294967296   (4.00 GiB)
v8-oom.heap.used  : 3503429524   (~3.26 GiB)
v8-oom.location   : CALL_AND_RETRY_LAST
> last resort; GC in old space requested
> out of memory
signal            : EXC_BREAKPOINT   (V8 fatal OOM, not a system EXC_RESOURCE)

Startup sequence (main.log), matches this issue exactly:

[CCD] /stats scanning 613/613 transcript files since 2025-12-14
[CCD] Session <id> transcript is 117116856 bytes; tail-loading last 50 MB   (x5 restored sessions, 53–117 MB each)

So beyond the full /stats scan, each restored large session also tail-loads + JSON-parses 50 MB into the same main-process heap. Corpus: ~1,627 transcripts / 9.2 GB total; 17 files >50 MB.

Transient spike, not a steady leak: surviving launches settle to ~220 MB RSS; crashes only happen in the first ~30–80 s during scan+parse, hence intermittent (GC timing right at the 4 GiB ceiling).

Workaround that confirms causation (the test this issue lacked): archiving the old large transcripts out of ~/.claude/projects lowers the startup spike. --js-flags=--max-old-space-size does not help — it does not apply to the Electron main process.

Also corroborating #50238: repeated MaxListenersExceededWarning: possible EventEmitter memory leak detected in the web logs.

Fix direction: stream/skip oversized files in the /stats scanner, move transcript parsing off the main process, lazy-load restored sessions, and/or raise the main-process heap cap.

junaidtitan · 4 months ago

The crash data from @Renhuai123 clarifies exactly what's happening: the browser process is trying to hold ~3.26 GB in the V8 heap (4 GB limit) before OOM, and the crash occurs mid-scan at file 793/1095. A scanner that materializes file contents into memory rather than streaming bounded reads can't handle that load — and the v1.12603.1 confirmation on the latest build makes clear this isn't going away on its own.

For the immediate workaround without losing history: the underlying reason sessions reach 5.5 GB is that tool outputs (Bash stdout, file reads, grep results, image payloads) are persisted verbatim in the JSONL. Cozempic can shrink those files substantially — the aggressive prescription strips oversized tool_result entries and replaces them with size-bounded stubs. Running cozempic treat current --execute -rx aggressive on the large sessions while CC is not running on them should reduce the footprint enough for the desktop scan to complete. The cozempic doctor command also identifies which sessions are the largest if you want an audit first.

Honest caveats: you'd want to verify the trimmed sessions still resume cleanly (check a small one first), and this is a mitigation for the file-size driver, not the scanner bug itself. Your streaming-scanner hypothesis is correct and that's the real fix — bounded reads per file, not full materialization. This is just a way to not have to delete your session history while waiting for it.

github-actions[bot] · 1 month ago

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.