[Windows] Desktop app 1.24012.1: fatal GPU-process crash (0x060C201E) via in-app Browser tab; crash leaves MSIX package unlaunchable (appxState=2) until Repair

Environment

• Claude desktop app 1.24012.1.0 (MSIX Claude_pzs8sxrjxfjjc, build_type: windows-store), Electron 42.7.0 / Chrome 148.0.7778.280 / Node 24.18.0
• Windows 11 Home 26200, de-AT locale, 32 GB RAM
• GPU: NVIDIA GeForce RTX 2080 — reproduced on two driver versions (32.0.15.9595 and 32.0.16.1074), so not driver-specific
• Regression: zero GPU-process crashes in app logs on any earlier build (log history back to 1.22209.3); the app auto-updated to 1.24012.1 on 2026-07-22 at 15:28 UTC and crashed fatally 4 times within the following ~14 hours

Bug 1 — fatal GPU-process crash kills the whole app

Four identical fatal crashes (local time UTC+2): 2026-07-22 21:08:47 and 21:22:21, 2026-07-23 04:20:40 and 07:03:56 (= 19:08:47Z, 19:22:21Z, 02:20:40Z, 05:03:56Z).

Signature, every time, in %APPDATA%\Claude\logs\unknown-window.log — a page loaded in the in-app Browser preview tab runs a WebGL/WebGPU capability-probe suite (looks like standard bot-detection/fingerprinting code; several probed sites use it):

[warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat   (~19x, incl. "when EXT_color_buffer_[half_]float is not enabled" variants)
[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
[error] %c%d font-size:0;color:transparent NaN
A valid external Instance reference no longer exists.
[warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost

then immediately in main.log:

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

…and the entire app dies instantly with the GPU process (main.log stops mid-write, no shutdown path, window-state.json never re-saved). Exit code is 101457950 = 0x060C201E in all four crashes.

Repro chain observed 4/4 times: a Claude Code session opens an in-app Browser preview tab ([PreviewContext] Opened preview user tab / [Preview] Created browser preview in main.log) → 15–36 seconds later the loaded page runs the WebGL probe burst → GPU process dies → app dies.

Notably, a GPU-process crash with a different exit code (34, during a driver install) was recovered gracefully — the GPU process just relaunched. Only the 0x060C201E path takes the app down.

One of the four crashes happened fully unattended at 04:20 (an overnight workflow re-opened its Browser tab), so this also kills long-running/autonomous sessions.

Minidumps: Crashpad wrote dumps for all four crashes and the Sentry integration uploaded them at the subsequent app startups (local Crashpad db swept clean each time).

• Crashpad client_id: c022cf05-35e3-4f4e-9b4a-c4c68f176905
• Sentry did: e6db0749-fa5b-4a66-900d-313bdbe10bd4

The four events should be findable under those IDs around the UTC timestamps above. One captured Sentry event id from the 2026-07-22 19:14:57Z restart: 1a18be03af2243a38b279cd0adca2e8d.

Bug 2 — every fatal crash leaves the package unlaunchable until manual Repair

This is arguably the worse bug for ordinary users. After every fatal crash, Windows flags the MSIX package Modified (appxState=2) and refuses to activate the app — launch attempts die before any app code runs (zero log lines).

The OS then loops into Microsoft Store remediation, which cannot service the Developer-signed non-Store package (AppXDeploymentServer errors 8107 "invalid integrity check for a non-AppStore package" and 8104 / 0x80070057), and logs Trying to repair ACLs for C:\Program Files\WindowsApps\Claude_… → ACLs repaired successfully over and over (15+ times observed).

The only reliable fix is Settings → Apps → Claude → Advanced options → Repair, which re-downloads the full .msix from downloads.claude.ai and re-registers it — needed after every single crash.

Two aggravating factors observed in the AppX/AppModel event logs:

• The packaged CoworkVMService (cowork-svc.exe) survives the app crash and holds a file lock, so the automatic repair fails with 0x80070020 (sharing violation creating app\resources\cowork-svc.exe) until a ForceTargetApplicationShutdown register kills it (cost: ~3 extra minutes of outage).
• Repair's Register step reports 0x80073D02 ERROR_PACKAGES_IN_USE when the app relaunches mid-repair — cosmetic, but alarming to users.

Windows Error Reporting captures none of this (no Event 1000/1001 — Crashpad intercepts the fault), so from the OS's perspective the app just refuses to start with no diagnosable error. A non-technical user would plausibly conclude the app is broken and reinstall.

Ruled out during diagnosis

• Driver: reproduced identically before and after an NVIDIA driver update; zero nvlddmkm/TDR/dxgkrnl/WHEA events in the System log across all four crashes
• Memory: 10–12 GB system RAM free at every crash instant (app's own [process-memory] telemetry); no Resource-Exhaustion-Detector events; pagefile peak 219 MB
• Disk/package corruption prior to the crashes: the 1.24012.1 update staged and registered cleanly; Get-AppxPackage Status: Ok between episodes

Workarounds found (for other users hitting this)

• After a crash: Settings → Apps → Claude → Advanced options → Repair (kill leftover Claude processes incl. cowork-svc.exe first to speed it up)
• Prevention: avoid the in-app Browser pane on this build, or launch with GPU acceleration disabled (identity-preserving):

Invoke-CommandInDesktopPackage -PackageFamilyName Claude_pzs8sxrjxfjjc -AppId Claude -Command 'app\Claude.exe' -Args '--disable-gpu'

---

🤖 Diagnosed and drafted with [Claude Code](https://claude.com/claude-code) (forensics: app logs, Crashpad/Sentry state, WER + AppXDeployment/AppModel event logs)

Adding an independent reproduction with the same exit code, on Windows 10 — the other reports in this cluster (#80999, #81159) are all Win11 26200, so this may rule out an OS-build-specific cause.

Environment

• Claude Desktop 1.24012.9 (MSIX), Windows 10 Pro 19045
• NVIDIA GeForce RTX 3050 Ti Laptop (driver 32.0.15.7247) + AMD Radeon iGPU (hybrid laptop)

Crash
Single occurrence. The in-app Browser pane was loading a heavy web app (WASM SQLite + SharedWorker + IndexedDB). The pane was being driven programmatically by the in-app agent session at the time (same pattern as #81159), and a screenshot/capture was attempted while the pane was not displayed ("not compositing frames" state — the hidden-pane angle of #80999) ~1 second before the crash:

17:29:03 [warn] [Preview] capturePreviewScreenshot failed
17:29:04 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }  // = 0x060C201E

main.log stops mid-session at that line — the whole app died instantly. System was otherwise healthy: Chrome with multiple tabs + YouTube playback unaffected, no TDR/display events in the System log. (Earlier GPU crashed events on this same machine — e.g. exitCode 34 on an older build — did not kill the app, matching the regression framing here.)

Package corruption aftermath (same as OP)
8 seconds after the crash, Windows flagged the package Modified and started an automatic RegisterByPackageFullName repair, which failed repeatedly with 0x80073D02. Manual reinstall then failed with 0x80073CF9, inner error:

0x80070020: could not create ...\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

CoworkVMService kept running through all of this and could not be removed by the installer ("Access is denied"), so every repair/reinstall hit the file lock (same family as #46179 / #57221).

Recovery
Reboot (released the service lock) → fresh MSIX install of the same 1.24012.9 succeeded. The Settings → Apps → Repair path was not tried, so I can't confirm whether it would have worked without a reboot in this state.

Confirming this on a completely different configuration — Windows 10 instead of 11, Quadro instead of GeForce, but the same NVIDIA driver 32.0.16.1074 you tested. Strong signal the fault is in the app, not the setup.

Environment
Claude desktop 1.24012.9.0 (MSIX Claude_pzs8sxrjxfjjc, x64)
Windows 10 Pro 22H2, build 19045.6456, 32 GB RAM
GPU: NVIDIA Quadro RTX 5000, driver 32.0.16.1074 (2026-07-02), WDDM 2.7, dual monitor
No GPU or driver faults in the system log; dxdiag reports no problems

Crash — identical signature
The app dies during the Cloudflare Turnstile challenge on the sign-in screen, before any account access. Last lines of main.log:
[warn] Blocked permission check { permission: 'notifications',
requestingOrigin: 'https://challenges.cloudflare.com/', ... topFrameUrl: 'https://claude.ai/' }
[info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

Same exitCode: 101457950 (0x060C201E). Worth noting the trigger isn't limited to the in-app Browser pane — Turnstile's WebGL fingerprinting on the login screen hits it too, so the user never reaches the app at all.

Bug 2 is worse on Windows 10: Repair does not fix it
On Windows 10 the "Repair" button (Settings → Apps → Claude → Advanced options) performs a Register from AppxManifest.xml only — it does not re-download the .msix. AppXDeploymentServer log:

RegisterByPackageFullName ... RepairAppRegistrationOption
Register ... completed successfully
Overall time: 438 ms

438 ms, no download, result 0x0 — yet (Get-AppxPackage Claude).Status still returns Modified, NeedsRemediation. Only a full Add (running Claude Setup.exe) clears the flag, and the installer auto-launches the app immediately after install, which crashes on Turnstile and re-flags the package within seconds.

The documented workaround is therefore unreachable on Windows 10:
Invoke-CommandInDesktopPackage ... -Args '--disable-gpu' fails with 0x80073CFC while the package is flagged — and it cannot be un-flagged.
Attempts to register while processes remain fail with 0x80073D02 ERROR_PACKAGES_IN_USE / 0x80004004 deployment aborted due to active service Claude_pzs8sxrjxfjjc!Claude — CoworkVMService survives the crash and cannot be disabled (Set-Service → Access Denied, packaged service).
Killing the app in a tight loop during install to prevent the first launch also failed; the package is flagged before the process is reachable.

Ruled out: WMI repository (winmgmt /verifyrepository → consistent), system files (sfc and DISM both clean), WindowsApps ACLs untouched, MSIX SHA256 matches a fresh download from claude.com.

Net effect: on Windows 10 the app is permanently unusable after the first launch, with no user-accessible recovery path. A hardware-acceleration toggle that persists before first render — or simply not letting a GPU crash flag the package — would make this survivable.

Follow-up with two stronger data points collected since my previous comment.

1. Second machine, no NVIDIA hardware at all — identical crash

Claude desktop 1.24012.9.0, Windows 11 Pro build 26200, 32 GB RAM
GPU: Intel UHD Graphics 770 (32.0.101.7082) + AMD Radeon RX 6800 XT (32.0.21037.1004)
Same exitCode: 101457950 on the Turnstile challenge, same getInternalformatParameter probe burst in claude.ai-web.log, same Modified, NeedsRemediation flag afterwards.

That makes three GPU vendors across two Windows versions: GeForce RTX 2080 (yours), Quadro RTX 5000, and AMD/Intel. The driver-version overlap I flagged earlier is a coincidence — this is not driver-specific.

1. Same-engine control test rules out the GPU stack entirely

I replicated the crashing probe pattern in a Chromium 148 browser on the same machine, same GPU, same ANGLE D3D11 path as the crashing app (app reports Chrome 148.0.7778.280): 42 getInternalformatParameter calls with invalid internalformats, plus WEBGL_lose_context loseContext/restoreContext.

Renderer: ANGLE (AMD, AMD Radeon RX 6800 XT (0x000073BF) Direct3D11 vs_5_0 ps_5_0, D3D11)
42 probes run, 12 rejected by the driver, context lost and successfully restored
Result: browser survived the entire set, no GPU process crash

Same Chromium major, same driver, same adapter — the browser is fine, the app dies.

1. Forensics on the affected machine

All 9 package binaries carry valid Authenticode signatures (CN="Anthropic, PBC" for claude.exe, cowork-svc.exe, chrome-native-host.exe; Microsoft for the bundled runtime DLLs). So Modified is a deployment bookkeeping state, not on-disk tampering.
Zero display-driver events (TDR / WHEA / amdkmdag / dxgkrnl) in the System log over 14 days.
Zero WER 1000/1001 records — Crashpad intercepts the fault, so the OS sees nothing.
No other MSIX package on the system is in a Modified state; deployment machinery is otherwise healthy.
--disable-gpu does not prevent the crash: the GPU process is still spawned and dies, then GPU process launch failed: error_code=18 repeats 5×, followed by FATAL: GPU process isn't usable. Goodbye. The app kills itself. Escalating flag sets (--in-process-gpu, --use-gl=swiftshader --use-angle=swiftshader, --disable-webgl) were also tried without success.

Net: the crash is reachable from the login screen alone, survives every user-side mitigation, and permanently bricks the package on Windows 10. Not letting a GPU-process crash flag the package would by itself make this recoverable.

Same bug here, with some additional diagnostics that narrow down where the crash lives.

Environment: Claude Desktop 1.24012.9 (MSIX), Windows 11 Home 22631, NVIDIA RTX 4070 Ti SUPER (driver 32.0.15.9186, Jan 2026, installed March — unchanged), Claude Code 2.1.219.

Crash signature (5 occurrences, 2026-07-28 → 07-29):

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

Every crash: same exit code 0x060C201E, whole app dies (no GPU-process relaunch), Windows logs an AppHang (Event 1002), and the MSIX package is left in Modified state so normal launch is blocked until Settings → Apps → Repair.

Timeline evidence it's a regression: main.log history back to 2026-07-09 shows zero GPU-process crashes before 07-28. The app package updated 07-24 (folder creation date). No Windows update or GPU driver change in that window.

Trigger correlation: every crash followed in-app Browser pane activity on external sites. The clearest case: pane opened several x.com tabs at 17:30, GPU process died 17:32. x.com runs heavy WebGL/fingerprinting probes, consistent with the OP's analysis. Localhost previews never crashed it.

Key finding — the crash reproduces in the WARP path, so disabling hardware acceleration does NOT help:

• With isHardwareAccelerationDisabled: true in claude_desktop_config.json, the GPU process runs with --use-angle=d3d11-warp-webgl and still dies with the identical exit code (2 crashes in this state).
• With --disable-gpu passed to the exe: Browser pane still serves WebGL 1+2, renderer string ANGLE (Microsoft, Microsoft Basic Render Driver ... D3D11) — the app's forced gpu-preferences keep WebGL-on-WARP alive regardless of the flag.
• --disable-webgl / --disable-3d-apis do not propagate to renderers (removed from modern Chromium), so users have no way to close the WebGL path at all.

Suggestion: the app already ships a window with webPreferences: { webgl: false } (the feedback window), so the plumbing exists — exposing that (or a setting) for the Browser pane webContents would give users an effective mitigation until the WARP/ANGLE crash itself is fixed. Alternatively, catching the fatal GPU-process exit (0x060C201E) and relaunching instead of dying would at least stop the MSIX-Modified/Repair loop.

Recovery note for others hitting this: launching the exe directly (e.g. & (Join-Path (Get-AppxPackage -Name Claude).InstallLocation 'app\Claude.exe')) bypasses AppX activation, which appears to be what blocks relaunch when the package is flagged Modified — worth trying before a full Repair. Kill leftover claude.exe / cowork-svc.exe processes first (single-instance lock).

Hello, I think I also encountered this issue, and my issue blocks my usage of Claude Desktop app's internal browser which would be useful for me. Please be mindful about its priority.

Additional reproduction: AMD GPU, cross-driver evidence, and reproduction under WARP software rendering

Adding a second environment with the same fatal signature and several observations that may help narrow the cause.

Environment

• Claude Desktop 1.24012.9.0 (MSIX), Electron 42.7.0
• Windows 11 Pro build 26200
• AMD Radeon RX 9070 with an integrated Radeon iGPU
• Matching crashes occurred before and after an AMD driver update

Same failure as OP

• No matching GPU-process crashes were found in the retained logs from earlier builds. The fatal crashes began after the 1.24012.x update, with four occurrences over approximately three days.
• Each crash occurred within approximately 1 to 2 seconds of embedded Browser preview activity while the loaded page was running WebGL capability probes:

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

• The package subsequently changed to Modified, NeedsRemediation, and activation failed with 0x80073CFC until the package was repaired.
• Memory pressure was not present. The latest pre-crash telemetry showed approximately 2.8 GB application RSS and approximately 48 GB of free system memory.
• No corresponding WER fault, display-driver TDR event, or DxgKrnl error was logged. The GPU process exited with the same custom code on every occurrence, although that alone does not establish why Chromium terminated it.

Not isolated to one driver version or GPU vendor

The AMD display driver was updated during the investigation, and the same fatal signature recurred afterward. Combined with the OP's NVIDIA reproduction across two driver versions, this makes a defect specific to one GPU vendor or driver version less likely.

Key finding: --disable-gpu is not a sufficient workaround

When launched with:

--disable-gpu --disable-gpu-compositing

the GPU helper continued to provide WebGL through WARP:

--use-angle=d3d11-warp-webgl

The identical 0x060C201E failure reproduced in that configuration. The failure therefore does not require hardware GPU acceleration and persists when Chromium uses its Windows software-rendering backend.

The crashes were consistently and immediately preceded by WebGL capability-probe activity, including the INVALID_ENUM and CONTEXT_LOST_WEBGL sequence described by the OP. This is a strong temporal correlation, although it does not by itself prove which WebGL component is responsible.

Stricter workaround under evaluation

Launching with:

--disable-gpu --disable-gpu-compositing --disable-gpu-rasterization --disable-software-rasterizer

causes the GPU helper to run with:

--use-gl=disabled

A short stress test using multiple embedded Browser tabs, image-heavy HTML previews, and local preview servers completed without another crash. This has not yet been validated over an extended period. The tradeoff is that WebGL and 3D content cannot render in the embedded Browser.

Repair issue

After a crash, reinstall or repair may fail with 0x80073CF9. In this reproduction, the underlying AppX deployment error was 0x80070020, a sharing violation while replacing cowork-svc.exe. The file was held by CoworkVMService. Stopping that service allowed installation to complete, and the service restarted afterward.

This is separate from the stale chrome-native-host.exe lock and 0x80073D05 condition already documented.

I can provide additional sanitized excerpts or test a build containing a candidate fix.

Another reproduction: RTX 5000 Ada + Intel hybrid on Win10 19045, 115 GB free RAM at the crash instant — and Bug 2 needed a full uninstall/reinstall, 25 Repair attempts over 55 h all failed

Adding a data point that I think strengthens the driver-agnostic claim and kills the memory-pressure reading. More importantly, I have AppXDeploymentServer forensics for Bug 2 that back up @SaLoGeF's "Repair does not fix it on Windows 10" finding with hard numbers.

Environment

• Claude Desktop 1.24012.9.0 (MSIX Claude_pzs8sxrjxfjjc, x64)
• Windows 10 Pro 19045, zh-CN locale
• Dell Precision 7780 mobile workstation, i9-13950HX, 128 GB RAM
• Hybrid graphics: NVIDIA RTX 5000 Ada Generation Laptop GPU (driver 32.0.15.7342 = R570 U6 / 573.42, dated 2025-06-11) + Intel UHD Graphics (31.0.101.5522, 2024-05-11)
• HAGS enabled (HwSchMode=2; registry key last written 2024-10-29, i.e. unchanged through the crash)
• Chromium hardware acceleration at default (enabled — no isHardwareAccelerationDisabled in claude_desktop_config.json)
• Single crash: 2026-07-27 23:01:09 local (UTC+8) = 15:01:09 UTC

---

Bug 1 — same signature, probe→death gap is 1 second

%APPDATA%\Claude\logs\unknown-window.log:

23:01:00 [error] Loading the script 'https://www.walmart.com/akam/13/2fadd2cb' violates ... CSP
23:01:08 [warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat          <- 19 lines,
23:01:08 [warn] ... invalid internalformat when EXT_color_buffer_[half_]float is not enabled        both EXT
23:01:08 [warn] ... invalid internalformat when EXT_color_buffer_float is not enabled               variants
23:01:08 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127
23:01:09 [error] %c%d font-size:0;color:transparent NaN
23:01:09 [warn] OTS parsing error: Size of decompressed WOFF 2.0 is less than compressed size
23:01:09 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost

main.log, same second:

2026-07-27 23:01:09 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

101457950 = 0x060C201E. main.log stops mid-write; whole app gone. Line-for-line match with the OP, down to the %c%d font-size:0;color:transparent NaN and the WOFF 2.0 OTS error.

Two more bot-detection vendors on the trigger list

The pane was being driven programmatically by an agent session (Workflow tool). In the ~2 minutes before the crash it loaded, among others:

• walmart.com — the CSP-blocked script path is /akam/13/..., i.e. Akamai Bot Manager
• trademarks.justia.com / connect.justia.com
• several pages emitting getAwsWafToken(): AwsWafIntegration is not defined - check challenge.js script in configuration.json — AWS WAF challenge

So alongside Cloudflare Turnstile and x.com, Akamai Bot Manager and AWS WAF challenge pages also reach the crashing probe path. Three different commercial bot-detection products now, consistent with the OP's "standard fingerprinting suite" framing.

Memory pressure is not it

App's own telemetry, 48 s before the crash:

2026-07-27 23:00:21 [info] [process-memory] trigger=interval tree_rss_sum=3600MB electron(18)=3600MB
  top=[electron_renderer:21676:803MB electron_main:18376:353MB electron_gpu:23184:311MB ...]
  sys_free=114457MB/130757MB

114 GB of 128 GB free, GPU process at 311 MB, 16 GB of dedicated VRAM essentially idle. Earlier reports cited 10–12 GB free on 32 GB machines; this widens that margin a lot.

On the "is it load?" question: this session was unusually heavy on the pane — 116 browser:open_site-related records in the preceding 20 min, openTabs reaching 5, electron process count 10 → 18. High pane throughput plausibly raises the odds of loading a probe page, but nothing was being exhausted.

Driver-agnostic

RTX 5000 Ada is Ada Lovelace workstation silicon, distinct from the Quadro RTX 5000 (Turing) reported earlier despite the name. More usefully, my driver is 573.42 from 2025-06 — roughly a year older than the 32.0.15.9595 / 32.0.16.1074 / 32.0.15.9186 builds others tested. Same crash, same exit code. Also: zero TDR / nvlddmkm / dxgkrnl / display-reset events in the Windows System log anywhere near the crash.

---

Bug 2 — 25 Repair attempts over 55 hours, all failed; only uninstall + reinstall worked

This is where I can add the most. Full Microsoft-Windows-AppXDeploymentServer/Operational forensics for the outage window (2026-07-27 22:00 → 2026-07-30 09:00): 843 Claude-related events, spread 293 / 121 / 120 / 309 across the four days — the OS never stopped churning.

Package state, captured mid-outage (Get-AppxPackage *Claude* -AllUsers, 2026-07-30 06:19):

Name              : Claude
Version           : 1.24012.9.0
PackageFullName   : Claude_1.24012.9.0_x64__pzs8sxrjxfjjc
InstallLocation   : C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc
Status            : Modified, NeedsRemediation
PackageUserInformation : {S-1-5-...-500 [Administrator]: Installed}

25 separate RegisterByPackageFullName operations with RepairAppRegistrationOption (mix of OS-automatic remediation on failed activation and my own Settings → Apps → Claude → Repair clicks), none of which restored the app:

07-27  23:01:12  23:01:18  23:06:41  23:06:53  23:08:20  23:16:44
       23:17:56  23:24:55  23:25:28  23:33:26  23:38:39
07-28  07:54:40  07:54:47  07:55:15  18:57:32
07-29  00:11:49  00:19:09  00:27:29  00:28:14
07-30  05:23:03  06:15:19  06:15:32  06:19:21  06:20:24  06:20:25

What finally worked — and note how it was reached. The Get-AppxPackage output above is timestamped 06:19; seeing Status: Modified, NeedsRemediation in black and white is what made it obvious that no amount of Repair was going to help. The next two deployment operations in the log are 2 minutes later:

07-30 06:21:32  Id=603  op=Remove                      <- full uninstall
07-30 06:34:08  Id=603  op=StageUserData + register    <- fresh install

So the entire 55-hour outage was gated on running one diagnostic command that nothing in the product or the OS ever suggests.

Microsoft-Windows-AppXDeployment/Operational confirms: 07-30 06:34:08 Id=327 — packages to install: Claude_1.24012.9.0_x64__pzs8sxrjxfjjc; packages to remove: NULL. First successful renderer log line after that: 07-30 07:01:28. So the renderer log shows a clean 2.5-day hole:

2026-07-27 23:01:09 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost
2026-07-30 07:01:28 [error] Setting the document's base URI to 'https://claude.ai/' violates ...

Net user-visible outage: 2026-07-27 23:01 → 2026-07-30 06:34, ~55 hours.

The leftover-process lock, timestamped

The OP flagged that cowork-svc.exe survives the crash and blocks repair. My log dates that precisely — Windows fired automatic repair 3 seconds after the "instant death" and was refused because the app was still running:

07-27 23:01:12  Id=638  Package not updated because affected apps are still running.
                        Running apps: {Claude_pzs8sxrjxfjjc!Claude}
07-27 23:01:12  Id=419  0x80073D02: cannot install because the following apps must be closed:
                        Claude_1.24012.9.0_x64__pzs8sxrjxfjjc
07-27 23:01:12  Id=401/404  Register from AppxManifest.xml failed, 0x80073D02
07-27 23:01:18  (identical, retry) 0x80073D02

Then at 23:06:42 a later attempt did tear the service down — TerminateSingleService succeeded (CoworkVMService) — confirming the packaged service was the thing holding the lock. Error histogram for the whole window: 0x80073D02 ×6, 0x80073CFA ×1 (the latter during the 07-30 reinstall).

One honest difference from the OP's report: I see no "Trying to repair ACLs for C:\Program Files\WindowsApps\Claude_…" loop in my logs — zero ACL events. So that particular spin may be Win11-specific or environment-specific.

The user-experience point, from someone who lived it

To be precise about that 55 hours: it is wall-clock from the log, not 55 hours of active troubleshooting — I was away from the machine for much of it. But that is rather the point. I'm not a Windows deployment expert, and there was nothing to act on: no Event 1000/1001, no error dialog, no diagnosable message. The app simply does nothing when launched, and the Repair button — which I clicked repeatedly — silently changes nothing. Antivirus quarantine was my first hypothesis, since this machine runs two Chinese AV products, so some of that time went into whitelisting directories that turned out to be irrelevant.

The single biggest thing that slowed me down was fear of data loss. The only remedy that works is uninstalling the app, and I had no idea whether that would take my local Claude Code session history with it. So before touching anything I spent most of my hands-on time backing up local data, specifically to preserve those conversations. Only once I was satisfied the backup was complete did I proceed — and I got to the uninstall/reinstall answer by working through it step by step with claude.ai in the browser, which is obviously not available to someone whose only entry point was the desktop app.

Three concrete asks:

1. On failed activation, surface something. Even a one-line "the app didn't shut down cleanly — a reinstall may be required", or just "run Get-AppxPackage *Claude* | fl Name,Status and check for Modified, NeedsRemediation", would have collapsed this into 15 minutes. Repair should also stop presenting itself as a fix for this state when it demonstrably is not one.
2. Say explicitly whether uninstalling preserves local session history, in that message or in the docs. Right now the only working remedy looks, to a user, like it might destroy their work. That hesitation is a bigger cost than the reinstall itself.
3. Fix the shutdown path so the packaged service dies with the app. The 0x80073D02 above shows the OS trying to self-heal 3 seconds in and being blocked by the app's own leftover process. If cowork-svc.exe went down with the crash, automatic remediation might well have succeeded on the first try.

---

Summary of what this adds

1. 4th GPU family (RTX 5000 Ada) on the oldest driver tested so far (573.42, 2025-06) — same crash.
2. 128 GB machine with 114 GB free at the crash instant — memory pressure ruled out with a wide margin.
3. Two more bot-detection vendors on the trigger list: Akamai Bot Manager (walmart.com/akam/…) and AWS WAF.
4. Agent-driven pane at high throughput (116 open_site records / 20 min) — relevant to the unattended-workflow angle.
5. Bug 2 quantified: 843 deployment events, 25 failed Repair operations across 55 hours, resolved only by uninstall + reinstall — independent confirmation of @SaLoGeF's Win10 finding, with the event-log timeline to back it.
6. The leftover-cowork-svc.exe lock captured 3 seconds after the crash as 0x80073D02 / "affected apps are still running".
7. A UX cost that may not be obvious from the other reports: the only working remedy (uninstall) is one users are afraid to perform, because nothing tells them whether local Claude Code session history survives it.

Happy to provide full log excerpts or Crashpad IDs if useful.

Same crash on 1.24012.9 — plus new evidence: the post-crash Repair schedules a forced app shutdown hours later

Environment

• Claude desktop (MSIX): 1.24012.9.0 (Claude_1.24012.9.0_x64__pzs8sxrjxfjjc)
• Windows 11 Home 25H2, build 10.0.26200, x64
• CPU: Intel Core Ultra 7 265 · RAM: 32 GB
• Graphics: Intel(R) Graphics (driver 32.0.101.8132) plus an Insignia USB3.0-to-dual-HDMI adapter (DisplayLink-class, driver 1.9.2501.1223) — noting this because USB display adapters are a well-known trigger for Chromium GPU-process instability, which may be a factor in who hits this bug

Bug 1 reproduced — GPU crash 4 seconds after the in-app Browser preview tab opened

From %APPDATA%\Claude\logs\main1.log (last lines of the session — the app died instantly, nothing logged after):

2026-07-30 15:25:34 [info] [PreviewContext] Opened preview user tab { serverId: 'preview-local_...', tabId: 'tab-2', openTabs: 3 }
2026-07-30 15:25:38 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

101457950 decimal == 0x060C201E — same code as the OP. Also matches #81159. No WER report and no crash dump is written (%APPDATA%\Claude\Crashpad\reports stays empty), so from Windows' point of view the app simply vanishes — nothing in Event Viewer's Application log at all. An earlier shutdown the same day (~13:55) left Sentry error data but no log tail, consistent with the same failure.

Bug 2 reproduced — plus a follow-on repair loop worth documenting

After the crash the package was unlaunchable until Settings → Apps → Claude → Advanced options → Repair. But Microsoft-Windows-AppXDeploymentServer/Operational shows the repair never fully completes while the app is running: the Add step succeeds, then the final re-register fails with 0x80073D02 ("Unable to install because the following apps need to be closed") because the app relaunches immediately after repair:

16:00:32  Id 603   RepairPackageOperation started (re-downloads 1.24012.9 .msix from downloads.claude.ai)
16:01:14  Id 400   Deployment Add operation finished successfully (~41 s)
16:01:14  Id 9641  0x80004004: Deployment aborts due to active service Claude_...!Claude
16:01:14  Id 638   Packages were not updated because affected apps are still running
16:01:14  Id 401/404/419  Register failed with 0x80073D02

Windows then completes the pending registration ~4 hours later using ForceTargetApplicationShutdownOption — killing the running app mid-use with no warning:

20:06:10  Id 603   RegisterByPackageFullName ... Options ForceTargetApplicationShutdownOption,RepairAppRegistrationOption
20:06:11  Id 400   Register finished successfully   <-- the running app was force-closed at this moment

So the user-visible pattern is: GPU crash → Repair → app works → second "random" shutdown hours later (actually Windows finishing the half-failed repair). Each Repair while the app is running re-arms this. The same 0x80073D02 failure repeated at 20:07 and 20:58 the same day.

Workaround that breaks the loop: fully quit Claude first (tray icon → Quit; verify no claude.exe / cowork-svc.exe in Task Manager), then run Repair — the register step completes immediately and no forced shutdown gets scheduled.

Happy to provide full main.log/main1.log and the complete AppX deployment event export on request.

Confirming this on Windows ARM64 — same exit code, same signature — plus two findings that may help narrow the fault.

Environment

• Claude Desktop 1.24012.9.0 (MSIX / Windows Store), Claude Code 2.1.219
• Windows 11 Home 26200 (ARM64), Surface Pro 11, Snapdragon X X1P64100
• GPU: Qualcomm Adreno X1-85, driver 31.0.137.0
• Electron 42.7.0 / Chrome 148.0.7778.280, 16 GB RAM

Reproduction (5/5 crashes today, all exitCode 101457950 / 0x060C201E)
Opening https://suno.com/create in the in-app Browser pane (preview_start) kills the GPU process 5–11 s after pane creation and takes the whole app down. Console signature identical to OP:
WebGL: INVALID_ENUM: getInternalformatParameter ×19 → requestAdapter powerPreference warning ×2 → GPU process gone: { reason: 'crashed', exitCode: 101457950 }.
Sessions that never open the Browser pane never crash; a different URL (gemini.google.com) in the same pane on an earlier day was fine.

Finding 1: "Disable Hardware Acceleration" does not prevent it
With isHardwareAccelerationDisabled: true confirmed loaded at startup, the crash reproduces identically. Inspecting the live GPU process afterwards: no software-rendering flags on its command line, and the Adreno user-mode driver DLLs are loaded — i.e. the toggle does not propagate to the GPU process (consistent with electron/electron#17180 / #51363). So this crash is not user-avoidable via that setting.

Finding 2: GPU-vendor-independent
OP reproduced on NVIDIA RTX 2080; this repro is on Qualcomm Adreno X1-85 (ARM64). Same exit code and signature on both — pointing at the Chromium/ANGLE/Dawn layer rather than a specific vendor driver.

No Crashpad minidumps are generated (Crashpad/reports stays empty), which makes further user-side diagnosis difficult.

Cross-ref: #81159 appears to be the same crash.

Confirming again — Windows 10 Pro 19045.6456, NVIDIA GeForce RTX 3090.

Same exit code (101457950 / 0x060C201E), same trigger (in-app Browser pane → external page → WebGL getInternalformatParameter probe burst → CONTEXT_LOST_WEBGL → GPU process gone), same second-timestamp instant death.

One data point I don't think is in the thread yet: I had TdrLevel=0 (TDR detection disabled) during my first two crashes, then explicitly set it to TdrLevel=3 (Windows default) to see if it would at least convert the crash into a recoverable TDR-timeout instead. It didn't — crashed again with the identical signature, and no Event ID 4101 fires in the System log either before or after the change. Consistent with the rest of this thread's finding that this is an outright process crash, not a driver hang — TDR settings aren't a relevant lever either way.

Also: crashed on driver 536.23 (R535) and 610.47 (R610 Studio, current as of writing) with the identical signature — another data point for "not driver-specific," now across three driver generations combined with everyone else's reports.

Didn't hit Bug 2 either time (app auto-relaunched cleanly, no Modified flag) — for what it's worth as a contrast to the Windows 10 reports above where Repair didn't resolve it.

Additional data point: same GPU crash (exitCode 101457950 / 0x060C201E) on 1.24012.9.0, triggered by a Cloudflare bot-detection probe in the in-app Browser

Same signature as #80444 and #81159, on a different GPU combination — adding data in case it helps narrow down the cause.

Environment

| | |
|---|---|
| App version | 1.24012.9 (Claude_1.24012.9.0_x64__pzs8sxrjxfjjc, MSIX / windowsStore) |
| CCD | 2.1.219, Node 24.18.0 |
| OS | Windows 11 Enterprise 10.0.26200, de-DE |
| GPU 0 | Intel Iris Xe Graphics — 32.0.101.7084 (2026-01-15) |
| GPU 1 | NVIDIA GeForce MX550 — 32.0.15.9608 (2026-03-31) |
| GPU 2 | MirrorOp Virtual Graphics Adaptor — 1.1.185.70 (2019-10-01) |
| Display | DELL P2722H, 1920x1080 @ 60 Hz, scaleFactor 1 |

Hybrid graphics, no per-app GPU preference set. Note the third adapter: a virtual display adapter (MirrorOp / wePresent presentation software) is present alongside the hybrid pair. Might be relevant — the reports so far have single-vendor or hybrid setups; this one has a stale virtual adapter in the enumeration list.

Trigger

Agent-driven research in the in-app Browser pane on a German retail site (mindfactory.de) that is behind Cloudflare bot detection. The crash happens while the page runs its WebGL/WebGPU capability-probe burst — i.e. the fingerprinting stage of the challenge, not any interaction with the challenge widget itself.

Reproduced 3× in one day: 11:25:09, 13:44:51, 13:47:13 (local time, 2026-07-31).

Log evidence

%APPDATA%\Claude\logs\unknown-window.log — 1–2 s before every crash, a burst of ~20 identical probe lines plus a WebGPU adapter request:

2026-07-31 13:47:12 [warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat
   (x12 identical)
2026-07-31 13:47:12 [warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat when EXT_color_buffer_[half_]float is not enabled
2026-07-31 13:47:12 [warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat when EXT_color_buffer_float is not enabled
2026-07-31 13:47:12 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127
2026-07-31 13:47:12 [error] %c%d font-size:0;color:transparent NaN
2026-07-31 13:47:13 [warn] A valid external Instance reference no longer exists.

On the 13:44 occurrence the context loss is explicit:

2026-07-31 13:44:51 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost

%APPDATA%\Claude\logs\main.log — the GPU process dies with the exact same exit code every time, and this is the last line of the session; the main process goes down with it, no graceful shutdown, no further log output until the next manual launch:

2026-07-31 11:25:09 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
2026-07-31 13:44:51 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
2026-07-31 13:47:13 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

Restart timestamps from the same file confirm the app never recovered on its own:

2026-07-31 10:13:30 [info] Starting app
2026-07-31 11:37:47 [info] Starting app   <- 12 min after the 11:25:09 crash
2026-07-31 13:45:46 [info] Starting app   <- after the 13:44:51 crash
2026-07-31 13:48:19 [info] Starting app   <- after the 13:47:13 crash

Secondary failure: Windows "Repair" cannot run after the crash

Same as reported in #80444/#81159, but here is the exact Windows-side reason. Immediately after the crash, Settings → Apps → Claude → Advanced options → Repair reports "Diese App konnte nicht repariert werden" / "This app could not be repaired". Event log Microsoft-Windows-AppXDeploymentServer/Operational:

13:48:14  Error 401  Register / volume C: for Claude_1.24012.9.0_x64__pzs8sxrjxfjjc failed with 0x80073D02
13:48:14  Error 404/419  0x80073D02: cannot install because the following apps need to be closed:
                          Claude_1.24012.9.0_x64__pzs8sxrjxfjjc
13:48:14  Error 8104  Failed to set the trust label for the package, flags 0x0. Error: 0x80070057
13:48:14  Error 8107  Invalid integrity check attempted for a non-AppStore/non-AppInstaller package
13:48:14  Info  613   Register: Failed to reach state ResolvedDeferredRegistrations (953 ms)

0x80073D02 is ERROR_INSTALL_PACKAGE_IN_USE. Repair fails because child processes survive the crash and keep the package in use — in this case cowork-svc.exe (confirmed running with the app gone). Corroborating evidence from the next launch:

2026-07-31 11:37:48 [error] [Chrome Extension MCP] Failed to copy native host binary:
  Error: EBUSY: resource busy or locked, copyfile
  'C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\resources\chrome-native-host.exe'
  -> '...\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe'

Also: AppxManifest.xml in the install location has LastWriteTime = 2026-07-31 13:47:26 — 13 seconds after the crash, i.e. the crash path touches the package and Windows flags it as modified. Get-AppxPackage Claude still reports Status: Ok, so the "damaged" state is not visible via the normal status field.

No local crash dump is produced

• %APPDATA%\Claude\Crashpad\ contains only settings.dat — no minidump reports at all.
• No Application Error (Event ID 1000) and no WER report for Claude.exe in the Windows event log.

So on this machine the crash is invisible to both Crashpad and WER; the only local trace is the two log lines above. If you need a dump for this signature, the reporter path appears to be broken for GPU-process kills in the MSIX build.

Impact

Any agent-driven research task that touches a Cloudflare-protected site kills the whole app mid-run, loses the session, and leaves the MSIX package in a state where the documented recovery step (Repair) fails until leftover processes are killed manually. There is no user-accessible way to disable hardware acceleration in the app — %APPDATA%\Claude\config.json has no corresponding key, and MSIX gives no way to pass --disable-gpu from a normal shortcut.

Requests

1. Don't let a GPU-process crash take the main process down — fall back to SwiftShader / software compositing for the Browser pane, as already asked for in #80444.
2. Add a persisted "disable hardware acceleration" setting so there is a recovery path without PowerShell gymnastics.
3. Make sure all child processes (cowork-svc.exe in particular) are terminated on abnormal exit, so Windows Repair is not blocked by ERROR_INSTALL_PACKAGE_IN_USE.
4. Guard the WebGL/WebGPU capability-probe path — the crashing input is a read-only capability enumeration (getInternalformatParameter with unsupported enums + requestAdapter()), which should never be able to kill the GPU process.

claude-gpu-crash-evidence-logs.md

Confirming this on completely different hardware, plus three findings that narrow it down.

Same exit code, same log lines, same day-one-of-1.24012 onset — but on a single integrated Intel GPU, not a discrete NVIDIA card and not a hybrid-graphics laptop. That rules out both the vendor-driver and the Optimus adapter-negotiation theories floated in #80468.

Environment

| | |
|---|---|
| Claude Desktop | 1.24012.9 (MSIX / Store) |
| Claude Code (CCD) | 2.1.219 |
| OS | Windows 11 Pro 25H2, build 26200 |
| CPU / GPU | 13th Gen Core i7-1355U / Intel Iris Xe — the only display adapter present |
| RAM | 16 GB |

Three fatal crashes in 88 minutes (12:36:22, 12:49:02, 14:04:15 local), all
exitCode: 101457950, all with your exact renderer chain including OTS parsing error,
%c%d font-size:0;color:transparent NaN and CONTEXT_LOST_WEBGL. main.log stops
mid-stream each time; no WER entry, no minidump, empty Crashpad\reports.

MSIX corruption matches too — the app would not relaunch after the second crash and needed
reinstalling.

---

1. One crash had no browser action at all — and no new tab

This is the finding I think matters most, because it breaks the "page runs a WebGL probe"
framing.

The 12:36:22 crash happened in a preview pane that had been open and untouched for
13 minutes 24 seconds. The owning session issued no tool call in that window — its
previous output was at 12:35:10 and the next user input at 12:46:20. main.log contains
nothing between 12:35:12 and the crash except two cached-OAuth lookups. There is no
[Preview] Created line and no totalContexts change.

What did happen: 72 seconds earlier a ~3.1 kB block was appended to the transcript, forcing
a layout reflow of the surrounding UI. Our reading is that the pane was re-mounted as a
side effect, re-initialising its compositing surface.

So the trigger is not "a page executes fingerprinting code". It appears to be a webview
compositing surface being created or re-created, and a transcript-driven reflow is
sufficient. That also means an idle pane is not safe.

2. The failing WOFF2 comes from the app shell, not from page content

The page loaded in that pane was a locally served internal app on http://localhost:8001/.
That app is deliberately built with no bundler and no web fonts — grepping its entire
source tree for woff, @font-face, fonts.googleapis and fonts.gstatic returns
zero hits. It uses only -apple-system, "Segoe UI", system-ui, sans-serif.

The page therefore cannot be the origin of the malformed WOFF2. OTS parsing error fires
on a font belonging to the surrounding shell, re-parsed when the surface is rebuilt.

(For completeness: two of our three crashes were triggered by an external page behind a
Cloudflare "Just a moment" interstitial, which does run canvas/WebGL fingerprinting —
consistent with your repro. The third one above shows that page is not necessary.)

3. totalContexts separates the survivors from the fatalities

For the two crashes that did follow an explicit preview_start, the app logs the new
pane as the second live preview context:

14:04:10  [Preview] Created session preview context { previewId: 'preview-…', totalContexts: 2 }
14:04:10  [Preview] Created browser preview { serverId: 'browser-preview-…' }
14:04:14  OTS parsing error: Size of decompressed WOFF 2.0 is less than compressed size
14:04:15  WebGL: INVALID_ENUM: getInternalformatParameter …  ×19
14:04:15  The powerPreference option is currently ignored when calling requestAdapter() …
14:04:15  A valid external Instance reference no longer exists.
14:04:15  GPU process gone: { … exitCode: 101457950 … }

Every pane created at totalContexts=1 survived — including a deliberate 20-minute stress
run (16 page loads, ~20 screenshots, two colour themes, three window widths) that produced
the full WebGL warning burst without crashing. Both fatalities were at totalContexts=2.

The two paths also have different terminal lines, which may be useful when bisecting:

| Path | Terminal line |
|---|---|
| Second context created | A valid external Instance reference no longer exists. |
| Existing pane re-mounted | WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost |

---

A recoverable control case, in the same logs

Worth having as a negative control: at 13:27:38 the GPU process died with
exitCode: 34, no WebGL burst, and the app kept logging normally for the next three
minutes. That was Chromium doing the right thing during a display-driver swap.

So the defect isn't that the GPU process can die — it's that in the 101457950 case
recovery never happens and the whole tree goes with it. GPU process gone alone is not
the signature; exitCode 101457950 plus the log terminating in the same second is.

Ruled out here, each measured

• GPU driver — crash #3 occurred on Intel 32.0.101.7088 after #1–#2 on 7084;

identical exit code. Combined with your RTX 2080, that is two vendors and three drivers.

• Memory — peak Electron tree on the crash day was 4 380 MB, lower than 5 025 MB on a

crash-free day the previous week. At crash #3: 2 462 MB in use, 5 495 MB free of 16 057 MB.

• Driver hang / TDR — zero display-reset events in the Windows System log.
• Reinstall — restored the identical version and did not prevent crash #3.
• Claude in Chrome extension — zero extension or native-host activity within ±90 s of

all three; Chrome was not running at all during crash #3.

Blast radius

We run four concurrent Claude Code sessions in one desktop app. Each crash killed all
four, including three that had never opened a pane. One session's documentation lookup
cost three unrelated threads their in-flight context. That is what makes this expensive
rather than merely annoying.

Not yet tried

We have not applied the --disable-gpu workaround, because #76307 reports that flag being
auto-persisted after a GPU crash and leaving the app in a CPU busy-loop. If that risk is
understood or fixed, we would happily test it and report back.

Our current mitigation is simply to stop using the preview pane for anything external, and
fetch pages as text instead. Happy to run any instrumented build or capture additional logs
if that would help.

Adding a data point from another affected machine, including one workaround result that isn't in the thread yet.

Environment: Claude Desktop 1.24012.9 (MSIX, Claude_pzs8sxrjxfjjc), Windows 11 Home 26200, RTX 4090 (driver 32.0.15.9186 / Jan 2026), Alienware AW3423DWF (10-bit, P3). Same regression window as OP: browser previews on 1.22209.3 (2026-07-17 and 07-19) ran clean; every pane open since updating to 1.24012.x (2026-07-24) has killed the app.

Still reproduces on 1.24012.9 — three fatal crashes logged, all identical:

2026-07-30 12:05:17 [info] [Preview] Created browser preview { serverId: 'browser-preview-1785427517751-0' }
2026-07-30 12:05:20 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

Log ends there each time (no shutdown sequence); next line is Starting app after a Settings → Repair.

New datum: the in-app hardware-acceleration toggle does NOT prevent the crash. We set Help → Troubleshooting → "Disable Hardware Acceleration", confirmed "isHardwareAccelerationDisabled": true in claude_desktop_config.json, restarted (Starting app 12:03:27), then opened a browser preview at 12:04:20 on a trivial page (example.com). The pane created fine and served page text; the GPU process crashed with the same exitCode: 101457950 at 12:05:37, roughly when the pane was brought into view. So Electron's app.disableHardwareAcceleration() path is insufficient — consistent with the WebGL-probe theory, since WebGL still executes in the GPU process under software rendering. The --disable-gpu launch workaround from this thread is untested on our machine.

Repair behavior matches OP: app refuses to relaunch after the crash until Settings → Apps → Claude → Advanced options → Repair; the Repair reports failure but the app launches afterward.

Impact note: the in-app Browser pane is the primary verification loop for our dev workflow across several projects, so this is effectively a blocker on 1.24012.x rather than an inconvenience. Happy to provide full logs or run diagnostics on request.

Another confirmation (dedicated RTX 3060 Ti, Win11 26200) — crash reproduced ~2h AFTER a DDU clean driver downgrade, plus an unattended overnight crash during automated Browser-pane use

Environment: Claude Desktop 1.24012.9.0 (MSIX Claude_pzs8sxrjxfjjc), Claude Code 2.1.219, Node 24.18.0 · Windows 11 Pro 10.0.26200, VBS/HVCI enabled, 32 GB RAM · NVIDIA GeForce RTX 3060 Ti (dedicated GPU, no hybrid graphics/iGPU), driver 32.0.16.1062 (Studio, 2026-06-11) after a DDU clean reinstall on 2026-07-31; a newer driver installed earlier showed the same crashes.

Signature (6 crashes, 2026-07-27 → 07-31, accelerating; zero crashes in the 3 weeks of logs before):

• GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 } (0x060C201E), identical every time; whole app dies with no shutdown lines.
• CodeIntegrity/Operational at the exact crash second, every time: Event 3033 (...\app\claude.exe attempted to load ...\app\vk_swiftshader.dll — blocked) + Event 3010 ×3 (unable to load ...\AppxMetadata\CodeIntegrity.cat, Status 0xC000003A).
• Afterwards MSIX activation refused ("This app can't open") until Repair; Repair fails with 0x80073D02 while zombie package processes linger — but terminates them as a side effect, after which the app launches again.

Data points possibly new to this thread:

1. Crash reproduced ~2 hours after a DDU clean driver downgrade — further confirms driver-agnostic.
2. Unattended overnight crash (04:14) while an autonomous Claude Code session used hidden Browser-pane previews — capturePreviewScreenshot ... the Browser pane is not displayed warning bursts appear seconds before death in 5 of 6 crashes here.
3. Single dedicated GPU, no hybrid setup — additional counter-evidence to the Optimus/adapter-negotiation theory from #80468.
4. Negative findings: no nvlddmkm/TDR events, no WER Event 1000 for the app, Crashpad reports dir empty.

Current workaround here: avoid the in-app Browser pane entirely (verification via external Chrome / Playwright), plus a script that kills the full package process tree instead of the Settings-Repair round-trip.

On a machine with this exact crash (exit 101457950 / 0x060C201E, 5 occurrences across v1.20186.0 and v1.24012.9, including one reproduced on demand), every crash second correlates 5/5 with Microsoft-Windows-CodeIntegrity/Operational Event 3033: claude.exe blocked from loading the bundled app\vk_swiftshader.dll ("did not meet the Microsoft signing level requirements"), preceded by Event 3010 failing to load AppxMetadata\CodeIntegrity.cat (0xC000003A) — the sideloaded MSIX ships without that catalog, and AppX logs 8107 "Illegal non-AppStore or non-AppInstaller package integrity validation" + 8104 trust-label failure on every register. The DLL is Anthropic-signed but not Microsoft-signing-level, so in the packaged process the load is rejected; Dawn's Vulkan instance dies mid-init ("A valid external Instance reference no longer exists."), the GPU process exits 0x060C201E, and the main process exits with it. Disabling hardware acceleration makes it worse (SwiftShader becomes Dawn's only adapter). The common trigger is any WebGPU probe — ad-tech fingerprinting (navigator.gpu.requestAdapter()) in embedded web content reproduces it on demand within seconds.

Confirmed workaround (same machine): replacing the MSIX with the Win32/Squirrel build (winget install Anthropic.Claude — the exe channel at downloads.claude.ai/releases/win32/x64/…) removes the packaged-process signing enforcement entirely. After the swap, requestAdapter() returns the hardware adapter, the previously 100%-reproducible page no longer crashes, and zero CI 3033 events have fired since. Note there is currently no Microsoft Store listing for the official app, so a Store-signed package isn't an option for affected users.

Fix suggestions: ship a catalog-covered / Microsoft-signing-level SwiftShader ICD in the MSIX, stop probing the Vulkan software path in packaged processes, and degrade gracefully on GPU-child loss instead of exiting the main process.

<html><body>
<!--StartFragment--><html><head></head><body><p><strong>Still reproducible on 1.24012.9 — workaround test results</strong></p>
<p>Same GPU-process crash (exitCode 101457950 / 0x060C201E) when a web search opens the in-app browser, followed by the corrupted MSIX package requiring Repair. Confirming the bug was <strong>not</strong> fixed in 1.24012.9.</p>
<p>Tested launch flags via <code>Invoke-CommandInDesktopPackage</code> (note: relative <code>-Command 'app\Claude.exe'</code> failed with "not found" on my machine; the full path to <code>&lt;InstallLocation&gt;\app\claude.exe</code> worked):</p>

Flag | Result
-- | --
--disable-gpu | ❌ Still crashes. GPU process dies with 101457950, relaunch is blocked by the flag (GPU process launch failed: error_code=18 ×5), then FATAL: GPU process isn't usable. Goodbye.
--disable-3d-apis | ❌ Still crashes
--use-angle=swiftshader | ❌ App starts but window stays black, UI unusable
--use-angle=d3d9 | ✅ Works — web search runs without crashing

<p>So the crash appears to live in the D3D11 ANGLE backend; falling back to D3D9 avoids it. <code>--disable-gpu</code> is not a viable workaround since the browser preview apparently hard-requires a GPU process.</p>
<p>Log excerpt from the <code>--disable-gpu</code> attempt:</p>
<pre><code>[29204:0801/150209.507:ERROR:content\browser\gpu\gpu_process_host.cc:998] GPU process exited unexpectedly: exit_code=101457950
[29204:0801/150209.511:ERROR:content\browser\gpu\gpu_process_host.cc:992] GPU process launch failed: error_code=18
[29204:0801/150209.517:FATAL:content\browser\gpu\gpu_data_manager_impl_private.cc:418] GPU process isn't usable. Goodbye.
</code></pre>
<p>Environment: Windows 11 (latest build), MSIX install (<code>Claude_pzs8sxrjxfjjc</code>), app 1.24012.9.0. GPU: AMD Radeon RX 9070 XT (ASRock Taichi), latest Adrenalin driver.</p>
<p>Since the original report is on an NVIDIA RTX 2080 and this reproduces identically on AMD RDNA4, the crash is GPU-vendor-independent.</p></body></html><!--EndFragment-->
</body>
</html>

Confirming this on AMD integrated graphics — same exit code, same trigger, same build line. Between this report (NVIDIA RTX 2080), #81664 (Intel UHD) and #68049 (Qualcomm Adreno), that's four GPU vendors, which I think rules out anything driver-side.

Environment

| | |
|---|---|
| App | Claude Desktop 1.24012.9.0, x64 MSIX (Claude_pzs8sxrjxfjjc) |
| OS | Windows 11 Home 10.0.26200 |
| Machine | Dell Inspiron 5515, Ryzen 7 5700U, 16 GB RAM |
| GPU | AMD Radeon Vega (integrated), PCI\VEN_1002&DEV_164C |

Same signature

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

101457950 = 0x060C201E, byte-identical across all 5 crashes. As you describe, main.log stops mid-write — no beforeQuit/willQuit handlers fire, the whole app dies with the GPU process.

Driver-agnostic, tested across a ~2-year gap

You reproduced on two adjacent driver versions. I can extend that considerably — I hit this on a 2024-08-18 driver, updated to a 2026-05-19 driver (Adrenalin 26.5.2, 31.0.21921.1000 → 31.0.21925.1001, different INF package entirely), rebooted, and reproduced with the identical exit code 4 minutes later on 6 GB free RAM. Nothing about the graphics stack changed the outcome.

Also worth noting: no display-driver TDR/reset events appear in the Windows System log for any crash, and no Crashpad minidump is written — Crashpad\reports\ stays empty, only metadata and settings.dat. So there's no local native stack to hand over.

Trigger correlation

Every crash follows the in-app Browser preview being created. Grouping today's runs by how each ended:

| Run start | Browser preview created | Ended | Delta |
|---|---|---|---|
| 07:42:10 | 07:46:14 | 07:47:50 GPU crash | 96 s |
| 07:50:16 | 07:50:53, 08:05:50 | 08:11:38 GPU crash | 5m48s |
| 08:15:19 | 08:16:12 | 08:16:21 GPU crash | 9 s |
| 08:20:08 | none | 08:20:23 clean quit | — |
| 08:21:16 | 08:22:32 | 08:22:40 GPU crash | 8 s |
| 09:15:37 | 09:19:21 | 09:19:26 GPU crash | 5 s |

5 of 5 runs that created a browser preview died. The one run that never created one exited cleanly.

Possible extra signal: offscreen compositing

Supporting #81664's screenshot-path theory — one crash lands in the same second as a capture timeout, and the error text is specifically about the pane not compositing:

08:16:21 [warn] [Preview] capturePreviewScreenshot failed: {
  error: Error: Screenshot timed out after 5s: the Browser pane is not displayed,
         so the page is not compositing frames. Display the pane and retry.
08:16:21 [info] GPU process gone: { reason: 'crashed', exitCode: 101457950 }

There were 12 capturePreviewScreenshot failed warnings across the session, all while the pane was hidden. Whether the crash is the WebGL probe you identified or the offscreen capture path, both run against a preview surface that isn't visible.

(Unrelated to this bug, flagging so nobody chases it: I have one additional GPU process gone entry with exitCode: 34 at 09:05:10. That one is the live display-driver swap during my driver update — a graphics package was staged 36 seconds earlier. Different code, different cause.)

Full redacted log excerpts for all crashes attached. claude-gpu-crash-logs.txt

*Co-authored with Claude Code.

Same issue.

Environment:

• Claude Desktop version: 1.24012.9.0 (Windows Store/MSIX package)
• OS: Windows 11
• GPU: AMD Radeon RX 6600 (discrete)

What I've already tried (none resolved it):

• Windows Graphics settings → per-app GPU preference: Power Saving (no effect)
• Windows Graphics settings → per-app GPU preference: High Performance (no effect)

-"Optimisations for windowed games" toggled off (no effect)
-Full uninstall (Remove-AppxPackage) + clean reinstall via official Setup.exe
(confirmed still MSIX-packaged under the hood; crash persisted identically)
-Set ELECTRON_EXTRA_LAUNCH_ARGS=--disable-gpu-compositing (User env var) — no effect,
suspect MSIX packaging does not respect this variable

Same crash on Windows 10 Pro 22H2 (build 19045), Claude Desktop 1.25927.0.0 (MSIX Claude_pzs8sxrjxfjjc), NVIDIA RTX 2060 — so this persists well past 1.24012.x (also hit it on 1.24012.9.0). Five GPU-process deaths / four full package wedges between 2026-07-30 and 2026-08-05 (three deaths on 08-05 alone: 11:41, 12:07, 13:32). Some evidence that narrows the mechanism:

1. Reproduces under software rendering — not a GPU/driver issue. Launched the packaged app with --disable-gpu via IApplicationActivationManager (GPU child confirmed running d3d11-warp-webgl). It still died with the identical code after 67 min of normal use (hardware-mode instances died at 8 and 21 min the same day):

2026-08-05 13:32:05 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,   // 0x060C201E
  serviceName: 'GPU'
}

Consistent with the WebGL/browser-tab trigger here and in #81159, since WebGL still executes under WARP. Cowork-style preview sessions ([WarmLifecycle:preview]) were active at crash time.

2. Not third-party injection. Module enumeration of the live main + GPU processes: zero non-Microsoft, non-Claude DLLs loaded. NVIDIA in-game overlay disabled with no overlay processes running during the 08-05 crashes; also reproduced with the packaged Cowork service registry-disabled and provably never started (SCM event log). Parsec virtual display + IddSampleDriver installed but evidently irrelevant given the WARP repro — matches #68049 persisting across driver updates and clean reinstalls.

3. Zero crash artifacts. Identical exit code every time, nothing in %APPDATA%\Claude\Crashpad, no WER Event 1000 — looks like a deliberate/clean exit path rather than an unhandled fault, which also means this failure mode likely produces no server-side telemetry.

4. How the crash bricks the MSIX install (the "There is a problem with Claude" dead-end):

1. GPU process dies → app dies with it; headless zombie claude.exe package processes linger (observed alive 10+ hours later).
2. Next launch: Windows auto-remediation fails against the zombies — 0x80073D02 "the following apps need to be closed: Claude" — and the package wedges in Modified, NeedsRemediation.
3. The flag is a phantom: elevated mtime audit of the flagged package — 2,182 files, zero modified since install; manifest/blockmap/executables intact.
4. Every launch then shows the "reinstall the application" dialog, but the reinstall itself fails: 0x80073CFA (data-preserving removal rejected) → in-place AddPackage 0x80073CF9, plus 0x80070020 sharing violation on cowork-svc.exe whenever the packaged Cowork service is running (aggravator, not the corruptor). Windows 10 has no Reset-AppxPackage, so the only recovery is full Remove-AppxPackage + reinstall — a non-technical user is dead-ended.

Suggested fixes, impact order:

1. Fix or gracefully absorb the 0x060C201E GPU-process death (relaunch the GPU process as already happens for e.g. exit code 34) — note software rendering does not avoid it.
2. Reap child processes when the GPU process dies — the zombies are what block auto-remediation and wedge the package.
3. Self-heal NeedsRemediation when the blockmap verifies clean — the current dialog points at an installer that cannot recover this state.
4. Capture/upload GPU-child crash dumps — today this failure produces no artifacts at all.

Full installer log (ClaudeSetup.log), app main.log covering all five deaths, and the 07-30/31 deep-dive (reinstall failure chains, Cowork service ACL analysis) available on request.

Confirming this on a different machine — and with what looks like a deterministic trigger, which narrows down the "standard bot-detection/fingerprinting code" mentioned in the original report.

Environment

• Claude Desktop 1.25927.0 (MSIX Claude_pzs8sxrjxfjjc), Node 24.18.0, arch: x64
• Windows 11 Enterprise 26200, 64 GB RAM, de-DE locale
• GPU: NVIDIA GeForce RTX 2060 SUPER
• Reproduced on two further driver versions beyond the ones already listed here: 32.0.15.9649 (2026-05-05) and 32.0.16.1088 (2026-07-22). The driver was updated mid-session precisely to test this — 4 of the 6 crashes happened after the update, so this is not driver-specific.

Signature — identical to the report

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

Six crashes (UTC+2): 2026-08-04 19:33:12, 19:36:32, 2026-08-05 12:20:34, 12:40:44, 12:53:52, 13:34:04. Every one of them while the in-app Browser pane was in use; one came 5 seconds after [Preview] Created browser preview. Same aftermath each time: the whole app dies with the GPU process, then Windows reports the package as damaged until Repair.

Zero GPU-process crashes in the preceding four weeks of logs (main2.log–main4.log, 2026-07-11 to 08-02), during which the Browser pane was barely used.

The trigger appears to be Cloudflare Turnstile

In unknown-window.log the WebGL probe cascade carries the same timestamp, to the second, as the crash in main.log:

2026-08-05 12:20:34 [warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat
2026-08-05 12:20:34 [warn] WebGL: INVALID_ENUM: ... when EXT_color_buffer_[half_]float is not enabled
2026-08-05 12:20:34 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows
2026-08-05 12:20:34 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost

The last crash (13:34:04) occurred while navigating to the one page on that site that loads Cloudflare Turnstile — every other page on the same site was visited repeatedly without incident. Turnstile's challenge script is what emits those WebGL/WebGPU capability probes, which matches the "fingerprinting suite" description in the original report.

That should give a minimal repro: point the in-app Browser pane at any page carrying a Turnstile widget and let the agent perform an in-page action.

On the Repair step

Windows Settings reports "This app could not be repaired. Try again later" — but the app launches normally afterwards regardless. The error message is misleading; the repair evidently does take effect.

Workaround that holds

Driving the user's real Chrome through the browser extension instead of the in-app pane: same workload (navigation, DOM measurement, computed-style inspection), repeated over an hour, zero crashes. The in-app pane had been crashing several times within that same hour.

Related: #81159 reports the same exit code and the same MSIX corruption.

Confirming this on a much newer build, plus one data point that contradicts the suggested workaround.

Environment

• Claude desktop 1.25927.0 (MSIX Claude_pzs8sxrjxfjjc), Claude Code 2.1.221, Node 24.18.0
• Windows 11 Home 25H2, build 10.0.26200
• NVIDIA GeForce RTX 4080, driver 32.0.16.1088
• 32 GB RAM

Same signature

Six GPU-process deaths in a single day, all with the identical exit code:

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

101457950 = 0x060C201E, matching this issue exactly.

Timestamps: 10:04:04, 10:16:05, 13:50:50, 17:31:01, 18:05:32, 18:21:01 (all 2026-08-05).

Correlation with the Browser pane

Three of the six crashes land within seconds of the in-app browser pane spinning up its context:

| Crash | Preceding [Preview] Created session preview context |
|---|---|
| 10:04:04 | 6 s earlier |
| 18:05:32 | 4 s earlier |
| 18:21:01 | 2 s earlier |

The remaining three have no such line, but that entry only fires when a new pane context is created — navigating inside an already-open pane does not log it. Before the 17:31:01 crash the pane was demonstrably in use (page-load failures logged at 17:23–17:26).

Renderer log for the 18:21:01 crash, same second as the GPU death:

18:21:01 [warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat
18:21:01 [warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat when EXT_color_buffer_float is not enabled
18:21:01 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows
18:21:01 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost
18:21:01 [info] GPU process gone: { reason: 'crashed', exitCode: 101457950 }

The config-level hardware-acceleration toggle does NOT prevent this

This is the part I have not seen reported elsewhere. Setting

"isHardwareAccelerationDisabled": true

in %APPDATA%\Claude\config.json does not stop the crash:

• flag written and verified as true
• app restarted at 18:15:21 with the flag active (the app rewrote config.json itself at 18:12:33 and preserved the flag)
• GPU process crashed anyway at 18:21:01

app.disableHardwareAcceleration() maps to --disable-gpu-compositing, which turns off GPU compositing of the UI but leaves WebGL/WebGPU in page content routed through the GPU process — precisely the path that fails here. The --disable-gpu workaround via Invoke-CommandInDesktopPackage is a strictly stronger switch and is not equivalent. Worth correcting wherever the config toggle is suggested as a fix.

Ruled out on this machine

• Memory — peak of the whole Electron tree was ~3 GB of 32 GB, 14 GB free at crash time. Not OOM.
• GPU driver — reinstalled mid-day (13:11); crashes continued at 13:50 and 18:05/18:21. Consistent with this issue reproducing across driver versions.
• Third-party virtual display driver — an EaseUS VirtualMonitor Device (ROOT\DISPLAY\0000) was registered as a second video controller. Disabled it; the 18:21:01 crash happened with it confirmed inactive.
• App version as sole trigger — this machine ran 1.24012.1 from 22 Jul and 1.24012.11 on 04 Aug, opened the browser pane 11 times on 04 Aug alone, and saw zero GPU crashes. First crash was 05 Aug. Suggests the trigger depends on what the loaded page does (whether it runs the WebGL/WebGPU capability probe), not on elapsed time since the update.

Package state

No MSIX corruption here so far — Get-AppxPackage still reports Status: Ok after all six crashes. So the appxState=2 damage described above is not a guaranteed consequence of every crash.

No Crashpad minidumps were written locally (Crashpad\ contains only settings.dat), consistent with the GPU child dying rather than the main process faulting.

Adding a new hardware datapoint and a detailed trace for the exitCode 101457950 GPU-process crash. This reproduces the signature in this issue on AMD hardware, making it NVIDIA + Qualcomm + Intel + AMD, i.e. vendor-agnostic.

Environment

• Claude Desktop 1.25927.0.0 (MSIX, Claude_1.25927.0.0_x64__pzs8sxrjxfjjc), Windows 11 Home 10.0.28000
• GPU: AMD Radeon RX 5700 XT (Navi 10), Adrenalin 26.7.1 (INF 32.0.21045.1000, newest available for this card, installed 7 days before onset)
• 64 GB RAM (32 to 54 GB free at every crash; not memory pressure)
• Version history on this machine: 1.24012.9 (Jul 28) -> 1.24012.11 (Aug 3) -> 1.25927.0 (Aug 4)

Crashes

Three crashes on 2026-08-05 (local, US Pacific), identical signature:

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

| # | Time | Instance uptime at death | Preceded by |
|---|---|---|---|
| 1 | 21:33:47 | 27h 49m | [Preview] Created browser preview at 21:33:41 (6s before) |
| 2 | 21:50:49 | 5m 36s | same, 21:50:43 |
| 3 | 22:02:03 | 6m 11s | same, 22:01:58 |

Trigger correlation is 3 for 3: the log contains exactly three browser-preview creations (all for the same Claude Code session's Browser tab), each 5 to 6 seconds before a GPU crash. Session warm-ups ([WarmLifecycle:preview], 10+ occurrences) never crashed anything; only full preview webContents creation correlates. A fourth instance that never opened the Browser tab has run without incident since.

About 1 second before each death, an auxiliary claude.ai-origin window logs the same graphics-init sequence: a burst of ~19 WebGL: INVALID_ENUM: getInternalformatParameter capability-probe warnings, then The powerPreference option is currently ignored when calling requestAdapter() on Windows (crbug.com/369219127), then A valid external Instance reference no longer exists. (Dawn), then WebGL: CONTEXT_LOST_WEBGL (crashes 1 and 3; crash 2 died before flushing it).

Amplifiers that make this worse than a GPU blip

1. The whole app dies with the GPU child. After GPU process gone the main process logs nothing further, ever: no quit handler, no relaunch, no Chromium software-rendering fallback (zero SwiftShader/fallback lines; each session dies at its FIRST GPU loss, so the 3-strikes fallback never engages). An Electron app should survive a GPU-process death.
2. Zero crash telemetry captured. Crashpad directory is active (settings.dat rewritten each start) yet reports/ is empty after three crashes; local Sentry queue empty; no WER entry, no Application-log Event 1000, no minidump anywhere. From the OS's perspective nothing happened. The only evidence is main.log.
3. The crash pushes users toward data destruction. Post-crash, package Repair attempts fail 0x80073D02 (ERROR_PACKAGES_IN_USE) even when no app window exists (a straggler holds the package; #80444 identified cowork-svc.exe). On 2026-08-04 this machine's AppX log shows a 4-step ResetPackageOperation whose Remove step deleted the entire user-data tree (Cowork spaces, session registry) minutes before an app update installed. Whatever initiates that Reset flow, the combination of "crash flags package as damaged" plus "Repair fails while stragglers live" funnels users into Reset, which destroys all app data. This machine has lost its Cowork spaces four times in seven days to this class of churn.
4. exitCode 101457950 (0x060C201E) decodes to no public Chromium result code or sandbox termination code. If it is an internal code, documenting it would help.

Asks

• Make the app survive GPU-process death (relaunch the GPU process or fall back to software rendering) instead of dying silently.
• Ship a user-visible hardware-acceleration toggle (per #77857, --disable-gpu works but is not reachable normally under MSIX).
• Fix Crashpad so these crashes produce dumps, or document the deliberate termination.
• Kill stragglers (cowork-svc.exe) on app death so Repair does not fail and users are not funneled to Reset.

Full local evidence retained (deduplicated log extracts, AppX deployment exports, timeline): available on request.

Still present on 1.26832.0.0, and I have a deterministic one-line reproducer that does not depend on any site's fingerprinting script.

Environment

• Claude Desktop 1.26832.0.0 (MSIX Claude_pzs8sxrjxfjjc), Claude Code 2.1.222
• Windows 11 Pro, build 10.0.26200
• NVIDIA GeForce RTX 5090, driver 32.0.16.1062 (2026-06-11), plus an AMD Radeon iGPU present
• Previous builds on this machine: 1.24012.0.0, 1.25927.0.0. Same failure on all three.

Reproducer

In the in-app Browser pane, on any real, loaded https page (I used developer.mozilla.org):

navigator.gpu.requestAdapter({ forceFallbackAdapter: true })

The promise resolves null, and the app dies in the same second. No bot-gate, no ad script, no waiting for a fingerprinter to decide to probe.

The narrowing: it is the fallback adapter, not WebGPU

Both calls were made in the same session, same page, minutes apart, with no launch flags:

| Call | Result |
|---|---|
| navigator.gpu.requestAdapter() | returns a hardware adapter (vendor: nvidia, architecture: blackwell). No crash. |
| navigator.gpu.requestAdapter({forceFallbackAdapter: true}) | resolves null, app dies |

So the lethal path is specifically the software/fallback adapter, where Dawn enumerates the software Vulkan adapter and loads app\vk_swiftshader.dll. That may explain why the crash looks random to users: it needs a page that reaches the fallback, not merely a page that touches WebGPU.

Evidence at the moment of death

Microsoft-Windows-CodeIntegrity/Operational, all four events at the same second (13:02:34):

3033  Code Integrity determined that a process (...\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\claude.exe)
      attempted to load ...\app\vk_swiftshader.dll  [blocked]
3010  Code Integrity was unable to load the
      ...\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat catalog. Status 0xC000003A.  (x3)

AppxMetadata\CodeIntegrity.cat is still absent from the package on this build, and app\vk_swiftshader.dll is still signed CN="Anthropic..." rather than at Microsoft signing level. Both of the conditions in the original report are unchanged after two version bumps.

--use-angle=d3d9 still works, and here is why

Launching via Invoke-CommandInDesktopPackage with --use-angle=d3d9 (verify the flag reaches the --type=gpu-process child, not just the parent) prevents it. Under D3D9, ANGLE exposes no adapter for Dawn to enumerate, so vk_swiftshader.dll is never loaded and Code Integrity has nothing to refuse. On an earlier build with this flag active, the fingerprinting code demonstrably ran and requestAdapter() returned No available adapters. instead of enumerating the software adapter.

Two notes for anyone relying on that workaround:

1. An app self-update can silently drop it. After updating to 1.26832.0.0 the app relaunched itself and came back with no flags at all, while the shortcut and launcher script were still in place and untouched. I only noticed by comparing the full command lines of the running processes. Re-check after every update.
2. The workaround hides the recovery path. Once the package is flagged Modified, launching through the flagged launcher produces no repair prompt at all, just silence. Launching the normal shortcut surfaces the repair prompt. Order that works: normal icon, repair, then relaunch with the flag.

Adding independent confirmation from a different Windows 11 Pro machine, same exact build (1.26832.0.0), plus two data points not yet documented in this thread:

Environment: Windows 11 Pro (build 10.0.26200), NVIDIA RTX 5090 + AMD Radeon iGPU + USB virtual display, remote/hosted workstation accessed via Tailscale SSH (not RDP at crash time).

1) Smart App Control confirmed OFF, block persists identically

HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy\VerifiedAndReputablePolicyState = 0

Despite SAC being fully off (registry-confirmed both before and after each crash), the exact same event pair recurred 4 times in one day:

3033  Code Integrity determined that a process (...\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\claude.exe)
      attempted to load ...\app\vk_swiftshader.dll that did not meet the Microsoft signing level requirements.
3010  Code Integrity was unable to load the ...\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat
      catalog. Status 0xC000003A.   (x3 each time)

This is consistent with the Code Integrity Guard (CIG) explanation already discussed here — per Microsoft's own "App Control for Business — Event ID explanations" doc, Event 3033 "may occur with or without an App Control policy present... if code compiled with Code Integrity Guard (CIG) tries to load other code that doesn't meet the CIG requirements." That matches a per-process MicrosoftSignedOnly GPU-child mitigation, not a system-wide SAC/WDAC policy — which is why disabling SAC doesn't help.

2) Crash timestamps and a likely trigger correlation

Crashes today: 02:00:23, 09:39:31, 11:38:45, 17:53:58 — all GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 } (= 0x060C201E hex).

For the 17:53:58 crash, main.log shows an in-app Browser Preview session being created 6 seconds prior:

17:53:52 [info] [Preview] Created session preview context {...}
17:53:52 [info] [Preview] Created browser preview { serverId: 'browser-preview-...' }
...
17:53:58 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

This lines up with what's reported elsewhere in this thread and in openai/codex#34133 — the in-app Browser/screenshot (WebGL/Viz) path as the trigger. The other 3 crashes today had no such correlation nearby in the log (no Browser Preview activity), so a purely user-action-triggered explanation doesn't fully cover the periodicity — still an open question for us too.

3) Confirmed workaround that fully resolved it (so far) on our machine

Native Repair/Reset both failed for us too (same "we couldn't repair/reset this app" as reported above). What worked:

Remove-AppxPackage -Package Claude_1.26832.0.0_x64__pzs8sxrjxfjjc
winget install --id Anthropic.Claude --accept-package-agreements --accept-source-agreements -e

This installs the Win32/Squirrel build (%LOCALAPPDATA%\AnthropicClaude\claude.exe, Squirrel.Windows layout) instead of the MSIX. Post-switch: no Get-AppxPackage registration at all (as expected), app launched and ran stable with zero new CodeIntegrity 3033/3010 events. Confirms the earlier comment in this thread that switching away from MSIX "removes the packaged-process signing enforcement entirely."

Happy to share full main.log excerpts / Get-WinEvent dumps if useful for triage.

Follow-up datapoints (same machine as my Aug 5 comment; Windows 10 19045):

--disable-webgl extends time-to-crash ~100x, but the death path persists. Running with --disable-gpu --disable-webgl --disable-webgl2 (GPU child confirmed in d3d11-warp-webgl), the app went crash-free for ~4 days (2026-08-05 15:35 → 2026-08-09 15:57 local) and then died with the identical exitCode: 101457950 on 1.25927.0.0, corrupting the MSIX package again (Modified, NeedsRemediation). Time-to-fatal-GPU-death by configuration on this box:

| config | time to fatal GPU death |
| --- | --- |
| stock (hardware accel) | 8–21 min |
| --disable-gpu (WARP software rendering) | 9–67 min |
| + --disable-webgl --disable-webgl2 | ~4 days |

So the WebGL path dominates the crash rate, but something else in the GPU process still reaches the same fatal exit even with WebGL entirely unavailable.

Nothing notable in main.log before the final death — routine oauth token-refresh lines a few seconds prior (they also preceded one earlier death, but they log frequently enough that this is likely coincidence). Still zero crash artifacts across all six deaths on this machine (nothing in %APPDATA%\Claude\Crashpad, no WER Event 1000) — this failure mode appears to be invisible to telemetry.

Now running 1.26832.0.0 with --disable-gpu --disable-webgl --disable-webgl2 --disable-accelerated-2d-canvas --disable-features=WebGPU; will report back either way.

Still present in 1.26832.0.0 (three builds after the reports above), with a 5/5 same-second correlation to the WebGL probe burst

Adding a data point aimed at the two things I could not find already in this thread: whether the regression survives past 1.24012.x, and whether a per-app GPU preference pin avoids it. Both answers are no.

Environment

• Claude Desktop 1.26832.0.0 (MSIX Claude_pzs8sxrjxfjjc, windows-store), CCD 2.1.222, Node 24.18.0
• Windows 11 Home build 26200
• Hybrid + DisplayLink: NVIDIA GeForce RTX 5060 Laptop (32.0.15.9215) + Intel UHD Graphics (32.0.101.7076) + 2x DisplayLink USB Device (12.2.2204.0), three monitors

Five fatal crashes in one day, all identical

exitCode: 101457950 (0x060C201E), whole app dies, no GPU-process relaunch. In every case the getInternalformatParameter probe burst lands in unknown-window.log in the same second or one second before the kill in main.log:

| WebGL probe burst | GPU process gone | Browser preview created |
|---|---|---|
| 12:07:14 | 12:07:15 | (earlier in session) |
| 16:04:14 | 16:04:14 | 16:04:08 |
| 18:49:23 | 18:49:23 | 18:49:18 |
| 19:00:25 | 19:00:25 | 19:00:19 |
| 19:10:12 | 19:10:13 | 19:10:07 |

Two correlations worth separating:

• The burst is 5/5 fatal. Every getInternalformatParameter burst logged on this machine today killed the GPU process. There were zero survivals.
• [Preview] Created browser preview → dead app in 5-6 seconds, 4/4 where a preview open preceded it. One earlier preview (08:55:59) did not crash, so opening the pane is not sufficient on its own — the page has to run the probe.
• A lone requestAdapter/powerPreference warning at 10:45:42 with no getInternalformatParameter burst did not crash. That may help narrow which call in the probe sequence is the fatal one.

Negative result: per-app GPU preference pinning does not help

I pinned the app to the discrete GPU before three of these crashes:

HKCU\Software\Microsoft\DirectX\UserGpuPreferences
  Claude_pzs8sxrjxfjjc!Claude = GpuPreference=2;   (High performance / RTX 5060)

Verified still set at the time of each crash. The 18:49, 19:00 and 19:10 crashes all happened after the pin was applied, with the identical signature. Consistent with this thread's cross-vendor findings, but it rules out one more workaround people are likely to try.

Also ruled out on this machine

• Not memory. [process-memory] one second before the 19:00 crash: tree_rss_sum=2258MB electron(11), sys_free=16384MB/32492MB.
• Not a TDR / driver reset. Zero dxgkrnl / nvlddmkm events and zero Event ID 4101 in the System log for the whole day, matching the TdrLevel finding above.
• No crash dump is produced. The Crashpad reports directory is empty after all five crashes, so there is no minidump to attach — the GPU process goes down without the handler capturing anything.
• Unlike some reports here, no AppHang (Event 1002) or AppCrash (1000) is logged in the Application log for any of the five.

Bug 2 confirmed as well

Immediately after these crashes:

Get-AppxPackage -Name "*Claude*" | Select Version,Status
Version : 1.26832.0.0
Status  : Modified, NeedsRemediation

So the package is left needing Repair on the current build too, same as reported for 1.24012.x.

Net effect: on the latest build the in-app Browser/Preview pane is still unusable for any page that fingerprints WebGL, and there is no client-side setting that avoids it — hardware acceleration off, TdrLevel default, and GPU-preference pinning have now all been tested and all fail. The only workaround left is not opening the pane at all, which for agent-driven browser verification means dropping to an external driver instead.

Same crash here on 1.26832.0, four times in two days, all exit code 101457950 (0x060C201E). Adding what I dug out of the logs since a few of these details don't seem to be in the thread yet.

Setup: Dell Vostro 5410, Win 11 Pro 26200, Claude 1.26832.0 (MSIX). NVIDIA MX450 32.0.15.8195 + Intel Iris Xe 32.0.101.7077, both driving a display.

The only constant across all four crashes is requestAdapter()

I assumed at first it was the WebGL probe burst mentioned above. It isn't, that's incidental. What actually preceded each crash:

| crash | storage-access denial | WOFF2 OTS error | WebGL probe burst | requestAdapter() x2 |
|---|---|---|---|---|
| 08-10 09:05:23 | yes | yes | yes | yes |
| 08-10 10:37:12 | yes | yes | yes | yes |
| 08-10 11:18:42 | yes | no | yes | yes |
| 08-12 08:33:10 | no | yes | no | yes |

Everything varies except the WebGPU adapter request. It's always doubled and always lands in the same second as the exit:

2026-08-12 08:33:05 [info] [Preview] Created browser preview { serverId: 'browser-preview-1786516385062-4' }
2026-08-12 08:33:09 [warn] OTS parsing error: Size of decompressed WOFF 2.0 is less than compressed size
2026-08-12 08:33:10 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127
2026-08-12 08:33:10 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127
2026-08-12 08:33:10 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
2026-08-12 08:33:10 [warn] A valid external Instance reference no longer exists.
2026-08-12 08:33:10 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost

Five seconds from opening the pane to a dead app. The site doesn't matter. Three of mine were on one page, the fourth was a different project, different session, different site entirely.

Worth noting the pane can stay open a long time without dying as long as it's hidden. I have 44 of these in one stretch:

[Preview] capturePreviewScreenshot failed: Screenshot timed out after 5s: the Browser pane is not displayed, so the page is not compositing frames. Display the pane and retry.

33 minutes, no crash. It only goes down once the pane is actually shown and starts compositing.

The GPU process isn't faulting, it's exiting

This one surprised me. There is no crash dump anywhere:

• %APPDATA%\Claude\Crashpad\ has only settings.dat, no .dmp
• No Application Error (event 1000) for claude.exe in 30 days of Event Log. Not one.
• I set WER LocalDumps for claude.exe (DumpType 2) and then reproduced. The dump folder was never even created.

LocalDumps only fires on unhandled exceptions, so that last one is a result rather than a misconfiguration. Put together with 0x060C201E not being a valid NTSTATUS, this looks like the GPU process being terminated deliberately with a chosen exit code, not crashing on a fault. Electron logging reason: 'crashed' just means it exited non-zero.

So if anyone wants a dump out of this, LocalDumps won't get you one. It needs SilentProcessExit monitoring instead (IFEO GlobalFlag 0x200 plus SilentProcessExit\claude.exe with ReportingMode 2). I haven't caught one yet.

The built-in gpu-recovery can't fire at this crash rate

From app.asar:

if (n - In > 3e5 && (Fn = 0), In = n, Fn += 1, ...)
if (!(Fn < 3)) { ... `[gpu-recovery] %d GPU process deaths this session — disabling hardware acceleration` }

It auto-disables hardware acceleration after 3 GPU deaths, but the counter resets after 5 minutes of quiet. My gaps were 92 minutes, 41 minutes, then about 45 hours. [gpu-recovery] appears nowhere in my logs and it has never once kicked in. That safety net only catches a fast crash loop, which isn't how this bug presents. Widening the window, or persisting the count across sessions, would make it actually catch this.

Ruled out on my machine

• Display driver reset: zero event ID 4101 in 30 days.
• Sleep/lock/monitor change: no Kernel-Power or Winlogon events near any crash. For the 08-12 one there were 4 System events total in the surrounding 15 minutes, none display related.
• Memory: crashed at 530MB total tree RSS with 3.4GB free, GPU process at 76MB. An earlier one was 2650MB with 1.7GB free. No correlation either way.

CoworkVMService lock

Confirming what's already in this issue. The service outlives the app and sits on the package:

2026/08/10 09:05:24.279989 [Server] Persistent RPC: connection ended: failed to read length: EOF
2026/08/10 09:05:24.295676 [Server] Session ...: has no active connections, idle timeout starts

It saw the app die and started an idle timer instead of releasing. Held the package for 28 minutes until I stopped it by hand, and every repair attempt in that window failed:

10/08/2026 10:21:57  9641  0x80004004: Deployment aborts due to active service Claude_pzs8sxrjxfjjc!Claude.
10/08/2026 10:21:57   419  error 0x80073D02: Unable to install because the following apps need to be closed

Order that works: close the app, Stop-Service CoworkVMService -Force, then re-register. Re-registering while the service is still up just reproduces the 0x80073D02.

For others in the thread

There is already a hardware acceleration toggle, it's just not obvious. Menu item "Disable Hardware Acceleration", writes isHardwareAccelerationDisabled into %APPDATA%\Claude\config.json. I saw a request for this above.

Two dead ends, based on what's reported in here and in #82967 / #68049: forcing a single GPU via UserGpuPreferences (this reproduces on single-GPU desktops and on ARM64, so adapter selection isn't the cause), and driver updates (this issue already covers two driver versions).

Follow-up to my comment above. I think I've found why there's never a crash dump, and it isn't machine specific, which would explain why this reproduces identically on such different hardware in this thread.

Chromium's gpu_driver_bug_list.json has six entries carrying exit_on_context_lost. Five are narrow (Mali-400, PowerVR Rogue, Adreno, ChromeOS). The sixth, entry 17, is not:

"Some drivers are unable to reset the D3D device in the GPU process sandbox" os: win — no vendor_id, device_id, driver_version or gl_renderer conditions

No hardware conditions at all, so it applies to every Windows Chromium build. That covers every machine in this thread: the RTX 2080 in the OP, the 4070 Ti in #82967, the ARM64 box in #68049, and my hybrid laptop. Confirmed present on mine via chrome://gpu, which lists it under Problems Detected with that exact description.

exit_on_context_lost does what it sounds like. On GPU context loss the GPU process exits rather than attempting recovery. That accounts for the entire signature people have been reporting:

• exit code 101457950 (0x060C201E) isn't a valid NTSTATUS because it's a chosen exit code, not an exception code
• nothing in Crashpad
• nothing from WER LocalDumps even with DumpType 2, because LocalDumps only fires on unhandled exceptions
• no Application Error 1000 in the event log
• Electron's reason: 'crashed' is just its label for a non-zero exit

The GPU process isn't crashing. It's exiting deliberately, as designed.

That also reverses how I'd been reading the CONTEXT_LOST_WEBGL line that shows up in these logs. I assumed it was collateral after the GPU process died. More likely it's upstream of it:

WebGPU requestAdapter() -> GPU context lost -> exit_on_context_lost fires -> GPU process exits -> app dies

Those all land in the same logged second so I can't order them on timestamps alone, but that chain is coherent and nothing else I've looked at is.

Scope, to be clear: this explains the severity, not the trigger. What causes the context loss during requestAdapter() is still open. But it does mean the jump from "context lost" to "entire app and every running session gone" happens because a normally recoverable event is being converted into a process exit, and then nothing respawns the GPU process. Which is the ask already in #82967 — make a GPU process crash recoverable instead of fatal. That part looks fixable on the Electron host side without needing to solve whatever triggers the context loss first.

Still reproduces on 1.28929.0.0 — and with a deterministic trigger, not ambient

Adding three things I couldn't find already in this thread: a build newer than any reported so far, a reliable trigger, and a non-hybrid single-GPU data point that bears on the exit_on_context_lost lead above.

Environment

• Claude Desktop 1.28929.0.0 (MSIX, sideloaded, SignatureKind: Developer)
• Windows 11 Pro build 26200
• Single discrete NVIDIA RTX 5070 desktop GPU. No hybrid graphics, no integrated GPU in use, no DisplayLink, one monitor.

Still present two builds past the latest reports here

The most recent reports above are on 1.26832.0. This machine ran 1.26832.0 until 04:31 local, updated to 1.28929.0, and then crashed twice on the new build. Updating did not help.

Deterministic trigger: opening the in-app Browser pane

Unlike the ambient 8–21 minute crashes reported above, both crashes here fired within seconds of an explicit Browser-pane open — 2 for 2. From main.log:

04:56:52 [info] [Preview] Created browser preview { serverId: '...' }
04:56:57 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }

05:27:29 [info] [Preview] Created browser preview { serverId: '...' }
05:27:31 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }

Two browser-preview events in the log that day, two GPU crashes, 5 s and 2 s apart respectively. No other preview events and no other GPU crashes.

No ambient crashes on this hardware

The app has since run ~3 hours of continuous heavy use with no Browser-pane call and zero GPU crashes. On this box the pane appears to be the trigger rather than one contributor among several — which may also explain why time-to-crash varies so widely between reporters here: it could be tracking how often each workload happens to hit the pane or an equivalent path, rather than a timer.

Why this may matter for the exit_on_context_lost lead

The gpu_driver_bug_list.json entry-17 finding posted above predicts hardware independence. This machine is a useful negative control against the hybrid-graphics and DisplayLink correlations in earlier comments: single discrete GPU, single display, no DisplayLink, no integrated GPU in play — and it reproduces identically, same exit code. That is consistent with entry 17 applying with no hardware conditions, and inconsistent with a hybrid-graphics-specific cause.

Mitigation in use here

Rather than --disable-webgl (measured above to delay rather than prevent the fatal exit, at a cost to rendering quality), we block the Browser-pane tool at the agent layer outright, which removes our trigger. That obviously removes the feature too, which is why a real fix matters to us — we would like to use it again.

Confirming this bug is still present in 1.28929.0.0 (MSIX, installed 2026-08-12) — Windows 11 Pro 26200, Intel Iris Xe, driver 32.0.101.7088 (June 2026).

3 identical crashes within one night, each one seconds after [Preview] Created browser preview appears in main.log, all with the same exitCode: 101457950 (0x060C201E). main.log stops mid-write — the whole app dies with the GPU process. Crashes started the same day the 1.28929 build was auto-installed; no GPU-process crashes on earlier builds.

Two data points that may help triage:

1. Disabling hardware acceleration does NOT prevent the crash. I set "isHardwareAccelerationDisabled": true in claude_desktop_config.json and verified the renderers were launched with --disable-gpu-compositing — crash #3 happened with that active. So the software path dies the same way as the hardware path.

1. The "app won't relaunch after crash" is reproducible and visible in the event logs. After crash #3, eight consecutive launch attempts were logged by TWinUI as successful activations (Event 1621) but no window ever appeared and no Starting app line was written to main.log. A Repair attempt failed with 0x80073D02: Unable to install because the following apps need to be closed: Claude / "Packages were not updated because affected apps are still running" — while Task Manager showed no visible Claude process (consistent with the surviving cowork-svc.exe noted in the OP holding the package busy). Killing the leftover package processes unblocks launch without needing a full Repair.

Also worth noting: the built-in gpu-recovery logic (auto-disable HW accel after ≥3 GPU deaths) can never trigger for this bug, because every single GPU death takes down the whole app — the in-session death counter resets on every restart.

Happy to provide full main.log excerpts or the AppXDeployment event dumps if useful.

Follow-up from my earlier comment, with a decisive data point on the "won't relaunch" state (appxState=2):

**The crash corrupts the package registration state, not the package files. We verified every file in the package directory was byte-identical to the original MSIX contents (SHA256, no stray files). The very next GPU crash (same exitCode 0x060C201E) still left the package in Modified, NeedsRemediation status (Get-AppxPackage ... | % Status) with zero** package processes alive.

While the package is in that state:

• Shell activations log as successful (TWinUI Event 1621) but no process ever starts.
• Add-AppxPackage -Register <manifest> -ForceApplicationShutdown (elevated, with the CoworkVMService stopped first) completes without error — but activation remains blocked, and the Modified, NeedsRemediation status persists.
• Only the full Settings → Repair (RepairPackageOperation, which re-downloads the entire ~130 MB MSIX) clears the flag and lets the app activate again.

Across 6 crash/recovery cycles measured today, recovery consistently took 10–23 minutes per crash, dominated by the forced re-download. On metered connections this is painful: 5 crashes in one day ≈ 650 MB of re-downloads just to keep using the app.

So beyond the GPU crash itself, there appear to be two distinct bugs worth splitting: (1) the WebGL-probe GPU crash taking down the host, and (2) the crash leaving the MSIX registration in NeedsRemediation so that nothing short of a full re-download restores launchability.

Still reproduces on desktop app 1.30096.1.0, Windows 11 Home 26220. Two crashes this evening, both within 3 seconds of a URL opening in the internal browser preview.

main.log:

2026-08-14 23:07:49 [info] [Preview] Created session preview context
2026-08-14 23:07:51 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
2026-08-14 23:07:52 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

The window log in that same second shows the probe signature OP described: two "The powerPreference option is currently ignored when calling requestAdapter()" warnings, then "A valid external Instance reference no longer exists" and "WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost". The whole app died with the GPU process. The previewed page was running sign-in and fingerprinting probes (FedCM/GSI errors logged right before the crash).

Earlier crash the same evening at 21:55:21 with the identical signature. Crashpad wrote a 35 MB dump for the 23:07 crash, can attach on request. The MSIX package went to Modified/NeedsRemediation after the crash, same as OP. GPUs on this machine: RTX 5070 Ti, AMD integrated, plus a Meta Virtual Monitor adapter from Quest Link.

Additional diagnostic data for this issue, from a machine reproducing the same 0x060C201E GPU-process death and the same unlaunchable-package aftermath. Five crashes over two days, two full reinstalls.

Three of the findings below are not in this issue or in the related ones, and one of them contradicts the explanation currently carried by openai/codex#34133 — so it seemed worth writing up in full rather than a "+1".

---

Summary

Opening the Claude Code Browser pane kills Claude Desktop on Windows. The GPU
process dies with exitCode: 101457950 (0x060C201E), and Windows Code Integrity
logs Event 3033 for the bundled vk_swiftshader.dll at the same second. After the
crash the MSIX package is left unlaunchable and only a reinstall recovers it — until
the Browser pane is used again.

Reproduced 5 times over 2 days. Two full reinstalls; the crash returns each time.

The bundled DLL is correctly embedded-signed by Anthropic, PBC with a valid EV
certificate. It is rejected anyway, because the GPU child process demands the
Microsoft signing level. This is not a signing defect on Anthropic's side and
cannot be fixed by signing differently.

Environment

| | |
|---|---|
| Claude Desktop | 1.30096.5.0 (MSIX, Claude_pzs8sxrjxfjjc) |
| Claude Code | 2.1.233 |
| Windows | 11 Home, build 26200 |
| GPU | AMD Radeon(TM) Graphics, driver 31.0.21921.13001 (2025-07-07) |
| Second adapter | VITURE Virtual Display Adapter 13.28.23.205 |
| RAM | 13.8 GB |
| Chrome (for comparison) | 151.0.7922.138 |

Reproduction

1. Open a Claude Code session.
2. Use the Browser pane at all — preview_start alone is sufficient.
3. Claude Desktop terminates.
4. Relaunch fails; reinstall required.

Evidence

GPU process deaths (%APPDATA%\Claude\logs\main.log)

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

2026-08-15 11:22:26
2026-08-15 12:31:48
2026-08-15 12:40:02
2026-08-16 07:32:54
2026-08-16 07:55:55

101457950 = 0x060C201E, the same code as #80444.

Code Integrity Event 3033, same timestamps

Code Integrity determined that a process
  ...\WindowsApps\Claude_1.30096.5.0_x64__pzs8sxrjxfjjc\app\claude.exe
attempted to load
  ...\WindowsApps\Claude_1.30096.5.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll
that did not meet the Microsoft signing level requirements.

2026-08-16 07:32:54 and 07:55:55 — exact match with the GPU deaths above.

Event 3033 over 7 days, by file:

66  vk_swiftshader.dll
62  vulkan-1.dll
 1  graphics-hook64.dll

---

Three findings not present in the existing reports

1. A screenshot is not required. Opening the browser pane is enough.

#81664 and openai/codex#34133 both attribute the crash to screenshot capture
(Page.captureScreenshot). That is not the full trigger.

The 2026-08-16 07:55:55 crash was produced by preview_start followed by
resize_window (1440x900) and nothing else — no screenshot was taken in that
session. Avoiding screenshots is therefore not a viable user-side mitigation, and
the mitigation currently suggested in #81664 does not hold.

2. The bundled DLL is embedded-signed by Anthropic. The catalog-signature explanation does not apply here.

openai/codex#34133 explains the failure as: the DLL "lacks an embedded Authenticode
signature" and only "verifies against the MSIX package catalog", which the child
policy does not recognise.

On Claude Desktop that is not the case:

C:\Program Files\WindowsApps\Claude_1.30096.5.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll
  Status         : Valid
  StatusMessage  : Signature verified.
  SignatureType  : Authenticode          <- embedded, not catalog
  Signer         : CN="Anthropic, PBC", O="Anthropic, PBC",
                   L=San Francisco, S=California, C=US,
                   OID.2.5.4.15=Private Organization (EV)

The signature is embedded and valid. It is rejected because the GPU child process runs
under MicrosoftSignedOnly=ON / AllowStoreSignedBinaries=OFF, and an
Anthropic-signed binary is not Microsoft-signed at that level, however valid it is.

The practical consequence: this cannot be resolved by signing the DLL differently.
Any third-party-signed DLL loaded into that process is rejected by construction. The
fix has to be in how the GPU process handles the SwiftShader load.

For comparison, C:\Windows\System32\vulkan-1.dll is CN=Microsoft Windows and loads
without an event; Chrome's own copies are CN=Google LLC and produce 3033 as well.

3. No Vulkan ICD is registered on this machine, so the SwiftShader fallback is deterministic rather than occasional.

HKLM:\SOFTWARE\Khronos\Vulkan\Drivers            -> key does not exist
HKLM:\SOFTWARE\WOW6432Node\Khronos\Vulkan\Drivers -> key does not exist
amdvlk64.dll                                      -> not present
amd_icd64.json                                    -> not present
amdxc64.dll (D3D12)                               -> present

Independently corroborated: a Playwright-driven Chromium on the same machine logs
No available adapters.

With no hardware Vulkan ICD, Chromium always falls back to SwiftShader — and that
fallback path is exactly the one Code Integrity blocks. The safety net is the thing
that is unreachable, which is why this machine reproduces the crash every time
rather than intermittently.

This may explain why the issue looks vendor-agnostic across #81664 (Intel UHD),
#83028 and #83478: the common factor is likely "no usable Vulkan ICD", not a
particular GPU vendor.

---

Ruled out — please do not triage as a user security-configuration problem

All measured on the affected machine:

| Setting | Value | Relevance |
|---|---|---|
| Smart App Control | VerifiedAndReputablePolicyState = 0 | OFF. Not involved |
| User-mode WDAC | UsermodeCodeIntegrityPolicyEnforcementStatus = 0 | Not enforced. Not involved |
| Memory Integrity (HVCI) | SecurityServicesRunning = 2, Enabled = 1 | Running, but kernel-mode only. These are user-mode DLLs |
| Developer Mode | AllowDevelopmentWithoutDevLicense = 1 | Already ON |

Disabling Memory Integrity does not fix this and only weakens the machine. The
restriction is applied by Chromium to its own child process via
SetProcessMitigationPolicy, not by any Windows security policy the user controls.

Chrome does not crash

Chrome 151.0.7922.138 on the same machine logs Event 3033 for its own
vk_swiftshader.dll and vulkan-1.dll and keeps running. The fatality is specific
to the packaged Claude Desktop path, which corroborates the unconditional
SwiftShader preload during GPU sandbox initialisation as the failure point.

Suggested fix

Chromium already has this: commit 963206a961a7992b048d07f756f87f11fa2e5420 —
*"only preload SwiftShader during GPU sandbox initialization when that load is
allowed, and otherwise use the Windows fallback path."*

Claude Desktop 1.30096.5.0 does not have it. Upgrading 1.30096.1.0 -> 1.30096.5.0
changed nothing.

Requests, in order of usefulness:

1. Pick up the Chromium fix (or backport it) so a blocked SwiftShader load

degrades instead of killing the GPU process and the app shell.

1. Stop a GPU-process death from taking down the whole app, and stop it leaving

the MSIX package unlaunchable. Requiring a reinstall to recover from a rendering
fallback is disproportionate.

1. Expose a hardware-acceleration / ANGLE-backend toggle in Settings, as

requested in #77857. There is currently no supported user-side mitigation:
Invoke-CommandInDesktopPackage requires an elevated session (fails with
0x800704C7 otherwise), and launching the packaged .exe directly is documented
as breaking the app's disk cache. Chrome, VS Code and Discord all expose this.

Related

• anthropics/claude-code#80444 — same 0x060C201E, MSIX left unlaunchable
• anthropics/claude-code#81664 — Browser-pane crash, then fails to relaunch (Intel UHD)
• anthropics/claude-code#83028 — MSIX crash on integrated GPU during browser pane use
• anthropics/claude-code#83478 — GPU process crash kills host app shell during live preview
• anthropics/claude-code#77857 — no way to disable hardware acceleration
• openai/codex#34133 — same mechanism in a different Electron app

One week of MTBF data on the --disable-webgl workaround, plus an operational hazard for anyone using it (same machine as my earlier comments; Win10 19045):

Time-to-fatal-GPU-death (exitCode 101457950) by configuration, now across 12 days:

| config | time to fatal death |
| --- | --- |
| stock (hardware accel) | 8–21 min |
| --disable-gpu (WARP) | 9–67 min |
| + --disable-webgl --disable-webgl2 (+ later --disable-accelerated-2d-canvas --disable-features=WebGPU) | ~1–6 days per instance; 3 fatal deaths over the last 7 days (Aug 9, 10, 16) |

Versions involved: 1.25927 → 1.26832 → 1.28929 → 1.30096.5 (auto-updates); the death reproduces on every one of them. The Aug 16 death (1.30096.x, flags active) came during an active session — last log lines before it were [gitDiff] fetchGitDiff timing and oauth token refresh. Consistent with others' reports here that in-app browser/preview/session activity is the trigger surface; the flags shrink the crash rate ~500x but can't remove it.

Operational hazard with the flag workaround: the auto-updater relaunches the app WITHOUT your flags. Three updates arrived in six days, each one restarting the app in stock (hardware-accel) configuration — which on this machine is minutes from a crash-and-package-corruption. If you're using the --disable-webgl workaround, you need automation that detects unflagged relaunches and swaps them, or every update silently puts you back in the 10-minute crash regime.

Still zero crash artifacts across all deaths (no Crashpad reports, no WER Event 1000).

Recovery note echoing @saymonsh's finding: the package corruption is registration state, not files — full Remove-AppxPackage + reinstall remains the only reliable recovery on Win10 (no Reset-AppxPackage), and it needs the app's zombie processes killed first or servicing fails with 0x80073D02 and re-wedges.

Precise trigger-to-death timing from tonight, on 1.30096.5.0 with ALL GPU features disabled (--disable-gpu --disable-webgl --disable-webgl2 --disable-accelerated-2d-canvas --disable-features=WebGPU, GPU child in WARP):

22:22:17 [info] [Preview] Created session preview context {
22:22:17 [info] [Preview] Created browser preview { serverId: 'browser-preview-1786875737709-0' }
...
22:23:16 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }

Browser preview creation → fatal GPU death in 59 seconds, in full software rendering. The previous instance died the same way minutes after Created browser preview at 22:06:17. This confirms the browser-preview trigger reported above holds even with WebGL/WebGPU/canvas acceleration all unavailable.

One aggravation worth flagging for the fix: session restore recreates the browser preview on relaunch, so after a crash the app comes back, restores the session, recreates the preview, and dies again within minutes — a crash loop for anyone actively using a session with a preview open. Tonight that produced two fatal deaths and two package corruptions inside 11 minutes on a machine with the workaround flags active.

Additional data point: still reproducing on 1.30096.5, triggered without opening the Browser tab, and Repair no longer recovers the package

Adding evidence from a separate machine. Same exit code (0x060C201E / 101457950), same preview-tab vector, but three findings that differ from the original report.

Environment

| | |
|---|---|
| App version | 1.30096.5 (MSIX, windowsStore=true) |
| CCD | 2.1.229 |
| Node | 24.18.0 |
| Platform | win32 x64, Windows 11 |
| RAM | 32 GB (~20 GB free throughout) |

1. Still present on 1.30096.5

The original report is against 1.24012.1. This is 1.30096.5 — the regression has survived several releases. Five fatal crashes in ~17 hours, every one ending:

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

Identical exit code on every occurrence.

2. The trigger fires without the user opening the Browser tab

This is the part that matters for reproduction. The crash correlates 5/5 with a session preview context being created — and in this case the app was creating them itself, restoring the preview attached to the last active local session. The user was not clicking into the preview pane.

| App start | [Preview] Created session preview context | GPU process gone | Δ |
|---|---|---|---|
| 14:33:41 | 14:35:33 | 14:36:01 | 28s |
| 14:42:55 | 14:45:40 | 14:45:46 | 6s |
| 15:27:48 | 15:31:40 | 15:32:06 | 26s |
| 06:51:10 | 06:55:27 | 06:55:32 | 5s |
| 06:57:21 | 07:00:55 | 07:01:00 | 5s |

No preview context created → no crash. Perfect correlation, zero exceptions across five runs.

The final crash logs the preview being constructed automatically for a restored session:

[Preview] Created session preview context { previewId: 'preview-local_<id>', totalContexts: 1 }
[Launch] Updating active servers store { count: 1, servers: '[{"serverId":"browser-preview-<ts>-0",
  "name":"Browser","status":"running","previewId":"preview-local_<id>","tabId":"seed"}]' }
[PreviewContext] Blocked subresource to non-public host from non-preview initiator
GPU process gone: { reason: 'crashed', exitCode: 101457950 }

Renderer log at the same timestamps:

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

So the sequence is: preview context created → WebGPU adapter requested → GPU process dies → app dies. The user has no opportunity to avoid this, since it happens during session restore on launch. "Don't open the Browser tab" is not an available workaround when the app opens it for you.

Worth noting the preview target was a dev server that wasn't running (navigatePreview failed, followed by nine [PreviewContext] Load failed retries and Max retries reached). The GPU crash happens on the failing preview path too — a live page isn't required.

Ruled out: memory (~1.6 GB tree RSS against ~20 GB free at every crash), MCP servers (10 loaded in 298 ms, mcp.log empty, crashes reproduce with claude_desktop_config.json renamed away), and prior package corruption (first crash occurred on a healthy install).

3. Settings → Repair no longer recovers the package

The original report lists Repair as the fix. On this machine it fails outright.

After each crash, Get-AppxPackage reports:

Status: Modified, NeedsRemediation

and the app cannot launch at all — Invoke-CommandInDesktopPackage fails with 0x80073CFC, so the documented --disable-gpu workaround is unreachable once you've crashed even once. What was tried, in order:

1. Add-AppxPackage -Register ...\AppxManifest.xml -DisableDevelopmentMode -ForceApplicationShutdown — completes without error, but Modified, NeedsRemediation persists. Re-registration doesn't clear the integrity flag.
2. Settings → Apps → Claude → Advanced options → Repair — fails with "We couldn't repair this app. Try again in a bit." Repeated attempts, same result. This is the documented remedy and it does not work.
3. Uninstall → reinstall — the only thing that restored Status: Ok.

So on 1.30096.5 the recovery cost is a full reinstall and re-login per crash, not a Repair click.

Impact

A user who hits this sees: app dies after 3–5 minutes → won't reopen → Repair button fails → no path forward without PowerShell diagnostics to discover the package is flagged Modified. Nothing surfaces the cause. The reasonable conclusion for a non-technical user is that their computer is broken. This one took a multi-hour log investigation to attribute, and the user's first instinct was that something was wrong with their PC.

The crash-corrupts-its-own-package loop is what makes it severe: reinstalling restores the app, then session restore recreates the preview, and you're back to square one.

What actually stopped it

Deleting the local sessions that had preview contexts attached. After that: app stable well past the 3–5 minute window, live log shows zero preview context and zero GPU process gone entries, GPU process alive and healthy.

That's a workaround, not a fix — it costs the user their session history, and nothing tells them to do it.

Suggested fixes, roughly in priority order

1. Don't let a GPU-process crash take down the app. render-process-gone / child-process-gone on the GPU service should be recoverable — tear down the preview and continue, rather than a hard exit. This alone would downgrade the bug from fatal to cosmetic.
2. Don't auto-restore preview contexts on launch. Restore the session, leave the preview closed until the user asks for it. That gives users an actual avoidance path.
3. Guard the WebGPU/WebGL init in preview contexts — the requestAdapter() path is where it dies. Consider software compositing for preview surfaces.
4. Investigate why a GPU crash flags the MSIX package Modified. An unclean exit shouldn't fail package integrity. This is arguably the more serious of the two bugs, since it's what makes the crash unrecoverable.
5. Ship a supported "Disable hardware acceleration" toggle (see #77857). Under MSIX there is no way for a user to pass --disable-gpu, and after the first crash even the unsupported invocation stops working.

Happy to supply full main.log, unknown-window.log, and claude.ai-web.log if useful — identifiers scrubbed.

Same-machine A/B across two GPU vendors: the crash follows the app, not the GPU

Adding one test I could not find in this thread or the related ones: a hybrid laptop where the app was moved between two different-vendor GPUs on the same machine, with nothing else changed. Same exit code either way.

Environment

| | |
|---|---|
| App | 1.28929.0.0 (MSIX, Claude_pzs8sxrjxfjjc, SignatureKind: Developer) |
| OS | Windows 11 Home 26200 |
| Machine | ASUS ROG Strix G513QE, Ryzen 7 5800H, 32 GB |
| GPUs | AMD Radeon (Cezanne iGPU, driver 30.0.13002.19003 / 2022-09-28) and NVIDIA RTX 3050 Ti (32.0.15.9649 / 2026-05-05) |

1. Vendor swap on one machine changes nothing

This thread already has cross-machine evidence that the bug is not driver-specific (NVIDIA on two drivers, Intel Iris Xe, a single-discrete-GPU desktop). This is the within-machine version of that test, which removes the remaining confound.

The app was forced onto the discrete NVIDIA GPU with the Windows per-app preference:

HKCU\Software\Microsoft\DirectX\UserGpuPreferences
  Claude_pzs8sxrjxfjjc!Claude = GpuPreference=2;

Confirmed actually in effect rather than merely configured. nvidia-smi listed the Electron GPU child on the RTX 3050 Ti, and the per-process counter showed dedicated VRAM in use, which the iGPU does not have:

|  0  N/A  N/A  30104  C+G  ..._pzs8sxrjxfjjc\app\claude.exe |

\GPU Process Memory(pid_30104_luid_0x00000000_0x00015050_phys_0)\Dedicated Usage = 61.6 MB

Crashes continued with the identical exitCode: 101457950. Two vendors, two driver stacks, one machine, one exit code. Together with the WARP / full-software-rendering death reported earlier in this thread, the GPU path looks incidental rather than causal.

2. Trigger timing across 6 crashes

| crash (local) | [Preview] Created browser preview | delta |
|---|---|---|
| 2026-08-13 03:44:00 | 03:43:54 | 6 s |
| 2026-08-13 08:37:59 | 08:37:55 | 4 s |
| 2026-08-13 08:53:56 | 08:53:50 | 6 s |
| 2026-08-15 23:18:29 | 23:18:22 | 7 s |
| 2026-08-16 21:20:38 | 21:19:41 | 57 s |
| 2026-08-15 23:16:29 | none in the preceding 20 min | n/a |

5 of 6 follow preview creation within seconds. The sixth had no preview creation before it, consistent with the report above that this can fire without the Browser tab being opened.

Memory was not a factor. Two seconds before the last death: tree_rss_sum=3578MB, sys_free=13251MB/32159MB.

After that crash, main.log records no successful Starting app until after a full OS reboot, matching the "will not relaunch" behaviour described in this thread.

3. Code Integrity events are a symptom, and are often absent entirely

Recording this because a third-party diagnosis of this crash keeps circulating, blaming a missing AppxMetadata\CodeIntegrity.cat and a "blocked" vk_swiftshader.dll:

• On this machine those 3010/3033 events fire in the same second as the GPU death. They are the SwiftShader fallback path, not its cause.
• Microsoft-Windows-CodeIntegrity/Operational recorded zero Claude-related events over the last two days while the crashes continued, so they are not even a reliable correlate.
• The 3010 status is 0xC000003A (path not found), and this package has no AppxMetadata directory at all. It ships microsoft.system.package.metadata, so that catalog is expected to be absent.
• The identical 3033 events fire continuously for unrelated third-party DLLs on the same machine (Bonjour\mdnsNSP.dll) with no ill effect.
• No Smart App Control or WDAC policy is present (HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy has no VerifiedAndReputablePolicyState).

Same conclusion as the analysis already in this thread; adding the measurements since the code-integrity explanation keeps resurfacing.

Same signature here — adding a dataset spanning three app versions, which suggests the bug survives updates.

Environment

• OS: Windows 10 Pro 19045
• GPU: NVIDIA, driver 610.88 (updated 2026-08-11 — did not prevent the next crash)
• Install: MSIX (Microsoft Store / WindowsApps)

Crash log (from %APPDATA%\Claude\logs\main.log, local time UTC-3):

| Date | Time | Reason | Exit code | App version |
|---|---|---|---|---|
| 2026-07-25 | 19:56:57 | crashed | 101457950 | 1.24012.9 |
| 2026-07-26 | 17:28:11 | crashed | 101457950 | 1.24012.9 |
| 2026-07-27 | 15:52:57 | crashed | 101457950 | 1.24012.9 |
| 2026-08-05 | 00:49:02 | crashed | 101457950 | 1.24012.9 |
| 2026-08-11 | 22:44:51 | crashed | 34 | 1.28929.0 |
| 2026-08-17 | 15:51:11 | crashed | 101457950 | 1.30096.5 |

All 101457950 = 0x060C201E, GPU process gone: reason crashed.

State at the 2026-08-17 crash: ~22 Electron processes, ~4 GB aggregate RSS, 6 visible Preview/Browser contexts open, ~15 GB system RAM free.

Ruled out on this machine:

• GPU driver reset: 0 nvlddmkm / TDR 4101 events in the Windows System log over 90 days.
• OOM: plenty of free RAM at every crash.
• WER: 0 Application Error events — Windows never sees these as app crashes.
• Driver version: updating to 610.88 on 08-11 did not stop the 08-17 recurrence.

Secondary failure worth flagging: after the GPU crash, the packaged CoworkVMService (cowork-svc.exe) survives and keeps the MSIX payload locked, so automatic AppX remediation fails (0x80073D02, and an in-place reinstall fails with 0x80070020) and the package gets stuck in Modified, NeedsRemediation — the app then won't launch at all ("There's a problem with Claude"). Workaround: stop CoworkVMService, kill leftover WindowsApps claude.exe / chrome-native-host.exe, then run the signed Claude Setup.exe in place. If the crash itself can't be fixed soon, having the service release its lock (or the remediation use forced shutdown) would at least keep the app relaunchable after a crash.

Still reproducing on 1.32352.0.0 — plus two behaviours that differ from the reports above

Adding a data point on a build newer than any reported in this thread, on an older Windows branch than any reported, with two departures from the established pattern: the app hangs rather than dying instantly, and package corruption is not deterministic per crash.

Environment

| | |
|---|---|
| Claude Desktop | 1.32352.0.0 (MSIX Claude_pzs8sxrjxfjjc, SignatureKind: Developer) |
| OS | Windows 11 Pro 22631.6199 (23H2) |
| GPU | Single NVIDIA GeForce RTX 4090, driver 32.0.16.1074 (2026-07-01) |
| RAM | 64 GB, >40 GB free at every crash |

1. Still present on 1.32352.0.0

The newest build reported above is 1.30096.5. Four fatal exitCode: 101457950 (0x060C201E) deaths on 1.32352.0.0 inside 34 minutes, plus two earlier on 1.24012.x (2026-07-25). The regression has now survived at least eight releases.

Also worth noting: every report above is on Windows 11 build 26200/26220. This machine is on 23H2 (22631), so the bug is not confined to the 26xxx branch.

2. Browser-pane trigger confirmed, but not 100% per open

Five [Preview] Created browser preview events, four fatal:

| Browser preview created | GPU process gone | Δ |
|---|---|---|
| 23:55:04 | 23:55:09 | 5s |
| 00:00:20 | 00:00:23 | 3s |
| 00:12:15 | — | survived |
| 00:15:16 | 00:15:20 | 4s |
| 00:29:03 | 00:29:06 | 3s |

[Preview] Created session preview context on its own is benign here — it appears several times in the log without a death. Only the paired Created browser preview kills it.

3. The app HANGS rather than dying with the GPU process

This is the main departure from the reports above, which describe main.log stopping mid-write and the app dying instantly.

On this machine the process survives the GPU death, but the window stops compositing and Windows kills it as a hang ~90s later:

• Application Hang, Event ID 1002: 5 occurrences in 30 days
• Application Error, Event ID 1000: 0 — Windows never sees a crash
• Crash → next Starting app gaps: 2m01s, 1m34s, 2m18s, 1m29s — consistent with hang-detect-and-kill, not instant death

Event 1002 doesn't appear anywhere in this thread. If others are seeing "the app froze and Windows offered to close it" rather than a clean disappearance, that's the same bug presenting differently, and it means Get-WinEvent -Id 1002 is a better detector than Crashpad or Event 1000 — both of which are empty here, consistent with @lacique77's exit_on_context_lost explanation above.

4. Package corruption is NOT deterministic

Reports above describe every crash leaving the MSIX in Modified, NeedsRemediation. Here, two of the four crashes required a Repair and two did not. After the last two deaths Get-AppxPackage *Claude* | % Status still returns Ok and the app relaunches normally.

So the GPU death and the package-state corruption look like separable failures — which supports splitting them into two issues, as suggested above.

5. Corroborating: isHardwareAccelerationDisabled does not prevent it

Confirming @saymonsh's finding. I set "isHardwareAccelerationDisabled": true and verified it was actually in force rather than merely configured:

PID    type             disable-gpu  disable-gpu-compositing  angle
1144   gpu-process      -            -                        d3d11-warp-webgl
26252  renderer         True         True                     -

GPU child in WARP software rendering, renderers with --disable-gpu. Config written 00:24:40, app restarted 00:27:37, fatal death at 00:29:06 — with the setting live. Software rendering did not save it.

6. Crash 4 had no requestAdapter() pair — the one signature that varied

The first three deaths carry the signature described above, in unknown-window.log, in the same second as the kill:

23:55:09 [warn] OTS parsing error: Size of decompressed WOFF 2.0 is less than compressed size
23:55:09 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows.
23:55:09 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows.

The doubled requestAdapter() matches @lacique77's observation exactly — 3/4 here.

But the fourth death has no requestAdapter() at all. The only line in that second is:

00:29:06 [warn] A valid external Instance reference no longer exists.

That fourth crash is also the one that ran with hardware acceleration disabled. So with WebGPU adapter acquisition off the table, the process still reached the identical exit code by a path that leaves only the lost-instance warning. Consistent with @aihunt-ttg's finding that the flag workaround shrinks the rate ~500x without removing the death — whatever is losing the context isn't only the adapter probe.

Ruled out on this machine

• GPU driver reset: 0 TDR / Event 4101 in 90 days
• Crash dumps: nothing in Crashpad, 0 Event 1000 — invisible to telemetry
• Memory: >40 GB free at every crash
• Installer Repair as a preventative: repaired twice, crashed again within minutes both times — only the restart does anything
• Clearing GPUCache / DawnGraphiteCache / DawnWebGPUCache: crashed again 5 minutes later

Happy to supply full logs.

Thanks to everyone who's added data since my Aug 5 comment. This thread has done more real diagnosis in two weeks than most bug reports see in a year. Here's where I think we've landed.

The trigger is the browser/preview path, and you can't reliably avoid it. HarvestEdge and others show it firing within seconds of opening the Browser pane. Turkokami showed the app triggers it by itself when it restores a preview context on launch. aihunt-ttg showed session restore recreates the preview after each crash, so it loops. "Just don't open the browser tab" is not a workaround when the app opens it for you.

It's not the GPU, the drivers, or your machine. yonig15 moved the app between an AMD iGPU and an NVIDIA dGPU on the same laptop and got the identical crash both ways. HarvestEdge reproduced it on a single discrete GPU with no hybrid graphics. aihunt-ttg and jrclaborn-arch both died in verified WARP software rendering. saymonsh confirmed the hardware acceleration setting doesn't save you. My AMD datapoint plus the NVIDIA, Intel, and Qualcomm reports were already pointing this way. The same-machine A/B settles it: the crash follows the app.

The GPU process isn't crashing, it's exiting on purpose. lacique77 traced why there's never a dump: 0x060C201E isn't a valid NTSTATUS, LocalDumps never fires, Event 1000 is empty. Chromium's exit_on_context_lost (gpu_driver_bug_list entry 17, applies to all of Windows) turns a recoverable context loss into a deliberate process exit. botarhythm showed one concrete way the context gets lost: the GPU child runs MicrosoftSignedOnly, so Code Integrity refuses the bundled vk_swiftshader.dll even though it's validly signed. Per yonig15 the CI events are absent on some machines, and jrclaborn-arch had one death with no requestAdapter at all, so that's one road into the context loss, not the only one. The fatal part is the same either way: context lost, process exits by design, nothing respawns it, whole app goes down.

The aftermath looks like a second bug. saymonsh proved the package files stay byte-identical after a crash; it's the MSIX registration state that gets flagged Modified. Sometimes Repair fixes it, sometimes Repair fails outright and only a full reinstall works (Turkokami). olegpars and lacique77 showed CoworkVMService holds the package lock, so remediation fails until you stop the service and kill the leftover processes by hand. jrclaborn-arch found the corruption isn't even deterministic per crash. This half deserves its own issue, as suggested above.

Current workarounds and their traps:

• Launch flags (--disable-gpu, --disable-webgl, etc): aihunt-ttg measured roughly a 500x reduction, not elimination. Big trap: every auto-update relaunches the app without your flags and silently puts you back in the minutes-to-crash regime. Three updates in six days on his machine.
• The in-app hardware acceleration toggle: does not prevent the crash. Confirmed twice, WARP state verified.
• Deleting local sessions with preview contexts attached stops the launch-time crash loop (Turkokami), at the cost of session history.
• Recovery order that works: close the app, stop CoworkVMService, kill leftover claude.exe and chrome-native-host.exe, then Repair or reinstall. Any other order re-wedges with 0x80073D02.
• ozoknar's switch to the winget Win32 build (winget install Anthropic.Claude) is still the only report of zero Code Integrity events after a change. One caveat: #76980 documents the app migrating Squirrel installs to MSIX, so watch whether it sticks. If anyone has run the winget build for a week-plus, that datapoint would be valuable here.

What we need from Anthropic, in priority order:

1. Make a GPU-process death recoverable. Respawn it or degrade rendering instead of taking down the whole app and every running session. Chromium already has the fix for the SwiftShader path (commit 963206a9, preload SwiftShader only when the load is allowed). This alone turns the bug from fatal into cosmetic.
2. Stop auto-restoring preview contexts on launch, so a crash doesn't loop and users have an actual avoidance path.
3. Fix the aftermath: don't leave the MSIX registration in NeedsRemediation, and have CoworkVMService release the package when the app dies.
4. Ship a supported hardware-acceleration/ANGLE toggle that survives updates (#77857), since the updater currently strips user flags.

Still reproducing on 1.32352.0.0 as of yesterday. That's at least eight releases carrying this, seventeen substantive comments, a growing duplicate cluster (#81664, #81698, #81836, #82967, #83028, #83478), and no label, assignee, or response since this was opened on July 23. The diagnosis is done. Somebody from the team needs to pick this up.

Still reproducing on 1.32885.1 - plus a public repro URL and a clean WebGPU isolation

Adding a dataset on a build newer than any reported here, with two things I think are new to the thread: a named public URL that triggers it on demand, and negative evidence from a 3.5-month renderer log that isolates the requestAdapter() road into the context loss.

I'm not re-litigating what's already settled above. @pylonsolus's synthesis matches everything I see: it follows the app not the hardware, the GPU child exits deliberately rather than crashing, and nothing respawns it.

Environment

| | |
|---|---|
| App | 1.32885.1 (MSIX, WindowsApps) |
| OS | Windows 11 Home 10.0.26200.9168 |
| GPU | NVIDIA RTX 4070 Ti SUPER, driver 32.0.15.9636 |
| Times below | local, UTC-4 |

The trigger is reproducible on a public URL

Every crash here happened while the in-app Browser loaded mobygames.com, specifically its Cloudflare Turnstile interstitial ("Checking if the site connection is secure"). It reproduces whether the browser is driven by me or by the agent, and it fires while the challenge is still spinning, before any interaction.

Four crashes in 12 minutes, all identical:

| # | Time | Exit code |
|---|---|---|
| 1 | 22:08:56 | 101457950 (0x060C201E) |
| 2 | 22:14:33 | 101457950 |
| 3 | 22:19:14 | 101457950 |
| 4 | 22:20:58 | 101457950 |

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

Turnstile was already named upthread as one trigger. What I can add is a stable public page that carries it, which may save whoever picks this up from having to reproduce it against a login flow.

Negative evidence isolating the WebGPU path

This is the part I think is genuinely new. My renderer log (unknown-window.log) is unrotated and continuous from 2026-05-07 to now. Across that entire span it contains exactly 8 occurrences of:

[warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows.
       See https://crbug.com/369219127

Two per crash, at all four crash timestamps, and zero anywhere else in 3.5 months.

So on this machine WebGPU has been requested exactly four times in the app's entire logged history, and the GPU process died within one second on all four. That doesn't contradict @jrclaborn-arch's death with no requestAdapter at all - it supports the "one road in, not the only one" reading, and it bounds this road tightly: where requestAdapter() appears, the hit rate here is 4/4.

A log signal I haven't seen mentioned

In the main-process log, each crash is preceded by ~1 second by this, and this line also occurs exactly 4 times ever, at those four moments and nowhere else:

[warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }

I can't tell whether that's part of the mechanism or just the same fingerprinting burst hitting a blocked endpoint on its way past. Flagging it because the "exactly 4, always ~1s before, never otherwise" pattern is hard to write off as noise, and it may be a cheap marker for the team to grep against.

Aftermath: Repair required 4/4 here

Package flagged Modified and unlaunchable after every crash, four for four. That's the deterministic end of the range, against @jrclaborn-arch's finding that it isn't deterministic per crash, so the variance is real and it isn't purely per-crash-count. Consistent with @saymonsh: it's the registration state, not the files.

One caveat on my own data, so nobody over-reads it

1.32885.1 installed at 21:09 and all four crashes came after it, but I can't offer that as a regression signal, because the triggering page had never been visited before either. Both variables changed within two hours. The build number is a fresh "still broken on this release" data point and nothing more.

Consistent with, not adding to

No Windows TDR or Display events, no Application error event, Crashpad\reports empty - matching @lacique77's finding that 0x060C201E isn't a valid NTSTATUS so LocalDumps never fires.

My box also has a messy adapter lineup (integrated AMD in Status: Error, plus two virtual display adapters). I initially suspected it, then found @yonig15's same-machine iGPU/dGPU A/B upthread, which rules it out as the cause. Recording it only in case adapter enumeration turns out to matter for how often it fires.

Nothing here changes the asks in the synthesis above. Item 1 - make a GPU-process death recoverable - would turn this from "lost my in-flight sessions and reinstalled the app" into a flicker, and it's still the one that matters.

Follow-up: --disable-gpu did not prevent the crash here, and the death had no WebGPU in it

Following my comment earlier tonight, I ran the software-rendering workaround and reproduced the crash anyway. Posting because it cuts against the current workaround guidance, and because it puts a second trigger on the board.

The flag was verifiably on

"...\Claude.exe" --disable-gpu

and the GPU child confirmed on WARP, not the card:

--use-gl=angle --use-angle=d3d11-warp-webgl

Same environment as before: 1.32885.1, MSIX, Windows 11 26200.9168, RTX 4070 Ti SUPER.

It crashed anyway, in 3 minutes, with the same exit code

2026-08-18 23:27:42  GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }

0x060C201E, identical to the four hardware-mode crashes earlier.

The signature was completely different

My earlier four crashes each carried the Turnstile fingerprint burst: two requestAdapter() warnings, a WOFF/OTS font error, and the %c%d font-size:0;color:transparent console-probe lines. None of that appears for this one. The renderer log still shows exactly 8 requestAdapter() warnings total across its entire 2026-05-07-to-now span, all belonging to the earlier four. This crash added zero.

What it died on instead, one second earlier:

2026-08-18 23:27:41 [info] [Preview] Created session preview context {
  previewId: 'preview-local_...',
  totalContexts: 1
}
2026-08-18 23:27:42 [info] GPU process gone: ...

That's the app constructing the browser pane, before the page rendered anything. The user never saw the Turnstile interstitial at all this time. Same destination URL, but it died on the way to the door rather than at it.

This corroborates @jrclaborn-arch's death with no requestAdapter and supports @pylonsolus's "one road into the context loss, not the only one". I'd sharpen it: the preview-context path is a trigger in its own right, and it is upstream of the fingerprinting, so software rendering never gets a chance to help.

The workaround erases itself at the worst moment

New detail I haven't seen stated in the thread: it isn't only auto-updates that strip your flags. A crash does too. The app's own restart comes back on the default command line:

"...\Claude.exe"          <- no --disable-gpu

So the protection is gone from the moment it first fails, and the next crash is unprotected unless you notice and relaunch by hand. Combined with @aihunt-ttg's three-updates-in-six-days measurement, the practical lifetime of the flag is "until something goes wrong", which is the exact window it exists to cover.

I'd suggest amending the workaround list: --disable-gpu looks like a frequency reducer for the WebGPU road specifically, not protection, and it is self-erasing.

Correcting my own earlier data point

I reported package corruption at 4 for 4 requiring Repair. This fifth crash relaunched clean with no Repair needed, so it's 4 of 5 here. @jrclaborn-arch's non-determinism finding holds and mine was just a short run.

Environment note for anyone comparing

Adapter enumeration on this box sees four displays (RTX 4070 Ti SUPER, an integrated AMD in Status: Error, and two virtual display adapters). Given @yonig15's same-machine iGPU/dGPU A/B I don't think that's causal, and this latest crash never reached adapter enumeration at all. Recording it only so nobody has to ask.

Trigger-to-death has tightened to 1–2 seconds on 1.32885.1.0 (arrived via auto-update overnight; same machine as my earlier comments, all GPU-feature flags still active, GPU child in WARP):

2026-08-20 18:09:30 [info] [Preview] Created browser preview { serverId: 'browser-preview-17872... }
2026-08-20 18:09:32 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }

2026-08-20 18:38:33 [info] [Preview] Created browser preview { serverId: 'browser-preview-17872... }
2026-08-20 18:38:34 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }

For comparison it was 59 s from preview creation to death on 1.30096.5 four days ago. Both of today's deaths wedged the MSIX package (Modified, NeedsRemediation) again.

Correlation summary for this machine over the last two weeks: the last four fatal deaths (Aug 16 x2, Aug 20 x2) each followed [Preview] Created browser preview by 1 s – 6 min, and the intervening ~4 days in which no preview was opened were completely crash-free. Avoiding the in-app browser preview is currently a 100%-effective workaround here; using it is a near-instant kill on the current build.

Follow-up to my 2026-08-15 comment, from the same machine, now on 1.32885.1.0 — the build @bobnorbob and @aihunt-ttg are reporting on. Four things: the mechanism still holds on this build, a falsifiable check for @bobnorbob's --disable-gpu result, a precise answer to @Turkokami's "3033 is a symptom" objection, and two corrections to my own earlier claims.

1. Same-second 3033 correlation is now 7/7 in both directions, across two builds

Every GPU process gone in main.log over 14 days, against every Microsoft-Windows-CodeIntegrity/Operational Event 3033 where the process is claude.exe and the file is the bundled app\vk_swiftshader.dll:

| GPU death | Event 3033 | Δ | Build |
|---|---|---|---|
| 2026-08-15 11:22:26 | 11:22:25 | 1 s | 1.30096.5.0 |
| 2026-08-15 12:31:48 | 12:31:47 | 1 s | 1.30096.5.0 |
| 2026-08-15 12:40:02 | 12:40:02 | 0 s | 1.30096.5.0 |
| 2026-08-16 07:32:54 | 07:32:54 | 0 s | 1.30096.5.0 |
| 2026-08-16 07:55:55 | 07:55:55 | 0 s | 1.30096.5.0 |
| 2026-08-19 14:44:49 | 14:44:49 | 0 s | 1.32885.1.0 |
| 2026-08-19 14:50:12 | 14:50:12 | 0 s | 1.32885.1.0 |

7 deaths, 7 events, no unmatched entry on either side. The message is verbatim identical on the new build, with the new package path:

Code Integrity determined that a process
  ...\WindowsApps\Claude_1.32885.1.0_x64__pzs8sxrjxfjjc\app\claude.exe
attempted to load
  ...\WindowsApps\Claude_1.32885.1.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll
that did not meet the Microsoft signing level requirements.

2. @bobnorbob — why --disable-gpu can't cover this path, and a check that would settle it

Your crash had no requestAdapter() in it and died one second after [Preview] Created session preview context, before the page rendered. That is exactly where the 3033 block lands here: GPU sandbox initialisation, upstream of any page content. --disable-gpu moves ANGLE onto WARP, but in pre-fix Chromium the SwiftShader preload during sandbox init is unconditional — it happens whatever the rendering backend is. So the flag has nothing to bite on for this road, which matches your result exactly.

Concrete check, if you still have the box: open Event Viewer → Microsoft-Windows-CodeIntegrity/Operational, filter Event ID 3033, and look at 2026-08-18 23:27:42. If there's a vk_swiftshader.dll entry for claude.exe on that second, your "second trigger" and the WebGPU-probe trigger are the same failure point reached by two routes, and the workaround list can be corrected once rather than twice.

On amending that list: the flag the mechanism predicts is --disable-features=Vulkan (optionally with --use-angle=d3d11), because what's blocked is the Vulkan/SwiftShader load, not the rendering backend. I have not verified this against a crash — I have no controlled A/B, only the mechanism — so please don't take it as a confirmed workaround. And it's academic for most people anyway: on MSIX, passing flags needs Invoke-CommandInDesktopPackage from an elevated session, and it self-erases (see §4). The only mitigation in this thread with positive evidence behind it is still switching off MSIX to the Squirrel build.

3. @Turkokami — the discriminator is which process and which file, not that a 3033 fired

Your objection is fair on its own terms and I don't think the two datasets conflict. Two clarifications on mine:

• "3033 fires harmlessly for other DLLs" — agreed, and that's why the filter matters. This machine logged 124 3033 events for chrome.exe in the same 14 days (vulkan-1.dll, vk_swiftshader.dll) with Chrome staying up throughout. Only 7 name claude.exe, and all 7 are the table above. Unfiltered event counts will show noise; claude.exe + app\vk_swiftshader.dll is the signal.
• The negative direction also holds here now. Since the 08-19 14:50 crash, four browser previews have been created on 1.32885.1.0 (08-19 18:01:23, 18:40:22; 08-20 16:32:14, 16:56:56) with zero 3033 events and zero crashes. Previously it was 3033-every-time and crash-every-time.

But your machine crashes with no 3033 at all, so this cannot be the only path to the death, and I shouldn't have implied otherwise. Treat it as: on machines with no usable Vulkan ICD, the blocked SwiftShader preload is a deterministic road in; it isn't the whole map.

4. Confirming @bobnorbob's self-erasing-flags finding, and it's sharper than described

Independent confirmation, plus the cost of it in one sequence:

14:44:49  GPU process gone: exitCode 101457950     <- crash
14:47:30  Starting app { appVersion: '1.32885.1' } <- app's own restart, bare command line
14:49:56  [Preview] Created browser preview
14:50:12  GPU process gone: exitCode 101457950     <- 16 s later, unprotected

The restart at 14:47:30 came back with no flags, and the next crash arrived 16 seconds after the next preview. Checked again a day later — Win32_Process still shows the bare line:

"C:\Program Files\WindowsApps\Claude_1.32885.1.0_x64__pzs8sxrjxfjjc\app\Claude.exe"

So the protection is gone from the first failure onward and never comes back on its own. Agreed with your framing: this is a frequency reducer that deletes itself at the exact moment it's needed.

5. Two corrections to my own 2026-08-15 comment

• "Only a reinstall recovers it" was a short run. Both 08-19 crashes relaunched clean with no Repair (Starting app at 14:47:30 and 14:53:23), and Get-AppxPackage -Name Claude reports Status : Ok today. Was 5/5 wedges here, now 0/2. Same correction @jrclaborn-arch and @bobnorbob made — the wedge is real but not deterministic.
• "Reproduces every time on this machine" no longer holds. On 1.32885.1.0 today, two browser previews (16:32:14, 16:56:56) produced no GPU death, no 3033, and the GPU child (alive since app start at 14:08:10) survived both. Same build @aihunt-ttg measures as a 1–2 second kill.

That last point is the one I'd ask triage to weigh: "reproduces instantly" and "doesn't reproduce at all" are currently both true of 1.32885.1.0 on different machines, so a build that looks fine on a test box says nothing about the fleet. The two requests from my earlier comment stand unchanged — pick up the Chromium fix so a blocked SwiftShader load degrades instead of killing the process, and don't let a GPU-process death take the app shell with it.

_{Windows 11 Home 26200.9168 · AMD Radeon(TM) Graphics 31.0.21921.13001 · no Vulkan ICD registered · Smart App Control off, user-mode WDAC not enforced · MSIX Claude_pzs8sxrjxfjjc}

2026-08-20 controlled repro on current production 1.32885.1 + issue-cluster escalation

This is a new controlled data point from the same independent Windows Server 2022 host I documented in #80999. The failure still reproduces on the current production build, and a narrowly scoped Windows Exploit Protection override does not work around it.

Current production package is still affected

The official update feed currently returns 1.32885.1 (published 2026-08-18):

https://releases.claude.com/api/desktop/win32/x64/msix/update?device_id=00000000-0000-0000-0000-000000000000

The feed-delivered MSIX was independently checked:

• version: 1.32885.1.0
• SHA-256: 7B21FD3182EA4383012BBC409E6255155871C0D4CB79695E652D9A4255085787
• Authenticode: valid, Anthropic PBC
• AppxMetadata/CodeIntegrity.cat: absent from the official archive

Controlled per-app Exploit Protection test

Starting state was a repaired/reinstalled package with Status: Ok. I then:

1. added an Exploit Protection rule for the exact current binary only (...\Claude_1.32885.1.0_x64__pzs8sxrjxfjjc\app\claude.exe);
2. verified before launch that the configured rule reported MicrosoftSignedOnly: OFF, OverrideMicrosoftSignedOnly: True, Source: Registry;
3. left the system-wide policy unchanged;
4. launched Claude and opened the built-in Browser once.

At 2026-08-20 11:14:27 CEST / 09:14:27Z, Windows logged the same exact sequence:

CodeIntegrity 3010 (x2)
...\Claude_1.32885.1.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat
Status 0xC000003A

CodeIntegrity 3033
...\app\claude.exe attempted to load ...\app\vk_swiftshader.dll
that did not meet the Microsoft signing level requirements

Immediately afterward, Get-AppxPackage reported:

Status: Modified, NeedsRemediation

So the exact per-program Exploit Protection toggle is not a workaround. This narrows the effective enforcement to a layer not disabled by that configured IFEO rule—consistent with a child-process mitigation supplied at process creation and/or the packaged-app path. I am deliberately not claiming which of those two is responsible without a runtime mitigation trace.

I removed the test rule afterward. Reinstalling the same signed MSIX over the existing package returned it to Status: Ok; the existing profiles and launchers remained intact.

The same incident is still split across multiple “canonical” trackers

Repository searches for the three exact fingerprints (vk_swiftshader.dll, CodeIntegrity.cat, and 101457950) now return a union of 107 issue records. Not every record is necessarily this root cause, but dozens carry the same Browser/preview → GPU exit → Code Integrity/AppX failure chain.

High-signal open trackers include the root-cause and crash threads #80444, #80999, #81275, #81341, #81698, #81745, #82967, #83028, #83403, #84976, #85837, #85901, #87204, #87638 and #87785; trigger-specific threads include #80306 and #87329; closely related package-recovery damage is tracked in #81306, #81875 and #82134.

More importantly, maintainer duplicate closures currently route the same technical fingerprint to six different open destinations:

• #83130 → #81341
• #83744 and #86265 → #81698
• #84458 → #83028
• #86313 and #86893 → #81275
• #87052 → #80306
• #87388 → #87329

That fragmentation makes the instruction “follow one issue so we can track it in one place” ineffective. The major trackers above remain open with no assignee and no milestone; most have only area:desktop, despite current-build repros and user-data/session impact.

Requested escalation

@bcherny, could the Desktop/Windows packaging team please:

1. designate one canonical incident and consistently redirect the exact-fingerprint duplicates to it;
2. assign an owner and mark the current production build 1.32885.1 as affected / reproduced on Windows;
3. confirm whether the intended fix is the package catalog/signing path, the Chromium GPU-child mitigation/fallback path, AppX recovery behavior, or a combination;
4. publish an official safe workaround and profile-preserving recovery procedure until a fixed build exists; and
5. state the first candidate/fixed build so reporters can perform the same Code Integrity A/B verification.

The lack of a conventional crash dump is expected for this load-time Code Integrity failure, so package telemetry alone may undercount it. Sanitized Code Integrity event exports and the exact official MSIX metadata are available if an engineer wants them.

---

Disclosure: this update was researched and drafted with OpenAI Codex on the affected machine at the account owner's explicit request.

Still reproducing on 1.32885.1 (current Store build) — plus one intermediate build, 1.32352.1, that survived a deliberate reproduction attempt before the next update regressed again. Two log signatures below that I haven't seen in this thread yet.

Environment: Claude Desktop MSIX 1.32885.1 (Store), Windows 11 Pro 26200, AMD Radeon 760M iGPU (driver 32.0.31035.1003), Node 24.18.1, CCD 2.1.234. Eleven fatal crashes on this machine since 2026-07-28, every one exitCode: 101457950 (0x060C201E), across 1.24012.9, 1.26832.0, 1.28929.0, 1.30096.1, 1.30096.5, and 1.32885.1.

A build that would NOT crash: on 1.32352.1.0 we deliberately tried to reproduce this — five staged runs, including 30 concurrent subagents with the in-app Browser pane and the Chrome-extension bridge both compositing for ~2 minutes, the exact combination that had killed three earlier builds on this machine in under a minute. Zero crashes; the GPU process gone count never moved. The Store then updated to 1.32885.1 (Aug 18), which produced two fatal 0x060C201E crashes within the next 2 days. Either 1.32352.1 got lucky, or something in the 1.32352.1 → 1.32885.1 delta re-broke it — it resisted a recipe that reliably killed 1.30096.x, so the diff may be worth a look.

Trigger correlation on our last four crashes — a second compositing surface, not the pane per se: each fired seconds after [Preview] Created browser preview while another GPU-compositing surface already existed (an HTML-file preview pane, the Chrome-extension bridge, or a second session's preview). Single-surface sessions run browser-heavy work for hours on the same builds.

| crash (2026, PT) | pre-existing surface(s) | preview created | GPU dead | Δ |
|---|---|---|---|---|
| 08-15 06:30:25 | html-preview + Chrome-ext bridge | 06:29:46 | 06:30:25 | 39 s |
| 08-15 19:34:07 | Chrome-ext bridge | 19:33:12 | 19:34:07 | 55 s |
| 08-19 12:06:03 | Chrome-ext bridge | 12:05:57 | 12:06:03 | 6 s |
| 08-19 20:28:31 | html-preview (local file) | 20:28:05 | 20:28:31 | 26 s |

Signature 1 — a sandboxed renderer fails to start 4 s before the GPU dies. In the 08-19 20:28 crash, unknown-window.log shows the probe signature from the OP (%c%d font-size:0;color:transparent NaN + the OTS WOFF 2.0 error) running at 20:22:13, 20:27:05, and 20:28:20 without incident while the html-preview was the only surface. The Browser preview was created at 20:28:05, and then:

20:28:27 [error] Electron sandboxed_renderer.bundle.js script failed to run
20:28:27 [error] TypeError: Cannot destructure property 'preloadScripts' of 'binding.startupData' as it is null.
20:28:31 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. (x2)
20:28:31 [warn] A valid external Instance reference no longer exists. (x2)

main.log, same second:

2026-08-19 20:28:31 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

The same probe burst that ran cleanly three times in the preceding six minutes became fatal only once the second surface existed — with a renderer that failed to initialize (binding.startupData null) in between. That TypeError hasn't appeared in this thread; it may help localize the race.

Signature 2 — a sometimes-tell minutes ahead: before 2 of the 4 crashes above, Chrome-extension computer tool calls began timing out at ~30 s ([claude-in-chrome] Tool call error: computer … after 30179ms — three of them across the 7 minutes before the 08-19 12:06 crash). The compositor was stalling before it died. Not reliable — absent before the 20:28 crash, and six such timeouts earlier that afternoon preceded no crash — but when the fatal path is coming, it has shown up early more often than not.

Repair on Win11 26200 (contrast with the Win10 reports): still recoverable, but takes two rounds. After the crash the package is unlaunchable (launch attempts produce zero log lines; no automatic remediation fired overnight). Settings → Repair: register w/ ForceTargetApplicationShutdown → 0x0 → RepairPackageOperation re-downloads the msix → its re-register fails 0x80073D02 ("apps need to be closed" — an instance left running) → a second Repair click → 0x0 → app launches. About 3 minutes hands-on once you know the sequence.

Memory ruled out at every crash (latest: 3.3 GB app tree, 10.6 GB system free). Happy to provide full log excerpts.

Cross-posting a resolution from #81836 (my own report of this same crash), since this is the larger thread and the switch method does not appear here yet.

Claude Setup.exe --exe forces the Squirrel (non-MSIX) install path, and on my machine it stops the crash. Same version before and after (1.34493.1), same page, same day, same GPU driver — packaging the only variable. Before: six fatal exitCode: 101457950 crashes, every one 3–10 s after a Cloudflare challenge page rendered in the in-app Browser pane. After: the same URL held on the same challenge for 70+ seconds with the app up, GPU pid unchanged, and nothing in the log.

Two details that may be useful here and that I could not find in this thread's 171 KB:

1. Microsoft-Windows-Security-Mitigations/KernelMode Event 36 fires at every crash second, showing WerFault.exe -u -p <gpu pid> launched and then blocked from NtFsControlFile. That is why no dump and no Application Error entry ever appears — WerFault is invoked and stopped, not skipped. Worth checking on other affected machines.
2. --exe as the installer switch itself. %TEMP%\ClaudeSetup.log confirms the path taken (No MSIX Claude packages found → Launching Squirrel installer).

Full evidence, the corrected mechanism, and the caveat about CoworkVMService not being re-created: #81836.

Same crash signature on a second machine — with two findings that may help triage: (1) event-log proof that the post-crash Settings "Repair" failure is cosmetic, and (2) a trigger that does not involve the in-app Browser pane: the GPU probe came from claude.ai's own Cloudflare Turnstile bot-check.

Environment

• Windows 11 Pro, build 10.0.26200
• Claude Code desktop app 1.34493.1 (MSIX x64, package Claude_1.34493.1.0_x64__pzs8sxrjxfjjc, SignatureKind: Developer, installed under C:\Program Files\WindowsApps)
• Two occurrences: 2026-08-21 14:00 and 2026-08-24 09:02 local time — the only abnormal process-exit events in main.log since 8/21, and each one produced a full "can't be opened → Repair fails → opens anyway" episode.

Crash signature

Final line the crashed instance ever wrote (%LOCALAPPDATA%\Claude\Logs\main.log) — same exit code as this issue, 101457950 = 0x060C201E:

2026-08-24 09:02:37 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

No graceful shutdown after this; the whole app dies.

Trigger: claude.ai's own Turnstile challenge, not the Browser pane

In both crashes, the seconds before death are a burst of blocked-permission warnings from a Cloudflare Turnstile challenge that claude.ai itself served inside the app's webview:

2026-08-24 09:02:36 [warn] Blocked permission check {
  permission: 'notifications',
  requestingOrigin: 'https://challenges.cloudflare.com/',
  requestingUrl: 'https://challenges.cloudflare.com/cdn-cgi/challenge-platform/h/b/turnstile/f/av0/rch/klahn/0x4AAAAAAADnPIDROrmt1Wwj/dark/fbE/new/normal?lang=auto',
  isMainFrame: false,
  topFrameUrl: 'https://claude.ai/api/challenge_redirect?to=https%3A%2F%2Fclaude.ai%2Fepitaxy%2Flocal_<redacted>'
}
2026-08-24 09:02:37 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

So the WebGL/WebGPU capability-probe theory in the OP fits, but users can hit this without ever opening the in-app Browser tab — a claude.ai/api/challenge_redirect → Turnstile interstitial is enough.

Post-crash package poisoning — Windows event-log timeline (2026-08-24, local time)

| Time | Log / Event | What happened |
|---|---|---|
| 09:02:37 | main.log | GPU crash, app dies |
| 10:23:41 | TWinUI 1621 | Launch attempt: activation "attempted … completed successfully" but no app process is created; nothing reaches main.log |
| 10:23:42 | AppModel-Runtime 67/68 | Failed with 0x5 modifying AppModel Runtime status (current 0x280002, desired 0x480002); package status settles at 0x2 (NeedsRemediation) |
| 10:25:20 | TWinUI 1621 | Second launch attempt, same silent non-start ("This app can't open") |
| 10:26:44 | AppModel-Runtime 68 | During Settings → Repair: status 0x2 → 0x0 — the block flag is cleared here |
| 10:26:45 | AppXDeploymentServer 8107/8104 | Illegal non-AppStore or non-AppInstaller package integrity validation attempted + Failed to set the Trust Label … 0x80070057 (Developer-signed sideload, so the Store remediation path can't run) |
| 10:26:45 | AppXDeploymentServer 401/404/419 | Register fails 0x80073D02: Unable to install because the following apps need to be closed Claude_1.34493.1.0_x64__pzs8sxrjxfjjc → Settings shows "repair failed" |
| 10:26:59 | AppModel-Runtime 201/210/211 | Manual relaunch works normally (AppX container + process created) |

Identical episode on 2026-08-21: crash 14:00:14 → four failed activations 14:00–14:05 → Repair failed 0x80073D02 at 14:06:59 → clean launch 14:23:21.

Two takeaways

1. The "repair failed" dialog is cosmetic in this flow. The NeedsRemediation flag is cleared before the register step trips over still-running package processes, which is why the app launches fine immediately after a "failed" repair. (Likely explains other reports of Repair "failing but fixing it".)
2. Recovery without Settings: kill leftover claude.exe / cowork-svc.exe, then Add-AppxPackage -Register -DisableDevelopmentMode "<InstallLocation>\AppxManifest.xml".

Possibly related: lingering processes also interact badly with staged auto-updates — AppXDeploymentServer 658 on 8/21 07:57: Marking package {Claude_1.34493.1.0…} for deferred registration because {Claude_1.32352.1.0…} is still running, so a crash plus zombie processes can additionally leave an update half-registered.

Happy to attach fuller event-log exports if useful.

Update from my Jul 31 report, same machine (Intel iGPU), now on 1.34493.1: the in-app Browser pane does not need to be opened by anyone. The app auto-seeds a browser preview for an active Claude Code session, and the GPU process dies about 5 seconds after the seed, every time. On a machine that hits this bug, an active Claude Code session is therefore a crash loop: relaunch, session resumes, pane re-seeds, dead again. Two full cycles inside ten minutes today.

Environment

• Windows 11 Home 10.0.26200, 32 GB RAM
• Claude desktop app 1.34493.1 (MSIX x64, Claude_pzs8sxrjxfjjc, SignatureKind Developer), Claude Code CLI 2.1.237
• GPU: Intel(R) Graphics (iGPU), driver 32.0.101.8860. For completeness, an Insignia USB3.0-to-dual-HDMI display adapter (driver 1.9.2501.1223) is also present, echoing @jkobber's virtual-adapter data point.
• The Claude Code session was doing WebFetch and local file reads only. No browser tools were invoked, and I never clicked the Browser tab.

Crash 1 (17:33 local): pane seeded by the app, GPU dead 6 seconds later

2026-08-24 17:33:53 [info] [Preview] Created session preview context {
  previewId: 'preview-local_cf31ae94-<truncated>',
  totalContexts: 1
}
2026-08-24 17:33:53 [info] [Launch] Updating active servers store { count: 1, servers: '[{"serverId":"browser-preview-1787610833900-0","name":"Browser","sessionId":"local_cf31ae94-<truncated>","port":0,"status":"running","startedAt":"2026-08-24T22:33:53.900Z","cwd":"<redacted>","previewId":"preview-local_cf31ae94-<truncated>","tabId":"seed"}]' }
2026-08-24 17:33:53 [info] [Preview] Created browser preview { serverId: 'browser-preview-1787610833900-0' }
2026-08-24 17:33:59 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

"tabId":"seed" is the app's own pre-seeding of the pane, roughly six minutes into the session. Between the seed and the crash the log holds only routine oauth lines.

Crash 2 (17:42 local): the loop

App restarted at 17:36:42, the same Claude Code session resumed, and five minutes later the app re-seeded a pane for that session. Identical sequence, five seconds to death:

2026-08-24 17:41:57 [info] [Preview] Created session preview context {
  previewId: 'preview-local_cf31ae94-<truncated>',
  totalContexts: 1
}
2026-08-24 17:41:57 [info] [Preview] Created browser preview { serverId: 'browser-preview-1787611317185-0' }
2026-08-24 17:42:02 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

Restart at 17:43:05.

Three data points for triage

1. "Avoid the in-app Browser pane" is not an available workaround for Claude Code users. The pane is created automatically for the session ("tabId":"seed"), with no user or agent action. Together with @horneliusdoteth's Turnstile finding above, there are now at least two no-user-action paths into this crash.
2. This trigger looks distinct from both previously reported paths. My log has zero WebGL/WebGPU warning lines before either death (unlike the OP's probe burst, and at 5-6 s the window is tighter than the OP's 15-36 s) and zero challenges.cloudflare.com requests anywhere in the file (unlike the Turnstile path). The last non-routine event before each crash is the pane creation itself.
3. Neither crash today wedged the package. Get-AppxPackage Status stayed Ok and manual relaunch worked on the first try with no Repair step, unlike my Jul 31 episode (deferred ForceTargetApplicationShutdownOption). The NeedsRemediation poisoning therefore looks contingent on which child processes linger after the crash, not on the GPU crash itself.

I am switching to launching via Invoke-CommandInDesktopPackage -PackageFamilyName Claude_pzs8sxrjxfjjc -AppId Claude -Command 'app\Claude.exe' -Args '--use-angle=d3d9' per @meigrafd and will report back whether the seeded pane still kills it. Full main.log excerpts available if useful.

Confirming this on multiple machines in our organisation, on a newer build than the OP, with a worse recovery path — details below in case they help triage.

Environment

Claude Desktop: 1.25927.0.0 (MSIX Claude_1.25927.0.0_x64__pzs8sxrjxfjjc)
OS: Microsoft Windows 11 Pro 25H2 (Build 26200.8973)
GPU: Intel(R) Graphics, driver 32.0.101.8724 (2026-04-16)
App: Claude_1.25927.0.0_x64__pzs8sxrjxfjjc
Affected: 2 of 4 machines in our fleet, all Intel iGPU — consistent with the OP's observation that this isn't vendor/discrete-GPU specific
Symptoms — same trigger as OP: crash during Browser-pane use shortly after navigation begins, then the app fails to relaunch ("Can't open this app" / Smart App Control dialog on launch attempts).

Where our experience diverges from the OP — recovery was harder:

A full system restart did not restore launch (OP reports reboots eventually worked; not for us)
Settings → Advanced options → Repair failed with "We couldn't repair this app. Try again in a bit." — including after Terminate + retry
Remove-AppxPackage -PreserveApplicationData was refused with HRESULT 0x80073CFA (flag only valid for development-mode packages, so there's no data-preserving removal path for store-channel installs)
Only plain Remove-AppxPackage + reinstall from claude.ai recovered the machine
So on this build the crash can leave the package in a state that is neither repairable nor gracefully removable — a full wipe/reinstall is the only recovery.

Confirmed mitigation (stable for us since): disable both Browser tools and Open links in Browser panel in Desktop settings, and route all browser automation through Claude Code CLI + the Claude in Chrome extension instead. No recurrence with the in-app browser disabled.

+1 to the OP's request for an exposed hardware-acceleration toggle or honoured ELECTRON_EXTRA_LAUNCH_ARGS — happy to test a build or flag set on an affected machine and report back. Also filing via /bug and business support referencing this issue.

Filed a separate report (#88818) that was just closed as a duplicate of this one — confirmed correct, identical exitCode: 101457950 signature. Adding the one detail here that doesn't overlap with the paths already documented above: my trigger was neither the WebGL/WebGPU probe burst nor the Cloudflare Turnstile path, and it wasn't the embedded Browser preview tab at all — it was the app's own main claude.ai window.

Timeline (UTC, from main.log):

• growthbook API call returned 521 (unrelated third-party service outage, coincidental timing)
• essentially the same second, the main window's own navigation hit .../api/challenge_redirect?to=... and failed with 403
• Turnstile iframe detected. Removing error overlay.
• three Blocked permission check entries against challenges.cloudflare.com (media/background-sync/notifications) over the next ~3s
• GPU process gone: { reason: 'crashed', exitCode: 101457950 }

No further log lines for ~14 hours until the next manual launch attempt.

Also checked the three native crash-evidence sources for this event: Crashpad (reports/ + metadata), the local Sentry queue, and Windows Event Viewer (Application + System, including GPU-driver TDR events) — all three are empty, no WER Application Error record either. That rules out a classic native crash and points toward an uncaught exception somewhere in the main process's own crash-handling path (Node's default is a clean process.exit(1) on an uncaught exception — no dump, no WER record, whole app still dies).

Recovery: a plain relaunch attempt immediately hit the Windows package-activation-failure dialog ("This app can't open. Claude has a problem. Reinstall this app from its original installation location, or contact your administrator.") — same dialog family already described in this thread. Reboot + reinstall (same downloaded installer, no new download) resolved it.

So this looks like a 4th no-user-action trigger path into the same crash signature: any navigation (main window included, not just the Browser pane) that lands on a Cloudflare challenge/Turnstile page.

🤖 Generated with Claude Code

Filed a separate report (https://github.com/anthropics/claude-code/issues/85701) that was just closed as a duplicate of this one.
I was able to overcome this issue by installing the desktop app again. Not necessarily to uninstall the old one. Run the install again solved the issue for me.

Generated by human :)

Adding a data point that I think widens this beyond the in-app Browser pane: on my machine the crash was triggered by Claude's own claude.ai/api/challenge_redirect Turnstile challenge in the main window, with no browser preview involved and no third-party site being visited. Same exitCode: 101457950 (0x060C201E) signature as this issue.

Environment

• Claude Desktop 1.32885.1 (MSIX Claude_pzs8sxrjxfjjc), Node 24.18.1
• Windows 10 Pro, build 19045 (most reports here are Windows 11)
• GPU: Intel HD Graphics 520 (integrated), driver 27.20.100.8854 — a third GPU vendor alongside the NVIDIA and AMD reports above
• CPU: Intel i3-6006U, 8 GB RAM

Log sequence — five seconds, main window, no Browser pane

From %APPDATA%\Claude\logs\main.log. The session URL 403s, the app retries its own main view, Cloudflare Turnstile is served by claude.ai, and the GPU process dies three seconds later:

2026-08-19 15:04:38 [info] Navigation to https://claude.ai/api/challenge_redirect?to=https%3A%2F%2Fclaude.ai%2Fepitaxy%2Flocal_2340dfd8-… failed with status code 403:
2026-08-19 15:04:38 [info] Main view load failure #1 (http_error); retrying in 13s
2026-08-19 15:04:40 [info] Turnstile iframe detected. Removing error overlay.
2026-08-19 15:04:40 [warn] Blocked permission check {
  permission: 'media',
  requestingOrigin: 'https://challenges.cloudflare.com/',
  requestingUrl: 'https://challenges.cloudflare.com/cdn-cgi/challenge-platform/h/g/turnstile/f/av0/rch/…',
  isMainFrame: false,
  topFrameUrl: 'https://claude.ai/api/challenge_redirect?to=https%3A%2F%2Fclaude.ai%2Fepitaxy%2Flocal_2340dfd8-…'
}
2026-08-19 15:04:41 [warn] Blocked permission check { permission: 'background-sync', requestingOrigin: 'https://challenges.cloudflare.com/', … }
2026-08-19 15:04:41 [warn] Blocked permission check { permission: 'notifications', requestingOrigin: 'https://challenges.cloudflare.com/', … }
2026-08-19 15:04:43 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

The log file ends on that line. No recovery attempt, no further entries — the app terminated and never wrote again. The package was then flagged Modified, NeedsRemediation; Repair did not fix it; only uninstall → reboot → reinstall did.

Why I think this matters for triage

Threads on this crash class (#81341, #83403) frame the trigger as the in-app Browser pane being pointed at a Cloudflare-fronted third-party site. That framing implies user-directed browsing is required, and it isn't. Here the challenge came from claude.ai's own endpoint during the app's session-load retry path — topFrameUrl is claude.ai/api/challenge_redirect, isMainFrame: false for the Turnstile iframe. Nothing was navigated to; the app served itself the challenge that killed it.

That is consistent with @harsh132's observation on #81341 (2026-08-25) that the crash does not require a browser preview, and it supplies a mechanism for that variant. If the root cause is the CIG / vk_swiftshader.dll signing-level issue documented in #81341, then any Turnstile render is sufficient — including the app's own auth challenge — and no amount of avoiding third-party sites will prevent it.

Second incident, same machine

It recurred on 2026-08-24 on version 1.34493.1, same outcome: unlaunchable package, Repair ineffective, full reinstall required. I have no logs for that one — the uninstall destroyed them, which is worth flagging in itself: the only fix for this bug deletes the evidence of it. Anyone asked to supply main.log after recovering will find it already gone. Copy %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs before uninstalling.

One earlier GPU crash on the same install carried a different signature — exitCode: -1073741571 (0xC00000FD, stack overflow) on 2026-08-17 — and was not fatal to the app. Noting it in case the two paths are related.

Impact

Second occurrence cost a working day on a commercial build: 76 minutes of live work destroyed outright, and the following day spent on recovery rather than the project. Both incidents required the full uninstall/reboot/reinstall cycle. Repair has never worked, on either occasion.

Update: I found a stable workaround and identified the failure chain more precisely.

Affected package:
Claude_1.34493.1.0_x64__pzs8sxrjxfjjc

This appears to be an MSIX packaging/code-integrity problem, not primarily a GPU driver problem:

• Get-AppxPackage reported "Modified, NeedsRemediation" and SignatureKind "Developer".
• Windows Code Integrity event 3010 reported that AppxMetadata\CodeIntegrity.cat could not be loaded, status 0xC000003A (path not found).
• The original signed MSIX downloaded from Anthropic contains app\vk_swiftshader.dll, but does not contain AppxMetadata\CodeIntegrity.cat.
• Code Integrity event 3033 then reported that claude.exe attempted to load vk_swiftshader.dll, but the DLL did not meet the required Microsoft signing level.
• Claude subsequently logged "GPU process gone" with exit code 101457950 (0x060C201E) and "CONTEXT_LOST_WEBGL".
• AppModel-Runtime then returned error 15612 because the package was in NeedsRemediation state.
• The package status could also become NeedsRemediation after local re-registration without launching Claude, so an application crash was not modifying the signed package files.
• Starting Claude with --disable-gpu only delayed the failure. It crashed again later and therefore was not a real fix.

Working workaround:

1. Install Anthropic's official Squirrel/Win32 build instead of the MSIX build. The official bootstrapper contains the following supported option:

.\ClaudeSetup.exe --exe

This installs Claude under:

%LOCALAPPDATA%\AnthropicClaude

1. After backing up any required package data, remove the broken per-user AppX registration:

Get-AppxPackage -Name Claude | Remove-AppxPackage

1. Start Claude using:

%LOCALAPPDATA%\AnthropicClaude\claude.exe

Validation:

• Get-AppxPackage -Name Claude now returns no package.
• Claude and its GPU process run from %LOCALAPPDATA%\AnthropicClaude, not WindowsApps.
• The Win32 executable has a valid Anthropic PBC Authenticode signature.
• Claude runs with the normal GPU process and without --disable-gpu.
• Since switching on August 23, there have been no new relevant Code Integrity events, AppModel errors, "GPU process gone" entries, or WebGL context-loss entries.

Caveat: Cowork reports "msix_required" in the Squirrel/Win32 build. Chat and Claude Code work, but Cowork currently requires the MSIX version.

Therefore, this is a reliable workaround, but Anthropic still needs to correct the MSIX packaging/signing problem.

Adding a reproduction case with logs.

Environment

• Claude desktop app (MSIX / Microsoft Store install): crashes observed on 1.34493.1; since updated to 1.37937.0 (not yet confirmed fixed or still crashing)
• Claude Code: 2.1.234–2.1.237 at time of crashes
• Windows 11 Home, build 26200
• Dual-GPU laptop: NVIDIA GeForce RTX 5060 Laptop GPU + Intel integrated graphics

Crashes — two identical events, whole app killed both times:

2026-08-21 23:23:20 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
2026-08-21 23:23:21 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

2026-08-25 11:34:32 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
2026-08-25 11:34:33 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

Notes that may help narrow it down

• Same exit code (101457950 / 0x060C201E) both times.
• NVIDIA driver was updated between the two crashes (March 2026 driver → July 2026 driver 32.0.16.1088) and the crash reproduced identically afterward, so GPU driver version appears ruled out on this machine.
• Both crashes occurred within ~1 second of a [PreviewContext] Blocked subresource to private-resolving host warning, i.e. while the built-in Browser/preview pane was rendering. That warning appeared 4 times total in the log; 2 of the 4 were immediately followed by the GPU crash.
• MSIX install, so the usual Electron mitigations aren't available: no hardware-acceleration toggle in settings, --disable-gpu prevents clean startup, and Windows per-app GPU preference doesn't apply.
• Crashpad wrote a dump for a related event on 2026-08-24 12:24 (%APPDATA%\Claude\Crashpad\reports), available on request.

Happy to provide full main.log excerpts or run a debug build if useful.

Additional evidence — crash now fires before any page loads (1.34493.1).

Reproduced across 3 machines (NVIDIA laptop on 1.32352.1, desktop with discrete GPU on 1.34493.1, and a VPS with virtual display): opening the in-app Browser pane kills the app. On 1.34493.1 the GPU process dies ~2 seconds after the preview is created, before the seed tab navigates anywhere, so page content (WebGL probes, Turnstile) can no longer be the trigger on this build:

10:59:31 [info] [Preview] Created browser preview { serverId: 'browser-preview-...', tabId: "seed" }
10:59:33 [info] GPU process gone: { type: 'GPU', reason: 'crashed', serviceName: 'GPU' }

14 "GPU process gone" crashes in the current main.log on that machine. Consistent with #81275's finding that WARP software rendering crashes identically — the defect is in the pane's own code path, and on newer builds it has moved earlier (pane open, not page render). Scheduled/unattended automation that depends on the pane is unusable. Also requesting #87659 be un-labeled "invalid" — it is this same bug.

Same signature, 4 occurrences across two app versions, on a machine with no physical GPU — plus a trigger correlation this thread hasn't recorded: Cloudflare Turnstile / anti-bot challenge content.

Environment: Windows 11 Pro 10.0.26200 as a Hyper-V Gen-2 guest (Hyper-V UEFI v4.1; Microsoft Hyper-V Video 10.0.26100.1150 + Microsoft Remote Display Adapter 10.0.26100.8972, Enhanced Session 3840×2160). No GPU partitioning, so Chromium's GPU process runs on software rasterization. x64, MSIX (Store) install, node 24.18.1.

Crashes 1–2 (v1.34493.1) — no Browser pane involved; challenge rendered in the main claude.ai view:

2026-08-21 14:00:10 [info] Navigation to https://claude.ai/api/challenge_redirect?to=... failed with status code 403: 
2026-08-21 14:00:11 [info] Turnstile iframe detected. Removing error overlay.
2026-08-21 14:00:11 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

2026-08-24 09:04:39 [info] Navigation to https://claude.ai/api/challenge_redirect?to=... failed with status code 403: 
2026-08-24 09:04:40 [info] Turnstile iframe detected. Removing error overlay.
2026-08-24 09:04:40 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

Crashes 3–4 (v1.37937.1, boot at 08:54:42 logged that version) — first Browser-pane open of the session, seed URL researchgate.net (challenge-fronted). 2/2 reproducible: the second was a retry of the identical call.

2026-08-26 08:33:07 [info] [Preview] Created browser preview { serverId: 'browser-preview-1787758387093-0' }
2026-08-26 08:33:09 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

2026-08-26 08:55:23 [info] [Preview] Created browser preview { serverId: 'browser-preview-1787759723907-0' }
2026-08-26 08:55:25 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

101457950 = 0x060C201E. Every time, the whole app died with the GPU process — main.log goes silent until manual relaunch. No Crashpad minidumps (%APPDATA%\Claude\Crashpad holds only settings.dat) and no Event Viewer / WER records, so the OS never sees a crash: the app's own reaction to GPU-process loss looks like the fatal step.

Two things this adds:

1. Turnstile challenge widgets run WebGL/canvas fingerprint probes, which fits the WebGL/WebGPU trigger suspected in #81698 — and gives it a common, unavoidable real-world source. Crashes 1–2 had no Browser pane at all, so the Browser pane is a delivery mechanism, not the cause; any surface rendering a challenge suffices.
2. This guest exposes no physical GPU, yet still dies with the same code. That rules out vendor driver bugs for this signature (consistent with the no-NVIDIA-TDR finding in #81698) and points at the software-rasterization path — or the app's handling of the GPU process exiting.

Sentry event IDs from the boots immediately following the Aug 26 crashes: 5092340dbdce468d9b766bb66ccc445d, 4d0a3d9bbbd1413a93d26ba0f8c19f3a.

Follow-up to my comment above: still reproduces on 1.37937.1 (updated from 1.34493.1 yesterday), and I can now add a consistent trigger signature.

2026-08-26 14:05:45 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
2026-08-26 14:05:46 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

That makes 3 crashes out of 3 (8/21 on 1.34493.1, 8/25 on 1.34493.1, 8/26 on 1.37937.1) where the GPU crash came ~1 second after the same [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' } warning — i.e. a page in the built-in Browser pane XHR-ing a private-resolving host and getting blocked. The warning has appeared 5 times total in my logs; 3 of the 5 were immediately followed by the crash.

Context for today's event: the Browser pane had a live third-party site loaded (login.squarespace.com, opened at 13:28; earlier [PreviewContext] onBeforeRequest mainFrame from untracked webContents — blocking { origin: 'https://login.squarespace.com' }). Crashes have only ever occurred with live external sites in the pane — local static files have been fine.

Also of note: after the auto-restart at 14:08:28, the main webview render process died again 16s later (Main webview render process gone: { reason: 'killed', exitCode: 1 }, Sentry eventId b49ecdf107624a86a09e9bb19549b1c4) before a second restart came up cleanly.

Same environment as my previous comment (Windows 11 build 26200, dual-GPU NVIDIA RTX 5060 Laptop + Intel, MSIX install).

Same crash on 1.34493.1.0, with the AppX event-log forensics of the "repair" fallout in case it helps.

Environment: Claude Desktop 1.34493.1.0 (MSIX Claude_1.34493.1.0_x64__pzs8sxrjxfjjc), Windows 11 Pro build 26200, Electron runtime Chrome 148.0.7778.280. GPUs: NVIDIA GeForce RTX 5080 (driver 32.0.15.9649) + AMD Radeon iGPU (32.0.13066.12), plus three virtual display adapters installed (Meta Virtual Monitor, Virtual Desktop Monitor, spacedesk).

Trigger: clicking a link in chat output that opens a https://www.cars.com/vehicledetail/<uuid>/ page in the in-app Browser tab (heavily bot-detection/fingerprinting-instrumented site). The whole app terminates within ~2 seconds of the pane opening — faster than the 15–36 s in the OP, but the same exit code. Hit at least three times here (2026-08-10, 2026-08-25, 2026-08-26). Each time, relaunching is blocked by the Windows "repair this app" prompt; Settings → Apps → Claude → Repair restores it.

Main log ends at the crash (the log file's last-write timestamp is the crash moment):

2026-08-10 15:45:52 [info] Failed to set title bar overlay, this is probably expected
2026-08-10 15:45:53 [info] using oauth config { … }        <- new pane/webview initializing
2026-08-10 15:45:54 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}
(end of file)

No OS-side crash artifacts, matching earlier reports: no Application-log Event 1000/1001, nothing in %LOCALAPPDATA%\CrashDumps, Crashpad db empty (settings.dat only), Sentry session not marked crashed.

AppX fallout timeline (Microsoft-Windows-AppXDeploymentServer/Operational), 2026-08-26:

14:02:54  app dies (whole process tree gone)
14:03:02  [603] RegisterByPackageFullName on Claude_1.34493.1.0 with Options
          ForceTargetApplicationShutdownOption, RepairAppRegistration…   <- backs the "repair" prompt
14:03:35  [9648/9650] TerminateSingleService for update … CoworkVMService terminated
14:03:35  [400] Register operation finished successfully
14:03:46  [603] second identical RegisterByPackageFullName round
14:04:57  app relaunches OK

Previous day was the same cycle but with an explicit user-side repair: crash ~12:07:20, RepairPackageOperation at 12:08:22 (step 1 re-downloads the full .msix from downloads.claude.ai), healthy again at 12:08:56.

Two details corroborating the file-lock discussion above:

• Auto-update registrations fail while the app is running — 00:59:29 [401/404] … 0x80073D02: Unable to install because the following apps need to be closed Claude_1.34493.1.0… — so on a long-running app there is almost always a staged, deferred update pending, and it collides with the post-crash remediation window.
• The deployment log here has days of event-471 spam, retrying every ~6 minutes to delete icudtl.dat / v8_context_snapshot.bin of two older versions stuck under WindowsApps\Deleted (error 0x12C, sharing violation). Something in the process tree keeps old-version Chromium files mapped long after updates, which fits the observation that cowork-svc.exe survives the crash and holds locks that block automatic repair.

Follow-up to my 2026-08-20 comment, same machine, now on 1.34493.1. Three things: a measurement hazard that affects everyone collecting logs right now, a crash on the challenge_redirect path with the Code Integrity event attached, and the running correlation total.

1. The log directory moved in 1.34493.x — the old file is still there, frozen

This one first, because it silently invalidates data collection. On update to 1.34493.0, the app stopped writing to the path most of this thread quotes and started a new file elsewhere:

%APPDATA%\Claude\logs\main.log        last line  2026-08-21 08:23:15
%LOCALAPPDATA%\Claude\Logs\main.log   first line 2026-08-21 08:23:21

Six seconds apart, and the old directory is left in place with all its files intact. Nothing indicates the handover. My own daily tracker read the old path for six days and reported "no new crashes" the whole time — while a crash sat in the new file. I only caught it because the Event Log disagreed with the log file.

If you are on 1.34493 or later and reporting that a build stopped crashing, please check which file you read. Grepping %APPDATA% after the update returns a frozen snapshot, not a quiet machine.

2. A crash on @philipandrewswork's challenge_redirect path — with the 3033 that path was missing

@philipandrewswork reported the crash arriving through Claude's own Turnstile challenge in the main window, no Browser pane involved. Same thing here on 2026-08-22, and this time the Code Integrity side is recorded:

06:00:24 [warn] Blocked permission check {
  permission: 'notifications',
  requestingOrigin: 'https://challenges.cloudflare.com/',
  requestingUrl: '.../cdn-cgi/challenge-platform/h/b/turnstile/f/av0/rch/...',
  topFrameUrl: 'https://claude.ai/api/challenge_redirect?to=https%3A%2F%2Fclaude.ai%2Fepitaxy%2Flocal_...'
}
06:00:25 [warn] Blocked permission check { ... same, x2 ... }

06:00:25  Event 3033: claude.exe attempted to load
          ...\Claude_1.34493.1.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll
          that did not meet the Microsoft signing level requirements.

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

Details that matter:

• No Browser pane was ever opened. The only Created browser preview in that entire log file is the next day, 2026-08-23 08:15:26. This was not @lamchiman3388's seeded-pane path either — there was no seed before the death.
• Nobody was at the machine. 06:00 local, and the app stayed dead until Starting app at 09:16:37 — 3 h 16 min of silent downtime. The line before the permission checks is [WarmLifecycle:session] Starting idle timeout.
• No package wedge. Get-AppxPackage Status stayed Ok, no Repair needed — matching @lamchiman3388's point 3 that the NeedsRemediation poisoning is contingent, not intrinsic.

3. Running total: 9 GPU deaths, 9 Code Integrity events, matched 1:1 across four builds

Every GPU process gone on this machine since July, against every Event 3033 where the process is claude.exe and the file is app\vk_swiftshader.dll:

| Build | Deaths | Matched 3033 | Max Δ |
|---|---|---|---|
| 1.24012.9 | 1 | 1 | 1 s |
| 1.30096.5.0 | 5 | 5 | 1 s |
| 1.32885.1.0 | 2 | 2 | 0 s |
| 1.34493.1 | 1 | 1 | 1 s |

9 / 9, no unmatched entry on either side. Same DLL, same signing-level message, same exit code, four builds, three log-path generations.

4. On whether these are separate roads

@lamchiman3388 argued their seeded-pane deaths look distinct — no WebGL lines, no challenges.cloudflare.com, tighter window. I think that is right about the trigger and wrong about the failure. Three visibly different entry paths have now been reported — a WebGPU probe on a third-party page, the app's own "tabId":"seed" pane, and claude.ai's own Turnstile challenge — and on this machine the two I have logs for both terminate on the same blocked vk_swiftshader.dll load at GPU sandbox init.

That would mean the trigger inventory is open-ended and not worth chasing to completion, because anything that forces GPU-process initialisation reaches the same block. It also means no user-side avoidance rule can cover it: I have been deliberately avoiding the Browser pane since 2026-08-16, and it made no difference to this crash.

The corollary for triage is the uncomfortable one: there is no user action to instrument. The remaining fixes are still the two from my earlier comment — pick up the Chromium change so a blocked SwiftShader load degrades instead of killing the process, and stop a GPU-process death from taking the app shell with it.

_{Windows 11 Home 26200.9168 · AMD Radeon(TM) Graphics · no Vulkan ICD registered · Smart App Control off, user-mode WDAC not enforced · MSIX Claude_pzs8sxrjxfjjc · thanks @BindingEnergy and @ventocamp-bit for the ClaudeSetup.exe --exe route — evaluating it, blocked for now by Cowork needing MSIX}

Same crash on Snapdragon X Plus hardware - adding a data point since most ARM64 reports are X Elite.

Environment: Claude Desktop 1.37937.1 (arm64 MSIX / Store), CCD 2.1.246, Windows 11 Home 26200, Lenovo IdeaPad Slim 5 14Q8X9, Snapdragon X Plus X1P42100, Adreno X1-45.

Key finding: crash persists on BOTH Adreno driver 31.0.128.0 (Oct 2025) and 31.0.148.0 (latest Qualcomm generic) - a driver update does not help.

Pattern: GPU process gone: exitCode 101457950 x15 in 4 days (Aug 24-27); reproduced within 2 minutes after a clean reboot; the whole app dies; some crashes leave the package unlaunchable until Settings > Apps > Repair (matches OP). One crash logged exitCode 34 instead. 32 GB RAM with >12 GB free, so not memory pressure. Plain text chat is stable; heavy rendering (in-app browser / preview) correlates with crashes. Full logs available on request.

Retraction: the isHardwareAccelerationDisabled: true workaround I posted in #81159 is wrong, and on this crash path it is an accelerant rather than a mitigation.

Written by Claude (Claude Code) and posted on behalf of @odedbahiri-arch, who asked for the correction after re-reading this thread.

On 2026-07-28 I posted this comment recommending "isHardwareAccelerationDisabled": true in %APPDATA%\Claude\claude_desktop_config.json, and stated it "stops the crashes entirely — no recurrence since applying it." That comment is still reachable and still being cited. It should not be followed.

Why it was wrong

1. The evidence never supported the claim. "No recurrence since applying it" was measured over a window in which no trigger fired at all. That is the absence of a probe, not the presence of a fix — I reported a zero-event window as proof of a mitigation.

1. It has the mechanism backwards. Per @yashacleary-bot's Code Integrity forensics and @botarhythm's follow-up, the crash is Event 3033 blocking the bundled app\vk_swiftshader.dll in the packaged GPU process, which runs under MicrosoftSignedOnly=ON / AllowStoreSignedBinaries=OFF. Disabling hardware acceleration makes SwiftShader Dawn's only adapter — it forces the app down the exact path that Code Integrity is blocking. Anyone setting this flag to escape the crash is making the blocked DLL the only route to a working graphics stack.

1. It was rebutted twice with better data and I did not come back to correct it. @Tragen reported 2/2 reproductions on AMD with the flag set, and showed that app.disableHardwareAcceleration() only reaches renderer processes — the GPU process still starts with hardware GL, which is where the crash occurs. @rex047 reported the same failure independently. Both rebuttals stand; my comment does not.

What that comment got right, and what I misread about it

The renderer-side signature is real and still useful for identifying affected machines: ~19 WebGL: INVALID_ENUM: getInternalformatParameter warnings inside one second, then requestAdapter()/powerPreference, then CONTEXT_LOST_WEBGL, roughly one second before the GPU death — and it lands in logs\unknown-window.log, not main.log, which records only the death with no apparent cause. @pylonsolus independently logged the same ~19-warning burst.

What I got wrong was the direction of causation. That burst is a WebGPU/WebGL capability probe touching the blocked SwiftShader path — it is the thing that trips the fault, not the fault itself. I treated a tightly correlated symptom as a root cause, and then built a workaround on top of that misreading.

What actually holds

Leaving the MSIX for the Win32/Squirrel build — Claude Setup.exe --exe, or winget install Anthropic.Claude (the same downloads.claude.ai/releases/win32/x64/… channel) — removes the packaged-process signing enforcement entirely. Independently confirmed by @yashacleary-bot, @BindingEnergy and @ventocamp-bit, with no recurrence reported since. Caveat already noted in-thread: Cowork reports msix_required on that build.

Apologies to anyone who set that flag on the strength of my comment.

Same end state, different trigger: MSIX auto-update finalization also produces this — with evidence the lock is a kernel-held job object that only a reboot clears

Adding a data point to this issue: I hit the identical unlaunchable state (Modified, NeedsRemediation → "Can't open this app / Repair" → 0x80070020) on two consecutive auto-updates, with no crash involved — the trigger was Windows finalizing a staged update while the app was running.

Environment: Windows 11 Pro 26200, Claude Desktop 1.37937.1.0 → 1.37937.3.0 (MSIX pzs8sxrjxfjjc). A third-party enterprise AV/EDR is installed but was ruled out (zero detections logged across the incident window; first post-reboot launch succeeded with protection fully on) — consistent with this issue reproducing without third-party AV.

Timeline (Aug 27, from event logs):

• 02:04 — update 1.37937.3.0 staged while 1.37937.1.0 was running
• 12:20 — servicing failed with 0x5 and destroyed the running app container mid-session (app "suddenly closed"); package left Modified, NeedsRemediation
• 12:20–12:46 — ~20 relaunch attempts, all failing with 0x80070020
• 12:48 — OS reboot → 12:50 clean launch

Identical pattern the previous morning (Aug 26, 08:10–08:36, 22× the same event) against 1.37937.1.0 — so it reproduces on every update on this machine.

Evidence the blocker is a stale kernel job object, not a user-mode file lock:

• Every relaunch logs AppModel-Runtime Event ID 215: 0x80070020: Cannot create the Desktop AppX container ... because an error was encountered converting the job (plus ID 208 [LaunchProcess]).
• Registering the already-staged new version (Add-AppxPackage -Register) does clear NeedsRemediation (package Status: Ok, no data loss) — but launch still fails with the same 0x80070020, so the package state and the launch blocker are two separate problems.
• Sysinternals handle64 sweep over Container_Claude* job objects and package folders found zero user-mode handles; killing all claude processes and restarting vmcompute (Host Compute Service) did not help (verified live — still failing 2 minutes before the reboot).
• Only a full OS reboot cleared it. Meanwhile AppXDeploymentServer logged Event ID 493 every ~6 min for hours (a file under WindowsApps\Deleted could not be deleted) — also cleared by reboot.

This suggests the update/crash path leaves the old version's sandbox job (HCS/CoworkVMService) alive kernel-side, and the new container creation collides with it.

Happy to share filtered .evtx exports (AppModel-Runtime/Admin + AppXDeploymentServer/Operational covering both days) through the support channel — I'll reference this issue number in the ticket.

Adjacent trigger, same systemic problem (surviving Claude processes breaking MSIX servicing): #90147 documents the auto-update deferral race with chrome-native-host.exe as the lock holder (event 5224 → 0x80073D05/0x80073CF6), plus DACL evidence that CoworkVMService recovery actions can only be set by NT SERVICE\AppXSvc — may help cluster these for triage.

Still present on 1.37937.3.0 (Windows 11, Intel Iris Xe). Two crashes 45 minutes apart today, plus three data points that may help.

Same signature as the original report:

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

Environment: Windows 11 Home build 26200, Intel Iris Xe integrated graphics (so this is not NVIDIA-specific), MSIX package. Versions seen here: 1.24012.11.0, 1.26832.0.0, 1.34493.1.0, 1.37937.3.0. All four crash identically. Five incidents since 2026-08-03.

1. The GPU crash and the MSIX corruption are separable.

Both of today's crashes left Get-AppxPackage -Name Claude reporting Status : Ok. No Repair was needed and a plain relaunch worked. My earlier incidents on 1.24012 and 1.26832 did corrupt the package every time, so something changed between those builds and 1.37937. Worth knowing if the two symptoms are being tracked as one bug.

2. The preview pane is kept warm across a crash and re-arms the trigger.

Today's sequence: crash at 11:04:41 with x.com content loaded in the pane. Relaunched at 11:09:59. Nobody browsed anything afterwards. [WarmLifecycle:preview] entries then show previews being kept warm on 1800-second idle timers for three sessions, and at 11:49:15 the app died again with the same exit code, preceded at 11:49:13 and 11:49:14 by the same x.com Content Security Policy and GSI_LOGGER console errors that preceded the first crash.

The page that killed the app survived the crash, came back with the restart, and killed it again. If that reproduces, clearing preview state on an abnormal exit would stop the repeat crashes even before the GPU issue itself is fixed.

3. The log directory moved at 1.37937.x, which silently invalidates existing diagnostics.

Logs are now written to %LOCALAPPDATA%\Claude\Logs\. The old %APPDATA%\Claude\logs\ directory is left in place, still populated, frozen at its last write before the update. Anything checking the old path after updating reports a healthy app with zero crashes indefinitely. Two of my crashes were invisible for this reason. Anyone collecting logs for this issue should confirm which directory they are reading.

Workaround status.

--disable-gpu --disable-gpu-compositing --disable-software-rasterizer --disable-features=Vulkan still works on 1.37937.3.0.

One practical warning for anyone running a launcher script for those flags: if it hard-codes the versioned path C:\Program Files\WindowsApps\Claude_<version>_x64__<hash>\app\Claude.exe, then every app update breaks it silently. The app reverts to running unprotected and nothing indicates it. Resolve the path at launch time via Get-AppxPackage -Name Claude instead. That is exactly how I ended up with two unprotected crashes today after an auto-update two days earlier.

Per #82967, Settings → Claude Code → Browser disables Browser tools entirely and removes the trigger, at the cost of the in-app browsing and preview feature.

Additional data point, and a causal link to the MSIX-corruption family (#90147, this machine): same crash signature during that incident, on different hardware again — NVIDIA GTX 680 + Intel HD 4000, Windows 11 Pro build 26200, session often rendered over RDP (Microsoft Remote Display Adapter).

2026-08-26 18:43:43 [info] Received permission response …: always (tool: browser:open_site)
2026-08-26 18:43:46 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

Three seconds after a workflow opened a site in the in-app Browser pane, the GPU process died and took the app with it; main.log is then silent for 16 minutes until the next launch attempt. The app was 1.37937.1 at the time, with 1.37937.3 staged but deferred (deferral events had fired at 17:12). The relaunch/repair attempts then collided with the deferred update and a surviving chrome-native-host.exe file lock, producing the Modified/NeedsRemediation outage in #90147. So on this machine the two families chain: an #80444-style crash is the entry point, and a pending deferred MSIX update is the amplifier that turns a crash into a multi-hour brick.

Can also confirm @RubberDuckBill's log-relocation observation on 1.37937.x: %LOCALAPPDATA%\Claude\Logs\ is the live directory; %APPDATA%\Claude\logs\ sits frozen at its pre-update last write. The crash above is visible only in the new location.

Windows-on-ARM confirmation — 9 crashes across 5 app versions and 2 GPU drivers, every one 3–9 seconds after a browser preview opened

Confirming this on ARM64 with data showing the crash is independent of GPU vendor, driver version, and app version — and adding what I believe is the strongest correlation datum in this thread: in 9 of 9 crashes, [Preview] Created browser preview appears in main.log 3–9 seconds before GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }.

Environment: HP OmniBook 5 16-bf0xxx (Snapdragon X Plus, Adreno X1-45), Windows 11 Home 10.0.26200 ARM64, Claude Desktop MSIX ARM64.

| # | Timestamp | App version | Adreno driver | Preview→crash gap / note |
|---|---|---|---|---|
| 1 | 2026-08-16 08:08 | 1.30096.5 | 31.0.148.0 | 9 s — unattended scheduled-task session |
| 2 | 2026-08-19 04:39 | 1.30096.5 | 31.0.148.0 | 9 s — overnight interactive session |
| 3 | 2026-08-19 12:07 | 1.32885.1 | 31.0.148.0 | 7 s |
| 4 | 2026-08-19 15:06 | 1.32885.1 | 31.0.148.0 | 9 s |
| 5 | 2026-08-23 15:16 | 1.34493.1 | 31.0.152.1 | 5 s — unattended scheduled-task session |
| 6 | 2026-08-25 12:05 | 1.34493.1 | 31.0.152.1 | 3 s — unattended scheduled-task session |
| 7 | 2026-08-26 17:21 | 1.37937.1 | 31.0.152.1 | 6 s — unattended scheduled-task session |
| 8 | 2026-08-27 15:00 | 1.37937.3 | 31.0.152.1 | 8 s — unattended scheduled-task session |
| 9 | 2026-08-27 17:35 | 1.37937.3 | 31.0.152.1 | 3 s — unattended scheduled-task session |

(Also 3× exitCode: 34 GPU exits on 2026-08-19 15:44–15:50 during the GPU driver swap — likely unrelated churn, listed for completeness.)

Additional observations:

• Unattended/autonomous sessions are a major vector. At least 6 of the 9 previews were opened by cron-scheduled task sessions running unattended (their spawn is logged by [CCDScheduledTasks] minutes before each crash); crash times track the cron slots (8am/12pm/3pm/6pm/11pm) and their catch-up bursts after relaunch. This matches the "overnight workflow re-opened its Browser tab" reports above — and because the app both restores panes on relaunch AND fires missed scheduled runs at startup, a crash re-arms itself within minutes of relaunch (the crash-loop pattern).
• A pane parked at about:blank did NOT crash (survived 10+ min on 2026-08-27 17:49); only previews that proceed to load content kill the GPU process — consistent with the WebGL/WebGPU-probe theory in the OP.
• Ruled out on this machine: GPU driver (identical crashes on Adreno 31.0.148.0 and 31.0.152.1, the latter installed via Qualcomm's Snapdragon Control Panel mid-series); app version (five releases, 1.30096.5 → 1.37937.3); memory pressure (telemetry logged ~14 GB free one minute before a crash); OS-level driver resets (zero TDR/Event 4101 entries in the System log across the whole period — the failure is entirely inside the app's GPU process).
• Each crash flagged the MSIX package Modified/NeedsRemediation (auto-repair observed via ClaudeSetup.log), as others report in #84992.
• Log locations for anyone else digging: apps ≤1.32885.1 wrote %APPDATA%\Claude\logs\main.log; ≥1.34493.1 write %LOCALAPPDATA%\Claude\Logs\main.log.

Workaround holding so far: Browser tools disabled in Settings (per #82967) on 2026-08-27 — the same scheduled sessions have since run without creating previews and without crashes. --disable-gpu remains unavailable on MSIX (no WindowsApps alias on 1.37937.3; Invoke-CommandInDesktopPackage fails as in #68049).

Requested fix (echoing others): software-rendering fallback when the GPU process dies repeatedly, or a persisted disable-hardware-acceleration setting — and ideally scheduled-task sessions not opening previews they can't render safely.

Happy to provide full main.log excerpts or WER/crashpad dumps on request.

Additional data point from a different GPU vendor (Intel), with local forensics
suggesting the crash is app/Viz-side and independent of driver and rendering mode:

Environment

• Claude Desktop 1.37937.3 (Electron 42.10.0), Windows 11 Home build 26200, MSIX install
• GPU: Intel Arc 140V (Lunar Lake iGPU, 16GB); reproduced on drivers 32.0.101.8132 and 32.0.101.8991

Signature — identical in all 6 crashes over 7 days of logs:
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 (0x060C201E) }
in main.log, after which the whole app dies immediately (no GPU-process relaunch attempt logged).

Key observations

1. Crashes occur with hardware acceleration ON and OFF. One crash (2026-08-28 20:40 JST) happened while isHardwareAccelerationDisabled: true was applied and the GPU process was confirmed running with --use-angle=d3d11-warp-webgl — so WARP reduces frequency (~2.1/day → ~0.2–0.7/day) but does not eliminate it. Updating the Intel driver had no effect (crashed 4 minutes after startup on the new driver).
2. 5 of 6 crashes occurred 3–49 seconds after a browser preview WebContentsView was created/warmed up; the 6th followed a Cloudflare Turnstile iframe render in the claude.ai webview. In one case a CDP screenshot request failed with UnknownVizError at the same moment (matches #82967).
3. A rare warning [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' } appeared only 5 times in 8 days of logs — all 5 within 1–31 seconds before a crash. Might help locate the code path.
4. No OS-level GPU evidence: zero TDR (Display 4101), zero WHEA, no WER entry for Claude.exe. Crashpad writes no dump for this death (exit-style, not an exception), so main.log is the only artifact.
5. The built-in gpu-recovery never fires because observed crash intervals (15+ min) never satisfy the 5-crashes-in-5-minutes threshold.
6. Possibly relevant: frequency increased after auto-update 1.34493.1 → 1.37937.x (zero crashes in 3.8 days on 1.34493.1 + WARP; reproduced on 1.37937.3 + WARP).

Happy to provide sanitized logs if useful.

Same crash here, with what I think is the actual mechanism — plus a warning that
the --disable-gpu workaround in the OP makes things worse on machines with
Memory Integrity (HVCI) enabled.

Root cause: Code Integrity rejects vk_swiftshader.dll from inside the package

Every GPU-process death on my machine is accompanied, in the same second, by
a Code Integrity block of the app's own SwiftShader DLL
(Microsoft-Windows-CodeIntegrity/Operational, event 3033):

Code Integrity determined that a process
(\Device\HarddiskVolume3\Program Files\WindowsApps\Claude_1.37937.3.0_x64__pzs8sxrjxfjjc\app\claude.exe)
attempted to load
\Device\HarddiskVolume3\Program Files\WindowsApps\Claude_1.37937.3.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll
that did not meet the Microsoft signing level requirements.

Two examples, matched to the app log to the second:

| App log (%LOCALAPPDATA%\Claude\Logs\main.log) | CodeIntegrity 3033 |
|---|---|
| 2026-08-27 21:45:20 GPU process gone: exitCode 101457950 | 2026-08-27 21:45:20 vk_swiftshader.dll |
| 2026-08-28 10:44:34 GPU process exited unexpectedly: exit_code=101457950 | 2026-08-28 10:44:34 vk_swiftshader.dll |

The reason the DLL fails the signing check appears to be that the package's own
catalog does not load — event 3010:

Code Integrity was unable to load the
\Device\HarddiskVolume3\Program Files\WindowsApps\Claude_1.37937.3.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat
catalog. Status 0xC000003A.

This looks specific to the Claude package, not to my machine: in a 10-day
window of that log, 27 of 27 catalog-load failures name the Claude package.
No other MSIX/Store app on this machine produces one.

This matches electron/electron#52700 (Windows MSIX/AppX: Chromium GPU process
killed when Code Integrity rejects vk_swiftshader.dll).

Why --disable-gpu is the wrong workaround here

--disable-gpu forces the SwiftShader path — which is exactly the blocked one.
Launching via
Invoke-CommandInDesktopPackage -PackageFamilyName Claude_pzs8sxrjxfjjc -AppId Claude -Command <full path>\app\Claude.exe -Args '--disable-gpu'
the app died in about four minutes with a fatal variant instead of the usual
recoverable one:

GPU process exited unexpectedly: exit_code=101457950
GPU process launch failed: error_code=18     (x5)
FATAL:gpu_data_manager_impl_private.cc(418)  GPU process isn't usable. Goodbye.

With hardware acceleration left on, SwiftShader is only reached as a fallback,
so crashes are less frequent. Anyone with HVCI on should not use this flag.

(Two gotchas if you do reproduce it this way: Invoke-CommandInDesktopPackage
fails with 0x800704C7 when run elevated, and also when -Command is given a
relative path such as app\Claude.exe — it needs the full path.)

The Repair loop is downstream of this

Confirming the OP's second bug: each crash leaves the package flagged, and the
next launch is refused until Settings > Apps > Claude > Advanced options >
Repair. On my machine AppXDeploymentServer/Operational logs 8107
(Illegal non-AppStore ... package integrity validation) and 8104
(Failed to set the Trust Label ... 0x80070057) around those failed launches.
Reinstalling from the Store does not help — it comes back at the next GPU crash.

Suggested fixes

1. Ship the MSIX with a catalog that actually validates (CodeIntegrity.cat

currently fails with 0xC000003A), or sign vk_swiftshader.dll to the
signing level HVCI requires. That removes the crash for everyone with Memory
Integrity enabled — which is the Windows 11 default on many OEM machines.

1. Until then, treat "GPU process unusable" as recoverable rather than calling

FATAL and taking the whole app (and any running sessions) down.

1. Update the workaround in this issue: --disable-gpu is counterproductive on

HVCI machines.

The only local mitigation I found is turning Memory Integrity off
(Windows Security > Device security > Core isolation), which is a security
trade-off users should not have to make.

Environment

• Claude Desktop 1.37937.3.0 (MSIX), SignatureKind: Developer
• Windows 11 Home 26200, Memory Integrity / HVCI enabled
• Hybrid graphics: NVIDIA RTX 5060 Laptop (32.0.16.1088) + AMD Radeon 610M
• GPU exit code 101457950 = 0x060C201E, identical across all occurrences
• 10 GPU-process deaths logged in ~16 hours of normal use

First, thank you to the Anthropic team for Claude and for the ambitious work behind Claude Desktop and Cowork. These tools are genuinely valuable for long-running research and document workflows. I am sharing this consolidated evidence in the spirit of contributing to the improvement of an otherwise excellent product.

High-severity impact

For affected users, this is a high-severity reliability issue, not merely an occasional rendering glitch:

• one internal Browser Preview failure terminates the entire desktop host;
• unrelated concurrent sessions and background jobs are interrupted;
• completed work can be lost when long-running tasks are not checkpointed;
• the MSIX package may become unlaunchable and require Repair or reinstall;
• Repair/re-registration restores launchability but does not remove the trigger, so the failure can recur immediately.

Newer affected build and deterministic recurrence

Confirmed on Claude Desktop 1.40609.0, Windows 11 build 26200, 32 GB RAM, AMD Ryzen 5 8600G / Radeon RX 9060 XT, during a long-running document-retrieval workflow.

First occurrence:

• 15:17:12 — [Preview] Created browser preview
• 15:17:23 — Code Integrity Event 3010 ×3: AppxMetadata\CodeIntegrity.cat could not be loaded (0xC000003A), plus Event 3033 blocking vk_swiftshader.dll
• 15:17:24 — GPU process crashed with 101457950 / 0x060C201E; the desktop app terminated and would not relaunch normally

After Windows Repair/re-registration, the same sequence immediately recurred:

• 15:25:14 — Browser Preview created
• 15:25:26 — identical Code Integrity events
• 15:25:27 — identical GPU-process crash

This adds a newer-build AMD reproduction and shows that Repair/re-registration does not remove the underlying failure condition. The same-second Code Integrity correlation is deterministic on this machine. I am not claiming that correlation alone settles whether Code Integrity is the primary cause or a fallback-path symptom; comments in this cluster contain evidence for both interpretations.

Scale of the report cluster

A repository-wide check today found 84 closed issues containing the exact decimal signature 101457950. Of those, 76 are formally marked duplicate. After excluding one obvious unrelated search hit, 75 duplicate-closed reports remain materially connected to this GPU/Browser Preview/MSIX failure family. Adding two directly related duplicate reports that use descriptive or hexadecimal wording rather than the decimal code gives at least 77 verified duplicate-closed reports.

Search used for the decimal signature:

https://github.com/anthropics/claude-code/issues?q=repo%3Aanthropics%2Fclaude-code+101457950+is%3Aclosed

This is a conservative triage signal, not a claim that every report has an identical root cause or represents a unique user. Nevertheless, the volume, cross-vendor reproduction, repeated work loss, and persistence across many app versions support high-priority ownership.

<details>
<summary>Verified duplicate-closed issue compilation (77 URLs)</summary>

• https://github.com/anthropics/claude-code/issues/77768
• https://github.com/anthropics/claude-code/issues/80247
• https://github.com/anthropics/claude-code/issues/80306
• https://github.com/anthropics/claude-code/issues/80468
• https://github.com/anthropics/claude-code/issues/80483
• https://github.com/anthropics/claude-code/issues/80689
• https://github.com/anthropics/claude-code/issues/80978
• https://github.com/anthropics/claude-code/issues/80999
• https://github.com/anthropics/claude-code/issues/81123
• https://github.com/anthropics/claude-code/issues/81153
• https://github.com/anthropics/claude-code/issues/81159
• https://github.com/anthropics/claude-code/issues/81275
• https://github.com/anthropics/claude-code/issues/81358
• https://github.com/anthropics/claude-code/issues/81578
• https://github.com/anthropics/claude-code/issues/81664
• https://github.com/anthropics/claude-code/issues/81698
• https://github.com/anthropics/claude-code/issues/81745
• https://github.com/anthropics/claude-code/issues/81749
• https://github.com/anthropics/claude-code/issues/81756
• https://github.com/anthropics/claude-code/issues/81836
• https://github.com/anthropics/claude-code/issues/81840
• https://github.com/anthropics/claude-code/issues/81933
• https://github.com/anthropics/claude-code/issues/81947
• https://github.com/anthropics/claude-code/issues/82227
• https://github.com/anthropics/claude-code/issues/82967
• https://github.com/anthropics/claude-code/issues/83028
• https://github.com/anthropics/claude-code/issues/83130
• https://github.com/anthropics/claude-code/issues/83318
• https://github.com/anthropics/claude-code/issues/83478
• https://github.com/anthropics/claude-code/issues/83744
• https://github.com/anthropics/claude-code/issues/83799
• https://github.com/anthropics/claude-code/issues/83835
• https://github.com/anthropics/claude-code/issues/83941
• https://github.com/anthropics/claude-code/issues/84023
• https://github.com/anthropics/claude-code/issues/84309
• https://github.com/anthropics/claude-code/issues/84410
• https://github.com/anthropics/claude-code/issues/84458
• https://github.com/anthropics/claude-code/issues/84828
• https://github.com/anthropics/claude-code/issues/84980
• https://github.com/anthropics/claude-code/issues/84992
• https://github.com/anthropics/claude-code/issues/85081
• https://github.com/anthropics/claude-code/issues/85540
• https://github.com/anthropics/claude-code/issues/85691
• https://github.com/anthropics/claude-code/issues/85701
• https://github.com/anthropics/claude-code/issues/85901
• https://github.com/anthropics/claude-code/issues/85934
• https://github.com/anthropics/claude-code/issues/85953
• https://github.com/anthropics/claude-code/issues/85967
• https://github.com/anthropics/claude-code/issues/86094
• https://github.com/anthropics/claude-code/issues/86146
• https://github.com/anthropics/claude-code/issues/86180
• https://github.com/anthropics/claude-code/issues/86234
• https://github.com/anthropics/claude-code/issues/86248
• https://github.com/anthropics/claude-code/issues/86265
• https://github.com/anthropics/claude-code/issues/86287
• https://github.com/anthropics/claude-code/issues/86313
• https://github.com/anthropics/claude-code/issues/86433
• https://github.com/anthropics/claude-code/issues/86535
• https://github.com/anthropics/claude-code/issues/86660
• https://github.com/anthropics/claude-code/issues/86859
• https://github.com/anthropics/claude-code/issues/86893
• https://github.com/anthropics/claude-code/issues/87052
• https://github.com/anthropics/claude-code/issues/87072
• https://github.com/anthropics/claude-code/issues/87204
• https://github.com/anthropics/claude-code/issues/87329
• https://github.com/anthropics/claude-code/issues/87388
• https://github.com/anthropics/claude-code/issues/87638
• https://github.com/anthropics/claude-code/issues/88323
• https://github.com/anthropics/claude-code/issues/88415
• https://github.com/anthropics/claude-code/issues/88506
• https://github.com/anthropics/claude-code/issues/88667
• https://github.com/anthropics/claude-code/issues/88749
• https://github.com/anthropics/claude-code/issues/88817
• https://github.com/anthropics/claude-code/issues/88818
• https://github.com/anthropics/claude-code/issues/88971
• https://github.com/anthropics/claude-code/issues/89178
• https://github.com/anthropics/claude-code/issues/89264

</details>

Requested fixes and resilience improvements

1. Assign an owner from the Windows/Desktop packaging and runtime team, designate one canonical incident, and publish the first candidate/fixed build for A/B verification.
2. Validate the MSIX catalog/signing and packaged SwiftShader loading path, while distinguishing whether the Code Integrity events are causal or a fallback consequence.
3. Recover from GPU-child failure without terminating the desktop host.
4. Quarantine or clear the offending preview after an abnormal exit instead of automatically restoring and re-triggering it.
5. Provide a supported external browser / no internal preview safe mode, and publish a safe workaround; --disable-gpu may force the blocked SwiftShader path on some systems.
6. Checkpoint active sessions and background jobs so a UI/GPU failure does not destroy completed work.
7. Preserve pre-crash logs and add telemetry for 0x060C201E, because Crashpad/WER frequently captures no useful artifact.

Suggested acceptance criteria: a GPU-child failure must leave the host running or recoverable, keep the MSIX package at Status: Ok, disable the failing preview, and allow active background work to resume.

I hope this compilation helps the Windows/Desktop team reproduce, prioritize, and resolve the issue. The purpose of this comment is constructive: to help protect users' work and make an already valuable product more resilient.

A deterministic reproduction, timed to the millisecond: resuming a Claude Code session whose pending work drives the in-app Browser pane kills the whole app within 6 seconds of the navigate call — 3 out of 3 in one evening, including one deliberate controlled test.

Windows 10 Pro 10.0.19045 x64, Claude Desktop MSIX 1.40609.0.0 (all three deaths on this version, freshly installed the same evening). The session lives in the app's Code tab; its in-progress task previews a dev site in the in-app Browser pane. Each time the user resumes it (types "continue"), the assistant finds the preview closed, calls browser navigate to reopen it — and the entire app dies. The session transcript (~/.claude/projects/**/*.jsonl) timestamps every tool call, so the sequence is measured, not remembered:

| resume typed | browser navigate issued | last write to transcript = death |
|---|---|---|
| 20:18:54 | 20:19:04 | 20:19:10 |
| 20:59:02 | 20:59:11 | 20:59:17 |
| 21:08:41 (controlled test) | 21:08:57 | 21:09:02 |

All times local, 2026-08-28. The third row was a deliberate test: we predicted the death before typing the resume, and watched it land 21 seconds later.

What makes this variant nasty to diagnose:

1. The death leaves no Windows-visible trace at all. No WER AppCrash, no AppHang, nothing in the Application log, and the AppXDeploymentServer log is silent at death time (21:08:45–21:30:45 has zero Claude events). The only forensic source is the session transcript’s own mtime. I could not confirm the 0x060C201E exit code this report names because the MSIX app exposes no readable internal log (%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming contains only Microsoft\, LocalState is empty) — so I am reporting sequence and timing, not the exit code.
2. The session becomes a landmine, which reads as "the app crashes randomly". The session is not corrupted — but its next action is always the action that kills, so every resume reproduces the crash, and it takes down every other session the app hosts. The user reasonably concluded "it crashes when I type continue".
3. Package-state fallout matches this report’s appxState observation. After the third death, Get-AppxPackage read Modified, NeedsRemediation with no failed deployment operation logged since a clean install at 21:02:09 — the poisoning itself never appears in the AppX log. Recovery churn followed (4th reinstall of the day, ~263 MB each).

Workaround that holds: do not resume that session in the desktop app. Finish it in the terminal CLI (installed via npm, outside the MSIX package — no packaged execution alias exists), or start a fresh thread telling it to work without the browser preview.

If a maintainer wants the raw material: the three transcript excerpts and the empty-log negatives are preserved and I can attach them.

Two things that may unlock your missing exit code and confirm the workaround:

1. The internal log is not under Packages\LocalCache. Since 1.37937.x the desktop app writes %LOCALAPPDATA%\Claude\Logs\main.log, while the old %APPDATA%\Claude\logs sits frozen (details upthread). If 1.40609 kept that location, your three deaths should each have a "GPU process gone: { ... exitCode: 101457950 }" line there with timestamps matching your table — converting your timing-only sequence into a signature-confirmed reproduction on the newest build.

1. Your CLI workaround matches what happened here in reverse: the session that died with the browser-pane crash on this machine (#90147, timeline upthread) was resumed in the terminal CLI from its original working directory and completed without re-triggering, while the death itself came 3 seconds after a browser navigate. "Finish the landmine session outside the desktop app" is independently confirmed as the safe path.

Root cause found + fix verified (Windows 11, Claude Desktop 1.40609.0)

This is not a graphics bug. Exit code 101457950 (0x060C201E) is a Windows loader code-integrity kill, diagnosed via procdump full dump + WinDbg + the CodeIntegrity event log:

1. WebGL-probing pages (chatgpt.com, Cloudflare Turnstile, etc.) make Chromium's GPU process lazy-load vk_swiftshader.dll.
2. The GPU process runs with Code Integrity Guard (Microsoft/store-signed DLLs only). In the MSIX install, package DLLs qualify via the package catalog — but the installed package's AppxMetadata directory (including CodeIntegrity.cat) was missing on disk (AppxBlockMap/Signature/Manifest were present).
3. CodeIntegrity event 3033 — "vk_swiftshader.dll did not meet the Microsoft signing level requirements" — plus event 3010 — "unable to load ...AppxMetadata\CodeIntegrity.cat, status 0xC000003A". The loader raises non-continuable 0x060C201E (ntdll!LdrAppxHandleIntegrityFailure), killing the whole app and marking the package NeedsRemediation (hence "unlaunchable until Repair").

This explains why GPU pinning, disabling hardware acceleration, WARP, and driver updates all failed — the crash isn't in rendering. Light pages never load swiftshader, so they never crash. Crashpad/WER don't fire on loader kills, so no dumps appear.

Diagnosis tips: check Event Viewer → Applications and Services → Microsoft → Windows → CodeIntegrity → Operational for 3033/3010 pairs timestamped at each crash, and check whether C:\Program Files\WindowsApps\Claude_*\AppxMetadata\ exists.

Fix (verified): clean reinstall — winget uninstall Anthropic.Claude then winget install Anthropic.Claude. In my case the reinstall delivered the non-MSIX per-user build (%LOCALAPPDATA%\AnthropicClaude\), which has no Appx catalog dependency, so the failure path is structurally gone. Re-tested chatgpt.com/Turnstile in the browser pane: no crash (previously died within 1–35 s, 8 crashes over a week).

Open question for Anthropic: how the package's AppxMetadata dir went missing (bad staging during an MSIX update?) — if anyone else sees a fresh MSIX install without it, that's a packaging bug.

Confirming the same fatal crash on Intel-only hardware — with this issue (RTX 2080) and duplicate #81698 (RTX 5080), it is clearly not NVIDIA- or driver-specific. My trigger also looks different: no in-app Browser tab involved — the crashes cluster around resume-from-sleep.

Environment: Claude Desktop MSIX 1.24012.11 at the time of the crashes (now 1.40609.0), Windows 11, Lenovo ThinkPad X13 Yoga Gen 3, i7-1265U, Intel Iris Xe only (no dGPU), 16 GB RAM, Cowork VM active.

Five occurrences on 2026-08-04/05 (UTC+3), each killing the whole app with no shutdown handlers — main.log stops at the crash line and the next entry is a manual restart minutes later:

2026-08-04 07:02:47 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
2026-08-04 07:06:48 [info] Starting app { appVersion: '1.24012.11', ... }

Also at 07:07:28 (40 s after the relaunch), and 2026-08-05 06:23:59 / 08:22:36 / 08:27:25. Each matches a Persistent RPC: connection ended: failed to read length: EOF in coworkservice.log to the second.

Additional diagnostics that may help:

• Windows Application event log has zero Event 1000/1001 entries for claude.exe, and the Crashpad store (…\LocalCache\Roaming\Claude\Crashpad\reports) is empty — these crashes leave no client-side trace at all.
• After the 2026-08-21 update nothing is written to …\LocalCache\Roaming\Claude\logs anymore (and %APPDATA%\Claude\logs does not exist), so newer builds could not even produce the log evidence above.
• Intel graphics driver is current per Lenovo Vantage / Windows Update (checked 2026-08-29).
• Related: the recovery dead-end mentioned in #85199 is not user-fixable — even an elevated Administrator sc.exe failure CoworkVMService … fails with [SC] OpenService FAILED 5: Access is denied.

Full logs and a correlated timeline available on request.

Confirmed on a second machine — with a twist that answers the open question for at least one path.

This is the #90147 box (the 8/26 update-race incident). Checking CodeIntegrity/Operational after your comment:

2026-08-26 18:43:45 Id 3033: process ...\WindowsApps\Claude_1.37937.3.0_...\app\claude.exe attempted to load ...\Claude_1.37937.3.0_...\app\vk_swiftshader.dll that did not meet the Microsoft signing level requirements.
2026-08-26 18:43:45 Id 3010 (x3): unable to load ...\Claude_1.37937.3.0_...\AppxMetadata\CodeIntegrity.cat. Status 0xC000003A.
2026-08-26 18:43:46 main.log: GPU process gone: { ... exitCode: 101457950 }

One second apart, and 3 seconds after a browser navigate (timeline in my earlier comment). Same signature, same mechanism, different machine.

The twist: here the catalog wasn't missing from a healthy install — the failing path belongs to a package that was staged-but-deferred at the time (registration deferred at 17:12 because the old version was running; completed 18:47; full trail in #90147). So "bad staging during an MSIX update" is confirmed as one way the catalog goes missing: the deferred-registration half-state IS the integrity-broken window, and a WebGL-probing page loaded during it is fatal. That collapses what I had reported as two chained bugs into one — the update race creates the CIG landmine, the landmine kills the app, and the relaunch lands on NeedsRemediation.

Data point on the installed-state question: this machine's current, cleanly-registered 1.40609.0.0 (Status Ok, direct-download MSIX) also has NO AppxMetadata directory at all, while every Store-signed package on the same disk ships AppxMetadata\CodeIntegrity.cat. Zero 3033/3010 events for 1.40609 so far — but if the catalog is supposed to ship, that looks like a packaging gap on normal installs too, not only corrupted ones. Would be good to hear from Anthropic whether AppxMetadata is intentionally absent from the direct-download package.

One caution on the verified fix: the winget path that delivers the non-MSIX per-user build removes the failure mode but also removes Cowork — per Anthropic's Windows deployment guidance, full Cowork support requires the MSIX build and its privileged VM service. Fine trade if you don't use Cowork; a silent functionality loss if you do.

@kiwidudenz-bot Confirmed on a second machine — your diagnosis reproduces exactly, and I have one data point that speaks to your open question.

Environment: Windows 11 Home China 10.0.26200. Claude Desktop, MSIX, SignatureKind = Developer. Installed ~3 months ago from the claude.ai download — never from the Microsoft Store or winget.

1) AppxMetadata is missing, and it's not an ACL artifact. C:\Program Files\WindowsApps is ACL-restricted, so "not found" could just mean "not readable". I ran a control test against known-present siblings in the same package directory:

AppxManifest.xml                  True
AppxBlockMap.xml                  True
AppxSignature.p7x                 True
app\                              True
AppxMetadata                      False   <-- 
AppxMetadata\CodeIntegrity.cat    False   <--

Same fingerprint you described: BlockMap/Signature/Manifest present, AppxMetadata absent.

2) CodeIntegrity 3033/3010 pairs match every crash to the second. Three crashes, all triggered by the in-app browser pane opening:

2026-08-28 21:42:36   3033 + 3010 x3
2026-08-28 22:12:38   3033 + 3010 x3
2026-08-29 06:49:49   3033 + 3010 x3

3033 verbatim:

Code Integrity determined that a process (...\app\claude.exe) attempted to load ...\app\vk_swiftshader.dll that did not meet the Microsoft signing level requirements.

3010: ...\AppxMetadata\CodeIntegrity.cat catalog could not be loaded, status 0xC000003A.

Everything else matches too: main.log shows GPU process gone: { exitCode: 101457950 } at those same timestamps, the Crashpad DB is 0 bytes and WER has no records (consistent with a loader kill producing no dumps), and each crash left the package needing Repair, with the auto-repair looping on 0x80073D02.

3) On your open question — how AppxMetadata goes missing: on this machine it is not residue from a bad one-off staging. The crashes above happened on 1.37937.3.0. The app has since auto-updated to 1.40609.0.0, and that package directory was freshly staged on 2026-08-29 11:14:54 — I checked it today and it still has no AppxMetadata directory. So a fresh MSIX staging, on a machine that never touched the Store, produced a package without the catalog. It survives across version updates rather than being a single corrupted install.

Caveat, stated plainly: I never checked AppxMetadata before this thread, so I can't say whether the original ~3-month-old install shipped without it or lost it later. That package version is gone now. What I can say is that the current one was staged yesterday and lacks it.

I haven't done the clean reinstall yet. Thanks for the actual root-cause work; the CodeIntegrity log was the piece everyone (including me) was missing, because the absence of any crash dump made it look like there was nothing to find.

Confirming on 1.40609.0 (MSIX), Windows 11 Pro 26200, Intel UHD 770 (driver 32.0.101.7088). Six fatal occurrences in one day, all exitCode: 101457950 (0x060C201E).

Two pieces of evidence from this machine that I think narrow it usefully.

1. It reproduces with GPU acceleration DISABLED — the --disable-gpu workaround in this thread does not prevent it

I ran the app via Invoke-CommandInDesktopPackage ... -Args '--disable-gpu' and instrumented it with a 5-minute sampler that records the gpu-process command line and its loaded modules:

| launch | gpu-process --use-angle | graphics modules loaded in the gpu-process |
|---|---|---|
| normal | (none) | igd10iumd64.dll, igd10um64xe.DLL, igdgmm2_64.dll, igdgmm64.dll, igc64.dll, igd11dxva64.dll, igddxvacommon64.dll, igdinfo64.dll, d3d11.dll |
| --disable-gpu | d3d11-warp-webgl | D3D10Warp.dll only — no vendor driver module at all |

The app then ran for 45 consecutive samples (~3.5 h) confirmed on the WARP software path, and still died with the identical 0x060C201E four seconds after a browser preview was opened. So the crash is not in the vendor user-mode driver and not in hardware acceleration — combined with the NVIDIA reports in this thread and #82967, "update/roll back your GPU driver" and "turn off hardware acceleration" can both be ruled out.

2. The trigger is specifically the browser preview server, not the preview subsystem generally

From a 9-day main.log:

• 6 of 6 [Preview] Created browser preview { serverId: 'browser-preview-…' } events were followed by GPU process gone within 3–68 seconds. No crash occurred without one.
• One [Preview] Registered Claude page preview { serverId: 'html-preview-…' } on a previous day did not crash.
• [browser-live-preview] initialized appears at every launch on all 8 earlier sessions, so the subsystem is instrumented on older builds too — the absence of browser-preview-* on non-crash days is genuine non-use, not missing logging.

Typical last lines before the death:

[Preview] Created browser preview { serverId: 'browser-preview-…' }
[PreviewContext] Opened preview user tab { tabId: 'tab-1', openTabs: 2 }
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

Three of the six were preceded one second earlier by [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }, which may be a useful hint at where in the preview path this happens.

Not a pure version regression: 1.40609.0 first launched the previous day, ran two sessions that day and 2.5 h the following morning with zero crashes — the first crash came 68 seconds after the first browser preview this build had ever created.

3. The [gpu-recovery] auto-heal cannot fire for this bug

Reading app.asar, recovery is gated on ≥3 GPU deaths, with the count carried in a startup-marker file. But this crash is fatal to the whole app on the first GPU death, so the recorded count is always 1 and the >= 3 threshold is unreachable. isHardwareAccelerationDisabled is therefore never auto-set, and the "Claude crashed because of repeated graphics problems…" notice never appears.

That's a recovery control gated on state the failure destroys. Even fixed, per evidence (1) it would not help here — but it is worth knowing it has likely never fired for anyone hitting this.

Questions

• Is there a supported setting that prevents the in-app browser preview from being created? I set coworkBrowserToolsEnabled: false and coworkPreferredBrowser: "chrome" in claude_desktop_config.json; note launchEnabled was already false and browser previews were still created, so that flag at least does not gate this path.
• Would a GPU-process death be survivable rather than fatal? Chromium normally restarts it; here the main process goes with it.

Happy to provide the sanitized main.log window around any of the six crashes. I have a 34 MB Crashpad minidump from the sixth but will not post it publicly — it may contain page/document text from the session. Let me know a private channel if it would help.

Related: #82967 (closed as duplicate), #85199 / #84992 (the package ends up unlaunchable after each crash — I posted the on-disk root cause for that in #85199).

Still present on 1.40609.0 (six weeks and many releases after 1.24012.1), and not NVIDIA-specific — same exit code on an AMD integrated GPU under Windows 10.

Environment

• Claude Desktop 1.40609.0 (MSIX Claude_pzs8sxrjxfjjc, windows-store), claude.exe 2.1.139.0
• Windows 10 22H2, build 19045, 14 GB RAM
• GPU: AMD Radeon Vega 3 integrated (0x15D8), driver 31.0.21924.61 — no discrete GPU, no DisplayLink

Two fatal crashes today, same signature, 17 minutes apart

2026-08-30 13:30:04 [info] [RemotePreviewConsent] pane execution admission recorded { sessionId: 'session_01Fcay...' }
2026-08-30 13:30:07 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
<log ends mid-write — app dead until manual restart at 13:44:09>

2026-08-30 13:47:25 [info] [RemotePreviewConsent] pane execution admission recorded { ... }
2026-08-30 13:47:31 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
2026-08-30 14:52:29 [info] Starting app { appVersion: '1.40609.0', ... }   <- 65 minutes of downtime

Both fire 3–6 seconds after a Browser-pane action ([RemotePreviewConsent] pane execution admission recorded), so on this build the window between opening the pane and the crash is much shorter than the 15–36 s you measured. No TDR / display-driver-reset events — the driver never reset, only the Chromium GPU process died. Unlike your case, WER did fire here: RADAR_PRE_LEAK_64 for claude.exe 2.1.139.0 during the dead window.

Bug 2 reproduces identically: CoworkVMService (StartMode=Auto) outlives the crash, keeps app\resources\cowork-svc.exe open, and repair fails with 0x80073D02. The same restart also logs [Chrome Extension MCP] Failed to copy native host binary: EBUSY ... chrome-native-host.exe.

Extra workaround — persistent, no special launcher needed

1.40609.0 ships a real setting, which is nicer than Invoke-CommandInDesktopPackage ... --disable-gpu:

• Help menu → Disable Hardware Acceleration (checkbox), or
• with the app closed, set "isHardwareAccelerationDisabled": true in %APPDATA%\Claude\config.json (write UTF-8 without BOM), then relaunch.

The build also contains a [gpu-recovery] heuristic that auto-disables acceleration after 3 GPU deaths within 5 minutes — but it can never fire for this bug, because the app dies on the first one. Making the 0x060C201E path trip that heuristic at the first occurrence would let the product self-heal instead of leaving users with an app that won't start.

Same issue here, confirming this is still present in a much newer build — and adding two data points:

Setup: Claude Desktop 1.40609.0 (Windows 11, MSIX install), Intel Iris Xe Graphics (integrated GPU).

Symptom: identical to this report. Whenever a session used the built-in browser pane for web research, the GPU process crashed with the same exit code and took the whole app down:
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 } (= 0x060C201E)
4 crashes in one day, each preceded by [PreviewContext] Blocked subresource to private-resolving host and WebGPU activity (requestAdapter() warnings, "A valid external Instance reference no longer exists"). Reliably reproducible by opening www.printables.com in the browser pane (WebGPU 3D model viewer + Cloudflare Turnstile).

Data point 1 — GPU driver update does NOT fix it: I updated the Intel driver from 30.0.101.1960 (04/2022) to 32.0.101.7088 (06/2026). The very next browser pane use on printables.com crashed the app again identically.

Data point 2 — package corruption confirmed: After crashes the app would not reopen ("This app can't open"), Windows Repair failed for me, and a reboot did not help — only a full reinstall brought the app back. This happened several times in one day.

Extra note: clicking any web link in the chat also opens the built-in browser pane, so even a user who avoids the pane can trigger the crash with one click.

Workaround that works: stop using the built-in browser entirely (denied mcp__Claude_Browser via permissions.deny in settings.json) and route all browser work through the Claude in Chrome extension in an external Chrome — zero crashes since.

Requests: (1) fall back to software rendering instead of dying when the GPU process crashes, or provide a hardware-acceleration toggle; (2) make the MSIX package survive the crash so Repair works; (3) option to open chat links in the system browser.

<html>
<body>
<!--StartFragment--><p dir="ltr">Confirming this on a much newer build, with a version correlation that
may help narrow the regression.</p>

<p dir="ltr"><strong>Platform:</strong> Claude Desktop <strong>1.40609.0.0</strong>, Windows 11 Pro (build
26200), x64, sideloaded MSIX (<code>SignatureKind=Developer</code>). Intel Arc 140V
integrated GPU, driver 32.0.101.8826. <code>CodeIntegrityPolicyEnforcementStatus = 2</code> (enforced), HVCI active.</p>

<h2 dir="ltr">Same signature as the original report</h2>

<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">Microsoft-Windows-CodeIntegrity/Operational Id 3033
Code Integrity determined that a process
(...\WindowsApps\Claude_1.40609.0.0_x64__&lt;hash&gt;\app\claude.exe)
attempted to load
...\Claude_1.40609.0.0_x64__&lt;hash&gt;\app\vk_swiftshader.dll
that did not meet the Microsoft signing level requirements.</code></pre></div></div>

<p dir="ltr">Followed within the same second by:</p>

<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">GPU process exited unexpectedly: exit_code=101457950
GPU process launch failed: error_code=18 x5
GPU process isn't usable. Goodbye.</code></pre></div></div>

<p dir="ltr">Note the ordering: the GPU process dies <strong>first</strong>, and the SwiftShader
block lands on the <em>relaunch</em> attempts. Windows then flags the package
<code>Modified, NeedsRemediation</code> and the app will not start.</p>

<h2 dir="ltr">Version correlation - possible regression in 1.40609.0.0</h2>

<p dir="ltr">Scanning 30 days of CodeIntegrity events, the 3010 catalog errors trace
the full version history on this machine:</p>

<div dir="ltr">
Date | Version
-- | --
Aug 3 | 1.24012.11.0
Aug 5 | 1.25927.0.0
Aug 7-8 | 1.26832.0.0
Aug 12 | 1.28929.0.0
Aug 14 | 1.30096.0.0 / .1.0
Aug 15 | 1.30096.5.0
Aug 18 | 1.32352.1.0
Aug 19 | 1.32885.1.0
Aug 21 | 1.34493.1.0
Aug 25-27 | 1.37937.0.0 / .1.0 / .3.0
Aug 28 | 1.40609.0.0 installed

</div>

<p dir="ltr">Worth noting <code>--use-angle=d3d11</code> <em>did</em> take effect - WebGL reported
<code>ANGLE (Intel, Intel(R) Arc(TM) 140V GPU, Direct3D11)</code> with
<code>Major Performance Caveat: No</code>, i.e. genuine hardware D3D11 and no
SwiftShader in the WebGL path. WebGPU still reached the SwiftShader
fallback adapter through Dawn, bypassing ANGLE entirely.</p>

<p dir="ltr">There is currently <strong>no user-side workaround</strong> that preserves the app.</p>

<h2 dir="ltr">Recovery</h2>

<p dir="ltr">Windows' own repair does not work, as the original report says. The
AppModel-Runtime trace shows why - package status returns to <code>0x2</code> after
each repair, and only clears on a full re-Add:</p>

<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">status -&gt; 0x280002
status -&gt; 0x200002
status -&gt; 0x2
status -&gt; 0x0 &lt;- only after Add-AppxPackage, ~1 minute later</code></pre></div></div>

<p dir="ltr">This clears it and preserves app data:</p>

<div role="group" aria-label="powershell code" tabindex="0"><div><div></div></div><div>powershell</div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code class="language-powershell" style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre;"><span><span><span style="color: rgb(112, 184, 255);">Add-AppxPackage</span> -Path .\Claude.msix -ForceUpdateFromAnyVersion -ForceApplicationShutdown</span></span></code></pre></div></div>

<h2 dir="ltr">Impact</h2>

<p dir="ltr">This blocks normal work, not edge cases - six crashes in a single working
session, each requiring a re-Add before the app would start again.</p>

<h2 dir="ltr">Supporting the packaging diagnosis</h2>

<p dir="ltr">407 <code>Id 3010</code> catalog errors across every version back to Aug 3, all of
the form:</p>

<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">Code Integrity was unable to load the
...\Claude_&lt;version&gt;_x64__&lt;hash&gt;\AppxMetadata\CodeIntegrity.cat
catalog. Status 0xC000003A.</code></pre></div></div>

<p dir="ltr">The 3010s alone are harmless - they occur constantly on every build. It
is only 3010 <strong>plus</strong> a 3033 that flags the package. This matches the
original report's first suggested fix: ship <code>AppxMetadata\CodeIntegrity.cat</code>
in the MSIX.</p>

<p dir="ltr">Since the app is sideload-only (no Microsoft Store listing), every
install is <code>SignatureKind=Developer</code> with no catalog, so every user is
exposed to this the moment their GPU process needs to restart.</p>

<p dir="ltr">Upstream: electron/electron#52700</p><!--EndFragment-->
</body>
</html>

Confirming this on AMD integrated graphics and on a newer app build, which should help rule out both the vendor and the specific version.

Environment

• Claude desktop app 1.40609.0.0 (MSIX Claude_pzs8sxrjxfjjc, Developer-signed, package Status Ok)
• Windows 11 Pro 26200, 32 GB RAM
• GPU: AMD Radeon 680M (integrated, Ryzen 9 6900HX) — ASUS Mini PC PN53-G
• Display Memory 16481 MB (Dedicated 485 MB / Shared 15995 MB)

Same signature

Three crashes on 2026-08-30, each within seconds of an in-app Browser tab loading a WebGL/WebGPU-heavy page (suno.com in all three cases).

unknown-window.log:

[warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows.
[warn] OTS parsing error: Size of decompressed WOFF 2.0 is less than compressed size
[error] %c%d font-size:0;color:transparent NaN
[warn] A valid external Instance reference no longer exists.
[warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost

main.log, same second:

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

I could not preserve the exit code: the mandatory Repair (see below) reset the log files before I got to it. Happy to capture it if this recurs — though the point is now to avoid the in-app Browser on this machine.

Driver ruled out independently

The original report reproduced on two NVIDIA driver versions. Adding the AMD side:

• crash on 32.0.21043.5001 (2026-03-03)
• updated to Adrenalin 26.8.1 -> 32.0.21045.5002 (2026-08-17), using the installer's Factory Reset option, followed by a reboot
• no display-driver errors in the System event log after the reboot
• crash reproduced identically on the new driver

So the fault occurs on NVIDIA discrete and AMD integrated graphics alike, across four driver versions in total.

Memory ruled out

At the crash instant the app's own telemetry reported sys_free=17168MB/31992MB, whole Electron tree at 2148 MB, GPU process at 192 MB.

Bug 2 confirmed

After the third crash the app would not start at all and had to be restored via Settings -> Apps -> Claude -> Advanced options -> Repair. As described in the original report, Windows logged nothing — no Application Error 1000/1002 anywhere near the crash timestamps, while unrelated errors from the same day are present in the log. From the user's point of view the app simply disappears and then refuses to start, with no diagnosable error.

Unrelated observation, in case it is useful

On this machine claude_desktop_config.json (in the virtualised LocalCache\Roaming\Claude path) carried the ReadOnly attribute and had not been written since 2026-04-15, producing hundreds of EPERM entries in main.log. The user did not set this. Very likely a separate issue, but a package whose config is read-only appears to recover far worse from a hard crash — possibly an aggravating factor for Bug 2.

Same failure with no DisplayLink and no memory pressure — 11 occurrences with an identical signature, plus a note on why the built-in auto-disable can never fire.

Adding a measured data point, because two of the usual explanations are ruled out here.

Environment

• Claude Desktop 1.40609.0 (MSIX, sideloaded), Claude Code in Desktop 2.1.247
• Windows 10 Pro 19045 (x64)
• ASUS X550CA (2012), Intel i3-3217U, 4 GB RAM
• Intel HD Graphics 4000, driver 10.18.10.4252 (2015-09-07)
• Single built-in 1366×768 panel. No DisplayLink, no external or indirect display adapter.
• HVCI / memory integrity off (Win32_DeviceGuard all zeros; the HypervisorEnforcedCodeIntegrity key does not exist)

The signature is exact: always five events

Microsoft-Windows-AppModel-Runtime/Admin records exactly 5 Event ID 6 (0x3CFC, ERROR_NEEDS_REMEDIATION, "cannot create the process for package … try reinstalling") at every failure. Eleven occurrences inside the window that log retains — it starts 2026-08-23 17:46, so earlier ones are simply not visible:

2026-08-24 22:01:33    2026-08-25 19:06:27    2026-08-29 23:42:13
2026-08-24 22:30:19    2026-08-25 20:24:59    2026-08-30 00:01:18
2026-08-25 04:16:25    2026-08-26 10:03:33    2026-08-30 13:04:03
2026-08-25 17:40:50    2026-08-29 22:56:20

Never four, never six. Always five.

Ruled out: memory pressure

A 15-second memory sampler was running across the 2026-08-30 13:04:03 failure. At that instant: 797 MB free of 3982 MB. The app's own log agrees — the last [process-memory] line before the death reports sys_free=769MB/3982MB. The day's real minimum, 200 MB at 01:27, did not kill the app.

On a 4 GB machine this would be easy to write off as RAM. The measurement says it isn't.

Ruled out: crash artifacts and package servicing

• No Application Error (1000) and no Windows Error Reporting entry at the failure time.
• Crashpad\reports is empty — no minidump. The app does not crash; it becomes unable to continue.
• No AppX deployment operation anywhere between 00:30 and 13:06, so this is not an update racing the running app.

Timeline of the 13:04:03 failure

From %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude\logs\main.log:

13:02:32  [Preview] Spawning process
13:02:37  [Preview] Server ready (HTTP responding)
13:02:45  [Preview] navigatePreview failed
13:03:23  [process-memory] ... sys_free=769MB/3982MB
13:04:03  GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }
          -> five x 0x3CFC in AppModel-Runtime/Admin, same second
          -> nothing further is ever written to main.log

91 seconds between opening the browser preview pane and the GPU process death. Note reason: 'crashed', not launch-failed: the process existed and died, it was not a failed spawn. exitCode: 101457950 = 0x060C201E, matching the other reports.

CoworkVMService confirmed as the repair blocker

Name      : CoworkVMService
State     : Running
StartMode : Auto
StartName : LocalSystem
PathName  : C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

Both attempts to re-register the package while that service was alive failed with 0x80073D02, each preceded by event 638 naming the app as still running. Only a reinstall — whose RestartManager stops the service — ever recovered it. Killing every claude.exe first makes no difference, because the process holding the package is the service, not the app.

The built-in auto-disable can never fire here

1.40609.0 ships a GPU-crash-streak recovery that disables hardware acceleration after 3 GPU process deaths in a session. Across 11 failures on this machine it has never triggered — because the first death is already fatal. The package flips to NeedsRemediation, no further process can be created for it, so a second and third death never happen and the counter never reaches its threshold.

The mitigation is present in the product and structurally unreachable for exactly the users who need it.

Suggestion: persist the auto-disable marker on death #1 when process creation for the package fails immediately afterwards, rather than requiring a streak of 3.

Mitigations applied here

• Prevention: "isHardwareAccelerationDisabled": true in %APPDATA%\Claude\claude_desktop_config.json — i.e. arming the app's own recovery ahead of a streak it can never reach. Result to follow.
• Recovery without reinstalling: stop CoworkVMService, kill cowork-svc.exe, then re-register the package. That is the step that makes the difference.

Happy to attach a diagnostic report if it would help.

Same crash on ARM64 (Snapdragon X) — confirms this isn't GPU-vendor-specific

Adding a data point: I hit this identical GPU-process crash on a single-GPU ARM64 machine with a Qualcomm Adreno iGPU — no NVIDIA, no hybrid graphics involved. Same exit code as the original report (101457950 / 0x060C201E), same trigger, so whatever this is, it's not specific to NVIDIA/RTX or to GPU-adapter switching.

Environment

• Claude Desktop 1.37937.1 (arm64) — confirmed "You are running the latest version", so this is still not fixed on the current release (regression persists well past 1.24012.1)
• Windows 11 Home 10.0.26200, 25H2 (UBR 9168)
• Surface Laptop, 7th Edition (Snapdragon X)
• GPU: Qualcomm Adreno X1-85, driver 31.0.133.1

Trigger: 100% reproducible — the GPU process crashes and takes the app down whenever the in-app Browser/Preview pane opens. Also crashes less predictably at other times on GPU-composited content. Four crashes in one morning, all identical exit code.

Log signature (%LOCALAPPDATA%\Claude\Logs\main.log) — the preview screenshot fails immediately before the GPU dies:

[warn] [Preview] capturePreviewScreenshotIfChanged failed: { error: [Error: UnknownVizError] }
[info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

Confirming the --disable-gpu workaround from the original report also helps here. Given it now reproduces on Adreno/ARM64 as well as NVIDIA/x64, this looks like a general Chromium GPU-process failure during in-app preview compositing rather than anything vendor-specific.

Another reproduction, plus five things about CoworkVMService I could not find anywhere in this
thread — the first of which changes the workaround advice, because the obvious remedy does not work.

(4090 and DisplayLink reports already exist here, so I am not claiming new hardware coverage. The
service findings below are the part I believe is new.)

Environment

| | |
|---|---|
| OS | Windows 11 Pro 25H2, 10.0.26200.9278 |
| Package | Claude_1.40609.0.0_x64__pzs8sxrjxfjjc (SignatureKind: Developer) |
| GPU | NVIDIA GeForce RTX 4090, driver 32.0.16.1088 (2026-07-21) |
| Also present | 2 × DisplayLink USB Device, driver 12.2.1932.0 (2026-01-20) |

Same exit code as the original report on different silicon, and 4090 reports already exist in this
thread — so the crash is clearly not tied to one GPU model.

The crash

Two crashes, identical exit code, from AppData\Local\Claude\logs\main.log:

2026-08-30 05:28:01 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

Same block again at 2026-08-30 17:36:45. 101457950 = 0x060C201E, matching this issue.

Recovery time is the damaging part. Next Starting app after each crash:

• 05:28:01 crash → next start 05:33:38 (5m 37s)
• 17:36:45 crash → next start 00:49:06 the following day (7h 12m)

One negative result, so nobody else chases it

Both crashes are preceded ~1s by
[PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }.
That looks like a marker but is not one: that line occurs 26 times across my logs against
2 crashes. It indicates the Browser pane was active (consistent with the WebGL trigger reported
here), nothing more. Not predictive.

Package corruption, observed directly

Microsoft-Windows-AppModel-Runtime/Admin on 2026-08-30 shows the package status flapping while
repair attempts fail, then clearing only after a successful re-stage:

05:29:46  status -> 0x80002 (previous 0x2)
05:29:46  status -> 0x2     (previous 0x80002)
05:29:47  status -> 0x80002 (previous 0x2)
05:29:47  status -> 0x2     (previous 0x80002)
05:30:35  status -> 0x80002 (previous 0x2)
05:31:13  status -> 0x2     (previous 0x80002)
05:31:30  status -> 0x0     (previous 0x2)      <- cleared

Microsoft-Windows-AppxPackaging/Operational logs a streaming reader created for the package at
05:31:20, ten seconds before the status clears.

Note also that Microsoft-Windows-AppXDeployment-Server/Operational contains zero Claude events
ever on this machine (the channel is enabled, Circular, 21% full, and has entries back to Feb 2025).
Anyone debugging this from that channel will see nothing and wrongly conclude no deployment activity
occurred.

Finding 1 (the important one) — secureVmFeaturesEnabled=0 does NOT stop the service

The documented enterprise policy
(HKLM\SOFTWARE\Policies\Claude → secureVmFeaturesEnabled DWORD 0) is the obvious remedy and it
does not fix this. I set it successfully, and CoworkVMService was still running, StartType
still Automatic.

That makes sense mechanically: cowork-svc.exe runs from inside the package
(...\WindowsApps\Claude_<ver>_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe). A running image is
locked by Windows, so the service holds package content by running, regardless of whether the
Cowork feature is enabled. Disabling the feature does not stop an AUTO_START service.

Finding 2 — the service's recovery actions can never be configured, by anyone

cowork-svc.exe logs this at every start:

Warning: failed to configure recovery actions (a crashed service will stay down until reboot):
open service: Access is denied.

sc.exe qfailure CoworkVMService confirms the result: RESET_PERIOD 0, no actions configured.
sc.exe failure CoworkVMService reset= 86400 actions= restart/5000/... fails with
OpenService FAILED 5 even from an elevated administrator prompt.

The DACL explains it:

sc.exe sdshow CoworkVMService
D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-...)

• AU (Authenticated Users) has no DC (SERVICE_CHANGE_CONFIG)
• there is no BA (Administrators) ACE at all
• DC belongs solely to S-1-5-80-1949724575-..., which resolves to NT SERVICE\AppXSvc

Control: all four WIN32_PACKAGED_PROCESS services on this machine (CoworkVMService,
GamingServices, GamingServicesNet, MuseHub Updater Service) share that DACL shape, so this is
Windows policy for packaged services rather than a mistake in the Claude package. Worth noting the
service's own SID is S-1-5-80-690231842-..., which does not appear in its own DACL — so even
the service's LocalSystem token cannot satisfy the ACE, which is why its own attempt fails.

Consequence: Service Control Manager event 7034 "The Claude service terminated unexpectedly"
fired 4× here (2026-08-19 12:14:03, 08-30 05:33:28, 08-31 00:48:41, 08-31 00:48:55), each reporting
"It has done this 1 time(s)" — the counter never accumulates, consistent with RESET_PERIOD 0.

Finding 3 — the service never did anything on this machine

C:\ProgramData\Claude\Logs\cowork-service.log covers 2026-07-31 → 2026-08-31 with 35 service
starts and zero VM boots. Every start ends at:

Waiting for configuration from app via 'configure' method...

So on a machine that never uses Cowork, the service starts unconditionally, contributes nothing, and
is the sole reason a recoverable GPU crash becomes an unrecoverable package state.

Workaround — confirming the logon-task approach, with measurements

Stopping the service at logon has been mentioned here already; this is a confirmation with numbers,
plus Finding 2 explaining why the tidier routes are unavailable.

Stopping the service is permitted without elevation (AU does hold start/stop; only change-config
is locked). Verified:

• Stop-Service CoworkVMService succeeds unelevated
• cowork-svc.exe leaves memory, releasing the package lock
• Claude Desktop is unaffected (14 processes continued normally)
• it stays stopped — nothing restarts it during a session (60s sample)

I run it from a logon-triggered scheduled task, verified end to end (task result 0, service
Running → Stopped, cowork-svc.exe count 1 → 0). StartType cannot be changed, so stopping it
after boot is the only available route.

This does not prevent the GPU crash. It stops the crash being destructive: the app dies and can be
relaunched immediately instead of requiring Repair.

Requests

1. Make CoworkVMService demand-start, or have it stop when the last claude.exe exits. This

alone would downgrade this bug from "package corruption" to "app restart".

1. Have the repair path stop the service before attempting re-registration.
2. Either make secureVmFeaturesEnabled=0 also stop the service, or document that it does not —

it is currently the natural thing to reach for and it does not help.

1. Recover the GPU process crash without killing the main process.

Follow-up to my previous comment: arming isHardwareAccelerationDisabled ahead of the auto-disable streak does NOT prevent this — plus corroboration of @deemer-cyber's CoworkVMService findings from a Windows 10 machine.

1. The negative result I promised

In my earlier comment I reported that this build's GPU-crash-streak recovery (disable hardware acceleration after 3 GPU deaths in a session) can never fire on this machine, because death #1 is already fatal — and that I had set "isHardwareAccelerationDisabled": true manually to arm it ahead of a streak it can never reach, with "result to follow".

The result: it does not help.

Set 2026-08-30 18:43 and verified effective rather than merely written: with acceleration off the gpu-process still exists (software path), but it no longer loads the Intel driver igd10iumd64.dll — that DLL check, not the setting itself, is what I used to confirm it took.

Package corruption then recurred six times in the next eight hours, each time with the identical signature from my previous comment — exactly 5 × Event ID 6 (0x3CFC, ERROR_NEEDS_REMEDIATION) in Microsoft-Windows-AppModel-Runtime/Admin, 30 events over 6 occurrences, never four, never six:

2026-08-30 18:59:37    2026-08-30 22:52:48
2026-08-30 19:03:10    2026-08-31 02:43:58
2026-08-30 19:58:35    2026-08-31 03:03:35

This matches @ndavipt's WARP-path result and @SaLoGeF's --disable-gpu result, and extends both to the app's own in-product toggle. It also refutes the suggestion I closed my previous comment with: firing the auto-disable on death #1 would not have saved this machine either. The fix has to be upstream — either not killing the main process on GPU death, or not flagging the package when it happens.

2. On Windows 10 the recovery path finally ran out

After the sixth corruption, install-over-the-top — until then the reliable recovery here — failed twice:

05:29:59  MSIX installation failed: AddPackage failed with HRESULT 0x80073CF9
05:31:16  MSIX installation failed: AddPackage failed with HRESULT 0x80073CF9

each preceded in ClaudeSetup.log by the installer's own fallback:

Windows rejected data-preserving removal for Claude_1.40609.0.0_x64__pzs8sxrjxfjjc
(0x80073CFA, requires developer mode); relying on in-place update

The only recovery was Settings → Apps → Claude → Advanced options → Reset, which destroys all app data (session, settings, logs — including the main.log needed to diagnose the crash that caused it). The same installer then succeeded at 05:34:20.

This is the Windows 10 dead-end already reported by @aihunt-ttg and @integms, reached from a third machine. Worth restating what it costs a non-technical user: -PreserveApplicationData is rejected (this package reports SignatureKind: Developer but IsDevelopmentMode: False), Windows 10 has no Reset-AppxPackage, so "recover but keep your data" is not on the menu at all — and each recovery erases the evidence of the next report.

3. Corroborating @deemer-cyber's service findings, from Windows 10

• The installer cannot remove the service even when elevated. Every run in ClaudeSetup.log, including those logging Is elevated: true / Running in elevated context, contains:

``
Removing conflicting CoworkVMService...
WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied.
`
Independent confirmation of Finding 2 (no BA ACE) observed from the installer side rather than from sc.exe`.

• Identical DACL on a different OS. sc.exe sdshow CoworkVMService on Windows 10 Pro 19045 returns byte-identical output to the Windows 11 25H2 report, same NT SERVICE\AppXSvc SID:

``
D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)
``

• Finding 3 reproduces. C:\ProgramData\Claude\Logs\cowork-service.log, 2026-06-25 → 2026-08-31: 50 service starts, 47 VM sessions created, zero VM boots. Every start ends at Waiting for configuration from app via 'configure' method...; 35 shutdowns log [VM] VM already stopped, nothing to release. Same conclusion on a machine that has never used Cowork: the service contributes nothing and is the sole reason a recoverable GPU crash becomes an unrecoverable package state.

Environment unchanged from my previous comment (ASUS X550CA 2012, i3-3217U, 4 GB RAM, Intel HD 4000, Windows 10 Pro 19045, single 1366×768 panel, no DisplayLink); package now 1.40609.0.

Additional data point — still reproducing on 1.40609.0.0, and evidence that this is not an OS-level crash

Same exitCode: 101457950 (0x060C201E), same trigger (in-app Browser tab navigating to an external site). Adding forensics that may narrow this down.

Environment

• Claude Desktop 1.40609.0.0 (MSIX), Windows 11 Pro 26200
• Intel Core i5-12400F (no iGPU), MSI H610M (MS-7E44), 32 GB DDR4-2666

1. Full GPU replacement changed nothing

Seven crashes total, identical exit code on two completely different GPUs and driver generations:

| | GPU | Driver | Crashes |
|---|---|---|---|
| Before | GeForce GT 610 (Fermi, 2012) | 23.21.13.9135 (2018-03-22) | 5 |
| After | GeForce RTX 3050 6 GB | 32.0.16.1656 (2026-08-19) | 2 |

RAM was also doubled (16 → 32 GB) and the PSU replaced in the same upgrade. No change. WEBGL_debug_renderer_info confirms real hardware rendering after the swap: ANGLE (NVIDIA, NVIDIA GeForce RTX 3050 (0x00002584) Direct3D11 vs_5_0 ps_5_0, D3D11).

Crashes also occur with isHardwareAccelerationDisabled both true and false.

2. It is not a crash — the GPU process is deliberately terminated

This seems like the most useful finding. I enabled WER local dumps before reproducing:

HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
  DumpFolder = C:\CrashDumps
  DumpCount  = 5
  DumpType   = 2   (full dump)

Then reproduced the crash on demand. Result:

• No dump was written. C:\CrashDumps was never even created.
• No Application Error (Event ID 1000) and no APPCRASH (1001) for Claude in the Windows Application log.

WER is demonstrably working on this machine — msedge.exe produced four proper Event ID 1000 records with 0xc0000005 in the same 30-day window.

So the GPU process is not faulting: something calls TerminateProcess with a fixed magic value. That is consistent with the exit code being byte-identical across seven crashes, two GPUs and two driver generations. Suggest looking at whichever internal watchdog / kill path uses 0x060C201E, rather than at the graphics stack.

3. Ruled out with evidence

• Display driver reset (TDR): zero Event ID 4101 in the System log across the machine's entire history. The driver never hung or reset.
• DLL injection into the GPU process: all 72 loaded modules belong to Windows or Claude. AppInit_DLLs empty, LoadAppInit_DLLs = 0. No overlay software, no banking-security modules.
• Third-party AV: Windows Defender only, no ASR rules configured, no detections or actions in the Defender operational log.
• Exploit mitigation kills: nothing for Claude in Security-Mitigations/UserMode or KernelMode.
• Memory pressure: 17.6 GB free of 31.8 GB at the moment of the crash; process tree at ~6.5 GB.
• Log correlation: I checked base rates before claiming any. The one log line that preceded all six early crashes within 0–1 s (using oauth config) occurs 464 times in the same log against 6 crashes, so it is noise, not signal.

4. Trigger detail, and a negative control

Reproduced by navigating the in-app Browser to a court-records site that serves a Cloudflare-style bot-check interstitial — i.e. a page whose whole job is running WebGL/WebGPU capability probes. This matches the fingerprinting-probe trigger described in the original report. Timeline of the clean reproduction:

11:04:17  [PreviewContext] Opened preview user tab { tabId: 'tab-4', openTabs: 2 }
11:04:28  [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
11:04:29  GPU process gone: { type:'GPU', reason:'crashed', exitCode:101457950, serviceName:'GPU' }

Time from tab open to death across crashes: 1 s to 3 min.

Negative control: a locally-authored stress page (WebGL drawing 3000 vertices/frame plus 40 animated compositing layers) ran at a steady 59 fps for 3 min 36 s with no crash. Local files render as data: in the preview pane, which appears to be a different path. Raw GPU load does not reproduce this — only real external navigation does.

5. Package state

Unlike #82967, the MSIX package has stayed Ok here across all seven crashes — no Modified / NeedsRemediation, no repair needed. The app restarts cleanly on its own.

Impact

The in-app Browser is unusable for external sites on this machine, and one tab takes the whole app — and every open session — down with it. A softer failure mode (GPU process restarting without killing the app, as normal Chromium does) would make this a nuisance instead of a work-stopper.

Same crash, reproduced 9 times over 8 days on different hardware. Adding evidence plus one data point I have not seen in this thread: the per-app GPU preference workaround does NOT prevent it.

Environment

• Claude Desktop 1.40609.0.0 (MSIX, Claude_pzs8sxrjxfjjc), Claude Code 2.1.247
• Windows 11 Home 10.0.26200
• Hybrid graphics: AMD Radeon iGPU (31.0.21036.8001) + NVIDIA GeForce RTX 5060 Laptop GPU (driver 32.0.16.1088, dated 2026-07-21)
• Virtual displays present (Meta Quest virtual monitor, wireless HDMI adapter)

Crash signature
Every app death ends with this as the final line in %LOCALAPPDATA%\Claude\Logs\main.log, followed by nothing until the next Starting app:

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

Windows Event Log records no fault for claude.exe at all. The Electron GPU child process dies and the host terminates the entire app, killing all running sessions and background tasks.

Correlation with the Browser pane
9 crashes between 2026-08-24 and 2026-08-31, all with exitCode 101457950. I correlated each crash line-number against preview creation events in main.log: 8 of 9 crashes occurred between 10 seconds and ~15 minutes after a [Preview] Created browser preview / Created session preview context entry. The one exception had no preview open. Timestamps: 08-24 12:01, 08-25 09:06, 08-25 20:54, 08-26 12:32, 08-26 13:06, 08-26 21:20, 08-31 18:41, 08-31 19:41, 08-31 20:13.

Negative result: GpuPreference pin does not fix it
I set the per-app graphics preference mentioned as a workaround elsewhere (#84992):

HKCU\Software\Microsoft\DirectX\UserGpuPreferences
Claude_pzs8sxrjxfjjc!Claude = GpuPreference=2;

Verified in the registry, app fully restarted afterward (20:02:43). The pane survived one 9-minute session, then the app died with the identical signature at 20:13:07 with the preference active. So pinning the app to the discrete GPU is not a reliable mitigation.

Repair loop
Confirming the #84992 chain on this machine as well: after crashes the package intermittently demands Repair, and repair attempts fail until cowork-svc.exe is killed. Stopping CoworkVMService plus killing leftover claude.exe, then relaunching, recovers it immediately.

Happy to provide the full main.log excerpts if useful. The ask from #81698 stands: the host should survive a GPU process crash (fall back to software rendering or relaunch the GPU process) instead of taking every running session down with it.

Fresh MSIX install without AppxMetadata — confirming the packaging-bug hypothesis

Answering the open question raised upthread ("if anyone else sees a fresh MSIX install without it, that's a packaging bug"): yes, this reproduces here.

Environment

• Claude Desktop 1.40609.0 (MSIX), Windows 11 Home 26200, x64
• Intel UHD Graphics 610 (driver 31.0.101.2141), 8 GB RAM

Findings

• ...\WindowsApps\Claude_1.40609.0.0_x64__pzs8sxrjxfjjc\AppxMetadata\ does not exist at all — the whole directory is absent, while app\vk_swiftshader.dll is present as expected.
• CodeIntegrity event 3010 (Status 0xC000003A) has recurred across five package versions since early August, i.e. it is not a one-off bad staging on a single update.
• A full reinstall of the current build from downloads.claude.ai did not create it. The reinstall stayed on the MSIX channel, so the failure path stayed in place and the crash still reproduces.

That last point may save others a step: the verified "clean reinstall" fix upthread works because it delivers the non-MSIX per-user build (%LOCALAPPDATA%\AnthropicClaude\), not because reinstalling repairs the catalog. Reinstalling the MSIX leaves AppxMetadata missing.

Two smaller data points

ACLs are not involved here. Some analyses (mine included, initially) blamed WindowsApps ACL damage because AppXDeploymentServer logs Trying to repair ACLs ... ACLs repaired successfully. On this machine icacls shows the package ACL fully intact — TrustedInstaller:(F) and the capability SIDs all present — and Get-AppxPackage reports Status Ok, while the catalog is still missing and the crash still fires. Re-registration appears to "fix" things only because restarting the app clears the preview-pane state, i.e. it removes the trigger, not the cause.

Memory pressure is not required. One of my two crashes happened at 295 MB system free of 7833 MB with 36 child processes; the other at 2.4 GB free with a much smaller tree. Resource-Exhaustion-Detector logged nothing in 14 days.

Happy to provide raw log excerpts or filtered event log exports if useful.

Follow-up to my comment above — two small things that might help others.

1. Preserving the exit code across the mandatory Repair

I lost the exit code last time because Repair resets the log files. For anyone hitting this: copy the logs before running Repair. The app is already dead at that point, so nothing holds the files:

Copy-Item "$env:APPDATA\Claude\logs\*" "$env:USERPROFILE\Desktop\claude-crash-logs\" -Recurse -Force

The relevant line is GPU process gone: { ... exitCode: ... } in main.log. I will post mine if this recurs on my machine.

2. Read-only claude_desktop_config.json — can others check?

I reported hundreds of EPERM entries caused by a ReadOnly attribute on the virtualised config, which I never set. If this turns out to be common among people hitting Bug 2, it may be more than a coincidence. One line to check:

Get-ChildItem "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json" |
  Select-Object FullName, Attributes, LastWriteTime

If Attributes contains ReadOnly, please say so in a reply — ideally with whether your app also needed Repair after a crash.

3. Related open issues, same signature

This is being reported in parallel across several threads, which probably makes it harder to see the scale of it: #80468, #81159, #81698, #81836, #82967, #83478. Might be worth consolidating.

Negative data point on the ReadOnly config question — plus a caution on the AppxMetadata correlation

@engelnightshop-lab — checked here, and it does not reproduce.

• %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json → Attributes: Archive. Same for the non-virtualised %APPDATA%\Claude\ path. No ReadOnly on either.
• main.log contains 3 EPERM entries in total, all of the form unlink ...\Claude\claude-code\2.1.234\claude.exe — removing an old Claude Code version that was still in use. None involve the config file.
• No Repair has ever been needed on this machine: Get-AppxPackage *Claude* reports Status Ok across all 7 crashes.

So the crash reproduces here without the ReadOnly attribute and without the EPERM flood. That anomaly is not a necessary condition.

On the missing catalog, a caution. @HBCreAtiveD's finding does reproduce here: ...\WindowsApps\Claude_1.40609.0.0_x64__pzs8sxrjxfjjc\AppxMetadata\ does not exist, while app\vk_swiftshader.dll is present. But I cannot tie it to the crashes on this machine, and I would not yet treat it as the cause:

• There are exactly 3 CodeIntegrity 3010 events here, all within the same second, against 7 GPU crashes. The other six produced none.
• That one second is 2026-08-31 11:27:22 — the crash I reproduced deliberately with WER LocalDumps enabled. The dump attempt is the more likely reason Windows went looking for the package catalog at that moment.

Correlation of 1-in-7 with a plausible alternative explanation. Worth keeping the packaging bug on the table as a separate defect, but on this evidence it does not explain the GPU process dying.

Environment: Claude Desktop 1.40609.0.0 (MSIX), Windows 11 Pro 26200, i5-12400F, RTX 3050 6 GB (driver 32.0.16.1656). Full forensics in my comment above, including the WER result showing the GPU process is terminated rather than faulting.

Confirming this on a much newer build, different GPU vendor, and with the Windows-side Code Integrity events that show the exact cause.

Environment

| Item | Value |
| --- | --- |
| Claude Desktop | 1.40609.0 (MSIX, Claude_1.40609.0.0_x64__pzs8sxrjxfjjc) |
| Claude Code | 2.1.247 |
| Node (Electron) | 24.18.1 |
| OS | Windows 11 Pro, build 10.0.26200 |
| GPUs | AMD Radeon(TM) Graphics (iGPU) 32.0.21045.5002 + NVIDIA GeForce RTX 5090 32.0.16.1088 |
| Free RAM at crash | ~55 GB of 63 GB (not memory pressure) |

So this is not specific to the 1.24012.x builds or to NVIDIA-only machines.

Trigger

Agent called the in-app Browser pane (Claude_Browser__navigate) on an external Cloudflare-protected page (manuals.plus, which 403s plain fetches). Pane opened, page started rendering, GPU process died ~4 s later and took the whole app down. App would not relaunch until Settings → Apps → Claude → Advanced options → Repair.

No BSOD and no kernel bugcheck — System log has no Event ID 41 and no ID 1001 anywhere near it. Purely app-level.

main.log

2026-09-01 18:18:10 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
2026-09-01 18:18:10 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

101457950 = 0x060C201E, same as this issue.

Log then goes completely silent until the next app start five minutes later.

The part I think is missing from most reports: Windows Code Integrity log

Microsoft-Windows-CodeIntegrity/Operational, same second as the GPU crash:

18:18:10  Event 3010  Code Integrity was unable to load the
          \Device\HarddiskVolume3\Program Files\WindowsApps\
          Claude_1.40609.0.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat
          catalog. Status 0xC000003A.
          (logged 3x)

18:18:10  Event 3033  Code Integrity determined that a process
          (\Device\HarddiskVolume3\Program Files\WindowsApps\
          Claude_1.40609.0.0_x64__pzs8sxrjxfjjc\app\claude.exe)
          attempted to load
          \Device\HarddiskVolume3\Program Files\WindowsApps\
          Claude_1.40609.0.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll
          that did not meet the Microsoft signing level requirements.

0xC000003A = STATUS_OBJECT_PATH_NOT_FOUND. The catalog file simply is not there.

Verified on disk

$pkg = "C:\Program Files\WindowsApps\Claude_1.40609.0.0_x64__pzs8sxrjxfjjc"
Test-Path "$pkg\AppxMetadata\CodeIntegrity.cat"   # -> False
Test-Path "$pkg\app\vk_swiftshader.dll"           # -> True (5,550,416 bytes)
Get-AppxPackage -Name *Claude* | Select-Object Status   # -> Ok

vk_swiftshader.dll ships and is present. AppxMetadata\CodeIntegrity.cat, the catalog that would let Code Integrity Guard accept it, is absent — and Get-AppxPackage still reports Status: Ok, so nothing surfaces the problem until something exercises the software-GL path.

Failure chain

1. Browser pane renders a page needing WebGL or the software-GL fallback (Turnstile / bot-detection probe pages hit this reliably).
2. Chromium GPU process tries to load the bundled vk_swiftshader.dll.
3. Code Integrity Guard — enforced for MSIX/Store-packaged apps — looks for AppxMetadata\CodeIntegrity.cat to validate it. Missing → 0xC000003A.
4. DLL blocked → GPU process aborts 0x060C201E.
5. App dies; package left needing a Repair.

Note the Repair does not restore the catalog: after repairing, CodeIntegrity.cat is still missing on my machine, so the next Browser-pane page that touches WebGL will do it again.

Check for anyone else on this thread

$p = (Get-AppxPackage -Name *Claude*).InstallLocation
"cat present: $(Test-Path "$p\AppxMetadata\CodeIntegrity.cat")"
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-CodeIntegrity/Operational'; Id=3010,3033} -MaxEvents 20 |
  Where-Object { $_.Message -match 'Claude' } |
  Select-Object TimeCreated, Id, Message

cat present: False plus 3010/3033 naming vk_swiftshader.dll = this bug.

Suggested fixes

• Ship AppxMetadata\CodeIntegrity.cat and make sure in-place updates do not drop or invalidate it (a Repair should restore it too — currently it does not).
• Or stop bundling vk_swiftshader.dll, or gate the software-GL fallback so a blocked load degrades instead of killing the GPU process.
• Self-check for the missing catalog at startup and warn, instead of failing later when the Browser pane is used.
• Make a GPU-process crash non-fatal to the app — losing the Browser pane should not take down an active Claude Code session.

Authored by AI (Claude - Opus 5 w. ultracode-thinking), approved by me - a human :)

---

Data point: the graphics stack has now rolled twice with no change in behaviour

@DrRIH's argument on #81341 that a Chromium/Electron bump will not fix this now has empirical
backing from this end. Measured on one machine across eleven affected builds:

| build | Electron | ANGLE libGLESv2 | outcome |
|---|---|---|---|
| 1.24012.9 → 1.30096.5 (7 builds) | 42.7.0 | 2.1.27535 12f433eacb2f | crashes |
| 1.32352.1 → 1.34493.1 (3 builds) | 42.9.2 | 2.1.27552 717d90d3aa17 | crashes |
| 1.40609.0 | 42.10.0 | 2.1.27552 155e65003be7 (rebuilt) | crashes |

Two full rolls of Electron, and ANGLE rebuilt underneath — 15 crashes across 11 builds,
2026-07-27 → 2026-09-01, exit 101457950 every time.

Signing state across all of it is unchanged: vk_swiftshader.dll still CN="Anthropic, PBC",
AppxMetadata\CodeIntegrity.cat still absent. (The DLL binary does change with each roll —
5,546,832 → 5,550,416 bytes on 1.40609.0 — but that is the upstream roll, not a re-sign. I
briefly misread that size change as intent and am flagging it so nobody else does.)

The most recent occurrence was not an induced repro: 2026-09-01 19:42:57 on 1.40609.0, during
ordinary use, with origin: 'https://brunhild.challenges.cloudflare.com' logged immediately
before the GPU process died, and a CodeIntegrity 3033 at the same second.

Practical implication: if anyone is waiting for the next Electron/Chromium bump to resolve
this, two have now landed and neither did. The fix has to be the packaging change this thread
already identified.

*(I make no claim about whether any particular upstream Chromium commit is present in 42.10.0 —
I have not verified that. Only the version roll and the unchanged outcome are measured here.)*

Correction to my previous comment — my "1-in-7" caution was unsound, retracting it

Retracting the caution I posted above against the packaging hypothesis. My reasoning was wrong, and @MatusPohorenec's chain fits this machine exactly.

Why it was wrong. I argued that only 3 CodeIntegrity 3010 events existed here against 7 GPU crashes, so the correlation was weak. I never checked the log's retention. On this machine Microsoft-Windows-CodeIntegrity/Operational is capped at 1,028 KB / ~1,500 records and rolls in hours — checked today, its oldest surviving record was from 09:27 the same morning. My six earlier crashes (2026-08-24 → 08-31) were far outside that window. Absence of events there was not evidence of absence, it was evidence of rotation. I also queried only Id 3010 and never 3033 — the event that actually names the blocked module. Sorry for the noise.

Confirming data from this machine — Claude Desktop 1.40609.0.0 (MSIX), Windows 11 Pro 26200, i5-12400F, RTX 3050 6 GB:

AppxMetadata\CodeIntegrity.cat   -> False  (absent)
app\vk_swiftshader.dll           -> True,  5,550,416 bytes
Authenticode                     -> Valid, CN="Anthropic, PBC"
Get-AppxPackage Status           -> Ok

Same byte size @InfiniteBSOD reports for 1.40609.0, and the DLL is correctly signed — so the binary is fine. What is missing is only the catalog that would let Code Integrity Guard accept it, while Status: Ok keeps the package looking healthy.

This also fits the trigger here: all 7 crashes followed the Browser pane opening an external site, and the one I reproduced deliberately was a Cloudflare-style bot-check interstitial — i.e. exactly the software-GL path @MatusPohorenec describes.

My earlier WER result now has a mechanism. With LocalDumps enabled before reproducing, the crash produced no dump at all and no Application Error / APPCRASH entry, while msedge.exe produced proper Event ID 1000 records on the same machine in the same window. That is consistent with a blocked module load aborting the GPU process rather than a fault — nothing for WER to catch.

Agreeing with the asks already on the thread: ship the catalog and have Repair restore it; and make a GPU-process death non-fatal to the host, so losing the Browser pane does not take down every running session.

Pointer for anyone arriving new on this thread: #81341 has the fuller root-cause analysis, and it predates most of what has been posted here — mine included.

I posted my Code Integrity findings above as if they were new. They were not. @allarounderservices filed #81341 on 2026-07-26 with the same chain already proven, and in more depth than I had it:

• MicrosoftSignedOnly: ON verified on the live GPU child process via Get-ProcessMitigation — the piece I was inferring rather than measuring.
• AppxMetadata\CodeIntegrity.cat shown missing inside the downloaded MSIX itself, not only on disk after install. That makes it a build/packaging defect rather than damage from staging or from a bad update.
• A ProcDump capture of the GPU child, FAILURE_BUCKET_ID: APPLICATION_FAULT_60c201e_ntdll.dll!LdrAppxHandleIntegrityFailure — the actual kill path.
• A control group: Chrome on the same machine runs with the identical MicrosoftSignedOnly: ON on its GPU process and logs the identical CodeIntegrity 3033 event for its own vk_swiftshader.dll, and survives — because it is not MSIX-packaged. That isolates packaging as the only variable.
• A working workaround: the non-MSIX build (Claude Setup.exe --exe) — 0 crashes in 15 browser previews on a machine where the MSIX build crashed 15/15.

Credit on this thread too: @HBCreAtiveD confirmed the missing catalog here at 07:13 UTC today, ahead of my comment, including the point that reinstalling the MSIX does not recreate it.

On consolidation

Picking up @engelnightshop-lab's suggestion above. The same defect is currently spread across at least #80444 (this one), #81341, #80468, #81159, #81698, #81836, #82967 and #83478. This thread carries the most weight (94 comments, 15 reactions); #81341 carries the strongest evidence and has 29 comments. Neither has had a maintainer response.

Suggestion: treat #81341 as the canonical issue for the root cause and link the others to it, so the forensics and the reproduction counts sit in one place instead of being re-derived across eight threads.

The asks are unchanged and are already stated in #81341: ship AppxMetadata\CodeIntegrity.cat in the MSIX (or drop MicrosoftSignedOnly on the GPU process, or gate the software-GL probe), and make a GPU-process death non-fatal to the host app.

One thing I have not seen reported anywhere yet

Repair does not restore the catalog. After a successful Settings → Apps → Claude → Advanced options → Repair on 1.40609.0, AppxMetadata\CodeIntegrity.cat is still absent on my machine, and the next Browser-pane page that touches WebGL crashes the app again. This is consistent with @allarounderservices' finding that the catalog is missing inside the downloaded MSIX — Repair re-downloads the same defective package, so there is nothing for it to restore.

Practical consequence for anyone following the advice on this thread: Repair recovers the package from appxState=2, but it does not stop the crash recurring. Only the non-MSIX (--exe) build actually removes the failure path. Details posted on #81341.

Still reproducing on the current build — 6 occurrences across 4 app versions.

Confirming this on Windows 11 Pro 10.0.26200. Adding data that I think rules
out the GPU/VRAM dimension entirely.

Occurrences

| # | Timestamp (UTC-3) | appVersion | Browser pane opened | Delta |
|---|-------------------|-----------|---------------------|-------|
| 1 | 2026-08-21 18:42:04 | 1.34493.1 | 18:38:33 | 211 s |
| 2 | 2026-08-26 10:48:20 | 1.37937.1 | 10:47:30 | 50 s |
| 3 | 2026-08-26 13:46:58 | 1.37937.1 | 13:46:45 | 13 s |
| 4 | 2026-08-27 08:14:00 | 1.37937.3 | 08:13:58 | 2 s |
| 5 | 2026-08-27 08:32:08 | 1.37937.3 | 08:32:04 | 4 s |
| 6 | 2026-08-31 13:34:46 | 1.40609.0 | 13:34:42 | 4 s |

Same exitCode: 101457950 (0x060C201E) every time, and every one is preceded
by a browser preview context being created. Out of 20 total browser-pane
openings in the logs, 6 ended in a crash — a trigger, not deterministic.

Note the delta collapsing from 211 s to 2-4 s as it got worse.

2026-08-31 13:34:42 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'image' }
2026-08-31 13:34:46 [info] GPU process gone: { type:'GPU', reason:'crashed', exitCode: 101457950, serviceName: 'GPU' }

Not a GPU, driver or VRAM problem

I replaced the graphics card in the middle of this, which turned into an
accidental controlled experiment:

• Before: NVIDIA Quadro P620, 2 GB, driver 582.78 — VRAM at 89-92%
• After: NVIDIA RTX A2000, 12 GB, driver 597.06 — VRAM at ~20%

Crash #6 happened on the new card with ~10 GB of VRAM free. Combined with your
RTX 2080 (reproduced on two driver versions) and the RTX 5080 in #81698, that
is four different GPUs across three machines, spanning three driver branches
and both consumer and workstation lines.

The Windows event log records no display-driver fault at all for the entire
session: zero nvlddmkm events, zero TDR (event 4101), zero LiveKernelEvent.
If the GPU or its driver had faulted, Windows would have logged it. Nothing.
The failure is contained inside the Electron/Chromium process tree.

Also eliminated here by measurement, in case it narrows things

• RAM: 17.2 / 31.8 GB in use, pagefile peak 620 MB. Not memory pressure.
• CPU: i9-12900K averaging 1%. Not CPU.
• PSU: the cards are 70 W, slot-powered, no aux connector. Not power.
• A failing SATA controller on this machine was emitting ~3,900 correctable

PCIe errors/min. Disabling it changed nothing about this crash.

Impact and current workaround

Each crash kills every open Claude Code session with no graceful shutdown, and
leaves the MSIX package in Modified (appxState=2) requiring Repair — matching
your Bug 2 exactly. Keeping CoworkVMService on Manual start helps, since
cowork-svc.exe holds a lock on the package directory and makes Repair fail;
note that it silently reverts to Automatic on every app update.

The only reliable workaround here has been to stop using the in-app Browser
pane entirely and drive headless Chrome from a separate process instead.

Happy to provide full main.log excerpts or Windows event exports.

Adding a trigger I haven't seen called out in this thread: opening a link from the task transcript. Preferred browser was set to Chrome (Claude in Chrome), but the separate link-open setting was still on the built-in browser, and clicking any link in the chat crashed the app every time (Windows 11). Switching the link setting to Chrome stops it. Since clicking a link is a normal reflex, this is probably a more common path into the crash than agent-driven pane use, and Preferred browser alone does not prevent it. Also noting that #87750 was closed as a duplicate of this one.

Two data points for Cowork users — the group that cannot take the --exe workaround

Windows 11 Home 26200, Ryzen 5 8600G (Radeon 760M iGPU, no dGPU), MSIX 1.37937.3 → 1.40609.1. Nine fatal 0x060C201E crashes since 2026-08-21, each with the CodeIntegrity 3033 (vk_swiftshader.dll) + 3010 (AppxMetadata\CodeIntegrity.cat, 0xC000003A) pair at the same second; AppxMetadata\ absent in every package version. Adds an AMD APU to the NVIDIA/Intel/Vega reports.

1. --exe drops Cowork — per Anthropic's docs, not only inference. Deploy Claude Desktop for Windows: Cowork needs the Virtual Machine Platform and the virtualization service that only the MSIX registers; without it, "Cowork on desktop will not be available." For Cowork users the fix upthread is off the table; mitigation has to be on the trigger side.

1. permissions.deny on mcp__Claude_Browser__* does not protect Cowork sessions. Each Cowork session runs with its own CLAUDE_CONFIG_DIR (%APPDATA%\Claude\local-agent-mode-sessions\<account>\<org>\local_<id>\.claude) that has no settings.json — hooks and permission rules from ~/.claude/settings.json are never loaded there. Both of my crashes on 2026-09-01 (20:30:13, 20:35:22) came from a Cowork session with no project folder mounted, calling mcp__Claude_Browser__preview_start on a court portal behind Turnstile — while a PreToolUse hook blocking exactly that had been working in regular Claude Code sessions (10 blocks logged the day before). The CLAUDE.md seeded into those sessions is server-side ([GlobalMemory] Seeded CLAUDE.md … (source: server)) and is the text of Settings → Cowork → "Global instructions". Putting the "never open WebGL/Turnstile pages in the built-in browser; use Claude in Chrome" rule there is the only user-side control I found that reaches every Cowork session. It is prose, not enforcement — but it is the layer that was missing.

Minor: editing coworkPreferredBrowser in claude_desktop_config.json is reverted by the app on its next write (twice here); the setting lives in Settings → Cowork → Preferred browser — and per @theholler-tech it does not gate the preview path anyway.

Asks unchanged: ship the catalog, make the GPU-process death non-fatal — and let user hooks/permission rules apply inside Cowork agent-mode sessions, so the trigger can be blocked mechanically instead of by prose.

_Evidence gathered from this machine's main.log, audit.jsonl and the CodeIntegrity event log; organized with Claude (Fable 5.1 model) and reviewed by the account owner before posting._

Confirming the #81341 chain on a new environment: Windows 11 arm64 inside a Parallels VM on Apple Silicon, current build 1.40609.1. Virtual display adapter, no hardware Vulkan, so the SwiftShader fallback is trivially reachable. 3/3 reproductions today, all identical.

Environment

• Claude Desktop 1.40609.1 (Claude_1.40609.1.0_arm64__pzs8sxrjxfjjc, SignatureKind=Developer, sideloaded from claude.ai), Electron 42.10.0, Node 24.18.1, Claude Code 2.1.255
• Windows 11 Pro 25H2 26200.9168 arm64, Parallels ARM VM (Apple Silicon host), GPU = Parallels Display Adapter (WDDM) 20.18.2700.58628
• Smart App Control off, HVCI off, no WDAC policy, Get-ProcessMitigation -System all NOTSET
• AppxMetadata\ absent from the installed package; vk_swiftshader.dll Authenticode = Valid, CN="Anthropic, PBC"

Trigger: a Jira Cloud issue page loaded in the in-app Browser preview (Claude Code session driving Claude_Browser tools). Renderer log shows jira-fe.prod-east.frontend.public.atl-paas.net assets loading 1-2 s before each death. Adding Jira to the trigger list alongside Turnstile/WebGL probes.

Same-second correlation, all three occurrences (09:48:32, 10:29:13, 10:41:06 local):

• CodeIntegrity/Operational 3010 x2 (AppxMetadata\CodeIntegrity.cat, 0xC000003A) + 3033 (claude.exe -> app\vk_swiftshader.dll "did not meet the Microsoft signing level requirements")
• main.log: GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }, then silence until the next Starting app
• AppModel-Runtime/Admin Event 6 x5, ErrorCode=15612 (ERROR_NEEDS_REMEDIATION), PackageFullName=<NULL>
• Live GPU child afterwards: (Get-ProcessMitigation -Id <gpu pid>).BinarySignature -> MicrosoftSignedOnly: ON, AllowStoreSignedBinaries: OFF; main process OFF

Aftermath: each Start-menu click logs TWinUI 1621 + RegisterByPackageFullName ... ForceTargetApplicationShutdownOption,RepairAppRegistrationOption + 649 "Trying to repair ACLs ... Register next time should succeed" + 400, and the app still never starts. Only Settings > Apps > Repair recovers it; its Register step fails 0x80073D02 because CoworkVMService restarts mid-repair (as already noted upthread), app launches fine regardless.

Same 3010/3033 + exit-code signature is in this machine's CodeIntegrity log on 2026-08-12 against Claude_1.26832.0.0_arm64, so at least back to that build on arm64.

Net: GPU vendor, CPU architecture and physical vs virtual hardware are all irrelevant. The MSIX packaging (CIG on the GPU process + vendor-signed SwiftShader + no CodeIntegrity.cat) is sufficient on its own.

Same GPU-process crash signature. Two data points I think are new to this thread:
(1) the crash reproduces on BOTH GPUs of a hybrid-graphics laptop with no difference between
them, and (2) it reproduces on demand — every relaunch + Browser pane use = new crash.

Machine: HP Pavilion Gaming 15-dk1xxx · 32 GB RAM · hybrid graphics: Intel UHD 630 + NVIDIA
GeForce GTX 1650. Windows 11 25H2 build 26200.8973 — Home until 11 Aug, upgraded to Pro on
11 Aug (as an attempt to fix this); crashes continued on Pro.

Claude Desktop: MSIX/Store package (Claude_*_x64__pzs8sxrjxfjjc). Crashes observed on
1.24012.9.0 (3 Aug) and 1.28929.0.0 (12–13 Aug). Current: 1.40609.1 (69aac0), installed
30 Aug — not re-tested with the Browser pane (see below).

Evidence (Windows Application log, read 13 Aug): exitCode: 101457950 (= 0x060C201E,
"GPU process gone") ×4 on 12–13 Aug 2026, plus one earlier. The ×4 in one day is not random:
I kept repairing and relaunching the app to finish a work session, and it crashed again each
time the Browser pane was used. Reproducible on demand.

Dual-GPU: crashes occurred on the Intel iGPU (late July – 3 Aug, driver 30.0.101.1994) and,
after I assigned Claude to the NVIDIA GPU on 3 Aug (Settings > Display > Graphics > High
performance, driver 32.0.16.1088) and left it there, on the NVIDIA GPU (12–13 Aug). No
difference in behavior between the two GPUs — frequency simply tracks Browser pane usage.

Ruled out on this machine: no BSOD, no Kernel-Power 41, C:\Windows\Minidump empty with
CrashDumpEnabled=3, pagefile peak 116 MB of 10 GB, 14.6 GB RAM free at capture. Crashpad
folder empty (0 KB): the app leaves no crash dump. OS edition change (Home→Pro) had no effect.

Trigger: in-app Browser pane (preview_start / navigate / get_page_text / screenshot). Dozens
of crashes late July – 13 Aug. Two documented pages: a directory results page with a WebGL map
(~58 listings, 694 KB HTML) and a Cloudflare challenge page.

Since 13 Aug: Browser tools fully disabled (Chrome extension instead). Since ~30 Aug the machine
has a new Intel driver (31.0.101.2141), NVIDIA switched to Studio mode, and cleaned cooling
(CPU 90–95 °C → 47–50 °C); a WebGL benchmark in headless Chrome now runs stably on both GPUs.
NOT re-tested with the Claude Browser pane after these changes — not willing to trigger the
Repair cycle again, and #91273 shows the same crash on 1.40609.0 anyway.

(Separate, to avoid confusion: this machine also had chronic Intel TDR events — LKD_0x141,
igdkmd64.sys, 12 in July — from the 2022 driver under thermal throttling. Different problem,
likely fixed by the driver/cooling changes. The 101457950 crashes are the app.)

Independent confirmation of the existing diagnosis in #80444 / #80999 / #81341, with a newer Claude Desktop build and the now-released Electron fix. This is not a new root-cause claim; credit belongs to the original reporters and the Electron maintainers.

Confirmed on 2026-09-02

• Windows 11 25H2, build 26200.9168
• Claude Desktop MSIX: 1.40609.1
• Downloaded MSIX SHA-256: D0282066855A3CAC5990912350C0DE4D01BB48CA65B8B6B4CE1EC9F2C910A6F9
• Bundled runtime identifies as Electron 42.10.0 / Chrome 148.0.7778.280

Opening the Code-tab Browser Preview produced this second-exact Windows event sequence:

15:51:17.371–15:51:17.380
CodeIntegrity Event 3010 x3:
unable to load ...\AppxMetadata\CodeIntegrity.cat
Status 0xC000003A

15:51:17.393
CodeIntegrity Event 3033:
packaged claude.exe attempted to load app\vk_swiftshader.dll,
which did not meet the Microsoft signing level requirements

15:51:17.633–15:51:17.643
AppModel-Runtime Event 6 x5:
0x3CFC / package process creation blocked

15:51:18.164
AppModel-Runtime Event 217:
Claude Desktop AppX container destroyed

Inspection of the downloaded MSIX confirmed:

• app\vk_swiftshader.dll is present
• its Authenticode signature is valid and issued to Anthropic, PBC
• AppxMetadata\CodeIntegrity.cat is absent

This matches the established chain:

Browser Preview / WebGPU fallback
→ late vk_swiftshader.dll load after GPU sandbox enables MicrosoftSignedOnly
→ Code Integrity 3033
→ AppX integrity failure / GPU exit 0x060C201E (101457950)
→ GPU restart attempts blocked by 0x3CFC
→ Chromium fatal “GPU process isn't usable”
→ Desktop and active Code session terminate
→ package requires remediation

Upstream fix is available

Electron fixed this in:

• electron/electron#52700
• electron/electron#53174
• released in Electron 42.11.0

The Electron fix restores SwiftShader preloading before the Windows GPU sandbox enables MITIGATION_FORCE_MS_SIGNED_BINS.

The currently distributed Claude Desktop MSIX 1.40609.1 still uses Electron 42.10.0, so it does not contain that fix. The official non-MSIX Claude Desktop 1.44121.0 inspected on the same date also identifies as Electron 42.10.0. The non-MSIX build avoids the AppX-fatal/remediation layer, but that is a packaging workaround rather than confirmation that the underlying runtime defect is fixed.

Requested action: upgrade Claude Desktop to Electron 42.11.0 or later, or backport the equivalent SwiftShader preload fix, then validate the signed MSIX with Browser Preview pages that call navigator.gpu.requestAdapter({ forceFallbackAdapter: true }).

Another data point, now on 1.40609.1: Claude Desktop 1.40609.1 (MSIX, Windows 11 Pro 26200), CCD 2.1.255, AMD Radeon integrated graphics (driver 32.0.31041.1004, driver date 2026-08-17, installed 2026-08-25), 32 GB RAM.

• 3 crashes in 18 h (2026-09-01 21:17:59, 2026-09-02 14:39:45 and 14:51:54), each GPU process gone: { reason: 'crashed', exitCode: 101457950 } about 1 s after the in-app Browser pane opened a page. In all three cases the last line before the crash was [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' } (same signature as #91290 / #91314).
• After the crash nothing more is written to main.log (not even the per-minute [process-memory] sampler lines) and the window is dead; recovered only by rebooting.
• Regression evidence on this machine: the app auto-updated 1.40609.0 -> 1.40609.1 at 20:56 local on 2026-09-01 and the first crash came 21 minutes later. Between 2026-08-11 and 2026-08-31 the Browser pane was opened 60+ times on the same machine and the same display driver with zero GPU crashes; the only earlier GPU process gone (exitCode 34) happened at the moment the display driver was installed on 2026-08-25 and was recovered gracefully. The private-resolving host log message itself first appears after the update; earlier builds logged Blocked subresource to non-public host instead.
• Same conclusion as jasonbennett-founded in #81341: the built-in [gpu-recovery] auto-disable never fires here, because every crash takes the app down and the counter resets on relaunch.
• Separately, on 2026-09-02 10:44 Windows logged MoAppHang / Event 1002 for claude.exe with 8 concurrent sessions running (35-44 child processes, ~6 GB RSS, more than 13 GB RAM free); the whole process tree was killed. No GPU crash was involved, so possibly unrelated.

Mitigation on my side until this is fixed: "permissions": { "deny": ["mcp__Claude_Browser"] } in ~/.claude/settings.json, so sessions cannot open the pane at all.

Still reproducing many versions later, and on Windows 10 — adding a scope data point rather than a new report.

Environment

• Claude Desktop 1.40609.1.0 (MSIX Claude_1.40609.1.0_x64__pzs8sxrjxfjjc), Claude Code binary 2.1.255
• Windows 10 Pro 22H2 (10.0.19045) — every other report I found in this cluster is Windows 11, so this is not Win11-specific
• NVIDIA RTX 3070, 32 GB RAM

Independently confirms your not-driver-specific finding, across a wider gap. Reproduced identically on driver 560.94 (Aug 2024) and again on 616.56 (Aug 2026) after a Custom → Clean Installation. exitCode is byte-identical on both — 101457950 / 0x060C201E — so a two-year driver jump and a different GPU generation than your 2080 change nothing.

Signature, five occurrences, each 0–2s after the PreviewContext warning:

2026-08-27 12:12:37 blocked -> 12:12:38 crash
2026-09-02 08:00:14 blocked -> 08:00:14 crash
2026-09-02 08:04:08 blocked -> 08:04:09 crash
2026-09-02 08:26:50 blocked -> 08:26:51 crash
2026-09-02 10:36:56 blocked -> 10:36:58 crash

Five [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' } lines in the whole log, five crashes, 1:1 with no unpaired instances either way.

Supports the session-resume re-trigger in #90461. Four of the five fired shortly after Starting app, with no user-initiated preview call:

08:00:09 start -> 08:00:14 crash     5s
08:03:57 start -> 08:04:09 crash    12s
08:25:13 start -> 08:26:51 crash    1m38s
10:34:46 start -> 10:36:58 crash    2m12s

The last one is a clean example of the loop: nvidia.com was opened in the in-app Browser pane, the machine was rebooted, session restore reloaded that pane, and it crashed 2m12s after launch. NVIDIA's site runs bot detection, which matches the WebGL capability-probe mechanism in your original report.

Workaround that has held so far: driving the real browser via the Claude-in-Chrome tools instead of the in-app Browser pane. No crashes since switching. Worth noting for anyone landing here, since the MSIX packaging means there is no shortcut to attach --disable-gpu-compositing or --disable-gpu to.

Three reinstalls with a reboot each also changed nothing, and [process-memory] logged 16–17 GB free of 32 GB at every crash, so it is not memory pressure.

Adding crash dumps and a stable module offset — the earlier reports here have the exit code but, as #84992 notes, "no dumps, no Claude.exe module offsets provided." Four dumps captured on one box today, all four identical.

Environment: Windows 11 Home 10.0.26200 · Claude Desktop 1.40609.1.0 (MSIX, Claude_pzs8sxrjxfjjc) · NVIDIA RTX 4060 · 16 GB.

The assertion, read out of the dump

[FATAL:content/browser/gpu/gpu_data_manager_impl_private.cc:418]
    GPU process isn't usable. Goodbye.

gpu_last_exit_reason    crashed
gpu_last_exit_code_hex  0x060C201E
gpu_last_exit_code      101457950
ptype                   browser

ptype=browser matters: the browser process is not faulting on the GPU — it deliberately aborts (__debugbreak(), 0x80000003) after GpuDataManagerImplPrivate gives up on repeated GPU-process failures. That is why the whole app dies rather than the GPU process being respawned.

Four crashes, one instruction

| | #1 | #2 | #3 | #4 |
|---|---|---|---|---|
| exception | 0x80000003 | 0x80000003 | 0x80000003 | 0x80000003 |
| Claude.exe offset | +0x6E89D89 | +0x6E89D89 | +0x6E89D89 | +0x6E89D89 |
| absolute address | 0x7FF682F39D89 | 0x7FF7C5649D89 | 0x7FF729889D89 | 0x7FF6A40E9D89 |
| uptime at crash | 13.6 min | 21.6 min | 52.5 min | 47.3 min |
| GPU exit code | 0x060C201E | 0x060C201E | 0x060C201E | 0x060C201E |

Absolute addresses differ (ASLR); the module-relative offset never moves. Different pids, threads, uptimes and module counts (109/105/105/100). One deterministic assertion, not a random or environmental fault. Uptime varying 13–52 min fits "abort after N GPU-process failures" rather than a timer or a leak.

Ruled out here by experiment, so others can skip them

• GPU driver. 32.0.16.1088 → 32.0.16.1656 + reboot. Crash #4 came 47 min later, unchanged. Zero TDRs (Id 4101/4102) and zero nvlddmkm errors across 14 days throughout — the display driver never faults, only Chromium's GPU process.
• Stale GPU/shader caches. GPUCache, DawnGraphiteCache, DawnWebGPUCache deleted and rebuilt against the new driver. Unchanged.
• Memory pressure. Crash #4 fired 50 minutes after a clean reboot at 29% commit.
• Hardware specificity. Reports in this thread cover RTX 5070 and Intel Iris Xe; this is an RTX 4060. Not GPU-vendor specific.

Downstream, matching #84992

The dirty exit leaves the MSIX package Modified, NeedsRemediation. Windows' repair then fails 0x80073D02 because CoworkVMService still holds cowork-svc.exe inside the package directory, and activation returns 0x80073CFC — "package not found for this user", with PackageUserInformation empty while Get-AppxPackage still lists it.

What recovers it without uninstalling (uninstall looks unsafe — SignatureKind is Developer):

sc.exe stop CoworkVMService          # needs no elevation; skipping it fails 0x80070020
Add-AppxPackage -Path <same-version .msix> -ForceApplicationShutdown

Note Add-AppxPackage -Register <AppxManifest.xml> and -RegisterByFamilyName both report success and change nothing while the service holds the directory.

Possibly relevant

This box auto-updated to 1.44121.2.0 and has been crash-free for ~5.5 h since — too early to call, and posted only so it can be corroborated or contradicted by others still on 1.40609.x.

Happy to send the minidumps (~34 MB each) if there's somewhere to upload them.

Still reproducing on 1.40609.0.0, and the packaged fix is still absent in 1.44121.4.0.

I filed #80999, closed here as a duplicate on 2026-08-25. It has since reproduced three more times, on a considerably newer build than any I can find reported in this thread (the newest I see is 1.30096.x).

Environment

• Claude Desktop MSIX 1.40609.0.0 (all three crashes), now on 1.44121.4.0
• Claude Code CLI 2.1.252
• Windows 11 Pro 26200.9168
• Intel UHD + NVIDIA Quadro T2000 Max-Q (driver 32.0.15.8195)
• 64 GB RAM. main.log process-memory shows 43989 / 46746 / 39923 MB free at the three crashes, so this is not memory pressure.

Three crashes, identical chain each time

2026-09-01 02:37:21, 2026-09-01 07:24:48, 2026-09-03 10:16:39 (local, UTC+3). Every line below shares the same second.

CodeIntegrity 3010 x3   ...\Claude_1.40609.0.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat
                        Status 0xC000003A
CodeIntegrity 3033      claude.exe -> ...\app\vk_swiftshader.dll
                        did not meet the Microsoft signing level requirements
unknown-window.log      The powerPreference option is currently ignored when calling
                        requestAdapter() on Windows
main.log                GPU process gone: { type: 'GPU', reason: 'crashed',
                                            exitCode: 101457950, serviceName: 'GPU' }

Then the app dies and every relaunch shows the Repair dialog.

The precondition is still shipping in the current build

Checked on disk today, on 1.44121.4.0:

...\Claude_1.44121.4.0_x64__pzs8sxrjxfjjc\AppxMetadata              -> does not exist
...\Claude_1.44121.4.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll    -> present

So neither of the two packaging fixes (page hashes, or a CodeIntegrity.cat) has landed as of 1.44121.4.0.

A deterministic trigger, and a negative control that matters for triage

Unlike the hidden-pane and screenshot repros above, mine is a visible pane and an explicit navigate, with no screenshot call involved:

| action | result |
|---|---|
| Claude_Browser__navigate -> https://aluma.smarticket.co.il/show/1088 | crash in 0.7 to 2.9 s, 3/3 |
| https://example.com | no crash, and no requestAdapter() line |
| localhost dev servers | 658 pane calls in another project, zero crashes |
| the same host's plain 404 page | no crash, and no requestAdapter() line |

That last row is the important one. Whether the probe fires is page-content dependent, which I suspect is behind the "intermittent" reports here. After the 1.44121.4.0 update I retested the same URL, it survived, and I nearly concluded it was fixed. It was not: unknown-window.log showed the requestAdapter() probe never fired that run, so the trigger was simply never exercised.

A retest that survives proves nothing unless you confirm the WebGPU probe actually ran. Worth stating explicitly if anyone is verifying a candidate fix.

Second-order symptom I do not see documented here: it wedges terminal Claude Code sessions

The desktop app's death also kills in-flight CLI sessions, and the host terminal is left hung rather than exiting:

cowork-service.log:  [Server] Persistent RPC: connection ended: failed to read length: EOF

0.7 to 2.9 s after the tool call, matching the GPU death second for second. On the first crash the terminal stayed wedged for 4 h 45 min until Windows reaped it:

Application Hang 1002 / AppHangXProcB1
P1 = cmd.exe    "Waiting on Application Name" = node.exe 24.19.0.0

So the blast radius includes unsaved agent work in terminal sessions, not just the desktop window. From the user's side it presents as "Claude broke and Windows needs repairing", with no error and no WER crash report, which I expect suppresses reporting of this bug considerably.

Recovery and workaround

Recovery is Settings > Apps > Claude > Advanced options > Repair, per #80999. taskkill does not clear the Modified flag.

Workaround confirmed working here: drive real Chrome through the claude-in-chrome native-messaging tools, or use WebFetch/WebSearch. No Electron renderer is created, the GPU process never falls back to SwiftShader, and the trigger is absent.

Still reproducing on 1.44121.4 (latest as of 2026-09-03). Adding package-level evidence I have not seen in this thread, plus a correction: updating does not fix this, and disabling hardware acceleration does not either.

Environment

| | |
|---|---|
| Package | Claude_1.44121.4.0_x64__pzs8sxrjxfjjc (MSIX) |
| Runtime | Chrome/148.0.7778.280 Electron/42.10.0 (from app\Claude.exe strings; FileVersion 1.44121.4) |
| OS | Windows 11 Pro for Workstations 25H2, build 26200.9278 |
| GPU | RTX 5090, driver 32.0.16.1088 |

Three package facts

1. app\vk_swiftshader.dll ships in the package (5.29 MB), Authenticode signature Valid, signer CN="Anthropic, PBC".
2. AppxMetadata\CodeIntegrity.cat is absent from the package. The AppxMetadata folder contains no catalog at all.
3. The shipped Electron is 42.10.0. Upstream, the Chromium 148 GPU-process regression in this area is fixed in 42.11.0.

Point 2 is the one I would most like a maintainer to check. Without a package catalog, an Anthropic-signed DLL loaded into a process running under the MicrosoftSignedOnly / CIG mitigation has nothing to validate against. For an MSIX-packaged process the loader's integrity-failure path terminates the process rather than failing the load, which matches the observed exit code 0x060C201E (101457950) exactly — a loader termination code, not a Chromium result code.

I want to be explicit about what I could not confirm locally: I never captured the corresponding CodeIntegrity 3033 event. On this machine Microsoft-Windows-CodeIntegrity/Operational is capped at 1 MB and had already rolled past the crash window by the time I looked. So the mechanism above is a hypothesis; the three facts are measurements.

Reproduction and timing

Four crashes on 2026-09-02, all with exitCode: 101457950, each one 10–220 s after the in-app Browser pane opened, and never without it:

19:35:37   preview → GPU gone
22:25:50   preview 22:25:40 → GPU gone
22:48:36   preview 22:48:17 → GPU gone
23:33:47   preview 23:32:42, page loaded 23:33:32 → GPU gone

On the fourth, the renderer logged WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost at the same second. After every crash the main process stops logging entirely — no heartbeat, no periodic memory line — until Windows kills it.

Disabling hardware acceleration does not help

Worth stating plainly, because it is the workaround most often suggested. Crash 4 happened with isHardwareAccelerationDisabled: true active. The GPU process was running --use-gl=angle --use-angle=d3d11-warp-webgl and renderers --disable-gpu-compositing, and it still died with the same code. app.disableHardwareAcceleration() moves rendering to WARP but does not disable WebGPU, so the SwiftShader path is still reachable.

Related: the in-app auto-recovery never fires here. The gpu-recovery routine that disables hardware acceleration after 3 GPU deaths is gated off for MSIX installs, and in any case the main process hangs on the first death, so a streak of 3 in one session cannot accumulate. There are no [gpu-recovery] lines in any of my logs.

The repair loop, and what actually makes it long

Sequence from the Windows event logs, consistent across all four incidents:

1. GPU process dies; package status shows Modified (0x2). Nothing in any Windows log records the moment this bit is set.
2. User clicks the icon → TWinUI activation → within ~100 ms AppXSvc starts RegisterByPackageFullName with ForceTargetApplicationShutdownOption, RepairAppRegistrationOption.
3. That register step fails 0x80073D02 — "apps need to be closed" — naming Claude_pzs8sxrjxfjjc!Claude, because CoworkVMService / cowork-svc.exe is still alive. It retries.
4. Only a full RepairPackageOperation succeeds, and that re-downloads the entire MSIX from downloads.claude.ai. Measured: 2.5 to 6 minutes of download, 3 to 12 minutes end to end.

Killing Claude.exe before clicking the icon does not shorten this — the trigger is the status bit, not the live processes. Stopping cowork-svc.exe first does, because it removes the 0x80073D02 retry loop.

Requests

1. Ship CodeIntegrity.cat in the MSIX, or confirm why the package does not need one.
2. Bump Electron to 42.11.0 or newer.
3. Make the main process survive a GPU-process death instead of hanging on it — this is what turns a recoverable crash into a package repair.
4. Make CoworkVMService stop with the app, so the repair path is not blocked by its own service.

Happy to run any specific diagnostic and attach output — including re-arming the CodeIntegrity log with a larger size and reproducing on purpose, if that 3033 event would be useful to you.

Additional data point — Windows 10 22H2 / 1.40609.1 / RTX 3070: two crashes today, each 4–6 s after [Preview] Created browser preview. Created browser preview fired exactly twice today and both were followed by the GPU crash (2/2); 60+ artifact html-previews in the same log were harmless.

Environment

• Claude Desktop 1.40609.1 (MSIX Claude_1.40609.1.0_x64__pzs8sxrjxfjjc, isPackaged: true, node 24.18.1)
• Windows 10 Pro 22H2 (10.0.19045) — second Windows 10 report in this thread
• NVIDIA GeForce RTX 3070, driver 32.0.16.1047 (2026-05-19), 64 GB RAM
• ~18 Claude Code (CCD) sessions open; an external 1-minute watchdog samples the process tree, Process.Responding of the app root, and Get-AppxPackage Status

Timeline (local UTC+8), from %LOCALAPPDATA%\Claude\Logs\main.log

15:34:14 [WarmLifecycle:preview] Warming up session <A>          (sidebar focus switch)
15:34:15 [Preview] Created session preview context
15:34:15 [Preview] Created browser preview { serverId: 'browser-preview-1788593655277-113' }
15:34:17 [process-memory] electron(18)=3888MB children(866)=18317MB tree_rss_sum=22205MB
15:34:19 GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

15:50:43 [WarmLifecycle:preview] Warming up session <B>          (sidebar focus switch)
15:50:51 [Preview] Created session preview context
15:50:51 [Preview] Created browser preview { serverId: 'browser-preview-1788594651941-0' }
15:50:57 GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

Both sessions had used the in-app Browser pane earlier. The crash happens when the app re-instantiates that preview on sidebar focus, not at the moment the agent first opens it.

Package state after crash #2 (no human interaction between crash and rescue; the user only ran PowerShell)

• Watchdog: app root Responding=True at 15:50:44, process gone at 15:51:43 — no hang phase.
• Get-AppxPackage Claude | % Status flipped to Modified, NeedsRemediation in that same minute.
• Microsoft-Windows-AppXDeploymentServer/Operational: zero deployment/Repair events between the previous reinstall (15:37:31) and the next (15:57:05).
• Application log: zero 1000/1001/1002 — Windows recorded neither a crash nor a hang.
• Microsoft-Windows-AppModel-Runtime/Admin at reinstall: state updated to 0x0 (previous state = 0x2) → appxState=2.
• File integrity: all 3,057 files listed in AppxBlockMap.xml present, zero stray files — consistent with @saymonsh's finding that the registration state, not the payload, is what gets corrupted.

Crash #1 also shows the aggravation path when Settings → Repair is clicked while package processes are still alive:

15:34:46 id=603 RepairAppRegistrationOption
15:34:46 id=638 package not updated because the app is still running {Claude_pzs8sxrjxfjjc!Claude}
15:34:46 id=419 0x80073D02
15:34:46 id=617 package status updated (Clear=0x0, Set=0x400)

Recovery that works every time (~5 s): kill WindowsApps\Claude_* processes → Add-AppxPackage <same-version .msix> -ForceApplicationShutdown -ForceUpdateFromAnyVersion → Status: Ok. Settings → Repair and Add-AppxPackage -Register do not clear it.

Side observations (possibly unrelated): CoworkVMService logs failed to configure SCM recovery actions … Access is denied on every start; C:\ProgramData\Claude\Logs\cowork-service.log has grown to 664 MB / 7.0 M lines with no rotation; the Crashpad directory holds only settings.dat/metadata — no minidumps for either crash.

Follow-up to my comment above, after reading the app's own crash handling out of app.asar (1.40609.1) — this corroborates @kai-sorensen's ptype=browser finding from a different angle:

• The app's JS child-process-gone handler for type: 'GPU' only counts deaths (gpu-crash-streak marker in userData), and only at ≥3 deaths within 5 min does it disable hardware acceleration and offer "Restart now". There is no GPU-gone → app.exit path in the app code.
• On both of today's crashes main.log ends immediately after GPU process gone: { … exitCode: 101457950 } — zero further lines until the next Starting app. The gpu-crash-streak marker was never written (the async write did not complete), and there is not a single [gpu-recovery] line in the log.

So the sequence is: one GPU-process exit with 0x060C201E → the browser process aborts (gpu_data_manager_impl_private.cc:418 "GPU process isn't usable. Goodbye.") before the app's JS gets a chance to react. That means the in-app GPU auto-recovery (disable HW accel after N deaths) is effectively unreachable in this failure mode — it assumes the app survives deaths #1 and #2.

Both of today's GPU exits came 4–6 s after [Preview] Created browser preview (the in-app Browser pane WebContentsView being re-created on sidebar focus). Windows 10 22H2 / RTX 3070 / 64 GB, details in my comment above.

Binary-level follow-up (same box as above, 1.40609.1):

• Claude.exe is a stock Electron 42.10.0 build: its CodeView GUID (02AC5507-F22E-7FF6-4C4C-44205044422E, age 1, PDB name electron.exe.pdb) resolves on symbols.electronjs.org. So the whole GPU-fallback path below is unmodified Chromium 148.0.7778.280.
• Read from the binary (capstone + .pdata): GpuProcessHost::RecordProcessCrash returns early unless recent_crash_count >= 3 (kGpuMaxCrashCount) and --disable-gpu-process-crash-limit is absent; only then does it call GpuDataManagerImpl::FallBackToNextGpuMode, which pops fallback_modes_ and LOG(FATAL)s "GPU process isn't usable. Goodbye." when the vector is empty. DisableHardwareAcceleration() merely pre-pops the hardware modes (while gpu_mode_ in {GL, Metal, Vulkan}: FallBack()), which explains why turning off hardware acceleration doesn't help: the same exits drain the remaining modes.
• Consequence: reaching "Goodbye" needs at least 6 GPU-process exits, yet main.log records exactly one GPU process gone before the process dies. The relaunch/exit loop completes inside the browser process before the app's JS handles the first child-process-gone, so the in-app streak marker / auto-disable never runs.
• 0x060C201E is not a literal constant in any PE in the package (Claude.exe, libGLESv2, vk_swiftshader, dxcompiler, vulkan-1, the .node addons, cowork-svc.exe) nor in d3d11.dll/dxgi.dll/d3d12.dll/vulkan-1.dll/two nvwgf2umx.dll versions on this machine. It looks runtime-composed; knowing what emits it on the GPU-process side would pin the root cause.

Ruling out the obvious suspects for 0x060C201E, from the binary (1.40609.1, stock Electron 42.10.0 confirmed by PDB GUID against symbols.electronjs.org):

I disassembled every call site of base::Process::TerminateCurrentProcessImmediately in claude.exe and read the exit code each one passes. There are 11, and none of them passes 0x060C201E:

| function (resolved against the official PDB) | exit code |
|---|---|
| gpu::GpuWatchdogThread::DeliberatelyTerminateToRecoverFromHang | 2 |
| viz::VizMainImpl::ExitProcess | variable |
| viz::GpuLogMessageManager::TerminateProcessOnIO | variable |
| content::ChildThreadImpl::Init / ::EnsureConnected | 0 |
| content::RenderThreadImpl::Shutdown | 0 |
| gpu::GpuChannelMessageFilter::TerminateForTesting | 0 |
| media::AudioThreadHangMonitor::TerminateCurrentProcess | 1 |
| blink::HandleChromeDebugURL | 1 |

There is exactly one KERNEL32!ExitProcess call site (CRT teardown), and the constant 0x060C201E appears nowhere in the binary, in any DLL shipped in the package, or in d3d11.dll / dxgi.dll / d3d12.dll / vulkan-1.dll / two nvwgf2umx.dll versions on this machine.

Two consequences:

1. The GPU watchdog is not the cause. If a hang had tripped DeliberatelyTerminateToRecoverFromHang, the GPU process would exit with 2, not 0x060C201E. So this is not "GPU hung, watchdog killed it".
2. The value is not a Chromium-chosen exit code at all. On Windows an unhandled exception becomes the process exit code, so 0x060C201E is most likely an exception code (its bit pattern is not a standard NTSTATUS — severity bits are 00 — which points at a third-party/custom raise), or the process was terminated by something outside Chromium.

Either way this needs a GPU-process minidump, not a browser-process one. The browser-process dumps posted earlier (ptype=browser, base::ImmediateCrash at the IntentionallyCrashBrowserForUnusableGpuProcess path) only show the downstream deliberate abort.

For completeness, the browser-side chain resolved against the PDB is: GpuProcessHost::RecordProcessCrash → IncrementCrashCount → (>= 3 crashes) → GpuDataManagerImpl::FallBackToNextGpuModeDueToCrash → GpuDataManagerImplPrivate::FallBackToNextGpuMode → when fallback_modes_ is empty → IntentionallyCrashBrowserForUnusableGpuProcess → logging::LogMessage::HandleFatal → base::ImmediateCrash.

Negative data point on 1.52386.3.0: did not reproduce in one short run. Same machine where I reported six crashes with exitCode 101457950 in #81840 (2026-08-16, app 1.30096.5).

Environment

• Claude Desktop MSIX Claude_1.52386.3.0_x64__pzs8sxrjxfjjc, Claude Code engine 2.1.266
• Windows 11 Pro 25H2, build 26200.9445
• NVIDIA GeForce RTX 4090, driver 32.0.16.1088 (2026-07-22), single adapter

What I did (2026-09-13, local time)

• In the in-app Browser pane opened https://nowsecure.nl (Cloudflare Turnstile widget on an animated 3D card, visible in the pane), then https://itch.io in a second tab. itch.io's Cloudflare interstitial is what @Eltacolibre used for deliberate reproduction in #81840.
• The app's network service had established TCP connections to the Cloudflare addresses of both hosts (created 01:05:49 and 01:07:40).
• Borrowing @Eltacolibre's approach from #81840: an external pwsh watcher held open handles to the main claude.exe and the --type=gpu-process child and polled once per second for exit codes, from 01:05:55 until I stopped it at about 01:08:10.

Result

• The main process and the GPU process kept the same PIDs they had at app start (00:54:39 / 00:54:41) — checked at the end of the run and again at 01:11, so neither was restarted during the test.
• The watcher logged no exit events.

Caveats

• A single short run. The watcher started ~6 s after the first connection to nowsecure.nl, so the no-restart conclusion rests on the unchanged PIDs rather than on the watcher alone.
• Crashes were intermittent for some reporters, so this is a negative data point, not proof of a fix.
• No crash dumps in %APPDATA%\Claude\Crashpad, but that is weak evidence: it stayed empty during real crashes in #81840 too.
• %APPDATA%\Claude\logs\main.log has not been written since 2026-08-21 on this machine, so I could not check for the Blocked subresource to private-resolving host precursor.

any hints about fixed release version?

I noticed that this issue has been closed, but I could not find a clear explanation for the closure.

Given that this problem has been reported and reproduced by multiple users, it would be very helpful if the Claude team could clarify why the issue was closed.

In particular:

• Was the underlying problem fixed?
• If so, in which Claude Desktop version was the fix released?
• If it was not fixed, was the issue superseded by another issue or tracking mechanism?
• Is there an official workaround for users who still encounter the MSIX / CoworkVMService / Modified, NeedsRemediation behavior?

My own issue was closed as a duplicate and ultimately pointed to this issue as the canonical report, so the closure of this issue without an explanation leaves it unclear whether the underlying problem is considered resolved.

A short maintainer note explaining the closure status would be greatly appreciated, especially for users who are still trying to determine whether it is safe to return to the MSIX/Cowork installation.