[Windows] Desktop app: GPU process crash (exit code 101457950) kills entire app and all running sessions
Environment
- App: Claude desktop app 1.24012.9 (MSIX install), Claude Code (CCD) 2.1.219, bundled Node 24.18.0
- OS: Windows 11 Home, build 10.0.26200
- GPU: NVIDIA GeForce RTX 5080 Laptop GPU, driver 610.47
- RAM: 32 GB (~16 GB free at last crash per the app's own process-memory log line)
What happens
The desktop app fully crashes — the window disappears and every running Claude Code session is killed mid-flight. This has happened repeatedly (2026-07-25 and again 2026-07-27), always with the same log signature.
Evidence from %APPDATA%\Claude\logs\main.log
Both crashes have the identical signature — the Electron GPU process dies, and the app goes down with it instead of recovering:
2026-07-25 16:56:17 [info] GPU process gone: {
type: 'GPU',
reason: 'crashed',
exitCode: 101457950,
serviceName: 'GPU'
}2026-07-27 11:56:26 [info] GPU process gone: {
type: 'GPU',
reason: 'crashed',
exitCode: 101457950,
serviceName: 'GPU'
}After each GPU process gone line there is no recovery attempt logged — the next line in the log is a fresh app start (Starting app { appVersion: '1.24012.9', ... }) from when I manually relaunched.
Likely trigger: WebGL/WebGPU content
%APPDATA%\Claude\logs\unknown-window.log shows that in the final second before the 2026-07-27 crash, a renderer window emitted a burst of WebGL errors followed by a WebGPU adapter request:
11:56:25 [warn] WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat
(repeated ~20x, some with "when EXT_color_buffer_float is not enabled")
11:56:26 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127The GPU process crashed at 11:56:26, immediately after.
Not a driver reset
The Windows System event log has no Display/nvlddmkm/Dxgkrnl TDR events at either crash time — the failure is contained to Chromium's GPU process, not a full NVIDIA driver reset.
Possibly related
2026-07-17: MoAppHang WER report on app version 1.22209.0.0 (claude.exe stopped interacting with Windows and was closed). May be a separate issue.
Expected behavior
A GPU-process crash shouldn't take down the whole app (Chromium normally relaunches the GPU process and repaints). At minimum, running Claude Code sessions should survive or auto-resume — losing all in-flight sessions and subagent work on every GPU hiccup is the painful part.
Impact
Repeated total loss of in-flight work: one crash killed multiple active sessions, including parallel subagent runs whose results were lost entirely.
Showing cached comments. Read the full discussion on GitHub ↗
52 Comments
4th occurrence — 2026-07-29 23:36:41 EDT, with the clearest trigger trace yet
Environment: app 1.24012.9 (MSIX), Node 24.18.0, Windows 11 Home 26200, RTX 5080 Laptop (driver 610.47), 32 GB RAM.
What happened
The Electron GPU process crashed and the entire app exited with it, killing every in-flight
session. Same exit code as the 2026-07-25 and 2026-07-27 occurrences — this is the 4th.
No recovery attempt — the next line in
main.logis a fresh app start ~8 minutes later (manualrelaunch). There is no renderer-crash or OOM line:
[process-memory]sampling showed a flat~1.4 GB tree RSS against 18.6 GB free system memory, so memory pressure is ruled out.
Not a driver-level TDR either: no
nvlddmkm/Dxgkrnlevents in the Windows System event log atthe crash time on any of the four occurrences. The fault is contained to Chromium's GPU process.
Trigger — the last second before death (
unknown-window.log)This is the clearest trace of the four. In the final ~1 s a window did WebGL float-buffer work,
then requested a WebGPU adapter, and then the GPU instance was reported gone:
A valid external Instance reference no longer exists.is a Dawn/WebGPU message and is the lastline written before the process death — i.e. the WebGPU instance was invalidated at the moment the
GPU process died.
Suspected repro shape: a window doing WebGL float-texture work
(
getInternalformatParameteragainst float internalformats withoutEXT_color_buffer_float) thatalso calls
requestAdapter()for WebGPU. On this machine that means an artifact / preview / in-appbrowser-pane page rendering canvas or 3D content. Every one of the four crashes was preceded by
WebGL+WebGPU activity in an app window.
Impact: because the app exits rather than restarting the GPU process, every concurrent session
dies. On this machine that is routinely 3–6 sessions of in-flight work.
Requests: (1) treat GPU-process death as recoverable — respawn it instead of taking the app
down; (2) if WebGPU/WebGL content in an app window can destabilise the shared GPU process, isolate
or software-fallback it.
same crash on totally different hardware, so this isnt a driver thing.
youre on a 5080 laptop / 610.47 / Win11, im on a 5090 desktop / 610.74 / Win10, and we get a byte-identical crash. two cards, two driver branches, two windows versions, so its the app.
crashed 2026-07-30 08:53:29, ~17 min into the session:
unknown-window.log has your exact sequence in the last second, ~16 of these then it dies:
main.log goes silent after that until i relaunched 6 min later, so the whole app died, took my running Claude Code session with it.
stuff i ruled out: full DDU wipe + clean 610.74 reinstall (crashed again first launch), older driver branch, and i cant even test with hw accel off since MSIX wont let you launch the exe with
--disable-gpuand theres no config toggle (grepped all the json). #81840 says it crashes with it off anyway. clearing the shader caches (GPUCache,DawnGraphiteCache,DawnWebGPUCache, plus the copies underPartitions\launch-preview-static\) cut it from ~7 crashes in 3 days to 1 in 2 days, but doesnt fix it.the worse half: every time it goes down the package flips to
Modified, NeedsRemediationand wont launch, "There's a problem with Claude. Reinstall the application". same as #81992 / #81836. and the obvious fix fails:0x80070020 is a sharing violation, and killing the Claude.exe procs doesnt help because whats holding that file is a service called
CoworkVMService(auto start, runs cowork-svc.exe out of the package dir). so nothing looks like its running but the file is locked. took me way too long to find that.this seems to work, elevated:
Claude.exeunderWindowsApps(if you use the CLI dont kill.local\bin\claude.exe)Stop-Service -Name CoworkVMService -Force, kill any leftovercowork-svc.exeAdd-AppxPackage -Path <the ~246mb Claude-*.msix sitting in %TEMP%> -ForceApplicationShutdown -ForceUpdateFromAnyVersionStart-Service CoworkVMServiceback to
Status: Ok. rebooting does not clear the package state, and reinstalling from claude.ai/download just gets you 1.24012.9 again so thats no help either.can attach full main.log / unknown-window.log if it helps, theres no tokens in them.
got a reliable repro, and its not a GPU load thing at all.
had Claude open my project page on itch.io in the in-app Browser pane, that rendered fine. then navigated to the edit page for it (the logged in editor/dashboard) and the whole app died about 45 seconds later. public page fine, edit page fatal, repeated it on purpose.
before that i'd been hammering shadertoy in a few tabs in chrome on the same machine, same 5090, same 610.74 driver, zero problems. so whatever this is its not raw GPU load or the driver, chrome drives the same chromium/ANGLE stack on the same card all day without flinching. its something that specific page does on load.
full sequence,
unknown-window.log+main.loginterleaved:two bits i havent seen mentioned in this thread or the related ones:
CONTEXT_LOST_WEBGL: loseContexttrailing the crash.app went from 11 processes to 2, took my running Claude Code session with it again, and the package flipped straight back to
Modified, NeedsRemediationso it wouldnt relaunch until i ran the CoworkVMService dance from my earlier comment.if anyone else wants to try reproducing: point the in-app Browser pane at a logged-in editor/dashboard page on a site rather than a public one. thats the difference that did it for me, and i dont think you need anything GPU heavy at all.
Adding a data point with forensics that may help: 4 identical crashes in ~24 hours on this machine — desktop 1.24012.9 (MSIX
Claude_1.24012.9.0_x64__pzs8sxrjxfjjc), Windows 11 Home 10.0.26200, 32 GB RAM, NVIDIA RTX 4060 Ti. Same signature as OP in%APPDATA%\Claude\logs\main.logevery time:with the main process dead the same second (the Cowork VM service log shows the app's RPC pipe EOF within ~250 ms). Each crash killed 3–4 running Claude Code sessions mid-turn, and one killed a 5-agent workflow moments after it spawned (journal: 5
started, 0 results).Crash timestamps (local, US Central): 2026-07-30 22:40:08, 2026-07-30 22:52:22, 2026-07-31 11:18:00, 2026-07-31 11:50:02.
Trigger correlation — Browser/preview pane. In all four crashes, the pane was being opened or driven seconds before the GPU death (cross-referencing main.log with the session transcripts' tool calls):
| preview activity | GPU gone | gap |
|---|---|---|
| 22:39:56 session calls
preview_start; 22:39:58[PreviewContext] Opened preview user tab+[Preview] Created browser preview| 22:40:08 | 10–12 s || 22:52:08 session calls
preview_start; 22:52:10[Preview] Created browser preview| 22:52:22 | 12–14 s || 11:17:27 session calls
preview_stop, then 11:17:44navigate+ 11:17:55get_page_text(re-driving the pane; anext buildwas also running) | 11:18:00 | 5–16 s || 11:49:58
[Preview] Created session preview context { totalContexts: 2 }— UI auto-restoring the preview of an already-finished session; no build, light load | 11:50:02 | 4 s |Update — exact repro URL identified. Cross-referencing the session transcripts: in all four crashes the pane was loading
https://one.dash.cloudflare.com/(the Cloudflare Zero Trust dashboard — Turnstile-protected, WebGL/canvas-heavy):preview_startto that URL at 22:39:56 → crash 22:40:08;preview_startagain at 22:52:08 → crash 22:52:22;navigateto it at 11:17:44 → crash 11:18:00; and the 11:49:58 event was the UI restoring that session's preview context, whose last URL was that same dashboard → crash 11:50:02. So on this machine, opening one.dash.cloudflare.com in the pane is a 4-for-4 reliable kill, including via session-preview restore. This lines up exactly with the Cloudflare/Turnstile repros in #80483 / #80978. Meanwhile a different session made 175+ Browser-pane tool calls against localhost dev-server pages the same day with no crash landing on its timestamps — plain localhost content seems mostly tolerated. Consistent with #81275 / #81398 / #81578; and #81275's WARP-software-rendering repro suggests GPU vendor/driver is irrelevant.Nothing reaches telemetry, it seems: no WER Event 1000, no crash dump for claude.exe, no display-driver TDR events at any of the four times, and the local Sentry queue (
...\Claude\sentry\queue-v2.json) looks empty afterward.The operationally worst part — the app can't relaunch after the crash.
Microsoft-Windows-AppXDeploymentServer/Operationalshows that after each abnormal exit, every launch click startsRegisterByPackageFullNamewithForceTargetApplicationShutdownOption, RepairAppRegistrationOption— ~31 seconds each (incl. "Trying to repair ACLs … repaired successfully") — which finishes "successfully" but the app still never appears; the user just sees the "needs to be repaired / still running" dialog again. On 07-30 Windows escalated by itself to a fullRepairPackageOperation(re-downloaded the .msix from downloads.claude.ai), whose final Register step failed with 0x80073D02 (package in use). Settings → Apps → Claude → Repair can never succeed because the packaged serviceCoworkVMServiceis StartType=Automatic and is already running from boot, so the package is always "in use" even right after a reboot — this is exactly #73694. There is also no Terminate button on the Advanced options page for this app.The only recovery that works (verified 3×, ~6 seconds): re-run the installer .msix. Its initial
RemovewithPreserveApplicationDatafails with 0x80073CFA, but the subsequentAddwithForceApplicationShutdownOption, ForceUpdateFromAnyVersionsucceeds and the app launches immediately. Stopping the service first (Stop-Service CoworkVMService -Forceelevated) should also unblock the Settings-Repair path.What survives: user data and all session transcripts made it through all four crashes (every session
.jsonlends in valid JSON and resumes cleanly) — the damage is confined to the GPU process and the package registration state.Happy to provide
main.log,C:\ProgramData\Claude\Logs\cowork-service.log, and aMicrosoft-Windows-AppXDeploymentServer/Operationalexport covering all four windows.Same setup here, Claude Desktop 1.24012.9 (MSIX), CCD 2.1.219, Windows 11 Pro 10.0.26200, 32GB RAM.
Got hit twice on 2026-08-02, about 11 minutes apart. Both times main.log shows
GPU process gone: {type: 'GPU', reason: 'crashed', exitCode: 101457950}and then the log just ends, whole app gone, no error dialog. First one at 20:22:43, a few minutes after I kicked off 3 background subagents (the session also had a bunch of big screenshots in it). Second one at 20:33:19, six minutes after relaunching, right after dispatching 5 more subagents. The restarts logged two Sentry events,5b75cdf3cfbf48b68be44d6f65141836andec9ac656d95a4e539991f65a2a6fc4e4.One thing that might help narrow it down. The next day the same machine ran a workflow with 4 subagents for 20+ minutes without any problem, but that UI is the compact progress tree and the transcript had no big images. So I don't think it's the number of subagents. Looks more like rendering load (several streaming panes plus lots of screenshots at once) or some bad GPU/driver state at that moment. Not memory either, the app's own process-memory line showed 17+ GB free seconds before it died.
Can pull more from main.log if that helps.
Our 4-for-4 turns out to be a third-machine confirmation of @keihoag's repro shape. The page our Browser pane was loading at every one of our four crashes was
one.dash.cloudflare.com— the Cloudflare Zero Trust dashboard, i.e. exactly a logged-in dashboard SPA — including one crash where merely viewing an already-finished session auto-restored its preview context onto that URL (dead 4 seconds later). Meanwhile a different session drove 175+ Browser-pane tool calls against plain localhost dev pages the same day with no crash landing on its timestamps. Public/plain pages tolerated, logged-in dashboard fatal — now shown on a third hardware config (RTX 4060 Ti, Windows 11 Home 26200, 1.24012.9 MSIX).@gs-imak yours is the interesting outlier: no Browser pane at all, just subagent dispatch with big screenshots and several streaming panes. If you're up for one more pull from the logs:
unknown-window.loginterleaved withmain.logat 20:22:43 and 20:33:19 — specifically whether the final second shows the signature @J-dev2 and @keihoag both captured:(± the OTS/WOFF2 font error keihoag saw). If that trio shows up on your crashes with no pane open, then the same WebGL+WebGPU→Dawn path is reachable from the app's own UI surfaces (streaming panes / large screenshot renders), not just Browser-pane web content — which would considerably widen where the fix needs to sit. If it doesn't show up, you may have found a second, distinct path to the same
101457950exit.Two smaller data points for the thread:
CoworkVMService(auto-start, runscowork-svc.exeout of the package dir) keeps the package "in use" even straight after a reboot, and ourAppXDeploymentServerlog additionally shows every post-crash launch click burning ~31 s in a silentRepairAppRegistrationcycle that "succeeds" without restoring launchability. Re-running the installer .msix recovered in ~6 s every time (its initialRemovefails 0x80073CFA, then theAddwithForceApplicationShutdown/ForceUpdateFromAnyVersiongoes through). Third machine confirming that whole failure/recovery chain.…\Claude\sentry\queue-v2.json) was empty after all four crashes — so @gs-imak's two Sentry event IDs above may be the only crash handles anyone from the team can actually look up from this thread.Since keeping the pane closed (and specifically away from that dashboard): zero recurrences here — though usage since Friday has been light, so treat that as weak confirmation only.
Hit the identical signature today (2026-08-03) on a Windows Server 2025 VM — adding this since our environment differs from the reports above in a way that points at a possibly distinct trigger path.
Environment
Get-CimInstance Win32_VideoControllerreturns no video controller at all on this VM, so Chromium has no real graphics hardware to fall back onTrigger: both crashes happened within 1–2 seconds of opening a new Browser preview tab/session (an additional Chromium renderer + GPU compositing surface) while the system was already under memory pressure. Reproduced twice in a ~6 minute window.
main.log:No recovery attempt between the crash and the cold restart — same as reported above. Repeated identically ~3 minutes later after a manual relaunch, again ~1-2s after opening another Browser preview tab.
Crashpad:
Crashpad/reportswas empty after both crashes — no dump captured, consistent with what's described in #81836.Given no-GPU-hardware + low-RAM is a different root condition than the hybrid-GPU-switching or WebGL/WebGPU-probe triggers described elsewhere in this thread and in #81836, it might be worth confirming whether the fix path covers a "no GPU adapter available" fallback (e.g. forcing software compositing rather than letting the GPU process attempt and crash) in addition to the hybrid-GPU and driver-related cases.
OP here. Adding a data point that cuts the other way from every report in this thread so far: a GPU-process crash on this same machine that the app survived.
Same environment as my original report — 1.24012.9 (MSIX), Node 24.18.0, Windows 11 Home 26200, RTX 5080 Laptop, driver 610.47, 32 GB.
2026-08-02 02:46:10 local —
GPU process gone, butexitCode: 34, not101457950:The app did not go down, and the GPU process was respawned. The app's own
[process-memory]sampling shows the GPU child PID changing across the crash:There is no
Starting appline anywhere between2026-08-01 21:14:46and2026-08-03 04:43:21, so this was not a relaunch — the same app instance kept running for roughly 26 more hours. No sessions were lost. Memory was not a factor either: 14.2 GB free of 32.5 GB, tree RSS 1.66 GB.Why I think this is worth having in the thread: it shows the Chromium GPU-process respawn path is present and works in this app. So the "app exits instead of recovering" behavior everyone here is reporting is not a general absence of recovery — something about the
101457950failure specifically takes the main process with it, while a34on the same build, same machine, same driver recovers cleanly. That narrows request (1) from my original post from "add recovery" to "find out why this one exit path bypasses the recovery that already exists."What I cannot tell you about this one: whether the WebGL/WebGPU trio was present.
unknown-window.logon this machine has no entries at all for 2026-08-02 — it jumps straight from 08-01 to 08-03 — so there is no renderer-side trace for this crash. I am not going to claim the trigger matched. The only nearby context inmain.logis a[WarmLifecycle:preview] Warming up session10 seconds prior, and a 4055 ms main-process event-loop stall in the same second as the death.@cmjdev-25 your logged-in-dashboard repro matches my behavior change: since I stopped pointing the Browser pane at anything but localhost dev servers and moved external pages to a real browser, I have not had another
101457950. Light usage caveat applies to mine too.Happy to attach
main.logfor the 08-01 to 08-03 window if the34case is useful to compare against; there are no tokens in it.Confirming this on yet another hardware/driver combo, with a couple of new data points that might help corroborate the root cause found in #83744.
Setup: Claude desktop 1.25927.0.0 (MSIX), Claude Code CLI 2.1.221, Windows 11 Home 10.0.26200, hybrid NVIDIA RTX 4050 Laptop + Intel Arc Graphics (driver 32.0.101.8424).
Trigger: not
one.dash.cloudflare.comthis time — any generic Cloudflare Turnstile-protected page reproduces it. Confirmed 100% (7/7 across 3 separate incident sessions) on a public Brazilian government-document mirror running standard Cloudflare Turnstile, nothing special about the site itself:https://leis.org/institucionais/br/aneel/lei/resolucao-homologatoria/2025/3560/resolucao-homologatoria-n-3560-2025-homologa-o-resultado-do-reajuste-tarifario-anual-de-2025-as-tarifas-de-energia-te-e-as-tarifas-de-uso-do-sistema-de-distribuicao-tusd-referentes-a-energisa-rondonia-distribuidora-de-energia-s-a-energisa-ro-e-da-outras-providenciasTiming, precisely measured: ran an external watcher process (spawned via
Win32_Process.Createso it lives outside the Claude process/job tree and survives the crash) polling the process tree every 2s. On both controlled repros, everyclaude.exeprocess of every role — main, gpu-process, all renderers, all utility, crashpad-handler — disappeared within a 13–21ms window. That's simultaneous, not cascading (a signal-driven cascade would show tens to hundreds of ms of inter-process gaps). It also took down a completely unrelated, concurrently running Claude Code session with zero relation to the browser tool — same process/job scope issue several people above already flagged.Why everyone's Crashpad folder looks empty afterward: on our first repro, Crashpad did write a ~35MB local dump about 1.6s before the mass-kill — but by the time we checked (after relaunching, which is the only way back into the app), it was gone. The app's own startup routine appears to consume/prune pending local reports on next launch. On the second repro we had the watcher copy the file out the instant it appeared, before any relaunch — that's the only reason we have dump content at all. Worth knowing for anyone still trying to catch one of these: the copy has to happen pre-relaunch, checking after the fact is too late.
What the preserved dump shows: parsing
MINIDUMP_EXCEPTION_STREAMdirectly —ExceptionCode: 0x80000003(STATUS_BREAKPOINT, a deliberateint 3, not a real hardware fault), faulting address resolves insideClaude.exeitself (+0x6DD36F9from image base), not inside any third-party DLL. That's consistent with @osmanerendgn's and @pierremorales's Code Integrity Guard finding in #83744 — if the GPU process is being killed over a rejectedvk_swiftshader.dllload, the address landing in Chromium's own GPU-init code (the caller that detects/handles the failed load) rather than in the DLL itself is exactly what I'd expect, and Crashpad synthesizing a breakpoint is a normal way for it to grab a stack right before a monitored process gets torn down. Reads like independent corroboration of the CIG theory rather than a separate cause.Given #83744 has a confirmed fix (the non-MSIX
.exebuild sidesteps Code Integrity Guard entirely), might be worth cross-linking the two threads for visibility — this one has most of the impact/reproduction history, that one has the root cause and the fix.Full timestamped watcher log and the 35MB dump available if useful. Not attaching the dump here since it's a full process memory snapshot (could contain conversation fragments/tokens) — happy to share privately if the team wants it.
Another occurrence — with what looks like a new trigger variant: the Cloudflare Turnstile challenge served by claude.ai itself.
Environment
Sequence (2026-08-07, local time, from main.log + renderer log)
13:21:08claude.ai responded with a Cloudflare challenge:``
Navigation to https://claude.ai/api/challenge_redirect?to=... failed with status code 403
Health check returned non-200 status: { status: 429, statusText: '' }
Turnstile iframe detected. Removing error overlay.
13:21:11renderer log shows a burst of WebGL probing from the Turnstile iframe — ~20 lines ofWebGL: INVALID_ENUM: getInternalformatParameter, thenCONTEXT_LOST_WEBGL: loseContext: context lost(same WebGL-error-burst signature described in the OP).13:21:11main.log:``
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
[process-memory]interval telemetry stops dead, no GPU-process relaunch, nobeforeQuit. The window disappeared, but 10+Claude.exeprocesses stayed alive for over an hour: AppX deployment events at14:29show a staged update failing with0x80073D02("apps need to be closed",Running apps: {Claude_pzs8sxrjxfjjc!Claude}), and Windows auto-ranRepairPackageOperationon the package — matching the repair-needed aftermath described in #81836 / #80444.Nothing captured the crash: no WER report, no display-driver TDR events in the System log (clean for 30 days), and
%APPDATA%\Claude\Crashpadcontains onlysettings.dat. Same silent-main-process-hang signature as #81836, on another hybrid-GPU machine.Since the trigger here was claude.ai's own bot-check (Turnstile WebGL fingerprinting) rather than user content in a Browser tab, any user of the desktop app can hit this without doing anything GPU-related themselves.
Happy to provide fuller logs if useful.
Root cause confirmed locally: Windows Code Integrity blocks
vk_swiftshader.dllinside the MSIX — the package ships withoutAppxMetadata\CodeIntegrity.catSame crash signature, and I can add the underlying mechanism with event-log evidence.
Environment: Claude Desktop MSIX 1.25927.0 → 1.26832.0, Windows 11 Pro build 26200, desktop PC (RTX 5090, driver 596.36, plus AMD iGPU and a Parsec virtual display — adapter config turns out to be irrelevant, see below).
Crashes: three full-app deaths on 2026-08-06 at 22:31:31, 23:03:19, 23:34:52 local, each logged in
main.logas:The third crash happened ~27 minutes after auto-updating to 1.26832.0, so the bug is live in the current build. I also have an earlier hit on 1.24012.9 (2026-08-02).
The smoking gun: at the exact second of every crash,
Microsoft-Windows-CodeIntegrity/Operationallogs Event 3033:immediately followed by Event 3010:
0xC000003A is STATUS_OBJECT_PATH_NOT_FOUND — and indeed the installed package has no
AppxMetadatafolder at all.vk_swiftshader.dllcarries a valid Authenticode signature (CN="Anthropic, PBC"), andGet-AppxPackagereportsSignatureKind: Developer— but Chromium applies the delayed CIG mitigation (MITIGATION_FORCE_MS_SIGNED_BINS) to the GPU process, so any DLL lazy-loaded after sandbox lockdown must validate to Microsoft signing level, which for a packaged app only the (missing) CI catalog could provide. Windows kills the GPU process with 0x060C201E (the ntdllLdrAppxHandleIntegrityFailurekill code, which is why the exit code matches no documented status). Chromium then falls back to software rendering — which requires the very DLL that was just blocked — so the fallback chain exhausts and Chromium intentionally aborts the whole browser process (IntentionallyCrashBrowserForUnusableGpuProcess:LOG(FATAL) "GPU process isn't usable. Goodbye."). That explains the whole-app death with no GPU-process relaunch attempt.Trigger needs no user WebGL content: in all my crashes the in-app Browser preview was on an ordinary consumer site (cruisecritic.com). Bot-detection/ad-tech scripts (Cloudflare Turnstile loaded seconds before one crash) probe WebGL and call WebGPU
requestAdapter(), which forces the post-lockdown lazy load of SwiftShader. Renderer log signature each time: burst ofWebGL: INVALID_ENUM: getInternalformatParameter→The powerPreference option is currently ignored when calling requestAdapter() on Windows→A valid external Instance reference no longer exists(Dawn) →CONTEXT_LOST_WEBGLat the crash second.Consistent with this mechanism, there are no TDR/
nvlddmkm/WER events at any crash — this is not a driver or hardware issue. OpenAI's desktop app has the identical failure (Event 3033 on its bundledvk_swiftshader.dll, then GPU relaunch fails): openai/codex#34133.Verify on any affected machine:
Fix directions: ship a valid
CodeIntegrity.catin the MSIX (or sign the package to Store level), preload SwiftShader before sandbox lockdown, or exempt the GPU process from CIG. Mozilla hit the same "doubly fatal under MSIX" behavior and fixed it by pre-initializing signing-policy rules: https://bugzilla.mozilla.org/show_bug.cgi?id=1796391Likely the same root cause as #80444, #82967, #83478, #81836, #83028.
Confirmed the exact mechanism on our machine too — ran your verification commands against the logs from our two controlled repros posted above.
Both Event 3033/3010 pairs land 2–7 seconds before our independently-measured mass-kill timestamps (external watcher process, polling every 2s):
10:36:39→ watcher caught the full process-tree death at10:36:4510:53:26→ watcher caught death at10:53:28Same pattern retroactively explains our original 4/4 crashes referenced further up this thread (2026-07-31, on 1.24012.9.0) — identical Event 3033 (
vk_swiftshader.dll ... did not meet the Microsoft signing level requirements) immediately followed by Event 3010 (CodeIntegrity.cat catalog ... Status 0xC000003A), at all four of those timestamps too.AppxMetadata\CodeIntegrity.catis missing on every version of the package still installed on this machine — 1.21459.1.0, 1.24012.0.0, 1.25927.0.0, and the current 1.26832.0.0. So this has been broken across at least four release cycles, not a one-off packaging slip in a single build.One more data point that might help scope the fix: the same log also shows Event 3033 rejecting a different non-Microsoft DLL under the identical missing-catalog condition —
nvspcap64.dll(NVIDIA's capture/overlay hook) — so the missing catalog isn't specific tovk_swiftshader.dll, it's blocking Microsoft-signing-level validation for the whole package indiscriminately. That particular rejection didn't correlate with a full app crash in our logs, for what it's worth — may just be a more tolerant caller than the GPU process's fallback path.Reproduced on Claude Desktop 1.26832.0 (Windows 11 Pro 26200, MSIX install), 23 occurrences over 18 days. Two findings that may narrow this down, because both cut against the NVIDIA/hardware-acceleration assumption in the reports so far.
1. It is not hardware acceleration. It still crashes with
--disable-gpu.I launched the app with
--disable-gpuand confirmed from the child-process arguments that rendering had fallen back to the Windows software rasterizer:It crashed anyway, same exit code:
So the NVIDIA driver is not in the rendering path at crash time. That points at an unguarded call in the compositing/preview path rather than a driver fault — consistent with the
WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformatwarning that precedes some occurrences.2. Trigger is Browser-preview-pane creation, within 3–6 seconds, every time.
Every one of my 23 crashes follows the creation or auto-restore of a Browser preview pane. Two consecutive examples from the same day:
This also produces a crash loop: the app restores the pane on launch, so it crashes again seconds after every restart. On 8 Aug that gave 7 crashes in 100 minutes (13:49, 13:59, 14:18, 14:31, 14:42, 14:58, 15:28 IST); on 5 Aug, 5 crashes in 32 minutes. It only stopped when I archived the session that owned the pane and blocked the pane's tools outright via a
PreToolUsehook.Other details
Display/nvlddmkm/DxgkrnlTDR events in the Windows System log at crash time — the fault is confined to the Chromium GPU process, not a driver-level GPU reset. Windows Error Reporting logsAppHangB1for the app teardown.Secondary impact worth flagging: token consumption.
Because the parent process exits rather than relaunching the GPU child, every crash kills all running Claude Code sessions and invalidates the prompt cache. Sessions are then relaunched with full-context replays (
--fork-session --resume-session-atin the relaunch arguments). With several large-context sessions open, this multiplies usage: on 8 Aug my 7-day quota went from 49% to 91% — roughly 42% of a weekly quota in one day, against 7–11% on crash-free days with comparable workload.So the missing GPU-process relaunch is not only a data-loss bug, it has a direct billing consequence for users. Even without a root-cause fix, containing the crash (relaunch the GPU process instead of exiting the app) would remove most of the harm.
---
Working mitigation (stops the crash loop completely)
This has held on my machine with zero crashes since applying it, after 7 crashes in the preceding 100 minutes. Three parts — the third is the one that actually matters.
1. What does NOT work — skip these, they cost time
--disable-gpu— still crashes, identical exit code (see above).2. Stop the crash loop across restarts
If a session has a Browser preview pane open, the app restores that pane on every launch and crashes seconds later — so it crashes in a loop and no amount of relaunching helps. Archive (or open and close the pane in) the session that owns the pane. In the app log, find which session id appears on the
[Preview] Created browser previewline right before the crash:That
sessionIdis the culprit. Archive it, or reopen it and close its Browser pane immediately.3. Block the pane from being opened again (the durable fix)
Deny the in-app Browser tools with a
PreToolUsehook, so no session can create a pane. In~/.claude/settings.json:block-browser-pane.ps1:On macOS/Linux the same thing with a shell script that echoes that JSON works identically.
Two details that make this work well in practice: putting the reason string in
permissionDecisionReasonmeans the model reads why it was denied and redirects itself to the Chrome extension instead of retrying; and because the hook lives in user settings it applies to every project and every session, including ones you have not opened yet.Verification: after adding the hook, ask a session to open a preview — the call should come back denied with your reason text, and no
[Preview] Created browser previewline should appear inmain.log.For web/UI verification while this is in place, the Chrome extension tools (
mcp__claude-in-chrome__*) do the same job and are unaffected, since they drive real Chrome out of process.OP here. Two corrections to how my earlier "no recurrences since moving off MSIX" is likely to be read, because on this machine the fix in #83744 works for a more specific reason than the version history suggests.
1. I have not run the update, and my clean streak is not evidence 1.26832.0 is fixed
Every one of the 16 desktop processes on this machine is running out of
app-1.25927.0, with the oldest alive since 2026-08-05 2:28:36 PM local.app-1.26832.0downloaded and staged on 2026-08-06 22:38 and I never restarted into it:So my data point is non-MSIX 1.25927.0, five days, zero
101457950, not 1.26832.0. @dot3x3q reports the crash live on 1.26832.0 under MSIX, and I am clean on an older build without it. That isolates the variable to the packaging rather than the app version, which I think is the useful part.For the record, my last occurrence was
2026-08-03 17:45:06local, the same second as the lastMicrosoft-Windows-CodeIntegrity/OperationalEvent 3033 namingclaude.exeon this machine. Nothing since, on either count, after switching to the non-MSIX build.2. The non-MSIX build fixes it here because it has no Cowork
This is the part I would not want a maintainer to miss: the
.exebuild is not simply "the same app, different container." It drops Cowork, and the app logs exactly that on startup:Get-Service CoworkVMServicereturns nothing on this machine now. The only Cowork artifacts left in the install tree are two icon SVGs.Which closes the loop on the mechanism in this thread: Cowork requires the MSIX package, the MSIX package is what applies Code Integrity Guard to the GPU child, and CIG is what rejects
vk_swiftshader.dlland escalates it to a process kill. The recommended fix does not neutralize CIG, it removes the reason to be inside the container at all. Anyone told to "just move to the.exebuild" is being told to give up Cowork, and that tradeoff should be stated out loud rather than discovered.To be precise about what I am and am not claiming: my crashes carried the CIG/
vk_swiftshadersignature, so I am not saying Cowork causes the GPU crash. I am saying it is why I was on the packaging that does.3. Cowork's service is also why recovery kept failing
Separately, and already reported independently by @keihoag and @cmjdev-25:
CoworkVMServiceis what made every crash unrecoverable here. Three consecutive elevated reinstall attempts on 2026-07-29 all died the same way:Conflicting service: trueon every run. The installer was fully elevated and the MSIX signature verified; the blocker was a running service holdingcowork-svc.exeopen inside the package directory. That is the same 0x80070020 sharing violation @keihoag traced, from a third machine.So on this machine Cowork sits on both halves of the problem: the packaging that makes the GPU-process kill fatal, and the service that makes the aftermath unrecoverable. It may well be different for other reporters here, several of whom have no Cowork involvement at all. For me that is what it was.
Confirming the CIG mechanism on the machine from my 2026-08-07 Turnstile report above (MSIX, hybrid RTX 5050 Laptop + Radeon 780M):
13:21:11),Microsoft-Windows-CodeIntegrity/Operationallogs Event 3033 — claude.exe (1.25927.0.0) attempted to loadapp\vk_swiftshader.dll, "did not meet the Microsoft signing level requirements" — plus 3× Event 3010 (AppxMetadata\CodeIntegrity.catunloadable, Status 0xC000003A).AppxMetadatafolder does not exist at all, so the catalog is still missing after updating.Scoping note: my trigger was the Cloudflare Turnstile challenge in the main claude.ai window, not a Browser preview pane — so the PreToolUse deny-hook mitigation reduces exposure but can't fully prevent this class. Anything that makes Chromium reach for its bundled software-rendering DLL (including claude.ai's own bot check) can set it off.
Same crash on ASUS Zenbook A16 (Snapdragon X2 Elite Extreme, Adreno X2-90, driver
32.0.149.0 of 2026-02-05, confirmed current via the ASUS BSP V1.312.4500.0), Claude
Desktop 1.26832.0.0 arm64 MSIX. "GPU process gone: reason 'crashed', exitCode
101457950" five times (Jul 26 x2, Aug 8-9 x3); each time the whole app exits with all
sessions.
One aggravating behavior not in the reports above: the trigger was one session with a
heavy page (dl.acm.org) open in the embedded Browser pane, and the app re-warms that
session's browser preview at every launch. All three recent crashes landed 4-5 seconds
after the preview was created/restored, including twice within seconds of app startup,
so a single bad page turns into a startup crash loop until that session's pane is
closed. A software-rendering fallback, or not restoring a preview whose render just
killed the GPU process, would both break the loop.
Claude Desktop (Windows, MSIX): GPU process crash at startup makes the app
unusable — bundled vk_swiftshader.dll is blocked by Code Integrity because
the MSIX ships no AppxMetadata\CodeIntegrity.cat
ENVIRONMENT
SYMPTOM
App launches, initializes fully, then dies a few seconds later. Log:
[info] GPU process gone: { type: 'GPU', reason: 'crashed',
exitCode: 101457950, serviceName: 'GPU' }
Immediately afterwards Get-AppxPackage reports:
Status : Modified, NeedsRemediation
Reinstalling restores Status: Ok, but the very next launch breaks it again.
ROOT CAUSE EVIDENCE
Windows CodeIntegrity/Operational, same second as the GPU crash:
...\app\vk_swiftshader.dll — "did not meet the Microsoft signing level
requirements"
— Status 0xC000003A (STATUS_OBJECT_PATH_NOT_FOUND)
I unpacked the official MSIX and confirmed it contains no AppxMetadata
directory at all. Chromium applies Code Integrity Guard (Microsoft-signed-only)
to the GPU process; inside a package, bundled binaries need the package catalog
to reach that signing level. Without the catalog, SwiftShader can never load,
the GPU process dies, and the app goes down with it.
DECISIVE CONTROL EXPERIMENT
Extracted the exact same MSIX to a normal folder and ran app\claude.exe
directly. Result: completely stable. GPU uses libEGL/libGLESv2 (ANGLE hardware
path), vk_swiftshader.dll is never loaded, zero Code Integrity events.
Same binaries, same signature, same machine — the only variable is package
identity. This rules out GPU drivers, hardware, and the DLL's own signature.
RULED OUT (so you don't have to)
to the original MSIX.
BinarySignature = ALWAYS_OFF for Claude.exe does NOT suppress the block,
because Chromium requests the mitigation at GPU child-process creation.
SEPARATE BUT RELATED PACKAGING BUG
The MSIX declares a packaged service (CoworkVMService), so installation
requires elevation. A non-elevated overwrite upgrade silently half-succeeds:
Add-AppxPackage returns success and deployment logs event 400 (success), but
the service never registers and the package lands in Modified, NeedsRemediation
with launch error 0x3CFC. Only a clean non-elevated install surfaces the real
error, 0x80073D28 ("administrator privileges required to install packaged
services"). This is almost certainly how auto-update corrupts installs in the
field. Fixing it restores Status: Ok but does not fix the GPU crash above —
they are two independent defects.
REQUESTS
This is the actual fix.
cannot take Chromium command-line switches, so users have no workaround.
POSSIBLY THE SAME BUG, ALREADY PUBLIC
Same crash here, and we traced it to a root cause that I don't think has been posted yet. Different GPU vendor from the two reports above, and we ran a driver rollback as a controlled experiment — both point away from the graphics driver and at the MSIX packaging.
Environment: Claude Desktop
1.26832.0.0(MSIX,Claude_pzs8sxrjxfjjc), CCD2.1.222, Node24.18.0, Windows 11 Pro10.0.26200, AMD Radeon RX 5700 (RDNA1), single discrete card, no iGPU. Also seen on app1.24012.9.Root cause: CIG blocks
vk_swiftshader.dllbecause the package ships no code-integrity catalogThe GPU process runs with Code Integrity Guard on. Measured live with
Get-ProcessMitigation -Id <gpu pid>:When a page's WebGL2/WebGPU capability probing pushes Chromium to the SwiftShader fallback, the GPU process delay-loads
app\vk_swiftshader.dll. That DLL carries only an Anthropic Authenticode signature:and the package has no
AppxMetadata\directory at all, so there is noCodeIntegrity.catto give it Microsoft coverage. A sibling file in the same folder,vk_swiftshader_icd.json, is catalog-covered (SignatureType: Catalog,IsOSBinary: True) — so within one directory, one file passes and the other cannot.Windows logs this at every crash, in order:
0xC000003ASTATUS_OBJECT_PATH_NOT_FOUND, the missing catalog``
FileNameBuffer : ...\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll
ProcessNameBuffer : ...\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\claude.exe
Status : 3221226536 = 0xC0000428 STATUS_INVALID_IMAGE_HASH
``
PublisherName : Anthropic, PBC
SignatureType : 1 (embedded)
PageHash : false
ValidatedSigningLevel : 1
VerificationError : 7
GPU process gone: { reason:'crashed', exitCode:101457950 }in the app log — the 3033 event carries the same PID aselectron_gpuin that log line.0x3CFC, five times:Cannot create the process for package <NULL> because an error was encountered while checking the machine-level package status.The GPU process cannot be re-spawned, Chromium runs out of fallbacks, and the whole app terminates.Status: Modified, NeedsRemediationat this point).Five crashes here (2026-07-30 and four on 2026-08-10), five identical evidence groups, timestamps aligned to the second.
False-positive check:
claude.exehas 18 Event 3033 records since 2026-06-15. Thirteen of them block an unrelated third-party security DLL injected into the process and are harmless — the app keeps running. The discriminator for this bug is "3010 ×3 + 3033 namingvk_swiftshader.dll", and that combination appears only at the five crashes.Chrome survives the identical block on the same machine
This is the part I'd flag as decisive. Ordinary
chrome.exeon this machine has been refused the same DLL by the same policy 16 times (2026-07-25, 07-28, 07-29 ×8, 08-01, 08-07). Chrome never died.| |
chrome.exe| Claude Desktop (MSIX) ||---|---|---|
| 3033 on
vk_swiftshader.dll| yes, 16× | yes, 5× || 3010 (missing catalog) | no | yes, ×3 each time |
| App survives | yes | no — all windows and sessions die |
| Left unlaunchable afterwards | n/a | yes, 4/4 |
CIG refusing a non-Microsoft-signed SwiftShader binary is normal machine-wide behaviour. What is specific to this app is that the refusal is fatal — which follows from the packaging (missing catalog) and from GPU-process loss not being contained.
Things this rules out
InstalledDisplayDriverspointing at a different INF package, DLLs dated 2026-06-27, no remnants of the newer branch loaded.C:\Windows\LiveKernelReportscontains only two files, both predating every crash. No WHEA, no Kernel-PnP 219, TDR registry at defaults. The kernel display driver never stopped responding — this is a user-mode load refusal, not a driver reset.exitCode 101457950(0x60C201E) is downstream of the refusal rather than its cause — but note it is byte-identical across four independent machines in this thread, which is what you'd expect from one deterministic code path rather than a random fault.Two product-level behaviours that turn one crash into many
WebFetchwas blocked by a site's anti-bot gateway, so the agent fell back to the in-app browser unprompted. Two consequences: users who decide to avoid the in-app browser cannot actually enforce that on sub-agents, and post-hoc auditing misses these calls entirely unless you also grep thesubagents/transcripts. The main session's own transcript showed a 91-second gap with no browser call at all.Rate on this machine: roughly 1 crash per 6 preview creations (~32 real preview creations over 14 days → 5 crashes). Presumably it depends on whether the page's probing actually drives Chromium into the SwiftShader fallback.
Requests
AppxMetadata\CodeIntegrity.catwith the package, or signvk_swiftshader.dll(and any other delay-loaded native binary underapp\) at a level CIG accepts, including page hashes — the current signature hasPageHash: false. NoteAllowStoreSignedBinariesisOFF, so store signing alone would not be enough.AppExecutionAlias, shortcuts can't carry switches, andconfig.jsonexposes no graphics settings, so there is currently no self-service mitigation.One warning for anyone else hitting this:
--disable-gpuis the wrong workaround. It forces the SwiftShader path, which is exactly the code path being blocked.--disable-3d-apisavoids the fallback instead. Disabling Browser tools in Settings → Claude Code → Browser (per #82967) is the reliable mitigation today, and it's the only one that also covers sub-agents.Happy to attach the raw event-log exports,
Get-ProcessMitigationoutput, and the renderer logs if useful.Same crash, one more hardware data point, and two diagnostic details I haven't seen in this thread.
Environment: Claude desktop 1.26832.0 (MSIX), Claude Code 2.1.222, Electron 42.7.0 / Chromium 148.0.7778.280, Windows 11 Pro build 26200, AMD Radeon 890M iGPU (driver 32.0.31035.1003) — so this reproduces on AMD integrated graphics as well as the NVIDIA setups reported above.
Trigger: 2-for-2 reproducible, ~2–5 seconds after submitting a search on a Cloudflare Turnstile-protected page (
onlineservices.miamidadeclerk.gov/officialrecords) in the Browser pane — same trigger as #80689 / #80483. Turnstile's GPU-fingerprint burst (~20×WebGL: INVALID_ENUM: getInternalformatParameterprobes + 2× WebGPUrequestAdapter()) appears inunknown-window.login the same second as the GPU process death, both times (2026-08-10 16:19:47 and 16:28:50 EDT, the second immediately after relaunching and retrying):The main claude.ai renderer logged
WebGL: CONTEXT_LOST_WEBGL: loseContext: context lostin the same second, and the app stopped logging entirely and hung until force-killed — no GPU-process relaunch, matching #84980. Not memory pressure: 9.5 GB free 12 s before crash #1 (renderer 658 MB, GPU process 135 MB per the app's own process-memory heartbeat).Two details that may help triage:
%APPDATA%\Claude\Crashpad\reportsand\attachmentsare empty,settings.datshows uploads disabled (options=0,last_upload_attempt_time=0), and Windows WER logged no APPCRASH for any Claude process. So for this whole crash class there may be no dump trail reaching you from the field — the exit code inmain.logis all a user can offer.RegisterByPackageFullNamerepair withForceTargetApplicationShutdownOptionfired and then failed in a loop (0x80073D02/0x80073D19/0x80073CF6) across two reboots before eventually recovering (package Status now Ok) — consistent with #81123 / #85081.Reproduces on demand on this machine — happy to run a diagnostic build or capture a local dump (WER LocalDumps) if useful.
Same crash signature (
exitCode 101457950/0x060C201E), but with a different trigger: no WebGL, no browser pane, no preview panel involved. Trigger is concurrent Workflow-tool subagents, and it is reproducible and dose-dependent.Environment
| | |
|---|---|
| Claude Desktop | 1.26832.0 (MSIX). Also crashed on 1.24012.9 and 1.25927.0 |
| Claude Code | 2.1.222 |
| OS | Windows 11 Pro, build 26200.8973 |
| GPU | Hybrid: Intel UHD Graphics (32.0.101.7088, 2026-06-17) + NVIDIA RTX 5060 Laptop (32.0.15.9174) |
| RAM | 16 GB (~6 GB free at crash time) |
Reproduction — time-to-crash scales inversely with concurrent agent count
Launch a Workflow with N subagents doing ordinary web research (WebSearch/WebFetch). No browser pane or preview is open at any point.
| Concurrent agents | Time to GPU crash |
|---|---|
| 8 | 27–90 seconds |
| 4 | ~3.5 minutes |
| 1 | survives 20+ min, completes normally |
Example: agents launched
04:50:0x→GPU process goneat04:51:36. Another run: launched~04:56→ crash at04:59:32.Notably,
grep -ci "WebGL\|WebGPU\|requestAdapter\|powerPreference" main.logreturns 0. The WebGL/getInternalformatParameterwarnings reported in the WebGL-triggered cases are entirely absent here, so this looks like a second path into the same fault.Impact
The GPU process crash takes the whole Electron host with it. Every in-flight subagent dies mid-request and nothing is journaled, so a batch of 8 loses all 8 results. Over one session this destroyed 4 separate multi-agent runs.
Onset
First
GPU process gonein my logs: 2026-07-31 23:48. Zero occurrences in the preceding six months of retained logs (main2.log,main3.log,main4.log, back to 2026-01-27, all report 0). Desktop app updated to 1.24012.9 on 2026-07-28, three days before the first crash.Ruled out, with evidence
tree_rss_sum=1741–1898MBacross crashes. The 8 agents had written only 378 KB of transcript.%APPDATA%\Claude\Crashpad\reports, no Application Error event.Attempted fixes that did NOT work
Claude.exeto the discrete NVIDIA GPU viaHKCU\Software\Microsoft\DirectX\UserGpuPreferences=GpuPreference=2;. No effect. In Optimus/hybrid mode the Intel iGPU still owns the display output (nvidia-smishowsdisplay_active: Disabledfor the dGPU).--disable-gpulaunch flag. Confirmed active on the process command line, but Chromium still spawns a GPU process for compositing and it still crashes with the identical exit code. This is worth flagging for anyone hoping the flag is a workaround — it is not.Only workaround found
Run a single subagent at a time. That is the only configuration that has completed successfully.
Suggestion
Independent of the root cause, the severity here is mostly the blast radius: a GPU process crash should not terminate the host and silently discard all in-flight session work. Isolating the GPU failure, or at minimum flushing partial results before the host exits, would turn this from "lose everything" into a recoverable event.
Same crash signature on a newer build (1.26832.0) — twice in one day, both times while a parallel-agent fan-out was running. The second crash landed 7 seconds after the app created an in-app browser preview.
Environment
Claude_pzs8sxrjxfjjc), Claude Code (CCD) 2.1.222, bundled Node 24.18.0Crash #2 (logs available) — 2026-08-11 13:53:18 UTC
Timeline from
main.log+ the session transcript (local times, UTC+2):Agenttasks (web-research subagents)[process-memory]sample: app tree 1867 MB (renderer 613 MB, GPU 183 MB),sys_free=495179MB/524114MB→ no memory pressure``
[Preview] Created session preview context
[Preview] Created browser preview { serverId: 'browser-preview-1786456391835-0' }
main.logends here and the whole app is gone:``
2026-08-11 15:53:18 [info] GPU process gone: {
type: 'GPU',
reason: 'crashed',
exitCode: 101457950,
serviceName: 'GPU'
}
Crash #1 — same day, ~12:55 UTC (earlier app run)
The session transcript cuts off mid-work at 12:55:14 UTC, seconds after the agent launched a background
Workflowfor the same kind of fan-out (plus agh issue edit). Themain.logfor that run was lost to the subsequent reinstall, so I can't confirm the GPU signature for #1 — but the observed behavior (window gone, all running sessions killed) was identical.Recovery
After each crash the app would not relaunch at all; only a full uninstall/reinstall restored it (I didn't know about the Settings → Apps → Claude → Advanced options → Repair route at the time). This matches the MSIX-corruption behavior described in #80444, #82967 and #83028.
Notes
exitCode 101457950=0x060C201E, same as in this issue and #80444.Created browser preview. The fan-out itself seems relevant only because parallel subagents make it likely that one of them opens the in-app browser.Same crash signature on another machine, two occurrences ~4 minutes apart today (11:49:28 and 11:53:45), both fully instrumented.
Environment
Claude_pzs8sxrjxfjjc), Claude Code (CCD) 2.1.222, bundled Node 24.18.0Log evidence (
main.log)exitCode 101457950=0x060C201E— identical to every other report in this thread and to the exit code in #80444's title.Both crashes happened seconds after an in-app Browser preview tab was created (
[Preview] Created browser preview). Inunknown-window.log, right before the second crash:That's a WebGPU
requestAdapter()warning, not a WebGL one — may be worth checking whether the trigger surface has broadened beyond WebGL.Ruled out on this machine
32.0.16.1088). Driver version does not correlate with occurrence here.Display,nvlddmkm, orDxgkrnlproviders in the Windows System event log around either crash — this is contained to the Chromium GPU process, not a GPU driver reset/TDR.[process-memory]log lines at the time.Crashpad\reports\for either crash — only an emptymetadatafile and a 40-bytesettings.dat. Same absence others upthread have reported.Side effect on MSIX installs
Because this is an MSIX install, the crash also brings down the bundled Cowork VM Windows service (registered as service "Claude", binary
cowork-svc.exe) — it loses its RPC connection to the crashed app and Windows logs a "service terminated unexpectedly" (Event 7034) ~20-40s later, then the service has to reinstall/restart itself on next launch. So on MSIX this bug has a second-order symptom beyond just the app disappearing.Follow-up from my earlier comment: found a fully deterministic reproduction tied to session resume, not just manually opening the Browser pane.
On this machine, a single previously-used session (one that had a Browser preview tab attached to it at some point) now crashes the app every time it's reopened/focused — 3 out of 3 attempts today, each separated by a fresh app relaunch:
| Browser preview auto-recreated | GPU process gone | Gap |
|---|---|---|
| 11:49:23 | 11:49:28 | 5s |
| 11:53:41 | 11:53:45 | 4s |
| 14:13:46 | 14:13:50 | 4s |
Each occurrence generates a fresh
browser-preview-<timestamp>-<n>serverId withtabId: "seed"— the app is auto-restoring a Browser preview tab as part of that session's warm-up, without any user action. No other session warmed in the same windows triggered this.Practical impact: once a session has ever had a Browser preview tab, simply reopening that conversation from the sidebar becomes a 100%-reproducible crash trigger — there's no way to avoid it short of never reopening that conversation in the Desktop app again.
Workaround that does work: resuming the same session via the Claude Code CLI (
claude --resume <sessionId>) instead of the Desktop GUI. The CLI doesn't restore the Electron Browser preview UI, so it doesn't hit this path.Data point: still reproducible on 1.28929.0 (newer than any version reported above), with the per-crash Code Integrity correlation verified to the second.
Environment: Claude Desktop 1.28929.0 (MSIX,
Claude_1.28929.0.0_x64__pzs8sxrjxfjjc), Claude Code CLI 2.1.227, Windows 11 Pro build 26200, x64. GPU: NVIDIA RTX 6000 Ada Generation, RTX Enterprise Production Branch driver R595 U7 (596.86, 2026-07-30).Crashes: four on 2026-08-12 alone — 20:59:28, 21:18:18, 22:06:19, 22:23:50 (local, UTC+3) — plus several more on 2026-08-10/11. All identical in
main.log:App exits entirely each time; on some earlier occurrences the package degraded and Windows offered the Repair flow.
Code Integrity correlation (verification commands from this thread): every one of the four crash timestamps has a matching Event 3033 in
Microsoft-Windows-CodeIntegrity/Operationalat the same second, withclaude.exefrom the MSIX package as the loading process:And the catalog is still missing in the current release:
Ruled out on this machine before finding this thread (all on the same day the crashes continued):
%APPDATA%\Claude\{GPUCache,DawnGraphiteCache,DawnWebGPUCache,Code Cache}— helped once for a browser-pane-on-first-launch case after a GPU swap, did not stop this crash class.nvlddmkm4101, no WHEA, no Display errors — matches the "not a driver/hardware fault" analysis.Two corroborating observations:
vk_swiftshader.dll/vulkan-1.dllthree times the same day — and survived every one. Same DLL-block condition, different outcome; the fatal part is app-side handling.CodeIntegrity.cat.Trigger pattern here: spawning parallel (web) agents — each spawn is a dice roll; also observed with only oauth activity in
main.logwhile agents were being launched from a second concurrent session. Losing every running session on each crash is the painful part; a GPU-process relaunch instead of app exit would remove most of the harm even before the packaging fix.@polestvr Thanks for the Code Integrity lead. Two updates from the same machine as my two comments above:
Still not fixed on 1.28929.0. This machine auto-updated to that exact version today. Immediately after the update:
AppxMetadata\CodeIntegrity.catis still absent from the new package folder — corroborates your finding on a second, independently-updated install.EBUSYerror (see my first comment) still fires on every launch, including the one right after the update-triggered restart.Tried to verify your Event 3033 correlation here too, but couldn't:
Microsoft-Windows-CodeIntegrity/Operationalon this machine is a small ring-buffer log (~1MB, no retention) that had already rotated past my crash timestamps, and right now it's dominated by an unrelated rejection (AV self-protection DLL blocked hundreds of times/hour) that would bury a Claude-related 3033 within under an hour anyway. Worth checking that log immediately after a crash rather than after the fact if anyone wants to reproduce this part.A working stopgap, though, confirmed on this machine: for a session that reliably crashed the Desktop app every time it was reopened from the sidebar (3/3, see my second comment above), resuming the exact same session via the Claude Code CLI (
claude --resume <sessionId>) instead of the Desktop GUI has not crashed once across multiple resumes. Same machine, same GPU, same driver — so whatever DLL load is being blocked only happens in the Desktop/Electron code path, not in the CLI process. Not a fix, but a usable way to get back into a session the Desktop app has made unreachable.Same crash on a different machine, with one extra data point that I have not seen reported yet: it still happens with the GPU fully disabled.
Environment
SignatureKind: Developer(non-Store)Trigger: Cloudflare Turnstile — 6 of 6, zero counter-examples
In
main.log,Turnstile iframe detectedandGPU process gonecorrespond one-to-one. There is no occurrence of either without the other.| Turnstile detected | GPU crash | gap |
|---|---|---|
| 2026-08-04 13:28:09 | 13:28:29 | 2s |
| 2026-08-05 14:21:04 | 14:21:17 | 1s |
| 2026-08-05 18:46:30 | 18:46:31 | 1s |
| 2026-08-06 13:56:06 | 13:56:11 | 1s |
| 2026-08-07 13:21:30 | 13:21:30 | same second |
| 2026-08-13 15:31:18 | 15:31:19 | 1s |
exitCodeis101457950on all six. The sequence is always the same:Nothing is written to Windows Event Viewer and no crash dump is kept in the Crashpad database, so
main.logis the only evidence.--disable-gpudoes not prevent itThe app has no supported way to persist a Chromium switch, so I launch it with:
Verified to be in effect: the main process command line carries
--disable-gpu, and the GPU process carries--use-gl=angle --use-angle=d3d11-warp-webgl(WARP software rasterizer).It still crashed on 2026-08-13 with the identical exit code. Frequency dropped noticeably (5 crashes in the 4 days before, 1 in the 5.5 days after), but it is not a fix.
Two things that may save others time:
isHardwareAccelerationDisabled: trueinclaude_desktop_config.jsonis not equivalent. With that alone the GPU process gets no--use-gl/--use-angleswitch and hardware rendering stays on.igd*.dll) are loaded in the GPU process is not a reliable way to confirm software rendering — they load lazily on GL context creation, so shortly after launch you see zero even when hardware rendering is active. The--use-angleswitch on the GPU process command line is the reliable indicator.Exit code
101457950has also been reported on NVIDIA (#80444) and Qualcomm Adreno / ARM64 (#68049) hardware, so this is not GPU-vendor specific.Recovery after each crash
The package goes to
Modified, NeedsRemediationand Smart App Control (enforcement mode) refuses to launch it. Windows logs event 8104Failed to set the Trust Label(0x80070057) and 8107Illegal non-AppStore package integrity validation.Add-AppxPackage -DisableDevelopmentMode -Register <AppxManifest.xml>reports success but leaves the status atModified, NeedsRemediation. The only thing that restores the app is Settings → Apps → Installed apps → Claude → Advanced options → Repair, followed by a reboot. The Repair itself shows an error before that reboot, but it still works.CoworkVMService(display name "Claude", Automatic, LocalSystem,cowork-svc.exeunderWindowsApps) blocks re-registration with0x80073D02while running, and clicking the app icon during recovery re-registers the service and restarts the loop.Requests
Related: #80444, #81159, #81836, #82967, #83028, #83478, #84333
Adding a data point that definitively rules out GPU hardware and drivers: I hit this exact crash (
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }) with byte-identical exit code across two different GPU vendors and every mitigation I could throw at it over three days.Environment: Windows 11 Pro for Workstations (26100), Intel Xeon W-2135, 64 GB RAM, Claude Desktop 1.28929.0 (MSIX), Electron 42.7.0 / Chrome 148.0.7778.280.
Elimination table — all configurations crash with exitCode 101457950:
| Configuration | Result |
|---|---|
| NVIDIA Quadro M2000, driver 556.39 (2024) | crashes (5x in one day) |
| NVIDIA Quadro M2000, driver 582.78 (June 2026) | crashes |
| App auto-updated 1.26832 → 1.28929 | crashes |
|
--disable-gpu(verified active on main process via command line) | crashes ~6 min in || Replaced GPU entirely with AMD Radeon RX 7600, driver 32.0.31035.1003 (July 2026) | crashes |
| Wiped
GPUCache,DawnGraphiteCache,DawnWebGPUCache,Code Cache(fresh rebuild verified by creation timestamps) | crashes 2.5 min after relaunch || Checked GPU process for third-party DLL injection | none present |
The same exit code surviving a full NVIDIA → AMD vendor swap plus a software-rendering flag plus fresh shader caches means this cannot be a driver or hardware issue — consistent with the WebGL/WebGPU
requestAdapter()trigger identified in this issue. Timing-wise, my crashes cluster during active Claude Code sessions using the in-app browser preview.Someone here mentioned Cloudflare and just that mention hit me with an idea. I just installed Turnstile on my site and then the crashes started to happen after. I removed Turnstile from my site and now everything is running fine with no crashes. So perhaps there is something wrong with Cloudflare security products being injected into sites that interferes with Chromium inside of Electron.
Additional notes that may help triage:
--disable-gpuflag the user launched with is silently dropped, so users who think they've applied the workaround are unprotected on the very next launch.Happy to provide full
main.logexcerpts if useful.Root cause and a verified fix for this exact signature are in #81341. Short version: the MSIX package ships
vk_swiftshader.dllsigned by Anthropic (not Microsoft) while the GPU process runs with theMicrosoftSignedOnlyCIG mitigation, and the package has noAppxMetadata\CodeIntegrity.cat— so the moment a page's bot-detection (Cloudflare Turnstile, Google Sign-In/GSI) runs its WebGL/WebGPU fingerprinting burst, the GPU process tries to load that DLL and Windows kills it (0x060C201E). This matches everything in this thread: vendor swap to AMD changing nothing (it's not a driver/hardware issue),--disable-gpunot helping (the kill happens at DLL load, and SwiftShader is the software renderer), no Crashpad/WER traces, and Turnstile/login pages being the trigger.Desktop RTX 5080 datapoint (same Windows build 10.0.26200 as OP): 10/10 crashes on MSIX with second-exact CodeIntegrity 3033/3010 events; the deterministic trigger in my case was Google Sign-In pages (GSI/FedCM widget), including plain google.com search results once.
Verified fix: the official installer has an undocumented
--exeswitch — run"Claude Setup.exe" --exeand it installs the classic non-MSIX (Squirrel) build to%LOCALAPPDATA%\AnthropicClaude\. Same CIG policy there, but the Code Integrity denial is non-fatal outside the MSIX container. User data survives (%APPDATA%\Claudeand~/.claudeare shared between builds; no re-login). After switching, the exact login pages that killed the app 100% of the time load fine. Full evidence in #81341.Additional data point that may help isolate this: the crash reproduces with hardware acceleration disabled (WARP software rendering) — so it is not specific to a GPU vendor/driver.
Environment: Claude Desktop 1.30096.1 (MSIX), Claude Code 2.1.229, Windows 11 Pro 26200.9168 (KB5121003 installed 2026-08-12), AMD Ryzen 5 3600, 16 GB RAM, NVIDIA GTX 1660 SUPER (driver 32.0.15.9186, Jan 2026).
Observations across 5 crashes (2026-08-13 x2, 2026-08-14 x3):
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }— then nothing further is logged; the whole app is dead instantly (no GPU-process relaunch attempt). Running Claude Code sessions and all subagents are lost.isHardwareAccelerationDisabled: truein claude_desktop_config.json and restarting (confirmed active: GPU helper running--use-angle=d3d11-warp-webgl), the crash reproduced with the same exit code in pure software rendering.Title
Claude Desktop (Windows) GPU process crash (exitCode 101457950 / UnknownVizError) when navigating to www.topps.com in the Browser pane — persists with --disable-gpu
Preflight Checklist
Environment
What's Wrong?
Navigating to www.topps.com in the in-app Browser/preview pane reliably crashes the app's GPU process, killing the preview and returning an UnknownVizError. This happens even when the app is launched with the
--disable-gpuflag via:Steps to Reproduce
--disable-gpu).Expected Behavior
The page should load in the Browser pane, or fail gracefully (e.g. blank preview) without crashing the GPU process or the app.
Actual Behavior
GPU process dies with exitCode 101457950 immediately after navigation, followed by repeated UnknownVizError failures on preview screenshot capture.
Troubleshooting already tried
%APPDATA%\Claude\Cacheand%APPDATA%\Claude\GPUCache— no change to this specific crash (did fix a separate, unrelated disk-cache access-denied error on launch)--disable-gpu— crash still occurs, same signatureRelevant log (main.log, ~%APPDATA%\Claude\logs)
Additional context
Same exitCode (101457950) and UnknownVizError signature as issues #81698 and #82967, but those were triggered by different sites/actions (general Browser tool use, screenshot verification). This report adds a specific, reliably reproducible trigger site (www.topps.com) and confirms the crash survives
--disable-gpu, suggesting the root cause may not be purely GPU-acceleration-related but something in how the Browser pane's screenshot/preview capture (Viz service) handles this particular page.**Additional data point: on this machine the crash correlates exactly with Cloudflare challenge responses — not with browser-preview use in general.**
Environment
SignatureKind: Developer, sideloaded — not Store-provisioned), Claude Code 2.1.229GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }Confirming the #81341 root cause on a second machine
Windows CodeIntegrity Event 3033 fires at the same second as every crash:
AppxMetadata\CodeIntegrity.cat— absent (27 companion Event 3010s in 14 days)vk_swiftshader.dll— Authenticode Valid, signerCN="Anthropic, PBC"(DigiCert); valid, but not Microsoft signing levelvk_swiftshader.dll(2026-08-13 19:41) and does not crash. Chrome is not MSIX-packaged.What may be new: the crash is selective, and the selector is measurable
These crashes were driven by agent
navigate/preview_startcalls into the Browser pane, so I had a clean list of every URL the pane was pointed at. I probed all 76 distinct URLs for Cloudflare's challenge header (Cf-Mitigated: challenge) rather than relying on status code alone:| | crashed | no crash |
|---|---|---|
|
Cf-Mitigated: challenge| 3 | 0 || no challenge | 0 | 73 |
Perfect separation across 76 URLs (≈1.4×10⁻⁵ by chance).
Two things that sharpen it:
law.justia.com,library.municode.com,capitol.hawaii.gov) were navigated without incident. Only the challenge responses crashed it.https://www.sos.mo.gov/library/reference/orders/2025/eo4(currently returnsHTTP 403+Cf-Mitigated: challenge).www.abuseipdb.com/check/<ip>and acodepublishing.communicipal-code page behaved the same way.Everything else was ruled out on this machine: not memory (Electron tree RSS 1.0–1.9 GB at crash), not session concurrency (two of the crashes happened with only 2 sessions live, others with 7), not driver/TDR (zero
nvlddmkmevents), and not display mode-change (only one Display 4107 in the window, ~1.6 h from the nearest crash).Why this might be worth a repro line
This could explain the split in this thread between reporters who see every browser preview crash and those who see it intermittently — it may depend on whether the destination serves a challenge. If a deterministic repro is useful, any URL currently returning
Cf-Mitigated: challengelooks like a candidate.I have not verified the intermediate step — that the challenge page's bot-detection specifically drives the WebGL/WebGPU path that pulls in SwiftShader. I can confirm challenge → crash and crash → 3033 →
vk_swiftshader.dll, but the mechanism in between is inference from #81341, not something I measured.(Filed originally as #85934, closed as a duplicate of this issue — reposting here as requested.)
4th reproduction of the same URL, and a one-second precursor line that may be greppable for other reporters.
Following up on my comment earlier today (app 1.30096.5, MSIX, Windows 11 Pro 26200, RTX 4080 SUPER).
1. The
sos.mo.govrepro is now 4 for 4. It crashed the app again at2026-08-15 14:17:06— about 45 minutes after I posted. Same URL, sameCf-Mitigated: challenge, sameexitCode: 101457950, same CodeIntegrity 3033 onvk_swiftshader.dllin the same second. An agent re-opened the identical URL that had already killed the app at12:49:06that day, and it died the same way 6 seconds later.2. A consistent precursor line in
main.log. Every crash in my retained logs is preceded within one second by:6 of 6 occurrences across 08-14 and 08-15:
I don't see this string anywhere else in this thread, so it may be a cheap way for other reporters to confirm whether they are hitting the same path — it is greppable without any Event Viewer work.
3. It is stochastic per-event but near-certain per app run. On 08-15 alone: 26 of those warnings, but only 4 crashes — so an individual blocked subresource is usually survived. Grouped by app run, though:
| App run | blocked-subresource warnings | outcome |
|---|---|---|
| 07:49:43–08:00:43 | 0 | no crash |
| 08:00:43–11:21:23 | 16 | crash |
| 11:23:05–12:45:17 | 4 | crash |
| 12:46:45–12:49:06 | 3 | crash |
| 12:50:45–14:17:06 | 1 | crash |
4 of 4 runs that emitted one ended in a GPU crash; the one preview session that emitted none did not. One run survived 15 and died on the 16th; another died on its first. So "it worked last time" isn't evidence of safety, which may explain the intermittency other reporters describe.
Also confirming @J-dev2's observation about non-recovery on much newer builds: across all six crashes on 1.30096.1 and 1.30096.5, the next timestamped line in
main.logafterGPU process goneis a freshStarting app— no recovery attempt, ever. The interval is just how long until I noticed and restarted (1m28s to 56m).Windows 11 Pro 26200, MSIX 1.30096.1 → 1.30096.5, another Windows box. Five
GPU process gone … exitCode: 101457950crashes on 2026-08-13/14, never recovered (next timestamped line isStarting app). One was 1 s after achallenges.cloudflare.comTurnstile iframe (topFrameUrl: https://claude.ai/api/challenge_redirect?to=…), which supports the challenge → crash reading — and this one wasn't a third-party site, it was claude.ai's own challenge redirect. The other four have only routine oauth token-lookup lines in the second before them.Zero
[PreviewContext] Blocked subresource to private-resolving hostlines anywhere in my logs, so that precursor isn't universal.No crash since 1.30096.5 (~40 h), though I've also stopped opening external sites in the Browser pane, so I can't separate the two.
Three data points from a Windows 10 machine, one of which may be useful to others as a quick check.
I'm not re-litigating the root cause — #81341 and #83744 settled it, and @liuquanqing's extract-and-run control earlier in this thread is a cleaner demonstration than anything I have.
1. A grep-able precursor line
On this machine, one log line predicts the crash. Across my entire
main.logthis appears exactly 8 times:All 8 are followed 0–2 s later by
GPU process gone(exitCode 101457950) with a matching CodeIntegrity 3033/3010 pair. No occurrence without a crash:|
xhrblock |GPU process gone||---|---|
| 08-12 17:48:21 | 17:48:21 |
| 08-12 19:24:05 | 19:24:06 |
| 08-13 12:14:05 | 12:14:05 |
| 08-14 13:17:19 | 13:17:21 |
| 08-14 14:29:17 | 14:29:18 |
| 08-14 16:16:30 | 16:16:32 |
| 08-14 18:32:07 | 18:32:08 |
| 08-15 22:50:03 | 22:50:04 |
The converse does not hold, and I want to be clear about it. Six earlier crashes (08-09, 08-10, on 1.26832.0.0) have no such line.
[PreviewContext]logging was already active in that build, but this particularBlocked subresourcewarning does not appear anywhere before 08-12, so I can't tell whether those crashes took a different path or the warning simply didn't exist yet. Treat this as "the line means a crash is coming", not "no line means you're safe".Since moving off MSIX: zero occurrences of the
xhrvariant. SixresourceType: 'image'blocks did occur, with no crash — different path.If it reproduces elsewhere it's a cheap way to tell this bug apart from other GPU deaths. It also says something about my own data: every crash I can characterise was preview-pane driven. I never reproduced a subagent-only crash, so I have nothing that bears on @maierserg1's report either way.
2. Windows 10 replication, with the base rate
Same conclusion as @a13701997241-source in #81341 — posting it only as an independent replication on a different OS build, not as a new finding.
Windows 10 Pro 19045, Claude Code 2.1.229 (desktop-bundled).
GPU process gone.Claude Setup.exe --exeonto the Squirrel build of the same 1.30096.5: 0 crashes, 0 CodeIntegrity events in 12 h 18 m, one unbroken GPU process since the 00:07:56 restart (measured 2026-08-16 12:25 KST).Base rate so you can weigh that yourselves: ~13 crashes in the 7 days before, 0 in the 12 hours since. Suggestive, not conclusive — one machine, one direction, and I have not reinstalled the MSIX build to confirm the crash returns.
Pre-empting the obvious question: I did not simply disable the GPU. The live
--type=gpu-processchild carries no--disable-gpu,--use-glor--in-process-gpuflags, andvk_swiftshader.dllis still sitting in the Squirrel app directory. Same DLL, same path — it just loads now.3. Correction to the installer switch list
@strumienapp — your list is right that the strings are in the binary, but only two of them are user-facing flags, and I think the others will bite someone. The usage strings in
Claude Setup.exe(AuthenticodeCN="Anthropic, PBC", Valid):--elevated,--msix-path,--log-pathand--uninstallSquirrelappear only as argv the installer passes to its own elevated child (--elevated --msix-path "%s" --log-path "%s",--elevated --uninstallSquirrel).--all-usershas no usage context at all. I only tested--exe.4. The installer writes its own log
For confirming what actually happened on your box,
%TEMP%\claude-squirrel-install.logstates it directly rather than leaving it to inference:The AppX
Removedeployment (event 603) starts 0.3 ms after thatRemoving:line, and the same operation terminates the packagedCoworkVMService(events 9647/9650). The installer then launches the new build itself — twoStarting appentries at 23:48:16/17.One caveat on data, since I nearly wrote the reassuring version of this: sessions and auth carried over here with no re-login, but @pierremorales in #83744 lost settings to the MSIX-virtualised
claude_desktop_config.jsonbeing removed with the package, and @juntinghu11-jpg in #81341 found theclaude://ProgID deleted too, breaking OAuth callbacks silently. Neither happened to me. Back up first anyway.@gupilleveldesigner Correction accepted, and thanks — mine was a raw-strings dump without usage context; your usage-string reading (only
--exe/--msixuser-facing, the rest internal argv for the elevated child) is the accurate version.%TEMP%\claude-squirrel-install.logis also a much better way to verify what actually happened than inferring from AppX events — matches my experience (installer removed the MSIX itself, sessions + auth carried over, no re-login), though seconding "back up first" given the #83744 and ProgID cases.Two datapoints for the precursor discussion:
1. The
Blocked subresource ... resourceType: 'xhr'line: 4/4 same-second on 1.28929.0, absent on 1.26832.0. All four of my crashes on 1.28929.0 (2026-08-13) have that exact warning in the same second asGPU process gonein main.log. My one crash on 1.26832.0 (2026-08-11) instead logged[Preview] capturePreviewScreenshotIfChanged failed: UnknownVizErrorand no xhr line. That fits your version-boundary observation (no xhr variant before ~08-12 builds) and @Traysiv's 6/6 — so on 1.28929+ it looks like a reliable same-second marker, while earlier builds emit a different (or no) precursor.2. On the challenge-selector reading: my deterministic trigger was the Google side of the same category — GSI One Tap/FedCM widgets (
[GSI_LOGGER]lines, then the WebGLgetInternalformatParameterburst + WebGPUrequestAdapter(), then the kill), and once a plain google.com search results page, which serves the same botguard probes. So "active bot-check, not hosting" holds from the Google direction too, consistent with @Traysiv'sCf-Mitigated: challengeseparation.We're also affected by this bug. Environment: Windows 11, Claude Desktop app,
in-app Browser tool (preview_start/navigate).
Reproduced twice on the same day with the identical exit code:
GPU process gone: { type:'GPU', reason:'crashed', exitCode:101457950, serviceName:'GPU' }
→ entire app crashed, all running sessions lost
App auto-restarted after ~7 minutes both times. We retried the same page
navigation ~13 minutes after the first crash and hit the identical exit
code (101457950 / 0x060C201E) at the same step again.
Rate: crashed 2 out of roughly 135 in-app-browser tool calls that day
(~1.5%), so this looks probabilistic rather than tied to any specific
page's complexity.
No workaround found on our end. We've reduced in-app-Browser usage and
switched to WebFetch for read-only page access, which avoids GPU entirely.
Wanted to consolidate what I've found while chasing this, since it looks like the same root cause is scattered across a lot of separate issues.
Confirmed trigger: the GPU process crash (exitCode: 101457950 / 0x60C201E) happens specifically when the embedded Browser preview renders a page containing a Cloudflare Turnstile widget. I reproduced it three separate times on three unrelated sites — two different third-party sites that use Turnstile for bot protection, plus Cloudflare's own public Turnstile demo page — all with the identical exit code. Other, non-Turnstile sites (search engines, plain dev/localhost pages) load fine repeatedly in the same Browser preview pane with no issue. Timing before the crash varied — anywhere from ~1 second to ~82 seconds after the page loaded — but the outcome was always the same.
Ruled out on my end:
GPU driver version (up to date, same behavior before/after an update)
Disable Hardware Acceleration (Help menu) — confirmed it actually persisted and the GPU process was running the software WARP renderer (--use-angle=d3d11-warp-webgl), not real hardware — crash still happened, same exit code, even faster
Hybrid graphics — single dedicated GPU only, not a dual-GPU/Optimus laptop
No Windows Error Reporting entry, no TDR event, and zero Crashpad .dmp files across ~10+ crashes — points to the GPU process being deliberately terminated (likely on a WebGPU adapter/IPC failure while compositing the Turnstile widget) rather than a genuine unhandled exception
This looks like the same bug reported (with the same exit code) across a long list of issues, going back months, on a variety of GPU vendors and configurations — worth someone triaging whether these should all be merged: #68049, #80444, #81159, #81698, #81836, #82967, #83478, #85691, #85934, #85967, #86094, #86146. A couple of the older/hybrid-GPU reports mention a workaround of forcing a specific GPU via Windows Settings → System → Display → Graphics — that doesn't apply to single-GPU setups like mine, and disabling hardware acceleration in-app doesn't help either, so there doesn't currently seem to be any user-side workaround besides avoiding Turnstile-protected pages in the Browser preview entirely.
Same crash, adding data points. Windows 11 Pro 26200, desktop app 1.30096.5 (MSIX), Ryzen 9 7950X3D + RTX 4090 + AMD iGPU (hybrid).
Happy to send full logs.
One week of systematic tracking on a single machine, adding three data points I have not seen elsewhere in this thread: the crash survives a GPU driver replacement, it fires with the Browser pane NOT visible, and it correlates tightly with one specific log line.
Environment: Windows 10 Pro 19045, MSIX install. Affected across app versions 1.26832.0.0, 1.28929.0.0 and 1.30096.5.0. NVIDIA GeForce RTX 5070.
Signature (identical every time):
Frequency vs driver version:
Correlation: 4 of the 6 crashes on Aug 13, and all 3 post-driver-update crashes, were immediately (0-2 s) preceded by:
Pane visibility is not required. One crash (Aug 17, 04:32) was triggered by an unattended overnight session that had opened the Browser pane programmatically; the pane was never displayed (screenshot calls time out with "the Browser pane is not displayed, so the page is not compositing frames"), and the GPU process died anyway, taking the whole app with it. So the lethal path appears to be page load / network handling in the preview context, not compositing.
Not deterministic: a supervised reproduction attempt (five heavy journal-publisher pages, viewport resizes, ~3 minutes) survived, including one occurrence of the same Blocked-subresource line (resourceType: image). Intermittent.
Possibly related diagnostic oddity:
logs/gpu-info.jsonon this machine reports both adapters (NVIDIA GeForce RTX 5070andMicrosoft Basic Render Driver) asactive: false, withglImplementationParts: "(gl=none,angle=none)"andskiaBackendType: "None", and the file is never refreshed - it kept a February timestamp through multiple app updates, a full driver replacement and reboots. If anything downstream reads that file for GPU-state decisions, it is reading stale data.Follow-up to my comment from earlier today, with a datapoint that narrows the trigger further: the crash does not need navigation, interaction, or even a visible pane - an idle Browser pane is sufficient.
Sequence on the same machine (Windows 10 19045, MSIX 1.30096.5.0, RTX 5070 on driver 610.88):
Blocked subresource to private-resolving host { resourceType: 'image' }survived.[warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }followed in the same second byGPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }. Whole app died.So a parked page's periodic background request (analytics beacon or similar) resolving to a private address is enough to take down the GPU process 25+ minutes after the last user action. The exposure window scales with how long a pane stays open, which is why overnight/background sessions with an open pane are the worst-hit case (same thing killed an unattended 04:32 session on this machine earlier the same day).
Workaround that follows from this: close the pane immediately after each use rather than leaving it resident. Frequency on this machine since adopting that: zero further crashes (small sample, noting it for other affected users).
Found a workaround that avoids the crash entirely, and it also produces a useful diagnostic signal.
Workaround: stop routing these pages through the in-app Browser preview and drive an external browser instead. I registered Playwright's MCP server pointed at my system Chrome:
claude mcp add playwright --scope user -- npx -y @playwright/mcp@latest --browser chrome
Claude Code then gets full browser tooling (navigate, page snapshot, clicks, form fill, screenshots, console/network logs) in a completely separate process tree, so nothing it renders can touch the Electron GPU process. The same Turnstile-protected page that reliably killed the app within 1–3 seconds via the in-app preview now loads fine, and the app stays up.
Diagnostic signal that might help narrow the root cause: the identical page renders without any problem in a standalone Chrome instance on the same machine, same GPU, same driver — the Cloudflare challenge appears and then clears on its own in about 12 seconds, exactly as it would for a normal user. So the crash does not reproduce in plain Chromium; it only reproduces when the page is composited inside the app's embedded browser view. That points at the Electron WebContentsView GPU path specifically rather than at Chromium's Turnstile/WebGPU handling in general.
Caveats, so nobody mistakes this for a fix:
It's a workaround, not a fix — the underlying bug is untouched, and anyone who opens such a page in the in-app preview still loses the whole app and their running session.
It requires Node plus a browser Playwright can drive. On my machine Playwright's own bundled Chromium wouldn't launch at all (spawn UNKNOWN — "side-by-side configuration is incorrect", missing Visual C++ Redistributable), which is why I pointed it at the system Chrome via --browser chrome. Worth knowing if anyone else tries this and hits that error.
Disabling hardware acceleration in the app does not substitute for this — I confirmed earlier that the crash still happens with the software WARP renderer active.
Happy to provide logs from either side (crashing in-app run vs. clean external-browser run) if that would help with triage.
Confirming this on a different machine and GPU, with a full variable-elimination pass that I hope helps narrow it down. Same exit code, same log signature.
Environment
| | |
|---|---|
| Claude desktop | 1.32352.1 (MSIX / Store) — also reproduced on 1.28929.0 and 1.30096.5 |
| Claude Code | 2.1.229 |
| OS | Windows 11 Pro 26200 |
| Machine | Lenovo Legion Pro 5 16AFR10 (83F2) |
| CPU / iGPU | Ryzen 9 9955HX / Radeon 610M (
PCI\VEN_1002&DEV_13C0) || dGPU | RTX 5070 Laptop, driver 610.88 (32.0.16.1088) |
| Displays | internal 2560×1600@165 driven by the AMD iGPU; external 3440×1440@180 driven by the RTX 5070 |
Crash signature
Correlation: the trigger is the preview context, not the Browser panel
On 2026-08-18 alone:
[Preview] Created session preview contexteventsGPU process gonecrashesImportantly, several crashes happened without the in-app Browser panel ever being opened — the preview context is also created when a session is warmed/focused (see 21:45:53 → 21:45:55 → 21:46:02 above). So "don't open the Browser tab" is not a sufficient workaround.
Variables eliminated
Every one of these was tested and the crash reproduced identically on both sides:
| Variable | Tested | Result |
|---|---|---|
| Windows reboot | crashes before and after a clean boot | no change |
| iGPU driver | OEM Dec-2025 build → AMD Adrenalin 26.7.1 (Jul 2026) | no change |
| Render GPU | AMD 610M → RTX 5070, via
UserGpuPreferences, verified withnvidia-smithat claude.exe moved to the dGPU | no change || Shader caches |
GPUCache,DawnWebGPUCache,DawnGraphiteCachedeleted (both the%APPDATA%and the MSIXLocalCachecopies) | crashed again 2 minutes after the caches were regenerated || App version | 1.28929.0, 1.30096.5, 1.32352.1 | all affected |
No display-driver TDR accompanies any of these crashes — the Windows System event log shows zero
nvlddmkm/ Event 4101 entries in the crash windows, and no bugchecks or minidumps. This is purely the Chromium GPU process dying.Escalation: MSIX package needs Repair after every crash
This is worse here than in most reports. After each crash the MSIX package is flagged and the app will not start at all until:
13 out of 13 crashes today required it. Same as #80444 and #82967 describe, but here it is deterministic, not occasional.
Hypothesis: RTX 50-series (Blackwell) + Dawn/WebGPU
The reporter of this issue is on an RTX 5080; I am on an RTX 5070. Both Blackwell.
One detail that may matter: because
powerPreferenceis ignored on Windows (crbug.com/369219127), WebGPU picks its own adapter regardless of the Windows per-app GPU preference. That is consistent with what I measured — moving the app's rendering from the AMD iGPU to the RTX 5070 changed nothing, because WebGPU was very likely already on the dGPU in both configurations. It also means the Windows Graphics settings route cannot be used as a workaround.If the pattern is "Dawn/WebGPU adapter init on RTX 50-series", that would explain why this reproduces trivially for some Windows users and not at all for others.
Request
These all appear to be the same defect and are currently splitting the signal across four separate reports:
0x060C201Evia the in-app Browser tab, plus the MSIX-unlaunchable follow-onConsolidating them would make the real frequency visible. Also worth checking whether this belongs in this repo at all — the defect is in the Claude desktop app (Electron/MSIX host), not in the Claude Code CLI, which may be why it has sat untriaged since 27 July.
Happy to provide full
main.log, renderer logs, or Crashpad output on request.Confirming this on Intel Arc integrated graphics, with a deterministic repro.
Environment: Claude Desktop 1.32885.1 (MSIX), Claude Code 2.1.234,
Windows 11 Insider Preview, Intel Arc Graphics driver 32.0.101.8860
(2026-06-24, current), single GPU, 32 GB RAM.
Repro: ask Claude Code to open the browser preview. The app dies ~5 seconds
later, every time.
2026-08-19 15:44:40 [info] [Preview] Created browser preview
2026-08-19 15:44:44 [warn] [PreviewContext] Blocked subresource to
private-resolving host { resourceType: 'xhr' }
2026-08-19 15:44:45 [info] GPU process gone: {
type: 'GPU', reason: 'crashed', exitCode: 101457950 }
Nothing is logged after that line. Memory was normal at crash time
(1,937 MB total, 289 MB GPU, 11.5 GB free) — not resource exhaustion.
One detail that may match #87329: the three log lines immediately before the
crash are OAuth lookups against claude.ai/desktop/callback, so the pane was
loading an auth page when the GPU process died.
Ruled out here: GPU driver update (crash predates and survives it),
hardware-accelerated GPU scheduling (not enabled), per-app GPU preference
(single GPU, no effect), plugins (6 active). No Windows Event Viewer entry —
the app terminates itself.
I've also seen the same crash with exitCode 34 and occasionally with no
preview open, so there may be a second path.
Another confirmed hit today (2026-08-20), matching this crash class: Windows 11, Claude Desktop MSIX build. Crash happened during a Claude Code session with sustained use of the in-app Browser pane — repeated
preview_start/navigatecalls plus ajavascript_toolexec against a live production site over several minutes. App became unlaunchable afterward; recovery required Windows Settings → Apps → Claude → Repair, then killing a leftover process before it would start again.Consistent with the root-cause writeup elsewhere in this thread (MSIX GPU process + Code Integrity killing the SwiftShader load when the Browser pane's Turnstile/GPU fingerprinting fires). No unusual display config here (single landscape monitor), so +1 to that being coincidental in the other report.
Additional evidence from a Windows machine that hit this crash 7 times between Aug 14 and Aug 20, all with the same exitCode 101457950 (0x060C201E). We captured the Chromium log at the moment of death via ELECTRON_LOG_FILE (with a scheduled task snapshotting the file every minute, because the app truncates the log on restart). It shows the fatal sequence is two-phase, which I have not seen in the other reports:
Phase 1: the GPU process dies with exit_code=101457950. Phase 2: every relaunch attempt fails instantly with error_code=18 (ERROR_NO_MORE_FILES from CreateProcess), so the entire six-crash budget is consumed within 7 milliseconds and the browser process hits LOG(FATAL). This also explains the "no recovery attempt logged" observation in the issue description: recovery is attempted at the Chromium level, but it fails faster than anything gets a chance to log or react.
Two observations that follow:
Also persists across an Intel GPU driver update (31.0.101.5333 to 32.0.101.7088) and app versions 1.28929.0, 1.30096.1 and 1.30096.5 (MSIX windows-store build). Our GPU is Intel Iris Xe while the OP has NVIDIA, so this is not vendor or driver specific. Ruled out locally: third-party DLLs in the browser process (minidump module list contains only system and app modules), zombie SIDs in the package DACLs, memory pressure (2 to 3 GB free at every crash), antivirus interference (AV report has no entries for the app at crash times).
Crash context matches the in-app browser correlation reported here: our crashes clustered around activity in the in-app Browser pane. The latest one came 3 minutes into a scheduled browsing sweep, with a PDF-embedding page open in the pane, and coincided with a burst of DNS resolution failures (network flap).
Environment: Windows 11 Home 10.0.26100, Intel i5-1235U with Iris Xe, 16 GB RAM.
Suggestion: if GpuProcessHost retried the relaunch with any backoff instead of six synchronous attempts, the existing auto-disable safety could engage and the app would survive the first kill.
I just experienced this as well, but after the crash Windows won't even open the app anymore with an error "There’s a problem with Claude. Reinstall the application from its original install location or contact your administrator."
I've never seen an error like this before. Whether the crash is causitive or purely coincidental I don't know, but sharing anyways. Claude was up to date as of last night (I don't know if there was something released in the past 24hrs).
Setup
(Side note: god I need a new computer.)
Same crash here, and I can add a datapoint I haven't seen in this thread yet: the crash reproduces even with hardware acceleration fully disabled (
--disable-gpu, ANGLE on d3d11 WARP) — so this is not a GPU-driver issue.Environment
Signature (identical every time, 6+ crashes over 3 weeks, 4 in one day):
After the GPU process dies, the whole app terminates within seconds — main.log just stops, no WER Application Error event, no Crashpad dump. All running Claude Code sessions are killed mid-flight.
Repro (100% for me):
[Preview] Spawning process→ server ready →[Preview] Created session preview context).What I ruled out with A/B tests (all crashes have identical exitCode):
--disable-gpu; confirmed viaWin32_Processthat the gpu-process child was running--use-gl=angle --use-angle=d3d11-warp-webgl(software WARP rasterizer). Crash still occurred at the same trigger point with the same exit code.Display/nvlddmkm), zero Kernel-Power 41, zero WER entries for Claude.exe in the same window.Since the crash is backend-independent (hardware ANGLE and WARP), the failure looks like it's in the viz/compositing layer of the embedded browser pane (consistent with the
UnknownVizErrormentioned in #82967), and the real severity is that the Electron main process exits instead of recovering — one bad pane kills every running session.Workaround I'm using: never display the built-in Browser pane; verify dev servers via HTTP checks or the Chrome extension instead. With the pane hidden the app is completely stable.
Adding a business-impact datapoint to this crash class (my report #86859 was merged into this issue; full env + deterministic Cloudflare-Turnstile/WebGL repro is documented there).
Environment (recap): Claude Desktop MSIX on Windows 11 Home, Lenovo 83DN (Intel Arc + RTX 4060 Laptop, drivers current), Claude Code current. Same signature as everyone here:
GPU process gone: reason 'crashed', exitCode 101457950→ the entire app exits, near-daily since Aug 11, latest occurrences Aug 17 22:59 and Aug 18 08:37.Why this is more than an annoyance: I am a paying Max 20x subscriber (>€200/month) and run my daily workflow on Claude Code — including ~30 scheduled tasks (job-search automation) plus interactive sessions. When the GPU process dies:
--disable-gpu/WARP datapoint above), daily shader-cache cleanup (GPUCache,DawnGraphiteCache,DawnWebGPUCache) helps somewhat, and I now maintain a blocklist of sites that must never be opened in the built-in browser pane because a single Turnstile/WebGL page tears down the whole app.Concrete asks:
Happy to provide logs, WER reports, or run instrumented builds — the Turnstile repro from #86859 still fires reliably on my machine if the team needs a live reproduction environment.
Version-persistence datapoint: still present in 1.32885.1.0 (Windows MSIX). Single event 2026-08-20 18:13 local, identical signature (
Blocked subresource to private-resolving host { resourceType: 'xhr' }thenGPU process gone, exitCode 101457950), trigger again an idle Browser pane parked ~21 minutes by a background session. Three prior days fully clean under a close-the-pane-immediately-after-use discipline, which continues to be an effective mitigation: frequency on this machine went from 3-7/day (Aug 10-13) to 3 total in the last week, each tied to a pane left open.Corroborating data point from a second machine, with a fully-evidenced causal chain — including why this bug also produces the MSIX "app corrupted / repair loop" reports (#80444).
Environment: Claude Desktop 1.32885.1.0 (MSIX), CCD 2.1.234, bundled Node 24.18.1, Windows 11 Pro 26200, hybrid graphics (AMD iGPU + NVIDIA RTX 5090), 64 GB RAM.
4/4 crashes today, identical signature in
main.log:After each entry the log jumps straight to the next
Starting app {— the main process exits with the GPU process instead of recovering. All running Claude Code sessions are killed.Trigger, to the second: in
unknown-window.log(the embedded browser pane), every crash is preceded 0–1 s by exactly two:i.e. a page in the embedded browser pane requesting a WebGPU adapter — in our case a YouTube page loaded during an agent task. The 13:48 crash additionally shows
WebGL: CONTEXT_LOST_WEBGLin the same second. Memory was not a factor (~48 GB free, app tree ~2 GB per the app's own process-memory log). No kernel TDR involved: no new dumps in LiveKernelReports, zero Event 4101 in 14 days.Causality note for the MSIX-corruption reports: the deployment/repair operations are a consequence of relaunching after the GPU crash, not the cause of the app closing. In the AppXDeploymentServer log the first RegisterByPackageFullName (ForceTargetApplicationShutdownOption, RepairAppRegistrationOption) starts 23–35 s after the app is already dead. The chain on every relaunch:
%TEMP%\Claude-<random>.msix— and fails with 0x80073CF0 / inner 0x80070002 (file not found).%TEMP%and force-reinstalls (Add with ForceApplicationShutdownOption, ForceUpdateFromAnyVersion), which re-arms the stale repair source for the next cycle. Manually running Add-AppxPackage against a persistent copy of the MSIX does NOT update the repair source (verified: the next repair still referenced the original temp file).Workarounds holding here: never load WebGPU-using pages in the embedded browser pane (use the Chrome extension for browser work); run long/valuable sessions in the terminal CLI, which has no GPU process. Keeping a persistent copy of the MSIX shortens manual recovery.
Suggested fixes from this evidence: isolate the shell from GPU-process death (relaunch the GPU process / fall back to software rendering instead of exiting), and/or disable WebGPU in the embedded pane; separately, register installs from a persistent package location so Windows' repair source survives temp cleanup.
Full logs available on request.
🤖 Diagnosed with Claude Code
Same crash signature here, and I think my machine is useful as a contrast case: the one thing we share is parallel subagent execution, while GPU class, RAM, and the WebGL symptom all differ.
Environment
claude-opus-5(OP does not state a model)Identical crash signature
Three occurrences in one evening (times are JST): 19:52:32, 20:16:14, 20:53:06. Each time the window vanished and every in-flight Claude Code session was lost — same as OP's "total loss of in-flight work".
Where the evidence lives (so this is reproducible):
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\main.logThat file also writes a
[process-memory] trigger=interval ...line roughly every 60 s, which is the same log line OP quotes for free memory. When the app dies, the line simply stops — so the crash time can be bracketed from the gap.Nothing in Windows event logs. Application log: 0 errors/criticals across the 4-hour window. WER
ReportArchiveandReportQueue: empty. Crashpadreports: empty.main.logis the only trace.---
1) Memory pressure is not the trigger.
Values from the last
[process-memory]line before each crash:| # | electron procs | tree RSS | system free |
|---|---|---|---|
| 1 | 22 | 4023 MB | 1509 MB |
| 2 | 17 | 3167 MB | 3968 MB |
| 3 | 15 | 2350 MB | 5955 MB |
Free memory went up across the three crashes (1.5 → 4.0 → 6.0 GB). On crash #3 the process count was already decreasing (17 → 16 → 15) as subagents finished. Idle baseline on this machine is 10 processes / ~1.5 GB / ~6.5 GB free.
2) WebGL errors are not required.
OP logged ~20
WebGL: INVALID_ENUMwarnings immediately before the crash. Grepping mymain.logforwebgl|webgpu|powerPreference|requestAdapterreturns 0 matches. The only WebGL line anywhere in my logs isCONTEXT_LOST_WEBGLinunknown-window.logat 20:16:14 — i.e. after the GPU died, as a consequence rather than a cause.Last log line before each crash:
(
PreviewContextis the in-app browser pane's context.)3) Spawn method matters — a controlled comparison.
| run | what | electron procs | result |
|---|---|---|---|
| A | the Workflow tool, 3 runs concurrently, ~24 agents total | 10 → 22 | crashed (19:52) |
| B | the Workflow tool, 1 run, 4 agents | 10 → 17 | crashed (20:16) |
| C | the Workflow tool, 1 run, 4 agents (lighter prompts) | 10 → 17 | crashed (20:53) |
| D | a single
Agenttool call — one general-purpose subagent doing web research (WebSearch/WebFetch only), 17 min 40 s, 83 tool uses, 170 k tokens | 10 → 10 (no increase at all) | no crash |Run D did more work than run C by every measure, yet it never spawned an additional Electron process and never crashed. Each concurrent Workflow run adds roughly +4 Electron processes; a single
Agentcall adds none.4) Not a regression from one version - and not the model.
A Workflow run with 13 agents on 2026-08-17 under v2.1.229 completed normally (its session log ends with the normal close marker). That run used the same model (
claude-opus-5) as all three crashes, so the model is not the variable. Earlier abnormally-terminated sessions span v2.1.221 / .222 / .227 / .229, but those all cluster around midday and match the separateForceTargetApplicationShutdownupdate-mechanism behaviour (#76357), not this GPU signature.Caveat on "first occurrence": my
main.logwas reset by a reinstall at 13:44 on 2026-08-20, so it only covers that single day. I can say this signature appears three times within that window; I cannot say it never happened before.Hypothesis (unverified). On an integrated GPU with shared VRAM, spawning several renderer-bearing subagent processes within a short window seems sufficient to kill the GPU process, independent of system memory headroom. If so, the shared factor with OP would be GPU-process pressure, reached by different routes — WebGL workload there, concurrent renderer spawns here.
Workaround on this machine (n = 1, three crashes vs one clean run): using single
Agentcalls instead of Workflow fan-out. No crashes and no process growth so far — but I have not tested severalAgentcalls in parallel, so I can't say where the boundary is.Reproducing this exactly, with some evidence that may help narrow it down.
Environment: Claude Desktop 1.34493.0 and 1.34493.1 (MSIX), Claude Code 2.1.235/2.1.237, Windows 11 Home 10.0.26200, NVIDIA RTX 2070 SUPER, 32 GB RAM (16+ GB free at every crash per the app's process-memory log lines).
Five identical crashes in two days, all
GPU process gone: { reason: 'crashed', exitCode: 101457950 }with no recovery attempt logged: 2026-08-20 15:53:23, 20:52:44, 22:14:22; 2026-08-21 10:04:14, 15:10:43 (local).Points that rule things out:
``
[warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
Workload at the time: a long Claude Code session with parallel subagents driving the built-in Browser pane against scientific-publisher sites (page loads, screenshots, PDF downloads). This is consistent with the reports here that the Browser pane is the trigger.
Interaction with the updater (the "Repair to relaunch" behavior in #81836): while an update was staged, every crash-triggered relaunch attempted an MSIX re-register that failed with
0x80073D02: Unable to install because the following apps need to be closed— leftover Claude child processes from the killed sessions were still alive — leaving the package in a state where Windows reported "Claude can't be opened" and Settings → Repair also failed with the same error, yet the repair attempt re-registered enough to let the app launch. Once the staged update finally installed, relaunches recovered on their own (the register error still logs at each post-crash launch, e.g. 2026-08-21 15:16:29, but no longer blocks).