[BUG] Claude Desktop MSIX installation fails with HRESULT 0x80073CFF on Windows 11 Pro Build 26200 — all workarounds exhausted

Status Open
Maintainer reply None cached
Activity 7 comments · opened May 30, 2026

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?

Claude Desktop installer consistently fails at the MSIX AddPackage step with HRESULT 0x80073CFF on Windows 11 Pro Build 26200. The error persists across all configurations and workarounds.

System Information

  • Windows edition: Professional
  • Windows version: 10.0.26200
  • Native arch: x64
  • Sideloading enabled: true
  • Developer Mode: enabled
  • S Mode: false
  • Claude Setup version: 390d6ca38de808ca81aeccd2945d9c8be800f47d

What Should Happen?

What Should Happen

Claude Desktop should install successfully and launch after the installation process completes. If the full MSIX installation with Cowork fails due to system policy restrictions, the "install without Cowork" fallback (Squirrel installer) should reliably install the application and write files to disk.

Error Messages/Logs

MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CFF
Deployment of package Claude_1.9659.2.0_x64__pzs8sxrjxfjjc with package origin Unknown failed because no valid license or sideloading policy could be applied.

Steps to Reproduce

Steps to Reproduce

  1. Download Claude Desktop installer from https://claude.ai/download (Windows x64)
  2. Run the installer (Claude Setup.exe)
  3. Installer downloads MSIX package successfully (220354768 bytes, SHA256 verified)
  4. Installer attempts AddPackage — fails with HRESULT 0x80073CFF
  5. Error dialog appears: "Administrator access is required to install Claude with full features"
  6. Clicking "Try again" reproduces the same error
  7. Running installer with --no-msix flag silently completes but writes no files to disk

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.9659.2.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

  • This issue affects multiple users on Windows 11 Pro Build 26200, see related issues: #60319, #58174, #53634
  • MSIX signature verifies successfully every time (WinVerifyTrust: MSIX signature is valid)
  • The Squirrel fallback path (--no-msix flag) silently reports "Installation complete" but writes no files to disk
  • ms-appinstaller protocol is disabled on this system (Windows policy)
  • AllowAllTrustedApps and AllowDevelopmentWithoutDevLicense registry values set to 1, Developer Mode enabled — error persists after reboot
  • Anthropic authenticode certificate manually imported to Cert:\LocalMachine\TrustedPeople — no effect
  • System is Windows 11 Insider Preview (now unenrolled), which may be contributing to the strict MSIX policy enforcement

View original on GitHub ↗

5 Comments

renestauder-cyber · 3 months ago

Note: This is labeled "invalid" but it is NOT a Claude Code issue —
it is a Claude Desktop installer bug. There is no separate issue
tracker for Claude Desktop, so filing here as recommended by support.
Please route to the Desktop team.

Loicvers · 2 months ago

Same issue, Windows build 26200, here is my log

ClaudeSetup.log

denningja · 1 month ago

SOLVED: Had the same issue on Windows 11 Home N, version 25H2, build 26200.8737.
ClaudeSetup.log

I discovered my daughter had signed into her school account on my Windows account. This may have been blocking sideloading. I removed it, rebooted and it still wasn't working.

Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\Appx" -Name "AllowAllTrustedApps" -ErrorAction SilentlyContinue

reported:

AllowAllTrustedApps : 0

so I used the registry command:

Remove-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\Appx" -Name "AllowAllTrustedApps"

I then rebooted, and Claude for desktop installed with no problems.

dhaunsperger · 1 month ago

Resolved on Windows 11 Home (Core), build 26200.

Get-AppxLog was empty; AppXDeploymentServer/Operational gave the standard package origin Unknown ... no valid license or sideloading policy could be applied. Note that this string is generic to any sideloaded non-Store package — the same text appears in unrelated 3CX and Adobe MSIX failures — so it is not evidence that Windows is mis-classifying Anthropic's signature. The signature verifies fine.

The actual cause was that sideloading policy was not being applied. Explicitly setting HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps=1 fixed it; install succeeded on the next attempt.

Installer bug: the log line AllowAllTrustedApps not found (sideloading assumed enabled) treats an absent key as "sideloading is on." That inference is wrong on this build. The preflight should either set the value or read the effective policy instead of assuming from key absence.

Followed Claude's suggestions:

1. App Install Control. Settings → Apps → Advanced app settings → Choose where to get apps. If this is set to "The Microsoft Store only," sideloaded MSIX is blocked outright and the installer never checks for it. Set to "Anywhere." Registry equivalent: HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\SmartScreen → ConfigureAppInstallControlEnabled.
2. Explicit sideloading policy. You're on Windows Home (Windows edition: Core in the log), so no gpedit — registry only:
powershell reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx" /v AllowAllTrustedApps /t REG_DWORD /d 1 /f reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" /v AllowDevelopmentWithoutDevLicense /t REG_DWORD /d 1 /f
Plus Settings → System → For developers → Developer mode: On. Microsoft's guidance is that on unmanaged Windows 11 devices, turning on Developer mode is the manual way to enable sideloading. Reboot after.

I actually didn't need that last step - Desktop installed after adding the reg keys in step 2.

dikiprawisuda · 1 month ago
Resolved on Windows 11 Home (Core), build 26200. Get-AppxLog was empty; AppXDeploymentServer/Operational gave the standard package origin Unknown ... no valid license or sideloading policy could be applied. Note that this string is generic to any sideloaded non-Store package — the same text appears in unrelated 3CX and Adobe MSIX failures — so it is not evidence that Windows is mis-classifying Anthropic's signature. The signature verifies fine. The actual cause was that sideloading policy was not being applied. Explicitly setting HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps=1 fixed it; install succeeded on the next attempt. Installer bug: the log line AllowAllTrustedApps not found (sideloading assumed enabled) treats an absent key as "sideloading is on." That inference is wrong on this build. The preflight should either set the value or read the effective policy instead of assuming from key absence. Followed Claude's suggestions: > 1. App Install Control. Settings → Apps → Advanced app settings → Choose where to get apps. If this is set to "The Microsoft Store only," sideloaded MSIX is blocked outright and the installer never checks for it. Set to "Anywhere." Registry equivalent: HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\SmartScreen → ConfigureAppInstallControlEnabled. > 2. Explicit sideloading policy. You're on Windows Home (Windows edition: Core in the log), so no gpedit — registry only: > powershell > reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx" /v AllowAllTrustedApps /t REG_DWORD /d 1 /f > reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" /v AllowDevelopmentWithoutDevLicense /t REG_DWORD /d 1 /f > Plus Settings → System → For developers → Developer mode: On. Microsoft's guidance is that on unmanaged Windows 11 devices, turning on Developer mode is the manual way to enable sideloading. Reboot after. I actually didn't need that last step - Desktop installed after adding the reg keys in step 2.

Can confirm this is working for me too.

Showing cached comments. Read the full discussion on GitHub ↗