Renderer SIGTRAP (exitCode 5) on getPrStateForBranch for .claude/worktrees paths — 1.4758.0

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/51011
2. https://github.com/anthropics/claude-code/issues/51649
3. https://github.com/anthropics/claude-code/issues/48276

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

Resolved on my end — confirmed same root cause as #48281

The fix from #48281 (archive oversized ~/.claude/projects/*.jsonl transcripts) resolves this crash. After applying it and restarting, the previously-crashing worktrees open cleanly with no SIGTRAP.

What I did

Two-pass archive of ~/.claude/projects/ to a backup location outside ~/.claude/:

1. First pass: .jsonl files >10 MB and not modified in the last 24 hours — moved 13 files, ~223 MB.
2. Second pass: all .jsonl files older than 14 days regardless of size — moved 3,294 files, ~896 MB.

| Metric | Before | After |
|---|---|---|
| Largest single project's transcripts (the repo in 100% of crashes) | ~566 MB | ~129 MB |
| Second largest project | ~196 MB | ~89 MB |
| Third largest project | ~229 MB | ~42 MB |
| Total ~/.claude/projects/ | ~1.5 GB | ~371 MB |

Confirmation that #48281 and this issue are the same underlying bug

Both manifest as renderer SIGTRAP / exitCode: 5 from a V8 OOM abort, even though the surface trigger differs:

• #48281 trigger: clicking the Code tab → app loads project transcripts → OOM → SIGTRAP.
• This issue's trigger: opening a session inside a .claude/worktrees/<name> directory → LocalSessions.getPrStateForBranch IPC fires → renderer is already loading the parent project's transcripts → OOM → SIGTRAP.

Same renderer code path, same V8 ~2.7 GB heap ceiling, same crash signal. The worktree-session path is just an additional way to trigger the same OOM, which is why "fixes" that don't address ~/.claude/projects/ size (clearing Application Support/Claude, reinstall, --disable-gpu, --max-old-space-size) don't help — they target the wrong directory.

Suggested upstream improvements (still applicable to this issue)

1. Cap or stream-load .jsonl transcripts so a single large file or a directory of many files cannot OOM the renderer. Tail-load the last N MB by default and lazy-load older history.
2. Surface a clear error to the user when project transcripts exceed a safe threshold, instead of silently SIGTRAP'ing.
3. Make LocalSessions.getPrStateForBranch defensive so it cannot bring down the renderer when called against a worktree path that triggers heavy transcript loading.
4. Consider periodic background compaction / archival of old session transcripts.

Closing this on my end since the workaround resolves it. Leaving the issue open in case maintainers want to track the upstream-side fix.

Another occurrence: 2026-05-01 16:59:42 (Claude Code 2.1.121, macOS).

Main webview render process gone: { reason: 'crashed', exitCode: 5 }

Active session at the time was operating in /Users/chriscase/Documents/GitHub — heavy git activity across multiple repos with worktrees enabled.

Independent corroboration of the worktrees-path hypothesis from this issue's title: during the same session I had .claude/worktrees/agent-<uuid> directories appearing in the working tree of repos I was committing in. They got accidentally swept up by git add -A as embedded git submodules and required a follow-up commit + .gitignore entry to remove. So the harness is materializing those paths inside the user-facing repo trees, which lines up with the renderer hitting them.

Full crash count for the session that hit this: grep "render process gone" main.log shows 8 occurrences over 2026-04-30 → 2026-05-01 (~36h window), all with the same exitCode: 5 signature.

Another occurrence: 2026-05-01 19:00:02 (CLI 2.1.126, renderer still on 2.1.121, macOS).

Main webview render process gone: { reason: 'crashed', exitCode: 5 }

Active session pattern was identical to the previous report — heavy multi-repo git work with .claude/worktrees/ directories materialized inside the user-facing repo trees. Six PRs across four repos in ~2 hours (broadcast/notification feature slices A→F), with frequent branch switches, stashes, cherry-picks, and rebases across ~/Documents/GitHub/abydonian, AbydonianSupport, NexaDeck, and NexaCore.

.claude/worktrees/ directories observed inside repos during the session:

• abydonian/.claude/worktrees/: agent-a457d41b, agent-a6e05934
• AbydonianSupport/.claude/worktrees/: present
• NexaDeck/.claude/worktrees/: present (multiple including NexaCore, NexaMix, sleepy-shannon-e453e3)

Total renderer crashes in this main.log since the issue opened: 6 occurrences on 2026-05-01 alone (~28 total across the log). Crash signature is unchanged: same exitCode: 5, same SIGTRAP pattern.

This continues to be reproducible just by working across multiple repos that the harness has spawned worktrees in. The transcript-archival workaround from #48281 reduces frequency but doesn't eliminate it — confirming wsalem117's analysis that the underlying renderer OOM in LocalSessions.getPrStateForBranch against worktree paths is a separate fixable code path.

Suggestion still stands: make getPrStateForBranch defensive against worktree paths that trigger heavy transcript loading, and stream-load transcripts so a single large file can't OOM the renderer.

4 more occurrences today (2026-05-02), still macOS, still CLI 2.1.126 + renderer 2.1.121, still the same exitCode: 5 SIGTRAP signature on workflows that touch .claude/worktrees/<name> paths.

2026-05-02 00:07:24 [info] Main webview render process gone: { reason: 'crashed', exitCode: 5 }
2026-05-02 12:19:08 [info] Main webview render process gone: { reason: 'crashed', exitCode: 5 }
2026-05-02 16:48:47 [info] Main webview render process gone: { reason: 'crashed', exitCode: 5 }
2026-05-02 18:00:49 [info] Main webview render process gone: { reason: 'crashed', exitCode: 5 }

Per-day cadence in this main.log:

| Date | Occurrences |
|---|---|
| 2026-04-29 | 4 |
| 2026-04-30 | 4 |
| 2026-05-01 | 6 |
| 2026-05-02 | 4 (in progress) |

18 crashes in 4 days — averaging better than once every 5–6 hours of active use.

A few observations from continuing to hit this:

1. Crashes interrupt mid-tool-call. Several of today's hit while a long-running deploy/build was in progress, leaving the session in an indeterminate state — partial output captured, but the conversation transcript loses the in-flight context, and "Continue from where you left off" is needed.
2. The .claude/ mitigation is partial. I've added .claude/ to .gitignore across all four repos I work in (so the worktree dirs no longer pollute git status), and that's reduced but not eliminated the crashes. The renderer is still crashing during heavy git activity in worktree-laden trees, so the trigger surface in getPrStateForBranch (or whatever the actual offending path is) is independent of whether the worktree dir is tracked vs. ignored.
3. Transcript size is the more durable fix. wsalem117's transcript-archival workaround in #48281 consistently helps for a few days, then crashes return as transcripts grow again. That's consistent with V8 OOM as the underlying mechanism. An upstream fix to stream-load transcripts (or at least bound the renderer's heap consumption) would actually close this — workarounds are degrading over time as multi-repo work piles up transcript volume.

I'd genuinely appreciate any signal from maintainers that this is being looked at — even just a "we see it, ETA Q3" would be useful. Right now it feels like the issue is open in the bug tracker but otherwise invisible to the team. For a paid product this volume of unaddressed crashing on a routine workflow (multi-repo dev with worktrees, which is exactly what Claude Code itself encourages via subagents) is hard to keep absorbing.

Update — crashes stopped after upgrade to 1.6259.1+

Last occurrence of this exact Main webview render process gone: { reason: 'crashed', exitCode: 5 } signature in my main.log: 2026-05-02 23:45:29, on app version 1.5354.0. Nine days, nine hours later (today is 2026-05-12) — through normal heavy multi-repo work, worktree churn, and the same .claude/worktrees/ materialization pattern that previously reproduced this several times a day — zero recurrences.

Version progression in the same main.log over the gap:

| Date | App version | Crashes |
|---|---|---|
| 2026-04-29 → 05-02 | 1.5354.0 | 19 across 4 days |
| 2026-05-03 → 05-05 | 1.5354.0 (no usage gap) | 0 |
| 2026-05-06 | 1.6259.1 | 0 |
| 2026-05-09 | 1.6608.0 | 0 |
| 2026-05-10 → today | 1.6608.2 | 0 |

So between 1.5354.0 and 1.6259.1 (or somewhere downstream) something fixed this. I don't know which release was the actual fix point — if maintainers have a candidate commit/release-note mapping, that'd be useful for confirming.

Not closing on my end yet — want a couple more weeks of clean signal before doing that. But the trend is unambiguous, and given how reliably this used to fire under workflows I've kept doing the same way, I'm reasonably confident it's a real fix rather than a coincidence.

Thanks to whoever shipped the fix. Strongly suggest tagging this issue with the fixing version once identified so users searching the tracker know they need to upgrade past it.

Getting an immediate fix for this in Thursday's desktop release.

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.