Single session hangs renderer / input unresponsive while sibling sessions work — Claude.app v1.5354.0 on macOS 26.4.1

Summary

A specific session in the Claude desktop app becomes permanently unresponsive: clicking it from the Recent panel pegs the renderer at 100–170% CPU, the message input box accepts no typing, and Electron repeatedly logs Main webview is unresponsive, will kill and reload. Other sessions in the same project open fine and work normally. Restarting the app, restarting the Mac, and clearing renderer caches do not recover the broken session — it stays broken across launches while siblings stay healthy.

Environment

| | |
|---|---|
| OS | macOS 26.4.1 Tahoe (build 25E253) |
| Claude.app | v1.5354.0 (installed 2026-04-29) |
| claude-code SDK | v2.1.121 (Apr 29) / v2.1.126 globally via npm |
| Hardware | macOS, Apple Silicon |
| Project transcripts dir | ~/.claude/projects/<project>/ — 14 sessions, ~645 MB total |
| Affected session file | 14 MB · 2,955 lines JSONL · 161 user turns spanning 2026-04-16 → 2026-05-04 |
| Sibling sessions | Several at 78–100 MB — most open fine; one specific 14 MB session hangs |

Symptom signature in logs

~/Library/Logs/Claude/main.log:

2026-05-04 10:31:51 [info]  Main webview is unresponsive, will kill and reload
2026-05-04 10:00:30 [error] Sentry caught: { value: 'Main webview became unresponsive', stack: undefined }
                            'Utility' process exited with 'killed'

Webview kill+reload loop fires every ~6–7 minutes and on every click on the offending session.

Steps to reproduce (best as we can describe)

1. Open Claude.app (v1.5354.0 on macOS 26.4.1).
2. From the Recent panel, click a long-running session — in this case a 161-turn / 14 MB JSONL transcript with multiple tool-use turns and large embedded file reads.
3. Renderer process pegs 100–170% CPU.
4. Message input box becomes unresponsive — typed characters don't appear.
5. Electron logs Main webview is unresponsive, will kill and reload. Auto-reload happens. State is identical after reload — same hang on the same session.

Other sessions in the same project (including ones much larger at 80–100 MB) open and respond normally. The hang is reproducible only on the one specific transcript.

What did NOT fix it

• pkill -9 on the renderer process (respawns into the same hang)
• Cmd+Q and force-quit Claude.app, then relaunch
• Full macOS reboot
• Archiving older transcripts (the broken one is among the smallest at 14 MB)
• Selecting any other session first (those work; switching to the affected session re-triggers the hang)

Workarounds confirmed working

1. CLI resume — claude --resume <session-uuid> opens the same session in terminal with full history; no Electron renderer involved; works perfectly.
2. Other sessions — every other session in the same project opens and works normally in the same desktop app instance.

What we suspect

Single-session-specific renderer state corruption. The message body parsing or rendering pipeline hits something in this specific JSONL that throws the renderer into a loop. The fact that the kill+reload loop never recovers suggests the bad state is being rebuilt from disk on every launch — the session file itself contains whatever triggers it.

If the team can share a JSONL parser version we could try to isolate which entry breaks it, that would let us narrow this further.

Logs / artifacts available

I can share (privately, not in this issue):

• ~/Library/Logs/Claude/main.log slice around the kill+reload events
• ~/Library/Logs/Claude/claude.ai-web.log slice
• The offending JSONL transcript (after PII review on our end)

Happy to attach via support channel if useful.

Severity

Medium-high for our workflow. This was a 17-day, 161-turn planning session for a customer PoC — losing the desktop UI access means we can only resume it via CLI. The transcript content is intact and accessible; only the desktop renderer can't display it.