[BUG] Claude Desktop (Windows/MSIX): in-app browser preview triggers a GPU process crash (exitCode 101457950) that kills the app and leaves the MSIX package needing remediation; Windows repair loops with no effect

Preflight Checklist

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

Note on the first box: I did find three related open issues (#86535, #87172, #88068) and I describe the overlap and the differences under Additional Information. I am filing separately because this report contributes a concrete trigger, an exact fatal log line, and a same-install control case that none of them have.

What's Wrong?

Opening an external web page in the in-app Browser preview (Claude Browser MCP preview_start) crashed the Chromium GPU process four seconds later. That single GPU-process crash killed the entire app, and left the MSIX package in Modified, NeedsRemediation.

Windows' own repair path then ran nine times over 22 minutes, reported success every time, and never actually fixed it. A full OS reboot did not help either. Only Remove-AppxPackage followed by a fresh signed-MSIX Add-AppxPackage restored Status : Ok.

The most useful detail: a GPU-process crash on this same install was survivable seven days earlier. On 2026-08-14 the GPU process died with exitCode: 34, the app recovered and kept running normally for another week. It is specifically the 2026-08-23 exit path (exitCode: 101457950 / 0x060C201E) that took the whole package down with it.

This was not an OS-level or driver-level GPU fault. Across 12:00–19:06 on the day of the crash the Windows System log contains 0 events with ID 4101 (display driver recovered / TDR), 0 BugCheck (1001), 0 WHEA, and 0 Kernel-Power 41. No blue screen, no driver reset. The failure was confined to Claude's own Chromium GPU process.

What Should Happen?

Two things:

1. A GPU-process crash inside a preview_start browser view should be contained — Chromium normally respawns the GPU process, as it did on 2026-08-14 on this same machine. It should not terminate the main process.
2. However the app terminates, it should never be able to leave the MSIX package in Modified, NeedsRemediation. That state is what makes this unrecoverable: Windows' RepairAppRegistrationOption path reports success while changing nothing, so the user has no way back short of a full uninstall/reinstall.

Error Messages/Logs

# --- %LOCALAPPDATA%\Claude\Logs\main.log --- the last three entries in the file ---
2026-08-23 19:02:55 [info] [Preview] Created browser preview { serverId: 'browser-preview-<ts>-0' }
2026-08-23 19:02:59 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
2026-08-23 19:02:59 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}
# <EOF> - nothing further was written for 30 minutes, until the reinstall.
# The GPU process was never recreated and the main process wrote no shutdown record.
# exitCode 101457950 = 0x060C201E

# --- CONTRAST: a survivable GPU crash on the SAME install, 7 days earlier ---
2026-08-14 10:50:48 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 34, serviceName: 'GPU' }
2026-08-14 10:50:48 [info] [process-memory] trigger=stall ...
2026-08-14 10:50:52 [warn] [event-loop-stall] main process blocked for 1652ms ...
#   ... log continues normally for seven more days ...

# --- Microsoft-Windows-AppXDeploymentServer/Operational ---
# NINE RegisterByPackageFullName ops with RepairAppRegistrationOption, 19:03:11 -> 19:25:14.
# Every single one reported success:
Deployment Register operation on Package Claude_1.34493.1.0_x64__pzs8sxrjxfjjc:
  Trying to repair ACLs for \\?\C:\Program Files\WindowsApps\Claude_1.34493.1.0_x64__pzs8sxrjxfjjc
Deployment Register operation on Package Claude_1.34493.1.0_x64__pzs8sxrjxfjjc:
  ACLs repaired successfully ... Register next time should succeed.
Deployment Register operation with target volume C: on Package Claude_1.34493.1.0_x64__pzs8sxrjxfjjc
  from: (AppxManifest.xml) finished successfully.

# ...and yet after every one of them:
PS> Get-AppxPackage -Name Claude | Select-Object Name, Version, Status
Name    : Claude
Version : 1.34493.1.0
Status  : Modified, NeedsRemediation

# --- Microsoft-Windows-TWinUI/Operational --- every launch attempt ---
Activation of app Claude_pzs8sxrjxfjjc!Claude attempted.
  Execution state: Attempted activation of the app, 0, The operation completed successfully.
# ...but no Claude process was ever created.

# --- Application log, 19:03:45, source CoworkVMService ---
Claude VM Service: failed to disarm SCM recovery actions for this stop; if the stop overruns,
the service may be auto-restarted during package servicing: open service: Access is denied.
# and on the later start:
Claude VM Service: failed to configure SCM recovery actions; if the service crashes it will not
restart until the machine reboots: open service: Access is denied.

# --- What actually recovered it ---
19:32:44  Remove-AppxPackage  Claude_1.34493.1.0_x64__pzs8sxrjxfjjc   -> finished successfully
19:33:16  Add-AppxPackage     Claude-<hash>.msix (Anthropic-signed)   -> finished successfully
19:33:21  Status : Ok

Steps to Reproduce

I have not tried to reproduce this deliberately — the machine is a working environment and the failure costs a full reinstall, so I would rather not trigger it again on purpose. What happened, exactly:

1. In the Code tab, a session was researching a hardware problem.
2. It tried to read a vendor support forum (heavy JS, behind Cloudflare Turnstile). WebFetch returned HTTP 403.
3. The session fell back to the in-app Browser preview and called preview_start on that same URL.
4. [Preview] Created browser preview was logged at 19:02:55.
5. At 19:02:59 the page attempted an XHR that the preview blocked (Blocked subresource to private-resolving host), and in the same second the GPU process crashed with exitCode: 101457950.
6. The app died. Every subsequent launch attempt did nothing; Get-AppxPackage reported Modified, NeedsRemediation; a reboot changed nothing; only Remove + Add recovered it.

If it would help, I am willing to attempt a controlled reproduction (open a heavy JS site behind a bot-check in preview_start) on a machine where a reinstall is cheap. Tell me if there is specific logging or a flag you would like enabled first — see the note about crash dumps below.

Claude Model

Not sure/Multiple

Is this a regression?

I don't know

Last Working Version

Same version. Claude Desktop 1.34493.1.0 had been installed since 2026-08-21 and worked normally for two days before this crash.

Claude Code Version

Claude Desktop 1.34493.1.0 (MSIX, per-user) / bundled Claude Code 2.1.237

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment

• Windows 11 Home 25H2, build 26200.9168 (x64)
• Claude Desktop 1.34493.1.0 (MSIX, per-user install), bundled Claude Code 2.1.237
• GPU: hybrid / dual — NVIDIA GeForce RTX 3090 (driver 32.0.16.1088) + AMD Radeon integrated (driver 32.0.21043.5001)
• Not a terminal session — this is the Claude Desktop app's Code tab. Timestamps are JST (UTC+9).

No crash dump available. The Crashpad reports directory was wiped by the uninstall/reinstall, so there is no minidump for the GPU process. If there is another location where that dump lands, or a flag that preserves it across a reinstall, I am happy to capture it should this recur.

Relationship to existing open issues

• #86535 — same exact Windows build (26200.9168) and the same trigger class: "a crash that happened while previewing a localhost dev server from inside the app". That reporter states their logs contain no FATAL/ERROR and no dump, and that their install survives reinstall. Mine has an explicit GPU process gone ... reason:'crashed' line, and mine was fixed by Remove + Add. One thing worth checking there: the log lives in %LOCALAPPDATA%\Claude\Logs\, not %APPDATA%\Claude\logs\ — the latter was completely empty on my machine, so it is easy to conclude nothing was logged when it was.
• #88068 — same aftermath: Repair/Reset failing, only a full uninstall/reinstall recovering, and the same CoworkVMService ... open service: Access is denied warnings in the Application log. Same build family (26200).
• #87172 — similar in outline (Windows, "repair" offered but repair fails), too little detail to compare further.

This report sits between #86535 and #88068: #86535's trigger plus #88068's aftermath, with an exact fatal log line and a same-install control case showing that a GPU-process crash alone is not sufficient to cause this.

Questions

1. Is a GPU-process crash inside a preview_start browser view expected to be able to take down the main process at all?
2. Is there a known code path where abnormal app termination can leave the MSIX package Modified, NeedsRemediation?
3. Is the hybrid NVIDIA + AMD-iGPU configuration a known aggravating factor? #86535 is single-GPU, so it is presumably not required.
4. Would disabling hardware acceleration (or --disable-gpu) be a sensible interim workaround? #86535 reports --disable-gpu did not help in their case, but their failure mode differs from mine.