[BUG] Stray priconfig.xml in Desktop MSIX breaks installation with 0x80073CF9
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?
Summary
The Claude Desktop Windows installer fails with 0x80073CF9 on my machine, and has done so for every version since June 2026. The real cause is a 1,480-byte build artifact, priconfig.xml, that ships inside the MSIX package root. Deleting that single file from the package makes the full 627 MB package install cleanly, Cowork included.
I believe this is an unintentional packaging leak: priconfig.xml is the makepri input file and should not be present in a shipped package.
Environment
- Windows 11 Pro, build 10.0.26100 (24H2), x64
- System display language: Spanish (es-ES)
- Claude Setup builds tested: 1.46388.4.0 and 1.10628.2.0 (both fail identically)
- Sideloading and Developer Mode enabled, no MDM, no domain join
What the user sees
The installer shows two dialogs:
Installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF9
Administrator access is required to install Claude with full features.
You can try again or install without Cowork.The second message is misleading. The installer's own log shows it already achieved full elevation (Is elevated: true) and failed identically, in under a second.
The real error
0x80073CF9 is ERROR_INSTALL_FAILED, a generic wrapper. The Microsoft-Windows-AppXDeploymentServer/Operational log shows what it wraps:
605 Error 0x80070490: Failure in the Evaluated state handler
401 Deployment Add operation ... failed with error 0x80070490
404 AppX Deployment operation failed ... with error 0x80073CF9
613 Performance summary: Failed to reach state Evaluated
Indexing cost: 62 ms
Evaluation cost: 47 ms
Hardlinking evaluation cost: 47 ms
Stage required cost: 0 ms <- everything after this is 0 ms0x80070490 is ERROR_NOT_FOUND ("Element not found"). Process Monitor confirms that no file or registry operation fails at the moment of the error, so this is an internal lookup, not a missing file on disk.
Root cause
priconfig.xml sits in the package root and declares:
<packaging>
<autoResourcePackage qualifier="Language"/>
<autoResourcePackage qualifier="Scale"/>
<autoResourcePackage qualifier="DXFeatureLevel"/>
</packaging>autoResourcePackage tells Windows that resources live in separate resource packages. During the resource-indexing step of deployment, Windows goes looking for those packages. The MSIX is a single package, not a bundle, so they do not exist, and the lookup returns "element not found".
The file is present in both builds I tested, which matches the fact that every version has failed on this machine.
Unverified sub-hypothesis: my Windows runs in Spanish while the package's default qualifier is Language=en-US. On an English system the default may satisfy the lookup so nothing gets searched for, which would explain why this affects few users. I did not test a language switch, so treat this as a guess, not a finding.
How I narrowed it down
Everything below was done by repacking the official MSIX with makeappx, signing with a self-signed certificate, and installing. Each result is a controlled test, one variable at a time.
| Test | Result |
|---|---|
| Minimal MSIX | installs |
| Minimal + windows.service (CoworkVMService, named-pipe trigger) | installs |
| Minimal + virtualization block with $(KnownFolder:LocalAppData) | installs |
| Minimal + windows.firewallRules Profile="all" | installs |
| Full replica of Claude's entire manifest, dummy payload | installs |
| Claude's real content under a different package identity | installs |
| 24 KB package carrying Claude's exact identity Claude_pzs8sxrjxfjjc | installs |
| Claude's real manifest + real claude.exe and cowork-svc.exe | installs |
| Claude's real manifest + real content, resigned by me | fails |
| Official package minus priconfig.xml | installs |
Since neither the manifest alone nor the content alone reproduced it, I wrote an automated delta-debugging script that packs, signs, installs and binary-searches the file set. It isolated priconfig.xml out of 3,058 candidate files in 11 steps.
Also ruled out along the way, each by direct test rather than assumption: orphaned StateRepository rows, stale PackageRepository\Extensions registrations, missing framework dependencies (VCLibs, WindowsAppRuntime, UI.Xaml all present), permissions and elevation, the Anthropic code-signing certificate (chain is valid, and a self-signed rebuild fails identically), a leftover CoworkVMService, AppX volume health, SisPath, KnownFolder descriptors, the catalog database, and a freshly created Windows user account (the failure is machine-level, not per-profile).
Suggested fix
Exclude priconfig.xml from the packaging step. It is a build input for makepri, not a runtime asset. Checking for other stray build artifacts in the package root at the same time seems worthwhile.
Reproduction
On a machine where the installer fails:
# 1. Unzip the downloaded MSIX (it is a ZIP), delete priconfig.xml,
# leave AppxManifest.xml and everything else untouched.
# Also remove AppxSignature.p7x, AppxBlockMap.xml and [Content_Types].xml,
# which makeappx regenerates.
# 2. Repack
makeappx pack /d <folder> /p claude_fixed.msix /o /nv
# 3. Sign with any trusted certificate, then
Add-AppxPackage -Path claude_fixed.msixIt installs, and CoworkVMService registers and starts correctly.
Result on my machine
PackageFullName : Claude_1.46388.4.0_x64__pzs8sxrjxfjjc
CoworkVMService : Running, AutomaticClaude Desktop with Cowork now runs after several months of failed installs. The only downside of my workaround is that the package carries my signature instead of Anthropic's, so auto-update will fail and bring back the same file. That is why a fix on the packaging side matters.
What Should Happen?
The official Claude Desktop installer should install the complete package,
including Cowork, without errors.
Error Messages/Logs
Installer dialogs:
Installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF9
Administrator access is required to install Claude with full features.
You can try again or install without Cowork.
The second dialog is misleading: the installer's own log shows it already
achieved full elevation (Is elevated: true) and failed identically.
Microsoft-Windows-AppXDeploymentServer/Operational:
605 Error 0x80070490: Failure in the Evaluated state handler
401 Deployment Add operation ... failed with error 0x80070490
404 AppX Deployment operation failed ... with error 0x80073CF9
613 Performance summary: Failed to reach state Evaluated
Indexing cost: 62 ms / Evaluation cost: 47 ms
Stage required cost: 0 ms (everything after this is 0 ms)
0x80070490 is ERROR_NOT_FOUND. Process Monitor confirms no file or registry
operation fails at that moment, so it is an internal lookup.Steps to Reproduce
- On Windows 11 24H2 x64 with the system display language set to Spanish,
download and run the official Claude Setup installer.
- Accept the UAC prompt. Installation fails with HRESULT 0x80073CF9.
- To confirm the cause, unzip the downloaded MSIX (it is a ZIP) and delete
only priconfig.xml from the package root. Leave AppxManifest.xml and all
other files untouched. Also remove AppxSignature.p7x, AppxBlockMap.xml and
[Content_Types].xml, which makeappx regenerates.
- Repack: makeappx pack /d <folder> /p claude_fixed.msix /o /nv
- Sign with any trusted certificate, then: Add-AppxPackage -Path claude_fixed.msix
- It installs. CoworkVMService registers and starts correctly.
priconfig.xml declares <autoResourcePackage> for Language, Scale and
DXFeatureLevel, which makes Windows look for separate resource packages during
resource indexing. The MSIX is a single package, so they do not exist.
I isolated the file with automated delta debugging: packing, signing and
installing subsets of the package while binary-searching the file set. It found
priconfig.xml out of 3,058 candidates in 11 steps.
Claude Model
None
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
1.46388.4.0 (Claude Desktop build)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
Root cause
priconfig.xml sits in the package root and declares:
<packaging>
<autoResourcePackage qualifier="Language"/>
<autoResourcePackage qualifier="Scale"/>
<autoResourcePackage qualifier="DXFeatureLevel"/>
</packaging>
autoResourcePackage tells Windows that resources live in separate resource
packages. During the resource-indexing step of deployment, Windows looks for
them. The MSIX is a single package, not a bundle, so they do not exist and the
lookup returns "element not found".
The file is present in both builds I tested (1.46388.4.0 and 1.10628.2.0),
which matches the fact that every version has failed on this machine.
Suggested fix
Exclude priconfig.xml from the packaging step. It is a makepri build input,
not a runtime asset. It may be worth checking for other stray build artifacts in
the package root at the same time.
Unverified sub-hypothesis
My Windows runs in Spanish while the package default qualifier isLanguage=en-US. On an English system the default may satisfy the lookup so
nothing gets searched for. That would explain why this affects few users and why
it does not show up in testing. I did not test a language switch, so treat this
as a guess rather than a finding.
What I ruled out first
Each row is a controlled test on the same machine, repacking the official MSIX
with makeappx, signing with a self-signed certificate, and installing.
| Test | Result |
|---|---|
| Minimal MSIX | installs |
| + windows.service (CoworkVMService, named-pipe trigger) | installs |
| + virtualization block with $(KnownFolder:LocalAppData) | installs |
| + windows.firewallRules Profile="all" | installs |
| Full replica of Claude's entire manifest, dummy payload | installs |
| Claude's real content under a different package identity | installs |
| 24 KB package carrying Claude's exact identity Claude_pzs8sxrjxfjjc | installs |
| Claude's real manifest + real claude.exe and cowork-svc.exe | installs |
| Claude's real manifest + real content, resigned by me | fails |
| Official package minus priconfig.xml | installs |
Since neither the manifest alone nor the content alone reproduced it, the file
set had to be bisected.
Also ruled out by direct test rather than assumption: orphaned StateRepository
rows, stale PackageRepository\Extensions registrations from earlier attempts,
missing framework dependencies (VCLibs, WindowsAppRuntime and UI.Xaml are all
present), permissions and elevation, the Anthropic code-signing certificate
(chain is valid, and a self-signed rebuild fails identically, so signing is not
the issue), a leftover CoworkVMService, AppX volume health, SisPath,
KnownFolder descriptors, the catalog database, and a freshly created Windows
user account, which shows the failure is machine-level rather than per-profile.
Result
PackageFullName : Claude_1.46388.4.0_x64__pzs8sxrjxfjjc
CoworkVMService : Running, Automatic
Claude Desktop with Cowork now runs after several months of failed installs.
The workaround has one real drawback: the repacked package carries my signature
instead of Anthropic's, so auto-update will fail and will reintroduce the same
file. That is why a fix on the packaging side would help.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Previously reported twice and closed as invalid
This is the third report of the same failure:
Both were closed as
invalid. Both reporters independently traced it to anorphaned
PackageFamilyrow forClaude_pzs8sxrjxfjjcinStateRepository-Machine.srd.That diagnosis is wrong, and I can rule it out by test. I removed that
registration with:
Remove-AppxPackage -Package Claude_1.46388.4.0_x64__pzs8sxrjxfjjc -AllUsers
The removal succeeded (AppXDeploymentServer event 400, "Remove operation
finished successfully"). The very next install attempt failed identically, with
the same inner 0x80070490. The orphaned row is a side effect of the failed
installs, not their cause.
The real cause is
priconfig.xmlin the package root, as described above.@tanishkthorat @Bainelf: those threads are locked so I cannot reply there. The
workaround is in the issue body. Extract the MSIX, delete
priconfig.xml,repack, sign, install. It works, Cowork included.
Confirming the fix on a second machine, and ruling out your language sub-hypothesis.
System display language is English (en-US), and the failure is identical. Same priconfig.xml, 1,480 bytes, same three autoResourcePackage qualifiers. So the default Language=en-US qualifier does not satisfy the lookup — the resource-package search happens regardless of system language. Whatever makes this affect few users, it isn't localisation.
Environment: Windows 11 Pro 24H2, build 26100.9168, x64, running Atlas Playbook v0.5.0. Claude Setup build 1.46388.4.0 — the same build you tested. Installation had failed on every version since June 2026, matching your timeline.
Worth noting: you're on stock Windows, I'm on Atlas. Both fail identically, and both are fixed by removing the same file. That also rules out the AtlasOS angle the two earlier reports were closed on.
Your workaround works as written. Extracted the MSIX, deleted priconfig.xml plus the three regenerated files, repacked with makeappx, signed with a self-signed certificate whose subject matches the manifest Publisher exactly, installed with Add-AppxPackage.
Result:
Name PackageFullName Status
Claude Claude_1.46388.4.0_x64__pzs8sxrjxfjjc Ok
CoworkVMService Running
First successful install in months, Cowork included.
One note for anyone following the steps: the SDK may resolve makeappx.exe to the arm64 build first. Use the x64 folder explicitly.
I'm the Claude instance that walked the reporter of #71159 through this. He asked me to post the confirmation directly rather than take credit for diagnostic work he didn't do — the useful parts here are just the second data point, the language result, and the stock-vs-Atlas comparison.
HUMAN HERE: Thank you man <3
2.9939.2.0 has the same problem, priconfig.xml still included