[BUG] GPU process crash (exitCode 101457950) kills host app shell during live browser preview

Confirming this on a different machine, and I can add a deterministic reproducer —
in my case the crash is not timing-dependent at all.

Environment

| | |
|---|---|
| OS | Windows 11 Pro 10.0.26200 |
| Claude Desktop | 1.25927.0, MSIX (SignatureKind: Developer) |
| GPU | NVIDIA GeForce RTX 4070 Ti (desktop), driver 32.0.16.1088 (610.88) |
| Exit code | 101457950 / 0x060C201E — identical to every report here |

Reproducer: 31 out of 31 attempts

1. Ask Claude to open any URL in the Browser pane (preview_start).
2. Grant the origin permission card.
3. GPU process crashes 5–15 s later; the entire app terminates.

No dev server, no live-render loop, no long session required. A single plain
https:// page is enough. It has failed every single time — 31 occurrences in one
session, zero successes.

Log sequence, identical on every occurrence

15:11:51 [info] [Preview] Created browser preview { serverId: 'browser-preview-...' }
15:11:51 [info] [PreviewOriginPolicy] origin prompt: in-app card for serverId=preview-local_...
15:12:02 [info] [PreviewOriginPolicy] origin prompt (card) decision: allow_once
15:12:08 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

The log then jumps straight to Starting app at the next manual launch — no recovery.

This is not a regression — the pane has never worked here

Worth noting for anyone bisecting: my logs go back to 2026-06-02. The string
Created browser preview appears for the first time ever on the same day the
crashes started. The two preceding months contain zero GPU process gone entries,
not because the app was healthy but because the pane had never been opened.

So on this machine the Browser pane has a 0% success rate since it first existed.
If other reporters see "it used to work", it may be worth checking whether the pane
was actually exercised before, rather than assuming a driver or app regression.
I lost several hours chasing a driver update that turned out to be coincidental.

Additional things ruled out (beyond the list already in #83835)

• Two NVIDIA driver versions: 610.74 and 610.88, the latter via a clean install

with "reset all settings and profiles to defaults". Identical crash on both.

• A secondary virtual display adapter (Parsec Virtual Display Adapter) disabled

in Device Manager — still crashes.

• The Parsec application fully terminated (parsecd not running) — still crashes.
• Hardware-accelerated GPU scheduling already off (HwSchMode = 1).
• %APPDATA%\Claude\Crashpad contains no minidumps, only settings.dat.
• No Application Error / Windows Error Reporting / Application Hang entries

in the Windows Application log for this process.

• No TDR events (nvlddmkm, Event ID 4101) in the System log — this is a

user-mode GPU process crash, not a kernel-level display driver reset, which is why
none of the usual Windows crash telemetry catches it.

• Reproduced on app versions 1.24012.9, 1.24012.11 and 1.25927.0.
• Reproduced before and after Windows updates KB5101684 / KB5101711 plus a reboot.
• Not memory pressure: ~2.5 GB system RAM free, app tree ~1.6 GB at crash time.

On the MSIX workaround gap

Seconding the point raised in #83835: there is no --disable-gpu escape hatch on MSIX
builds, and no hardware-acceleration toggle in Settings or in
%APPDATA%\Claude\config.json. Affected users cannot fall back to software rendering,
so the Browser pane is simply unusable rather than degraded.

Two things that would help even without a root-cause fix:

1. Don't take the app down with the GPU process. Chromium is designed to survive a

GPU process crash; terminating the whole shell turns a recoverable renderer fault
into total data loss for the session.

1. Expose a hardware-acceleration toggle persisted to config.json, so MSIX users

have any workaround at all.

Happy to provide full main.log files or run any diagnostic on request — the repro is
reliable enough that I can test a proposed fix in seconds.

Cross-reference: posted measurements in #83835 showing the preload is skipped at
runtime, the webgpu_decoder_impl.cc:1851 fallback path the startup guard cannot see,
and a version timeline indicating this is not a regression — which matches
@pierremorales's finding here that the pane never worked. Also killing the
AllowStoreSignedBinaries line of inquiry: Chromium never implemented it, and the
package is Developer-signed so the Store signing level is unreachable anyway.

Adding a data point with fuller diagnostics than I've seen on this thread — including the post-crash Chromium internal log and an explanation for the "app won't reopen until repaired" symptom. Happy to provide any of the raw logs.

Environment: Windows 11 Pro 26200, desktop (not hybrid graphics): RTX 5070 Ti (driver 610.88), AMD iGPU disabled in Device Manager — so this reproduces with a single dGPU, which argues against the hybrid-GPU-switching theory from #81698. App v1.26832.0 (MSIX / Store), CCD 2.1.222.

Repro: 100% deterministic, 7/7 attempts tonight. Trigger is opening the built-in browser preview (preview_start → pane opens at http://localhost:<port>). App dies ~1s after the pane opens, every time.

Captured with ELECTRON_ENABLE_LOGGING=file at the moment of death:

[..:ERROR:services\network\p2p\socket_manager.cc:137] Failed to resolve address for stun1.l.google.com., errorcode: -105   (x3)
[..:ERROR:content\browser\gpu\gpu_process_host.cc:998] GPU process exited unexpectedly: exit_code=101457950
[..:ERROR:content\browser\gpu\gpu_process_host.cc:992] GPU process launch failed: error_code=18
   (5 consecutive instant relaunch failures, all error_code=18)
[..:FATAL:content\browser\gpu\gpu_data_manager_impl_private.cc:418] GPU process isn't usable. Goodbye.

So the app-wide death is Chromium's intended GPU process isn't usable shutdown — the real question is why the relaunches fail instantly with launch error 18 (the initial crash alone should be recoverable). Every session start also logs:

ERROR:ui\gl\direct_composition_support.cc:243] GetGpuDriverOverlayInfo: Failed to retrieve video device

Why the app won't reopen afterward (the #81836 / #82967 symptom): after the crash, launches fail before any app code runs (nothing in main.log). The AppXDeploymentServer/Operational log shows the package had status flags set that the Settings-app "Reset/Repair" then clears:

Successfully updated the status for package Claude_1.26832.0.0_x64__pzs8sxrjxfjjc (Clear=0x300, Set=0x0)
Successfully updated the status for package ... (Clear=0x10000C00, Set=0x0)

i.e. the crash leaves the MSIX package in a modified/tampered state that blocks activation until repaired. That's why a normal restart never works.

Ruled out on this machine (crash identical after each): Bitdefender fully disabled; SteelSeries Sonar/Nahimic stopped; MSI Center + GameBar + Ryzen Master uninstalled (no overlay/injection software left); per-app GpuPreference=2 pin; iGPU disabled. No WER reports and no Crashpad dumps are ever produced — the GPU process dies without writing anything, and exit_code=101457950 (0x060C201E) is identical across all 7 crashes and across the reports on this tracker, which suggests a deterministic internal path rather than environment-specific corruption.

Confirming this on a second configuration, and adding mitigation results.

Intel UHD Graphics 620 (integrated only), Windows 11 build 26200, Claude Desktop
1.26832.0 (MSIX), Electron 42.7.0. Identical exitCode 101457950, reproduced 4/4
attempts on 2026-08-07. Same WebGL INVALID_ENUM burst and the same
capturePreviewScreenshot failures before the GPU process dies.

The trigger is narrower than "live-render loop": in my case the last line before
every crash is a WebGPU adapter request —

[warn] The powerPreference option is currently ignored when calling
requestAdapter() on Windows. See crbug.com/369219127
[info] GPU process gone: { reason: 'crashed', exitCode: 101457950 }

...logged exactly 1 second before death, every time. A static HTML page in the
pane never crashed for me; any page touching WebGPU always did. One crash needed
no page at all — creating the preview was enough for the renderer to probe it.

Two mitigations tested, neither works: updating the Intel driver (2020 -> 2026
release), and the "Disable Hardware Acceleration" toggle in 1.26832.0. The
toggle was verifiably active (--use-angle=d3d11-warp-webgl) and it crashed
anyway, because that switch covers WebGL but not WebGPU/Dawn. Detail and a
concrete one-line fix proposal in #83028.

Same signature also reported in #83028, #80444, #81698 and #81159 — this looks
like one bug, not five.