Code tab: renderer crashes during session hydration (exitCode 5 / SIGTRAP) — Claude Desktop 1.6608.2 on macOS 26.4.1

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?

Summary
The Claude Desktop app's main webview renderer crashes reliably when opening certain Code-tab sessions. The crash fires during the session "warm" phase — before any user input — and the app silently reloads to a blank state. Sessions whose on-disk .jsonl transcript is around 1 MB or larger reproduce 100%. Smaller sessions in the same app work fine.

This appears to be the same V8 crash class as the closed issue #57174, which carries a v8::Isolate::LowMemoryNotification() stack. Filing fresh because that issue is closed as a duplicate and is scoped to the bundled CLI rather than the desktop renderer.

Environment
Claude Desktop: 1.6608.2 (also seen on 1.6608.0)
CCD bundled: 2.1.128
Electron: 41 — Node: 24.15.0
macOS: 26.4.1 (Build 25E253)
Hardware: Mac16,7 (M4 Pro), 48 GB RAM, Apple Silicon (arm64)
Reproduction
Open Claude Desktop → Code tab.
Click into a CCD session whose .jsonl transcript is ≥ ~1 MB on disk (under ~/.claude/projects/<encoded-cwd>/<sessionId>.jsonl).
Within ~1 second of the session finishing its warm-up, the renderer dies and the app reloads.
Reproducible every time on the affected session. Same session resumes cleanly via the bundled claude CLI, so the transcript itself is not corrupt.

Crash signature (from ~/Library/Logs/Claude/main.log)
[info] [CCD] LocalSessions.setFocusedSession: sessionId=local_36ace9d3-...
[info] [CCD] Warming session local_36ace9d3-...
[info] LocalSessions.startShellPty: sessionId=local_36ace9d3-..., cols=80, rows=24
[info] [CCD] Session local_36ace9d3-... warmed successfully in 1170ms
[info] Main webview render process gone: { reason: 'crashed', exitCode: 5 }
[error] Sentry caught: { value: 'Main webview render process gone', stack: undefined }
exitCode: 5 + reason: 'crashed' on macOS = SIGTRAP from the renderer. No JS stack is captured because Sentry can't serialize anything before the process is gone. Electron also suppresses per-renderer crash dumps for the webview helper, so no .ips exists in /Library/Logs/DiagnosticReports.

The trigger is session hydration, not message send — no user input is required.

Likely V8 path (from closed sibling #57174)
v8::Isolate::LowMemoryNotification()
node::AsyncWrap::~AsyncWrap()
A fatal CHECK inside V8's low-memory handler, not a clean V8 OOM (which would surface as reason: 'oom'). LowMemoryNotification is invoked by Chromium in response to OS memory-pressure signals, so V8 heap size limits are not the gating factor.

Related listener leak (probably compounding, not causal)
Recurring in claude.ai-web.log since at least early May 2026:

[warn] MaxListenersExceededWarning: Possible EventEmitter memory leak detected.
11 ... AutoUpdater_$_updaterState_$store$_update listeners added
11 ... LocalSessions_$_onEvent listeners added
Same pattern as #26924 / #2506.

What does NOT prevent the crash
Verified by relaunching with these flags and reproducing the crash within seconds:

--js-flags="--max-old-space-size=24576" (24 GB V8 heap)
--disable-gpu-compositing
Both flags together via open -a Claude --args ...
Full ⌘Q quit + relaunch sequence
Workaround that works
Resuming the same session via the bundled CLI bypasses the Electron renderer entirely and works without issue:

cd /path/to/project
claude --resume <sessionId>
Logs available
Full main.log, claude.ai-web.log, and the macOS Claude Helper.diag resource report (shows ~8.6 GB of disk writes from the helper over 22 hours, with stacks dominated by v8::ArrayBuffer::GetBackingStore → Node page allocator → pwrite/ftruncate/__unlinkat — indicates aggressive memory spilling under sustained load) are available on request.

What Should Happen?

It shouldn't crash

Error Messages/Logs

Steps to Reproduce

Because the sessions become unstable, I cannot open them up to study them once they get locked into this state. I did move to CLI on one of them, at which point I had to expand to 1M token context window to continue so it could be linked to the need to compact at the 200k threshold, but I cannot verify that. I have had this occur across multiple projects though.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.139 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

_No response_