[BUG] Claude Desktop (Windows MSIX): GPU process repeatedly crashes with exitCode 101457950 (0x60C201E), killing the app and stranding it behind a stale single-instance lock
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Note: this is about Claude Desktop for Windows (MSIX build 1.26832.0.0, bundling CCD 2.1.222), not the standalone CLI. Filing here as this is the public tracker.
The Electron GPU process dies at unpredictable intervals and takes the entire app down with it. Five crashes in three days of normal use on hardware that is nowhere near saturated: GPU process RSS flat at ~155 MB, 13.6 GB of system memory free, current NVIDIA driver (32.0.16.1088, 2026-07-22).
Four of the five crashes report the identical exitCode 101457950 (0x60C201E), while the application-layer activity immediately before each crash is completely different every time (OAuth token refresh, title-bar overlay, page navigation). That points at the Chromium/GPU layer rather than any single feature.
The more damaging half of this bug is what happens next. After the crash, orphaned child processes keep holding the Electron single-instance lock for 60-90 seconds. Clicking the app icon during that window does nothing at all — no window, no error, no tray notification. Windows then surfaces "You'll need to go to advanced options for Claude and select Repair."
On that Settings page the buttons appear in this order: Terminate, Repair (greyed out: "can't repair while running"), Reset ("this will delete this app's data"), Uninstall.
A user who does not know the lock exists reads the dead icon as "the app is broken", follows the Windows prompt, finds Repair disabled, and reaches for Reset or Uninstall. Both rotate the Trusted Device credential — which orphans every Remote Control session bound to it, permanently and with no rebinding path.
That exact sequence already cost 281 sessions on this machine on 2026-08-07 (support conversation 215475384515127, still open). So a recoverable 90-second GPU hiccup sits one misread dialog away from unrecoverable loss of months of work.
What Should Happen?
- A GPU process crash should not kill the application. Electron's child-process-gone event for type: 'GPU' is recoverable — Chromium itself falls back to SwiftShader rather than terminating. The GPU process should be relaunched.
- If the app does go down, the single-instance lock should be released deterministically, or a stale lock should be detected and taken over on the next launch. The silent 60-90 second dead zone is what sends users to the Settings page in the first place.
- Users should be able to disable hardware acceleration from Settings. On an MSIX build there is currently no way to do this at all (see Additional Information for why every standard workaround is unavailable).
- Reset and Uninstall should warn that app data includes device credentials, and that sessions bound to the current credential will not be recoverable afterwards.
Error Messages/Logs
From %APPDATA%\Claude\logs\main.log (note: every line is written twice in this log; counts below are de-duplicated)
2026-08-10 11:26:31 [info] GPU process gone: {
type: 'GPU',
reason: 'crashed',
exitCode: 101457950,
serviceName: 'GPU'
}
All five occurrences:
2026-08-07 09:09:30 exitCode=101457950 (preceded by: OAuth cached-token lookup)
2026-08-07 15:59:21 exitCode=101457950 (preceded by: OAuth cached-token lookup)
2026-08-07 16:22:15 exitCode=101457950 (preceded by: OAuth cached-token lookup)
2026-08-07 16:50:02 exitCode=34 (preceded by: claude-in-chrome keepalive, title-bar overlay)
2026-08-10 11:26:31 exitCode=101457950 (preceded by: challenge_redirect navigation failure + Turnstile iframe)
Crashes 2 -> 3 -> 4 landed within 51 minutes (23 min, then 28 min apart).
101457950 = 0x60C201E. Not a standard NTSTATUS or Chromium RESULT_CODE_* value,
which suggests it propagates up from the graphics stack rather than from
Chromium's own shutdown paths.
--- Resource pressure ruled out ---
The app's own telemetry, one minute before crash 1:
2026-08-07 09:09:21 [info] [process-memory] trigger=interval tree_rss_sum=3172MB electron(17)=3172MB
top=[electron_renderer:701MB electron_renderer:425MB electron_main:277MB ...]
sys_free=13670MB/32581MB
GPU process specifically, across the half hour before a crash — flat, no leak, no spike:
08:41:37 electron_gpu:157MB
08:42:37 electron_gpu:154MB
08:44:31 electron_gpu:153MB
08:45:28 electron_gpu:155MB
08:46:24 electron_gpu:155MB
08:47:21 electron_gpu:153MB
--- Crash 5 immediate context ---
11:26:31 [info] Navigation to https://claude.ai/api/challenge_redirect?to=... failed with status ...
11:26:31 [info] Turnstile iframe detected. Removing error overlay.
11:26:31 [info] Redirecting to claude.ai
11:26:31 [info] GPU process gone: { reason: 'crashed', exitCode: 101457950 }
Tempting to blame the Turnstile iframe, but "Turnstile" appears exactly once in
65,000 lines of log, and the other four crashes have no Turnstile involvement.
Different triggers, same exit code.Steps to Reproduce
Not deterministically reproducible on demand — that is part of the problem. Observed 5 times across 3 days of normal use.
Conditions present during all five:
- Claude Desktop for Windows, MSIX install (1.26832.0.0)
- Several Claude Code sessions open in the app
- Browser preview panes in use
- Chrome extension MCP (claude-in-chrome) connected
- Single NVIDIA GPU, no integrated graphics fallback available
To observe the follow-on lock problem after any crash:
- Wait for the GPU process to crash (app disappears)
- Immediately click the app icon -> nothing happens, silently, for 60-90 seconds
- Windows suggests "go to advanced options and select Repair"
- Settings > Claude shows Repair greyed out ("can't repair while running") with Reset and Uninstall directly below it
Concurrency was investigated as a cause and ruled out. From the log:
03:25:27-03:25:59 (32s): 4 distinct sessions warmed previews -> fine
02:59-03:02: 3 sessions interleaved -> fine
09:09:17: 1 session -> CRASH 13s later
09:11:57-09:15:24: 4 sessions (post-crash) -> fine
210 preview warmups across the log, 5 crashes. The highest-concurrency moments
were uneventful; one crash followed a single warmup.
Happy to supply the full 65k-line main.log or run an instrumented build.
Claude Model
Not sure / Multiple models
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.222 (bundled in Claude Desktop 1.26832.0.0, Windows MSIX)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
--- Environment ---
App version : 1.26832.0.0 (Claude_1.26832.0.0_x64__pzs8sxrjxfjjc)
Install type : MSIX ([CCD-autoupdate] Disabled: MSIX install)
Bundled CCD : 2.1.222
OS : Windows 11 Pro 10.0.26200 Build 26200
CPU : Intel Core i5-12400F <- F-series, NO integrated graphics
RAM : 31.8 GB
GPU : NVIDIA GeForce RTX 3070
GPU driver : 32.0.16.1088 (2026-07-22) - current
Node : 24.18.0
--- There is no user-side mitigation on MSIX ---
Every standard workaround is unavailable:
| Mitigation | Status |
|---|---|
| --disable-gpu / --disable-gpu-compositing | Unavailable. The MSIX package declares no AppExecutionAlias; the manifest exposes only Windows.FullTrustApplication with app\Claude.exe. No supported way to pass argv. |
| Windows Settings > Graphics > GPU preference | Unavailable. i5-12400F has no iGPU. One adapter only, nothing to switch to. |
| In-app hardware acceleration toggle | Does not exist in the UI, and there is no corresponding key in %APPDATA%\Claude\config.json. |
| Update GPU driver | Already current (32.0.16.1088). Crash 5 occurred on this driver. |
| Launch Claude.exe directly with flags | Technically possible but runs outside the MSIX container identity, which is what the session binding is keyed to. Cannot be recommended without risking the data-loss path described above. |
The only working recovery is to kill the stale processes and relaunch via
shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude, which preserves package identity.
Users should not have to discover that.
--- Priority suggestion ---
Root-causing the NVIDIA/Windows GPU interaction may take a while. The two cheap
changes that would help immediately and independently:
- A hardware acceleration toggle in Settings (does not depend on root cause)
- Stale single-instance lock detection on launch (removes the dead zone that
funnels users toward Reset/Uninstall)
--- Related ---
Trusted Device credential rotation orphaning Remote Control sessions:
support conversation 215475384515127 (open). 281 sessions, 654.5 MB of .jsonl
transcripts still on disk but unreachable. That report is separate; this issue
is about the GPU crash that steers users into triggering it.