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

[danielsddd]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Summary

Keeping a live, continuously updating preview panel/browser view open during interactive web sessions repeatedly crashes the entire Claude Desktop application on Windows.

Actual Behavior

During active live-render updates in built-in browser views, Chromium's GPU process dies (GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }). Instead of gracefully catching the renderer/GPU crash and allowing the main app to recover, the parent Electron host process panics and terminates the entire application instantly.

Expected Behavior

A crash or failure within the GPU rendering layer or browser preview pane should be isolated to the webview process (showing an error frame or reload option) without killing the main desktop application shell or dropping active sessions.

What Should Happen?

The GPU process panic should be isolated to the webview layer, presenting a reload/error frame inside the browser pane without taking down the entire desktop application shell.

Error Messages/Logs

Evidence from %APPDATA%\Claude\logs\main.log:
2026-07-27 11:56:26 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

Associated log errors right before termination:
- WebGL: INVALID_ENUM: getInternalformatParameter
- capturePreviewScreenshotIfChanged failed: Preview not found

Steps to Reproduce

1. Open a web development session in the Claude Desktop app on Windows.
2. Allow the built-in browser/preview pane to stay open with a live dev server tab or active preview updates.
3. Perform interactive web testing or allow the live-render loop to run.
4. Mid-render, the GPU process panics and terminates the app instantly.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.218 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

• Tested on Windows 11 (MSIX packaged build).
• Workaround implemented: Adding instructions to .claude/CLAUDE.md to disable continuous live-updating preview panels and take single static screenshots via Chrome extension bypasses the trigger entirely.
• Suggestion: Add process isolation / exception handling around Electron's built-in GPU renderer so process panics don't crash the host application host.
• my current solution was to tell claude to never use preview live in browser, always open the app in chrome (from extension). using chrome never crushed my app.
• after crushing there is no way to open the app, the only fix is to uninstall the app completly.

[pierremorales]

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.
2. 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.

[osmanerendgn]

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.

[suburbazine]

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.

[rubendmmendes]

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.

[Fife84]

Adding two data points I haven't seen in this thread yet, plus downstream-cascade evidence with mitigations that hold up in practice.

Environment: Windows 10 Pro stable (10.0.19045), single-GPU desktop — AMD Radeon RX Vega (driver 31.0.21924.61) — Claude Desktop 1.28929.0.0 (MSIX Claude_pzs8sxrjxfjjc). Same signature as this issue, multiple occurrences across 2026-08-11 → 08-13:

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

Whole app dies with it every time (main.log goes silent instantly; Crashpad reports/ stays empty; no WER events). Timing matches the seconds-after-page-load pattern reported here: our three timestamped cases died 21s after an HTTPS API-docs page, 13s after an e-commerce listing page, and 44s after a localhost Next.js dev site loaded in the in-app browser pane. Frequency scales with usage intensity — 3 crashes in 21 minutes during a heavy multi-session afternoon.

1. Reproduces under pure software rendering. With isHardwareAccelerationDisabled: true active (GPU process confirmed running --use-gl=angle --use-angle=d3d11-warp-webgl, i.e. WARP software rasterization), the crash recurs with the identical exitCode. So no vendor driver is involved at all — consistent with the decoder/viz-layer findings above, and it means the "disable hardware acceleration" workaround is a dead end for this bug (worth knowing before anyone burns a day on it, as I did). This also extends the vendor matrix: NVIDIA and Intel are reported above; this adds AMD and Windows 10 stable.

2. The crash corrupts the package, and the self-repair can end in a full uninstall. Each crash leaves the package Modified, NeedsRemediation (the "won't reopen until repaired" state discussed above). The subsequent MSIX self-repair then collides with CoworkVMService locking its own cowork-svc.exe:

error 0x80070020: Creating file \\?\C:\Program Files\WindowsApps\Claude_...\app\resources\cowork-svc.exe failed.

On bad days that loop strands the machine with the app fully uninstalled until a manual re-download (event-log receipts in my comments on #84005 and #85905). So this GPU bug and the servicing-collision bugs multiply each other — fixing either one break the chain.

Mitigations that actually hold (for other affected users):

• Avoid the in-app browser pane for web work where possible (the Chrome-extension browsing path renders in Chrome's own processes; a crash there doesn't touch the app).
• CoworkVMService's ACL grants Authenticated Users stop rights — a standard-user script can Stop-Service CoworkVMService before reinstalling/re-registering to break the 0x80070020 loop, no admin needed.
• A scheduled task that re-registers the package (Add-AppxPackage -DisableDevelopmentMode -Register <InstallLocation>\AppxManifest.xml) during quiet hours clears NeedsRemediation left by the day's last crash.
• Not effective: disabling hardware acceleration; updating GPU drivers.

Happy to provide full main.log excerpts and the AppXDeploymentServer event sequences on request.