[BUG][Root cause + working fix] Claude Desktop install fails with 0x80073CF6 — orphaned, ACL-corrupted C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc blocks the windows.stateExtension step

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

Every install of Claude Desktop for Windows (bootstrapper, direct Add-AppxPackage, Add-AppxPackage -Register, and the AppReadiness sign-in registration of a provisioned copy) fails with:

AddPackage failed with HRESULT 0x80073CF6 (ERROR_PACKAGE_REGISTRATION_FAILURE)
  inner: 0x80073D05 (error deleting the package's previously existing application data)
  inner: 0x80070005 (ACCESS DENIED)

Root cause (verified with a Process Monitor trace): Claude's MSIX registers CoworkVMService as a packaged Windows service (desktop6:Extension Category="windows.service", AppxManifest.xml line ~111). Windows stores packaged-service state under the machine-wide root C:\ProgramData\Packages\<PackageFamilyName>\<user-SID>\SystemAppData — not under the user profile. An earlier unclean uninstall left that folder behind with ACLs so damaged that AppXSvc running as SYSTEM is ACCESS DENIED on a read-attributes open. The deployment engine's windows.stateExtension step ("delete the package's previously existing application data") walks into it on every attempt and the whole registration dies. The rollback also fails (error 0x80070005: While reverting the request, the system failed to de-register the windows.stateExtension extension: Access is denied), so every attempt leaves fresh litter (HKCU\...\AppModel\SystemAppData\<family>, per-SID AppxAllUserStore entries), which sent all prior debugging in the wrong direction.

This machine failed identically for 3 weeks across dozens of attempts. After repairing/removing that one folder, the very next Add-AppxPackage succeeded and the app launches normally.

None of the workarounds on the related issues (#49917, #56949, #81747, #49655) resolve this variant, because none of them touch C:\ProgramData\Packages.

---

Quick self-test: are you hitting THIS bug?

Run in an elevated PowerShell/cmd:

icacls "C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc"

If that prints Access is denied (or the folder exists but can't be read even as admin), and your Microsoft-Windows-AppXDeploymentServer/Operational event log shows this sequence for each failed install —

id 5230  Warning  Error while deleting the existing application data. Error Code: 0x80070005.
id 306   Error    0x80073D05: ... failed to register the windows.stateExtension extension ...
                  An error occurred while deleting the package's previously existing application data.
id 331   Warning  0x80070005: While reverting the request ... Access is denied.
id 300   Error    0x80073CF6: Cannot register the Claude_pzs8sxrjxfjjc package

— then this is your bug, and the workaround below should fix it.

---

WORKAROUND (verified working)

Run everything in an elevated Windows PowerShell (not PowerShell 7 — the Appx cmdlets behave best in 5.1). Total time: ~5 minutes. Nothing below deletes user data: the broken folder is moved aside, and registry keys are exported before removal. Claude conversations are stored server-side and are unaffected.

1. Close Claude and remove any partial install:

Get-Process claude,"Claude Setup*" -ErrorAction SilentlyContinue | Stop-Process -Force
Get-AppxPackage *Claude* | Remove-AppxPackage -ErrorAction SilentlyContinue
Get-AppxProvisionedPackage -Online | Where-Object DisplayName -match Claude |
    Remove-AppxProvisionedPackage -Online -ErrorAction SilentlyContinue

2. Repair and move aside the poisoned machine-state folder (the actual fix):

$f = 'C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc'
takeown /F $f /A /R /D Y
icacls  $f /reset /T /C /Q
icacls  $f /grant "*S-1-5-32-544:(OI)(CI)F" "*S-1-5-18:(OI)(CI)F" /T /C /Q
Move-Item $f "$env:USERPROFILE\Desktop\Claude_pzs8sxrjxfjjc.backup" -Force

If takeown/icacls are themselves denied, run the same three commands as SYSTEM via a one-shot scheduled task:

schtasks /create /f /tn ClaudeAclFix /sc once /st 23:59 /ru SYSTEM /tr "cmd /c takeown /F C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc /A /R /D Y & icacls C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc /reset /T /C /Q"
schtasks /run /tn ClaudeAclFix
Start-Sleep 10; schtasks /delete /f /tn ClaudeAclFix

3. Clear the registry litter left by the failed attempts (each failed install re-creates some of this, so do it after step 2, right before reinstalling):

$fam = 'Claude_pzs8sxrjxfjjc'
$keys = @(
  "HKCU:\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\$fam"
  "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Deprovisioned\$fam"
)
$keys += (Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore' -Recurse -EA SilentlyContinue |
          Where-Object Name -match 'pzs8sxrjxfjjc').PSPath
$keys += (Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateChange\PackageList' -EA SilentlyContinue |
          Where-Object PSChildName -match 'pzs8sxrjxfjjc').PSPath
$i = 0
foreach ($k in ($keys | Where-Object { $_ -and (Test-Path $_) } | Sort-Object -Unique)) {
  $i++; reg.exe export ($k -replace '^.*::','' -replace 'HKEY_CURRENT_USER','HKCU' -replace 'HKEY_LOCAL_MACHINE','HKLM') "$env:USERPROFILE\Desktop\claude-regbackup-$i.reg" /y | Out-Null
  Remove-Item $k -Recurse -Force -EA SilentlyContinue
}
Remove-Item "$env:LOCALAPPDATA\Packages\$fam" -Recurse -Force -EA SilentlyContinue

4. Reinstall (official installer, or directly):

curl.exe -L -o "$env:USERPROFILE\Downloads\Claude-latest.msix" https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect
Add-AppxPackage -Path "$env:USERPROFILE\Downloads\Claude-latest.msix"

5. Verify — all three must be true, because a hollow success mode exists (see below):

(Get-AppxPackage *Claude*).Status                      # must be: Ok
Test-Path "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc"   # must be: True
explorer.exe shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude     # app must launch AND stay running

A fresh C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc created by the new install is expected and healthy. Delete the .backup folder and .reg exports once you're satisfied.

If your icacls self-test did not show access denied, your blocker may be a different object: reproduce the failure under Sysinternals Process Monitor and filter for ACCESS DENIED results from the AppXSvc service PID during the Add-AppxPackage call — that names the exact file/key, which is how this one was found.

---

Environment

• Windows 11 Pro for Workstations 25H2, build 26220.9022 (Insider Dev channel), x64 — but the cause is local ACL damage, not an OS-build regression
• Claude Desktop bootstrapper 6e13464cbd9c3dc0501fe5ecb0568e3d3e9ea77a; MSIX Claude_1.30096.5.0_x64__pzs8sxrjxfjjc (SHA256 A947CCF4...C12A76F, signature valid)
• History: this machine has run Claude Desktop MSIX builds spanning v1.1.x → v1.30096 (long-time user); the poisoned folder dates from a failed uninstall ~3 weeks before diagnosis

Symptom constellation (for search/triage)

1. Bootstrapper fails ~10 s after download/signature-verify with AddPackage failed with HRESULT 0x80073CF6; misleading follow-up dialog claims "Administrator access is required" even when fully elevated.
2. Get-AppxPackage / Get-AppxPackage -AllUsers -PackageTypeFilter All / DISM / winget all show nothing installed, yet every install fails; staged folder is moved to WindowsApps\Deleted\... on each rollback.
3. Deployment perf summary shows failure to reach state RegistrationChanged; staging succeeds (~4 s), registration dies (~0.5 s in).
4. Add-AppxProvisionedPackage succeeds (staging skips per-user/service state processing) → Start-menu tile appears, package can even report Status: Ok — but the install is hollow: %LOCALAPPDATA%\Packages\<family> never materializes, the tile launches a process that dies instantly (AppModel-Runtime shows the container created and destroyed), and uninstall from the tile silently fails.
5. AppReadiness loops in the background: RegisterPackageAsync ... failed ... 0x80073D05, "install failed ... will be attempted after <timestamp>" — each retry re-creates HKCU\...\AppModel\SystemAppData\<family>, making the state look "self-regenerating" during cleanup attempts.

Root-cause chain

unclean uninstall (weeks earlier)
  └─ leaves C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc\<SID>\SystemAppData
     (machine-wide state of the packaged CoworkVMService) with corrupted ACLs:
     even SYSTEM is denied FILE_READ_ATTRIBUTES
        └─ every AddPackage/Register: windows.stateExtension step must delete
           "previously existing application data" → CreateFile on that path
           → ACCESS DENIED (0x80070005) → 0x80073D05 → 0x80073CF6
              └─ revert path ALSO hits access denied → per-user state litter
                 left behind on every attempt → red herrings everywhere

Process Monitor proof (AppXSvc = svchost PID 12512, at the exact millisecond of event 5230):

23:09:45.64  svchost.exe  12512  CreateFile
  C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc\S-1-5-21-...-1001\SystemAppData
  → ACCESS DENIED   (Desired Access: Read Attributes, Open Reparse Point)
23:09:45.64  svchost.exe  12512  CreateFile
  C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc\S-1-5-21-...-1001
  → ACCESS DENIED
(repeats in 3 retry cycles at .64 / .76 / .89, then deployment aborts)

Why the previously posted workarounds don't fix this variant

Stopping CoworkVMService (#49655): the service doesn't exist while the package is uninstalled — and the lock isn't a lock, it's ACLs. Remove-AppxPackage -AllUsers, deprovisioning, reboots (#49917, #81747): nothing is registered to remove, and reboots don't change ACLs. Registry cleanup of AppxAllUserStore/SystemAppData/StateChange and even removal of dangling AppModel\Repository symlinks from years of old versions: all necessary hygiene here, all insufficient — the blocking object is a filesystem folder under C:\ProgramData\Packages, which no published workaround touches and which the generic error surfaces nowhere.

Suggestions for the installer team

1. Preflight: before AddPackage, probe C:\ProgramData\Packages\<family> (and %LOCALAPPDATA%\Packages\<family>); if unreadable/undeletable, repair ACLs (the bootstrapper is already elevated) or fail with an actionable message naming the path.
2. Uninstall: ensure packaged-service state under C:\ProgramData\Packages\<family> is actually removed; log if it can't be.
3. Error surfacing: the dialog shows generic 0x80073CF6 and then incorrectly blames elevation; the inner 0x80073D05 + "deleting previously existing application data" is available in the deployment log and would have pointed at state, not permissions-of-the-user.
4. Hollow-install detection: after provisioning, verify AppReadiness actually completed per-user registration before reporting success; Status: Ok with no %LOCALAPPDATA%\Packages\<family> is a detectable broken state.
5. Likely the same root cause behind (at minimum some reports in) #49917, #56949, #81747; related service-lock variant #49655.

---

Diagnosed 2026-08-14 → 2026-08-17 across six instrumented rounds (AppX deployment event logs, registry forensics, and finally a Process Monitor trace filtered to the AppXSvc service PID, which named the folder). Full logs/traces available on request.

What Should Happen?

Add-AppxPackage / the official bootstrapper should register the package successfully, as it did for years on this machine (v1.1.x → v1.30096). When pre-existing package state is unreadable or undeletable, the installer should repair the ACLs (the bootstrapper is already elevated) or fail with an actionable message naming the blocking path — instead of the generic 0x80073CF6 plus a misleading "Administrator access is required" dialog.

Also: a provisioned install that never completes per-user registration should not present as installed (Start-menu tile appears, package reports Status: Ok) — the hollow-install state is detectable. See "Suggestions for the installer team" at the end of the report in "What's Wrong?".

Error Messages/Logs

AddPackage failed with HRESULT 0x80073CF6 (ERROR_PACKAGE_REGISTRATION_FAILURE)
  inner: 0x80073D05 (error deleting the package's previously existing application data)
  inner: 0x80070005 (ACCESS DENIED)

Microsoft-Windows-AppXDeploymentServer/Operational — sequence logged for every failed attempt:
id 5230  Warning  Error while deleting the existing application data. Error Code: 0x80070005.
id 306   Error    0x80073D05: ... failed to register the windows.stateExtension extension ...
                  An error occurred while deleting the package's previously existing application data.
id 331   Warning  0x80070005: While reverting the request ... Access is denied.
id 300   Error    0x80073CF6: Cannot register the Claude_pzs8sxrjxfjjc package

Process Monitor (AppXSvc = svchost PID 12512, at the exact millisecond of event 5230):
23:09:45.64  svchost.exe  12512  CreateFile
  C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc\S-1-5-21-...-1001\SystemAppData
  → ACCESS DENIED   (Desired Access: Read Attributes, Open Reparse Point)
23:09:45.64  svchost.exe  12512  CreateFile
  C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc\S-1-5-21-...-1001
  → ACCESS DENIED
(repeats in 3 retry cycles at .64 / .76 / .89, then deployment aborts)

Steps to Reproduce

1. Start from a machine where an earlier unclean uninstall of Claude Desktop left C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc behind with corrupted ACLs — running icacls "C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc" from an elevated prompt prints Access is denied (even SYSTEM is denied a read-attributes open; ProcMon proof in "What's Wrong?").
2. Attempt any install of Claude Desktop: official bootstrapper, Add-AppxPackage on the MSIX, Add-AppxPackage -Register, or Add-AppxProvisionedPackage + sign-in (AppReadiness).
3. Registration fails with 0x80073CF6 (inner 0x80073D05 → 0x80070005) at the windows.stateExtension step ("delete the package's previously existing application data"). The rollback also fails with access denied, leaving fresh per-user registry litter on every attempt.
4. Repair the ACLs on that one folder and move it aside (workaround in "What's Wrong?") — the very next Add-AppxPackage succeeds and the app launches and stays running.

Reproduced identically for 3 weeks across dozens of attempts; diagnosed 2026-08-14 → 2026-08-17 across six instrumented rounds.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Not a version regression — v1.1.x → v1.30096 all installed fine until an unclean uninstall corrupted local ACLs (see report)

Claude Code Version

N/A — Claude Desktop for Windows, MSIX Claude_1.30096.5.0_x64__pzs8sxrjxfjjc (bootstrapper 6e13464cbd9c3dc0501fe5ecb0568e3d3e9ea77a)

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This report concerns Claude Desktop for Windows (MSIX/bootstrapper installer), not the Claude Code CLI — filed in this tracker because the related install-failure reports live here: #49917, #56949, #81747, #49655. A dedicated section in "What's Wrong?" explains why every workaround posted on those issues fails on this variant (none of them touch C:\ProgramData\Packages).

Environment: Windows 11 Pro for Workstations 25H2, build 26220.9022 (Insider Dev channel), x64 — the cause is local ACL damage, not an OS-build regression. MSIX signature verified valid (SHA256 A947CCF4...C12A76F).

Full AppX deployment event logs, deployment performance traces, registry forensics, and the Process Monitor trace (filtered to the AppXSvc service PID) from all six diagnostic rounds are available on request.