Desktop app terminates entirely when GPU process crashes on WebGPU request (AMD RDNA3, Electron 42; fixed in current Chromium)

Summary

Claude Desktop on Windows crashes completely (whole app terminates) whenever a page loaded in the embedded Browser/Preview pane requests a WebGPU adapter on a system with an AMD RDNA3 GPU. The GPU process crashes inside the AMD driver stack and instead of recovering (as Chromium normally does by restarting the GPU process), the entire app exits. This has happened 25+ times since late July 2026 on this machine, twice today.

Two distinct problems:

1. GPU process crash on WebGPU adapter request (Electron 42.9.2 / bundled Dawn + AMD RDNA3). Current Chromium does not have this problem: on the same machine, same driver, Edge 151 handles navigator.gpu.requestAdapter() + requestDevice() flawlessly (verified via webgpureport.org, full report renders). So the underlying Dawn/driver issue appears to be fixed or worked around in newer Chromium, and the app is exposed only because it ships an older Electron.
2. The app does not survive a GPU process crash. Even if the GPU process dies, the expected behavior is a restarted GPU process and a degraded-but-alive app. Instead the whole app terminates and all local sessions are lost. This resilience gap will bite anyone with a flaky GPU driver, regardless of vendor.

Environment

• Claude Desktop 1.34493.1 (MSIX / Microsoft Store install), Electron 42.9.2 (from app\version)
• Claude Code CCD 2.1.237
• Windows 11 Pro 10.0.26200, x64
• GPU: AMD Radeon RX 7900 XT (RDNA3), Adrenalin driver 32.0.31035.1003 (2026-07-24)
• isHardwareAccelerationDisabled: true was already set in config.json — does not help, since WebGPU/Dawn bypasses that setting and still talks to the real driver.

Log evidence

main.log (repeats for every crash; app start follows as next line, i.e. the process died):

2026-08-24 16:01:37 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
2026-08-24 16:01:38 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}
2026-08-24 16:03:34 [info] Starting app { appVersion: '1.34493.1', ... }

Window log immediately before each crash shows the WebGPU trigger:

16:01:38 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127
16:01:38 [warn] A valid external Instance reference no longer exists.
14:59:15 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost

Observed GPU-process exit codes across ~25 crashes since 2026-07-20: 101457950 (most common recently), -1073741205, 34, plus one reason: 'killed', exitCode: 1073807364.

Crashpad reports/ remained empty, so no minidumps were captured for these crashes.

Repro

1. Windows machine with AMD RDNA3 GPU (RX 7900 XT here), Adrenalin 32.0.31035.1003.
2. In Claude Desktop, open any page that calls navigator.gpu.requestAdapter() in the embedded browser/preview pane (e.g. webgpureport.org or any WebGPU demo).
3. GPU process crashes; entire app terminates.

Counter-test: same page in Edge 151 on the same machine/driver works perfectly (adapter vendor: amd, architecture: rdna-3, device creation OK).

Workaround

Launching the app with --disable-features=WebGPU prevents the crashes entirely. Clearing GPUCache / DawnWebGPUCache / DawnGraphiteCache alone was not sufficient historically.

Suggested fixes

• Upgrade the bundled Electron (Chromium ≥151 demonstrably handles this driver), or backport the relevant Dawn workaround/blocklist entry for RDNA3.
• Make the app survive child-process-gone for the GPU process: fall back to software/WebGPU-off instead of terminating. The config flag isHardwareAccelerationAutoDisabled suggests such a mechanism exists, but it never engaged here.
• Consider exposing a supported setting to disable WebGPU without command-line flags.