Desktop app renderer crashes (exitCode 5) when opening large sessions (7K-14K messages)

Summary

The Claude desktop app renderer process crashes consistently (Main webview render process gone: { reason: 'crashed', exitCode: 5 }) when clicking on sessions with very large conversation histories. The app recovers but immediately crashes again on the next attempt to open the session.

Environment

• Claude desktop app: 1.5354.0
• Claude CLI: 2.1.128
• macOS: Darwin 25.3.0 (Apple Silicon, arm64)
• RAM: 24 GB
• Node.js: v24.2.0

Reproduction

1. Accumulate a long session (7,000–14,000 messages / 25–36 MB JSONL)
2. Open the Claude desktop app
3. Click the session in the sidebar

Result: Renderer crashes within 3–5 seconds. The app auto-reloads but crashes again on the next click of the same session. 34 crashes observed in a single day.

Root cause (from logs)

The renderer mounts the full message history as DOM nodes all at once. With 7,787–14,425 messages, the renderer heap is exhausted and the browser process kills it with exitCode: 5 (RESULT_CODE_KILLED).

The crash is always preceded by [CCD] [replaceRemoteMcpServers] Calling SDK with N servers — the renderer is being killed during or just after initial session render.

Relevant log lines:

[info] [CCD] LocalSessions.setFocusedSession: sessionId=local_311cb25c-...
[info] [LocalPluginsReader] Found 2 local plugins
[info] [CCD] [replaceRemoteMcpServers] Calling SDK with 8 total servers
[info] Main webview render process gone: { reason: 'crashed', exitCode: 5 }
[error] Sentry caught: { value: 'Main webview render process gone' }

Contributing factor: GitHub repo API polling fires unauthenticated 401 errors every ~7 seconds (/api/organizations/.../code/repos), adding constant GC pressure during the already-expensive initial render.

Affected session sizes

36 MB  / 14,425 lines  → crash
25 MB  /  7,787 lines  → crash
20 MB  /  ~5,700 lines → (untested but likely)

Workaround

claude --continue in the project directory works fine — the CLI streams without rendering full history.

Suggested fix

Virtualize the message list (e.g. react-virtuoso or similar) so only visible messages are mounted. The current approach of mounting the full history is not viable for long-running sessions.