The symptoms
Worked yesterday, dead today
Claude had already quit itself after boot; reopening shows an error or the window never appears.
PowerShell confirms it
Get-AppxPackage *claude* shows Status : Modified, NeedsRemediation.
Repair only holds briefly
Windows Repair / reinstall restores Status : Ok — then after a few minutes of use it flips back to broken.
Crashed right after an in-app captcha
Some people report it dies right when a Cloudflare captcha pops up inside the app — that's a symptom, not the cause (more below).
What's actually happening
Recent Claude Desktop MSIX builds (1.24012+) bundle vk_swiftshader.dll — Chromium's software-rendering fallback for when the GPU dies. On machines where Windows enforces Code Integrity, loading that DLL from inside the MSIX container is blocked:
Code Integrity event 3033: ...\app\vk_swiftshader.dll "did not meet the Microsoft signing level requirements."The chain reaction
- 1. GPU process falls back to swiftshaderThe DLL gets blocked and the GPU process crashes (exit code 0x060C201E).
- 2. Windows flags the packageThe whole signed package is marked Modified, NeedsRemediation.
- 3. Next launch failsActivation fails with 0x3CFC ("Cannot create the process… try reinstalling").
"It crashed right after a captcha / opening a link in the app"
A few people notice the crash lines up with a specific moment: an in-app Cloudflare captcha popping up, or clicking a link that opens inside the built-in browser (the Browser pane / preview). Those aren't really the culprit, and it's worth being precise about why. The whole app is already an Electron window painting continuously, so ordinary rendering isn't what tips it over. What tips it over is the GPU child process being asked to do work that reaches the software Vulkan fallback — and the trigger is broader than "a WebGPU page." Opening any page in the Browser pane makes the pane take a screenshot of it (Chromium's capturePage), and that needs a GPU context. So a plain static page with no WebGL/WebGPU at all can crash it too; a Cloudflare challenge (or any WebGPU-touching page) just gets there faster and more reliably.
Once the GPU child needs that path, it tries to load the package's own app\vk_swiftshader.dll — the software Vulkan ICD. That child runs under Code Integrity Guard (Microsoft-signed-only), the Anthropic-signed DLL fails the check (event 3033, STATUS_INVALID_IMAGE_HASH), and the GPU process dies. Chromium retries the GPU process five times, all fail, and it then takes the whole app down ("GPU process isn't usable. Goodbye."). Because the blocked DLL lives inside a WindowsApps package whose integrity catalog can't be loaded (event 3010 — the shipped MSIX is actually missing AppxMetadata\CodeIntegrity.cat), Windows flags the package Modified, NeedsRemediation.
This is exactly the mechanism documented — with logs — in Anthropic's own bug report (anthropics/claude-code#88323), independently reproduced there on NVIDIA, AMD, Intel-integrated and even Windows-on-ARM machines, on both sideloaded and officially-downloaded builds. Two details from that thread are worth stealing: the same machine's real Google Chrome hits the identical 3033 block on its own vk_swiftshader.dll and carries on fine — because Chrome is unpackaged, there's no package status to corrupt — which proves the block is only fatal in the MSIX/CIG context. And disabling hardware acceleration does not help: vk_swiftshader IS the software renderer, so turning off the GPU just steers Chromium toward the blocked DLL, not away from it. Different-looking triggers, one root cause — and the fix below still applies.
Who this hits
Not everyone — but reliably if Windows enforces Code Integrity on your machine (security hardening / HVCI-Memory Integrity enabled, some enterprise or virtual-display setups). It is not tied to a specific GPU or driver: the failing path never reaches the vendor driver, and it's been reproduced on brand-new and years-old drivers alike, on discrete and integrated GPUs, and on ARM64. It looks like an Electron-version regression that showed up around the 1.28929 → 1.30096 builds, not a hardware fault. (OpenAI's Codex desktop app has the exact same class of bug.)
The fix that sticks
Stop using the MSIX (Store) build. Use the Squirrel build, which installs to %LOCALAPPDATA%\AnthropicClaude — outside the MSIX container — so the "Microsoft signing level" enforcement never applies to its DLLs. Same app, same version family, no more self-corruption.
Steps (Windows)
- 1. Get a Squirrel package (.nupkg)https://downloads.claude.ai/releases/win32/x64/AnthropicClaude-<version>-full.nupkg — the RELEASES file in that folder lists the current version.
- 2. Extract lib/net45/Extract its contents into %LOCALAPPDATA%\AnthropicClaude\app-<version>\
- 3. Run claude.exeRun it from there; create Desktop / Start-menu shortcuts.
- 4. Lock the versionSo it can't auto-update back into the broken MSIX build, add to your hosts file: 0.0.0.0 downloads.claude.ai (remove that line later when you want to update).
Don't want to do it by hand?
There's a PowerShell script that wraps the whole thing (download the right Squirrel build, extract, make shortcuts, optionally remove the broken MSIX and lock the version): https://gist.github.com/KehuiPang/0a678ac866ed4b9b883e9a30f4b63372 — MIT, no warranty, and it doesn't touch your Claude data or sign-in.
FAQ
Why does Claude Desktop say "This app can't open" only sometimes?
It's tied to Code Integrity. On machines that enforce it (security hardening, HVCI / Memory Integrity, some enterprise or virtual-display setups), the bundled vk_swiftshader.dll gets blocked and corrupts the package. It's not about your GPU or driver — the failing path never reaches the vendor driver, and it's been reproduced on new and old drivers, integrated and discrete GPUs, even ARM64. On machines that don't enforce Code Integrity, Claude runs fine.
Will reinstalling Claude Desktop fix it permanently?
No. Repair or reinstall restores it for a few minutes, then it self-corrupts again because the trigger (the blocked DLL) is still there. You have to move off the MSIX build.
Is switching to the Squirrel build safe?
Yes — it's the same Claude app, just installed outside the MSIX sandbox. It doesn't touch your data or sign-in. You can revert anytime by reinstalling the Store version.
Does the same bug affect other AI desktop apps?
Yes. OpenAI's Codex desktop app uses the same Electron + MSIX + bundled swiftshader combination and hits the same class of bug.
After switching, Claude is stuck on the sign-in screen after I log in with Google. Why?
That's the claude:// protocol handler not being registered. When you sign in with Google, the browser hands the result back to Claude via a claude://... callback; if nothing owns that protocol, the callback goes nowhere and the app loops on the sign-in screen. Signing in with email + a verification code works because it never uses the deep-link. To fix it properly, register the claude:// handler pointing at your extracted Claude.exe (the PowerShell script in this guide does this automatically). Then Google sign-in redirects back into the app.
My chat history looks wiped after switching to the Squirrel build. Is it gone?
No, nothing was deleted. The MSIX build kept its data inside its sandboxed package folder, while the Squirrel build reads from %APPDATA%\Claude, so the new build just can't see the old data yet. Copy your old chat/session data over and the history reappears (the script's -MigrateData option does this for you).