[BUG] Windows desktop 1.30096.5: whole app killed when Browser pane renders a Cloudflare challenge — Code Integrity blocks vk_swiftshader.dll (exit 0x060C201E), MSIX flips to Modified. Root-cause evidence for #80444
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?
This is a desktop-app bug filed with full root-cause evidence. Issue #80444 describes the same crash signature on 1.24012.1; this report names the mechanism (verified in Windows event logs), adds three fresh reproductions on 1.30096.5.0, and documents a machine where the suggested Repair workaround cannot work.
Environment
- Claude Desktop 1.30096.5.0, MSIX (
Claude_1.30096.5.0_x64__pzs8sxrjxfjjc), Electron (node 24.18.0 per startup log) - Windows 11 Pro 26100.8037, Smart App Control off
- GPU: NVIDIA RTX 5060 Ti, driver 32.0.16.1088 (2026-07-22, current); crash reproduces identically on the previous driver (32.0.15.8180) and after a full reboot
- Claude Code CLI on the same machine: 2.1.229 (bundled) / 2.1.233 (npm)
Summary
Rendering any Cloudflare managed-challenge page in the app's built-in Browser pane kills the entire app process tree in ~3 seconds — no Crashpad dump, no WER AppCrash. Reproduced 3/3 on https://gnosis.library.ucy.ac.cy/ (2026-08-16 21:18:10, 23:37:45, 23:40:08 local UTC+4), once by a human clicking "Open". Six agent sessions were lost to the same signature over two days; in every one an agent had the pane on a challenge page at the moment of death.
Death signature (main.log, identical all three times)
23:37:42 [info] [Preview] Created browser preview { serverId: 'browser-preview-1786909062064-0' }
23:37:45 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
23:37:45 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }
-- log ends; whole app gone --
Root cause, from Windows event logs at the exact death seconds
CodeIntegrity/Operational Event 3033 (all three deaths, verbatim):
Code Integrity determined that a process (…\WindowsApps\Claude_1.30096.5.0_x64__pzs8sxrjxfjjc\app\claude.exe) attempted to load …\app\vk_swiftshader.dll that did not meet the Microsoft signing level requirements.
Event 3010 (same seconds): unable to load …\AppxMetadata\CodeIntegrity.cat, Status 0xC000003A — the package ships no CodeIntegrity catalog (the AppxMetadata directory does not exist on disk), so the Anthropic-signed DLL fails the GPU sandbox's MicrosoftSignedOnly (CIG) check when the challenge's WebGPU probing (requestAdapter() warnings logged at the same seconds in unknown-window.log) forces a post-lockdown SwiftShader load.
AppModel-Runtime Event 6 (same second, ×5): 0x3CFC: Cannot create the process … an error was encountered while checking the machine-level package status — the violation flips the MSIX package (status 0x2 → 0x80002), Windows refuses to respawn the GPU process, and the app dies with it. A policy kill raises no exception, hence no dump anywhere.
So exitCode 101457950 (0x060C201E) = Code-Integrity kill of the GPU child + package flip. This also explains why the crash is instant total death rather than a recovered GPU restart.
Controls that isolate it
- Survivable GPU crash for contrast: same day, 22:25:46,
GPU process gone: exitCode 34with no browser pane open — app respawned the GPU process and lived. No CodeIntegrity event at that second. Only the 0x060C201E class is fatal. - Same page, other clients: plain curl →
403,Cf-Mitigated: challenge(harmless); user's own Chrome → renders fine (Chrome logged its own 3033s the same evening and survived — not MSIX, tolerates GPU-child death); Anthropic's server-side fetch (claude.ai) → full content. - DNS/hosts/proxy on the machine are clean; the
Blocked subresource to private-resolving hosttarget is not logged, so we cannot say what was vetoed.
Impact beyond the crash: on this machine, Repair can never work
#80444's workaround is Settings → Repair. Here every Repair/Reset fails: the stored repair source is a bare filename (Claude-1777202620.msix) that exists nowhere on disk → 0x80073CF0 / 0x80070002 ("Opening the package from location … failed"), Windows escalates Repair→Reset→Repair in a loop, each attempt force-terminating the app (eight failures in four minutes, 21:19:57–21:23:31). The only recovery is uninstall + reinstall, and the freshly recorded repair source is again a bare filename not on disk, so the trap re-arms on every install.
Workaround identified (not yet field-verified)
isHardwareAccelerationDisabled: true in claude_desktop_config.json (key present ×5 in app.asar of this build). With acceleration off, SwiftShader should preload before sandbox lockdown. Note the app's own auto-recovery apparently sets this after 3 GPU deaths per session — but this crash kills the app at death #1, so that threshold is unreachable.
Asks
- Ship a
CodeIntegrity.catcoveringvk_swiftshader.dll(or Microsoft-sign it, or preload it before GPU sandbox lockdown). - Make the browser process survive a GPU-respawn refusal instead of dying silently with the pane's content.
- Record a valid, path-qualified MSIX repair source so Repair can ever succeed.
- Log the hostname in
[PreviewContext] Blocked subresource to private-resolving host— it fires exactly once, one second before every kill, and is currently undiagnosable.
What Should Happen?
A hostile or heavyweight page in the built-in Browser pane should cost at most that pane. The app already survives a GPU-process crash and respawns it (observed same day: exitCode 34, no browser open, app lived) — the same should hold here: no page should be able to kill the whole application, take every running agent session with it, and flip the MSIX package into a state that (on this machine) can only be recovered by uninstall + reinstall.
Error Messages/Logs
main.log (identical signature, 3 reproductions: 21:18:10, 23:37:45, 23:40:08 local):
23:37:42 [info] [Preview] Created browser preview { serverId: 'browser-preview-1786909062064-0' }
23:37:45 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
23:37:45 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }
-- log ends; whole app process tree gone; no Crashpad dump, no WER AppCrash --
Microsoft-Windows-CodeIntegrity/Operational, Event 3033, at every death second:
Code Integrity determined that a process (\Device\HarddiskVolume3\Program Files\WindowsApps\Claude_1.30096.5.0_x64__pzs8sxrjxfjjc\app\claude.exe) attempted to load \Device\HarddiskVolume3\Program Files\WindowsApps\Claude_1.30096.5.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll that did not meet the Microsoft signing level requirements.
Event 3010, same seconds (x3 each):
Code Integrity was unable to load the ...\AppxMetadata\CodeIntegrity.cat catalog. Status 0xC000003A.
(the AppxMetadata directory does not exist in the installed package)
Microsoft-Windows-AppModel-Runtime/Admin, Event 6, same second (x5):
0x3CFC: Cannot create the process for package <NULL> because an error was encountered while checking the machine-level package status.
Event 68, minutes later: AppModel Runtime status for package Claude_1.30096.5.0_x64__pzs8sxrjxfjjc successfully updated to 0x80002 (previous status = 0x2).
unknown-window.log, at every death second (x2 each):
[warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127
Survivable control, same app instance, 22:25:46, no browser open:
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 34, serviceName: 'GPU' } -> app respawned GPU, lived.
Repair attempts (AppXDeploymentServer/Operational):
AppX Deployment operation failed for package with error 0x80073CF0. The specific error text: error 0x80070002: Opening the package from location Claude-1777202620.msix failed.
(8 such failures 21:19:57-21:23:31; the stored repair source is a bare filename not present on disk)
Steps to Reproduce
- Windows 11, Claude Desktop installed as MSIX (Store/offline installer).
- In any session, have the built-in Browser pane open a Cloudflare managed-challenge page, e.g.
https://gnosis.library.ucy.ac.cy/. (Verify the page is challenge-gated first:curl -sI https://gnosis.library.ucy.ac.cy/ | grep -i cf-mitigated→cf-mitigated: challenge. Any page serving the "Just a moment..." interstitial reproduces; three different hosts of this class all killed the app, 5 of our 6 session deaths ended on one.) - Wait ~3 seconds while the challenge runs its WebGPU/fingerprint probes (
requestAdapter()warnings appear in unknown-window.log). - The whole app process tree dies:
GPU process gone: exitCode 101457950 (0x060C201E), CodeIntegrity Event 3033 forvk_swiftshader.dll, AppModel0x3CFC, package flips to Modified. Reproduced 3/3, including once by a human clicking the link chip in chat. - Recovery on this machine: uninstall + reinstall only (Repair/Reset loop on
0x80070002because the stored repair source is a bare filename that is not on disk).
Note: #86313 (Desktop MSIX, Browser pane) appears to be the same family, and #80444 is the same crash signature on 1.24012.1 — this report adds the Code Integrity root cause verified in the OS event logs, the survivable exit-34 control, and the broken-repair-source finding.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Desktop app 1.30096.5.0 (the affected component); Claude Code CLI on the same machine: 2.1.229 (bundled) / 2.1.233 (npm)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
Affected component is the desktop app's built-in Browser pane ("Other" selected for terminal — sessions run inside the desktop app UI, host shell is PowerShell 7). Regression context: per #80444, earlier builds had zero GPU crashes; on this machine the same kill reproduces on 1.30096.5.0, on two different NVIDIA drivers (32.0.15.8180 and 32.0.16.1088), after a full reboot, with clean DNS/hosts/proxy and Smart App Control off. Six unattended agent sessions were lost to this over two days before the trigger was isolated. Happy to provide full main.log excerpts, the exported event-log entries, or run a diagnostic build — the reproduction is 100% reliable on this machine.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗