Windows: no non-MSIX installer available, leaving users with no workaround for MSIX-layer launch failures

Clarifying scope, since this was auto-labelled invalid ("Issue doesn't seem to be related to Claude Code") by github-actions 11 minutes after filing.

This does block Claude Code. I use Claude Code through the desktop app's Code tab — that is how I run it on this machine. When the MSIX container fails to activate (0x80070020, AppModel-Runtime 215/208), the desktop app does not launch, and every Claude Code session hosted in it is inaccessible until the machine is rebooted.

Three occurrences in six days, all ending in a reboot:

| Date | Downtime |
|---|---|
| 2026-09-03 | ~30 min (13:36 → 14:06) |
| 2026-09-07 | morning until 10:43 |
| 2026-09-09 | 11h45m (02:04 → 13:49) |

On 2026-09-09 the app attempted 15 RepairAppRegistrationOption re-registrations and a full package Remove → Add over 3.5 hours. None recovered it. Logs in #53247.

So the packaging choice is not cosmetic for Windows users of Claude Code: it is the delivery vehicle for the client I run it in, the bug lives in that layer, and there is currently no non-MSIX build to fall back to.

Happy to have this moved or closed as a duplicate of #53247 if that is the better home — but it is not unrelated to Claude Code.

Correction on the winget entry: it is not the MSIX installer, and it is currently the only non-MSIX path that exists.

winget show Anthropic.Claude still reports manifest version 1.44121.2 and that same downloads.claude.ai exe, but installing it produces an unpackaged Squirrel build under %LOCALAPPDATA%\AnthropicClaude, not an MSIX package. Verified here while the MSIX package Claude_2.110.0.0_x64__pzs8sxrjxfjjc was wedged in exactly the 0x80070020 state this issue is about: the unpackaged build launched and ran normally. It has no packaged service, so it never enters package servicing and never meets the container failure.

It works as a stopgap for the MSIX-layer bugs listed above. The caveats support your request:

• It installs side by side with the MSIX package instead of replacing it, and winget install --id Anthropic.Claude --force does not repair or reinstall the MSIX.
• The Start-menu shortcut it creates points at the unpackaged build and shadows the MSIX tile, so afterwards you cannot easily tell which one you are launching.
• Both builds share %APPDATA%\Claude.
• It is pinned at 1.44121.2 and updates through Squirrel, so the two installs drift apart in version.

To remove it again: %LOCALAPPDATA%\AnthropicClaude\Update.exe --uninstall, then delete the leftover %LOCALAPPDATA%\AnthropicClaude folder and the dead %APPDATA%\Microsoft\Windows\Start Menu\Programs\Claude.lnk.

An unpackaged build is therefore already built and shipped. It is reachable only through a winget manifest that describes something else, with no documentation and no clean coexistence with the packaged install. Documenting that path, or shipping it from the download page, would close the gap this issue names.

Confirming the root cause underneath both 0x80070020 and the SignatureKind: Developer MSIX you're both hitting, since it explains why the unpackaged build sidesteps it and not just that it does.

Recent Claude Desktop MSIX builds bundle vk_swiftshader.dll. On any machine with Memory Integrity (HVCI) enabled, Windows Code Integrity blocks that DLL and logs event 3033 in the Code Integrity operational log. That kills the GPU process, and the package servicing layer then flags the whole MSIX as Modified, NeedsRemediation — which is the state that forces the reboot/logoff to clear, since (as you both found) app-level repair can't touch a container-level flag. v-tab-vispero's unpackaged Squirrel build works around it for exactly the reason you'd expect: outside the MSIX container there's no package-integrity status for HVCI to flag in the first place, so the failure mode structurally can't happen.

Check for it directly: Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' | Where-Object Id -eq 3033 — if you see entries naming vk_swiftshader.dll around your downtime windows, this is that bug, not something environment-specific.

One thing worth flagging for anyone hitting this: a repair/reinstall cycle on the MSIX side can silently lose Claude Code chat history even though other data survives (a separate, confirmed issue — #62997). Worth backing up ~/.claude before attempting any repair, not after.

Wrote up the full repro (reproduced on NVIDIA/AMD/Intel-integrated/ARM64) plus a small PowerShell script that checks a machine for this exact risk and backs up ~/.claude first: https://github.com/sifatahmedsrk52-cyber/claudeguard — the diagnose/backup tooling itself is a paid download now (real clone traffic before that pivot confirmed people wanted more than the README), but the repo's README documents the root cause and the manual fix (switch to the unpackaged build, same as v-tab-vispero found) for free, no download needed.