Windows desktop app dies entirely when GPU process crashes (Intel Arc); reliably triggered by built-in Browser pane

Summary

The Claude desktop app on Windows (MSIX, v1.30096.5.0) dies completely whenever its Chromium GPU process crashes. Chromium/Electron normally survives a GPU process crash (relaunches it, or falls back to software rendering after repeated crashes) — the Claude app instead vanishes entirely: the main process dies mid-log-write, taking every open Claude Code session with it.

On this machine (Intel Arc iGPU) the GPU process crash is reliably triggered within seconds by the built-in Browser pane / preview.

Environment

• Claude desktop app 1.30096.5.0 (MSIX, Claude_1.30096.5.0_x64__pzs8sxrjxfjjc), bundled Claude Code 2.1.229
• Windows 11 Home 10.0.26200
• Intel Core Ultra 5 125H (Meteor Lake), integrated Intel(R) Arc(TM) Graphics
• Reproduced on GPU driver 32.0.101.8801 (2026-05) and 32.0.101.8974 (2026-08, current latest) — driver update did not help

Evidence (from %APPDATA%\Claude\logs\main.log)

4 occurrences on 2026-08-17 alone — every time the last line before the app dies is:

2026-08-17 18:01:38 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

(log ends there mid-event; next line is the next app start)

Crash times: 17:49:24, 17:56:06, 18:01:38 (driver 8801), 18:28:07 (driver 8974).

Browser pane correlation:

18:01:30 [Preview] Created browser preview { serverId: 'browser-preview-...' }
18:01:38 GPU process gone   <- 8 seconds later

The 18:28:07 crash likewise happened the moment a session was using the built-in Browser pane. Sessions that avoid the Browser pane run for hours without issue.

There is no WER event, no Crashpad minidump (Crashpad reports/ is empty) — the main process death is silent. Sentry only captures a generic type: 'Unknown', value: 'No message' event on the next startup, so telemetry contains no useful signal about these deaths.

Nasty side effect (user confusion)

After the silent death, child claude.exe processes linger. They block MSIX re-activation — Windows tells the user the app "cannot be opened" — and Settings → Repair always fails with 0x80073D02 ("apps need to be closed"). Users end up at Repair/Reset, which never helps because the package is intact. Killing the leftover processes and relaunching is the actual fix.

Expected behavior

• Survive GPU process death like Chrome does: relaunch the GPU process, and after repeated crashes fall back to software rendering (--disable-gpu-equivalent) instead of dying.
• Alternatively (or additionally): expose a "disable hardware acceleration" setting so users on flaky GPU drivers (Intel Arc has a documented history of this — LiveKernelEvent 141/117/193 watchdog dumps on this machine since 2025) can opt out.
• Bonus: on startup after such a death, clean up leftover processes so MSIX activation and Repair don't fail.

---
Diagnosed and reported via Claude Code running inside the affected app, on behalf of the machine's owner.

🤖 Generated with Claude Code