[Bug] Desktop crash loop: >50 MB session transcript crashes the GPU process on render, and startup session-restore repeats it

[Bug] Desktop app crash loop: sessions with >50 MB transcripts crash the GPU process on render, and startup session-restore repeats the crash

Environment

• Claude Desktop (Windows, MSIX install): app 1.24012.9, Claude Code Desktop component 2.1.219, Node 24.18.0
• Windows 11 Home 10.0.26200
• Intel Arc 140V GPU (16 GB), driver 32.0.101.8132 (2025-09-19)
• 32 GB RAM, 764 GB free disk

Summary

A long-running Claude Code Desktop session accumulated a transcript of 58 to 80 MB over several days. Whenever the app renders that session it logs a "tail-loading last 50 MB" warning; shortly afterwards the Electron GPU process crashes and the whole app dies. Because the app restores the last-focused session at startup, every relaunch immediately tail-loads the same transcript and dies again, producing a crash loop that looks to the user like a broken machine (I ran the Windows app Repair between attempts; it made no difference). The loop only ended when a different, small session took focus. Archiving the heavy session is a reliable workaround.

There were 13 app starts between the evening of 28 July and 08:43 on 29 July (six restarts 19:49-20:33, four around midnight, three between 08:32 and 08:43). In the log history from 2 May to 27 July there are zero GPU-process crashes; they begin the day the transcript passed roughly 58 MB.

Log evidence (from %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\main.log)

The tail-load warning fires on every render of the session, with the transcript growing across the crash window:

2026-07-28 22:42:49 [warn] [CCD] Session eef65079-... transcript is 58507739 bytes; tail-loading last 50 MB
2026-07-29 08:04:14 [warn] [CCD] Session eef65079-... transcript is 69092801 bytes; tail-loading last 50 MB
2026-07-29 08:32:04 [warn] [CCD] Session eef65079-... transcript is 80669480 bytes; tail-loading last 50 MB
2026-07-29 08:34:36 [warn] [CCD] Session eef65079-... transcript is 80707982 bytes; tail-loading last 50 MB

Two of the deaths left an explicit GPU-process crash record, identical both times, and each is the final log entry before the next "Starting app":

2026-07-28 00:05:22 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
2026-07-29 08:11:53 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

(101457950 = 0x60C201E.) The other terminations were abrupt, with no crash entry in main.log and, notably, no Crashpad reports at all (...\LocalCache\Roaming\Claude\Crashpad\reports is empty), so the crash reporter is not capturing these. The restore-then-crash sequence at each startup:

2026-07-29 08:32:01 [info] Starting app { appVersion: '1.24012.9', ... }
2026-07-29 08:32:04 [warn] [CCD] Session eef65079-... transcript is 80669480 bytes; tail-loading last 50 MB
2026-07-29 08:32:14 [info] [CCD] LocalSessions.setFocusedSession: sessionId=local_44c045aa-...
2026-07-29 08:34:33 [info] Starting app { ... }   <- app died within ~2.5 minutes, no crash record

The Cowork VM service (C:\ProgramData\Claude\Logs\cowork-service.log) sees each death only as Persistent RPC: connection ended: failed to read length: EOF, then stops; it is otherwise healthy. Windows also filed a RADAR_PRE_LEAK_64 resource-leak report against claude.exe on 27 July, consistent with memory pressure from the same session. The Windows System event log has no kernel or display-driver events across the whole period; the failure is contained entirely inside the app.

Steps to reproduce

1. Run a single Claude Code Desktop session with heavy tool output for several days until its transcript (~/.claude/projects/<cwd-key>/<session>.jsonl) exceeds ~58 MB.
2. Focus that session, or restart the app while it is the last-focused session.
3. Observe the "tail-loading last 50 MB" warning, then within seconds to minutes the app terminates (sometimes with the GPU process gone: reason 'crashed' record above).
4. Relaunch: the app auto-restores the same session and dies again.

Expected behaviour

• Rendering a large transcript should not be able to kill the app (virtualised rendering, or a much smaller render window than 50 MB).
• After an abnormal exit, the app should not immediately auto-restore the exact state that crashed it (crash-loop detection, or restore to the session list instead of the heavy chat).
• Crashpad should capture these terminations.

Workaround (verified)

Archive the oversized session (its transcript file remains on disk) and continue in a fresh session. The app has been stable since.