GPU process crashes (UnknownVizError) when using Browser tools, corrupting the app package and requiring full reinstall

Adding a data point confirming this on a high-end discrete GPU with a fully healthy DX12 stack — so this isn't limited to integrated/weak GPUs or headless sessions.

Environment

• Claude Desktop 1.26832.0 (MSIX: Claude_1.26832.0.0_x64__pzs8sxrjxfjjc)
• Electron 42.7.0 / Chrome 148.0.7778.280 / Node 24.18.0
• OS: Windows 10 IoT Enterprise LTSC 2021 (10.0.19044)
• GPU: NVIDIA GeForce RTX 3080, driver 32.0.16.1074 (2026-07-02), WDDM 2.7
• Physical/direct-access desktop (NOT RDP or a headless session)

System GPU state is healthy (rules out a driver/DirectX problem):

• Win32_VideoController: Status OK, ConfigManagerErrorCode 0
• dxdiag: DDI Version 12, Feature Levels 12_1,12_0,11_1,11_0,10_1,10_0,9_3,9_2,9_1

Repro
Trigger the in-app agentic browser (a "site · Opened in Browser" card with an Open button; in my case app.roll20.net). Clicking Open opens the browser pane, then the window disappears within a second — before the target page even renders.

Log signature (main.log), matching this issue:

[error] [CDPTools] Compressed screenshot failed { error: [Error: UnknownVizError] ... }
[warn] [Preview] capturePreviewScreenshot failed: { error: [Error: UnknownVizError] ... }
[warn] [Preview] capturePreviewScreenshotIfChanged failed: { error: [Error: UnknownVizError] ... }

The crash correlates with the browser pane's automatic preview-screenshot capture, not with page content — consistent with the compositing-path hypothesis in this thread.

Aftermath (also matches): the MSIX package flips to Modified, NeedsRemediation and the app then refuses to launch with "There's a problem with Claude. Reinstall the application from its original install location…".

Mitigations that did NOT work in my case:

• winget repair / winget install --force / Add-AppxPackage -Register — none cleared NeedsRemediation (note: winget install --force pulled an older version 1.25927 and created a duplicate parallel install).
• Only re-laying the current MSIX over the top (Add-AppxPackage -Path Claude.msix -ForceApplicationShutdown) restored Status: Ok — but the next browser crash re-corrupts it.
• --disable-gpu passed via shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude --ArgumentList appears to be swallowed by the packaged app (no effect).
• No hardware-acceleration toggle is exposed in Desktop settings to test as a mitigation.

+1 on the request for a hardware-acceleration toggle (or honoring ELECTRON_EXTRA_LAUNCH_ARGS / an electron-flags.conf) so affected users have a working fallback.

main.anonymized.log
gpu-info.anonymized.json

Another data point — this time on integrated Intel graphics, so it's not limited to discrete GPUs either.

Environment

• Claude Desktop 1.26832.0 and 1.28929.0 (MSIX, Microsoft Store)
• Windows 10 Pro 19045
• GPU: Intel UHD Graphics 750, driver 32.0.101.7088 (2026-06)
• Same signature every time: GPU process gone: reason 'crashed', exitCode 101457950 (0x060C201E) while the in-app browser loads an external site, then main.log stops — the whole app dies. (exitCode 34 occurrences are benign here — GPU process restarts fine.)

Additional things ruled out on this machine

• Hardware acceleration OFF: on 1.28929 there IS a native toggle — Help → Troubleshooting → "Disable Hardware Acceleration" (persists isHardwareAccelerationDisabled: true in %APPDATA%\Claude\claude_desktop_config.json). The crash still occurs with acceleration disabled, identical exit code — so the GPU driver stack is fully out.
• Antivirus (Avast) folder exclusion for C:\Program Files\WindowsApps\Claude_* — no change.
• The crash leaves no forensic trace: no WER report, no Application/System event, Crashpad folder empty. The GPU process exits with a fatal code rather than faulting, so there is no dump to attach.

Possibly useful correlation for locating the code path: in 4 of 6 fatal crashes the last main.log line ≤2 s before death was
[PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
— and that warning never appears anywhere else in our logs.

MSIX recovery that works here without reinstall or reboot: the servicing failure lands ~7 s after the crash with 0x80073D02 ("apps need to be closed") because zombie claude.exe processes still hold the package — that's what leaves it in NeedsRemediation. Killing them first, then re-registering, has cleared it every time here:

Get-Process claude -ErrorAction SilentlyContinue | Stop-Process -Force
Get-AppxPackage *Claude* | % { Add-AppxPackage -Register -DisableDevelopmentMode "$($_.InstallLocation)\AppxManifest.xml" }

+1 on the core request: a GPU-process crash should not take down the shell and every running session.

Confirming this on a desktop dual-GPU system (not a laptop), with the full corruption-recurrence cycle documented. Same exit code, same WebGL signature.

Environment

• Claude Desktop 1.26832.0.0 x64, MSIX (Claude_pzs8sxrjxfjjc)
• Windows 11
• Desktop, AM5 platform, 8-core AMD Ryzen 7000-series CPU
• Discrete: NVIDIA RTX 50-series, driver 32.0.16.1088 (2026-07-22)
• Integrated: AMD RDNA2 iGPU, driver 32.0.21045.1000 / Adrenalin 26.7.1 (2026-07-23)
• Monitor connected to the discrete GPU

Crash signature — main.log:

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

Logged twice, then the app dies. The crash occurs ~2 seconds after launch, immediately after the OAuth token lookup — i.e. during initial render, not during an active browsing session. This differs from the existing reports, where the crash follows interaction with the browser pane.

Preceding errors — unknown-window.log, same second as the crash:

[warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127
[warn] OTS parsing error: Size of decompressed WOFF 2.0 is less than compressed size
[warn] A valid external Instance reference no longer exists.
[warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost

Also recurring, though I can't tell whether they're related: an unhandled promise rejection reporting no registered handler for a $eipc_message$ ... claude.buddy ... BuddyBleTransport ... reportState remote method (identifiers redacted), and Setting the document's base URI to 'https://claude.ai/' violates the following Content Security Policy directive: "base-uri 'none'".

Package corruption is a consequence of the crash, and it recurs

This is the part worth emphasising, because it turns a crash into an unusable install. After each GPU crash:

Get-AppxPackage *laude* | Select-Object Version,Status
1.26832.0.0    Modified, NeedsRemediation

In this state the app shows the Windows dialog "Can't open this app / go to Claude's advanced options and select Repair", and CoworkVMService cannot start at all (Cannot start service CoworkVMService) because its binary lives inside the package. Note the service's security descriptor also denies configuration changes to an elevated administrator (Set-Service ... Access is denied) while Stop-Service is permitted — worth checking whether that's intended.

What did and did not restore it:

• Settings → Apps → Claude → Repair: did not clear NeedsRemediation
• Add-AppxPackage -Register AppxManifest.xml (re-registration): completed with no error, status unchanged — it rewrites the store entry, not the files on disk
• Add-AppxPackage -Path Claude.msix -ForceApplicationShutdown -ForceUpdateFromAnyVersion, overwriting with the signed package freshly downloaded from your latest/redirect endpoint: restored Status: Ok and allowed the service to start

But it does not hold: the package returned to Modified, NeedsRemediation after the next crash. Three full cycles over two days. Each crash re-corrupts the registration, so the recovery path is a repeated 253 MB reinstall.

Ruled out

• GPU driver: updating the integrated AMD driver from a 2025-04 build to Adrenalin 26.7.1 with Factory Reset did not stop the crash
• Not a display-driver TDR — no nvlddmkm/Dxgkrnl events in the System log at crash time; the failure is contained to the Electron GPU process
• vmcompute and hns running, Virtual Machine Platform enabled

No usable mitigation via flags (confirming #83028 and #77857): MSIX blocks passing --disable-gpu / --disable-gpu-compositing, arguments passed via Start-Process shell:AppsFolder\... are silently dropped, and there is no hardware-acceleration toggle in Settings.

Workaround that appears to work: Settings → Claude Code → Browser → disable Browser tools. The cost is the entire in-app browser and live preview.

Requests

1. Don't let a GPU-process crash take down the whole app — Chromium normally relaunches the GPU process and repaints
2. Above all: don't let an ungraceful exit corrupt the MSIX registration. Repair-or-reinstall as the recovery path for a rendering fault is a very high price
3. Expose a Disable Hardware Acceleration toggle, or honour ELECTRON_EXTRA_LAUNCH_ARGS, so there is a reachable mitigation on MSIX
4. Consider defaulting multi-GPU desktop systems to software compositing (see #56805, which reports the same AMD-iGPU-plus-RTX-50-series pairing)

I can provide main.log, unknown-window.log and cowork-service.log privately via support if useful — I'd rather not attach them publicly, as they contain account and workspace identifiers.

There is a mitigation that keeps the in-app browser and live preview: the official Claude Setup.exe bootstrapper accepts an undocumented --exe switch that installs the classic non-MSIX (Squirrel) build to %LOCALAPPDATA%\AnthropicClaude\ instead of the MSIX. Root cause analysis in #81341 explains why that helps: the GPU process runs with the MicrosoftSignedOnly CIG mitigation while the package ships an Anthropic-signed vk_swiftshader.dll and no working AppxMetadata\CodeIntegrity.cat — inside the MSIX container that Code Integrity denial is escalated to a fatal GPU-process kill (your 0x060C201E) and it's the same integrity failure that flags the package Modified, NeedsRemediation after every crash. Outside MSIX the identical denial is non-fatal, which also solves the "MSIX blocks passing flags" problem, since the Squirrel claude.exe is directly runnable.

Verified on my machine (RTX 5080, Win11 26200) after 10/10 fatal crashes on MSIX with second-exact CodeIntegrity 3033/3010 events: after switching via "Claude Setup.exe" --exe, the same pages (Google Sign-In / GSI widgets in my case) load fine, GPU process survives, no new 3033 events, no package corruption. User data survives the switch (%APPDATA%\Claude and ~/.claude are shared between builds; no re-login). Another user confirmed the same fix on Win10 + AMD iGPU in #81341.