Windows: app exits entirely when GPU process crashes (WebGL in in-app browser); no GPU-process recovery

Summary

On Windows, when the Claude Desktop app's GPU process crashes, the entire app exits — every open session dies and all their background tasks/subagents/workflows are killed. There is no GPU-process recovery. The GPU-process crash itself is reliably triggered by the in-app browser pane loading WebGL-heavy pages.

Environment

• Claude Desktop for Windows (MSIX install), observed on 1.24012, 1.25927.0, and 1.26832.0 (crashed 3.5 minutes after auto-updating to 1.26832.0, so the update did not fix it)
• Windows 11 Pro 10.0.26200
• GPU stack: NVIDIA RTX 5070 Ti (driver 610.74) + AMD iGPU + Meta Virtual Monitor driver + occasional RDP remote display adapter (machine is often used over RDP)
• NVIDIA driver update 591.86 → 610.74 (2026-07-22) made no difference — crash signature identical before and after

Signature

main.log (every occurrence, five so far across three days):

GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

The app process exits together with the GPU process. Crashpad captures nothing for these events.

Trigger

In-app browser pane navigating to WebGL-heavy pages. Cleanest confirmed case (2026-08-07 23:54): a forum page initializing three.js — the renderer log (unknown-window.log) shows a WebGL feature-probing burst (getInternalformatParameter INVALID_ENUM spam, typical three.js capability probing) at 23:54:38, and the GPU process died one second later, taking the app with it.

History

• Zero occurrences in logs June 1 – July 18 (pre-1.24012)
• 2026-07-21: app updated to 1.24012
• 2026-07-22: two crashes (16:13:00, 16:21:56), both WebGL pages in the in-app browser
• 2026-08-07: three crashes (~18:14, 23:48:06 on 1.25927.0, 23:54:39 on 1.26832.0 — i.e. it crashed again minutes after the auto-update)

Impact

One WebGL page in any single session's browser pane kills every concurrent session in the app, including long-running background agents and workflows in unrelated sessions. Subagents tend to fall back to the in-app browser when a site blocks plain fetching, so this fires organically during normal agentic work, not just interactive browsing.

Expected behavior

Either of:

1. Survive GPU-process crashes (Chromium/Electron supports GPU process relaunch; the renderer can fall back to software rasterization) instead of exiting the whole app.
2. Failing that, expose a hardware-acceleration/--disable-gpu toggle in settings so affected machines can opt out.

Happy to provide fuller log excerpts on request.