[BUG] Claude Desktop Windows installer fails with AddPackage HRESULT 0x80073CF6 after an earlier "successful" install left the package in an inconsistent state

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/48437
2. https://github.com/anthropics/claude-code/issues/49655
3. https://github.com/anthropics/claude-code/issues/47877

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Workaround: Claude Desktop install fails on Windows 11 with 0x80073CF6 (and 0x80073D05)

<img width="2752" height="1536" alt="Image" src="https://github.com/user-attachments/assets/ba95cf32-500a-46cd-bee7-3b0aafa3114c" />

‌

TL;DR — If the Anthropic Squirrel/MSIX installer keeps failing with AddPackage failed with HRESULT 0x80073CF6, the cause is almost always a half-removed previous install that left: 1. A stale CoworkVMService service (non-removable by the installer without admin) 2. A staged/registered MSIX package (Claude_pzs8sxrjxfjjc) stuck in an inconsistent state 3. Locked per-package registry hives (User.dat / UserClasses.dat under SystemAppData\Helium) that block Windows from cleaning up old AppData. The installer doesn't elevate enough to fix any of this. The following procedure cleans up everything deterministically and re-registers the app. ⚠️ A reboot in the middle is mandatory — do not skip it. The locked hives only release on sign-out/reboot after the package is unregistered.

This worked on Windows 11 Pro (build 10.0.22631.6199) after 4 failed installer attempts producing 0x80073CF6. Same steps should resolve the related 0x80073D05 (ERROR_DELETING_EXISTING_APPLICATION_DATA_STORE_FAILED) and 0x80073D28 (Administrator privileges required to install packaged service) that you'll hit if you only do half the cleanup.

---

Why the installer keeps failing

Looking at %TEMP%\ClaudeSetup.log, the failure chain is:

WARNING: CoworkVMService already exists (potential conflict)
WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied.
Removing: Claude_1.3109.0.0_x64__pzs8sxrjxfjjc
WARNING: Remove failed ... RemovePackage failed with HRESULT 0x80073CFA
Installing via AddPackage (current-user)...
MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6

Then, if you pre-stage with DISM and retry, the deeper root cause surfaces in Get-AppPackageLog:

503  The file system entries for package Claude_pzs8sxrjxfjjc could not be cleaned up after reboot.
5224 Error while deleting file ...\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat. Error Code : 0x20.
5224 Error while deleting file ...\SystemAppData\Helium\UserClasses.dat. Error Code : 0x20.

0x20 = ERROR_SHARING_VIOLATION. Windows has the per-package registry hives mounted for your session. Killing claude.exe does not release them — only unregistering the package, then rebooting (so nothing re-mounts them), then deleting the folder works.

---

Full fix (step by step)

Phase 1 — Clean up (run in PowerShell as Administrator)

# 1. Kill anything from the previous install
Get-Process *claude*,*chrome-native-host*,*cowork* -ErrorAction SilentlyContinue | Stop-Process -Force

# 2. Remove the registered package (per-user and all-users)
Get-AppxPackage -Name "Claude*" | Remove-AppxPackage -ErrorAction SilentlyContinue
Get-AppxPackage -AllUsers -Name "Claude*" | Remove-AppxPackage -AllUsers -ErrorAction SilentlyContinue

# 3. Remove any provisioned (system-staged) copy so Windows doesn't auto-re-register on next login
Get-AppxProvisionedPackage -Online |
    Where-Object { $_.DisplayName -like "Claude*" -or $_.PackageName -like "*Claude*" } |
    Remove-AppxProvisionedPackage -Online

# 4. Delete the conflicting service (the installer can't do this non-elevated)
sc.exe stop CoworkVMService
sc.exe delete CoworkVMService
Remove-Item "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" -Recurse -Force -ErrorAction SilentlyContinue

# 5. Clean leftover Squirrel / Claude folders
Remove-Item "$env:LOCALAPPDATA\AnthropicClaude"   -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "$env:LOCALAPPDATA\SquirrelTemp"      -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "$env:LOCALAPPDATA\SquirrelClowdTemp" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "$env:APPDATA\Claude"                 -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "$env:TEMP\Claude-*.msix"             -Force          -ErrorAction SilentlyContinue

Phase 2 — 🔴 REBOOT (mandatory — do NOT skip)

Reboot Windows. This is the step that releases the locked User.dat / UserClasses.dat hives from your user session. Skipping this guarantees you'll get 0x80073D05 on the next install attempt.

After rebooting, do not launch Claude, Cowork, or any Anthropic app. Go straight to PowerShell.

Phase 3 — Delete the leftover AppData (PowerShell as Administrator)

# Hives are now unloaded — these should succeed silently
Remove-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc"  -Recurse -Force
Remove-Item "C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc"     -Recurse -Force -ErrorAction SilentlyContinue

# Sanity check — should return nothing
reg query "HKU" | Select-String "Claude"

If a hive is still mounted (the reg query returned a hit), unload it:

reg unload "HKU\<the-exact-key-name-from-the-query>"

Then re-run the two Remove-Item commands.

Phase 4 — Download and stage the MSIX (PowerShell as Administrator)

$TempPath = "C:\ClaudeTemp"
New-Item -Path $TempPath -ItemType Directory -Force | Out-Null

Invoke-WebRequest `
    -Uri "https://claude.ai/api/desktop/win32/x64/msix/latest/redirect" `
    -OutFile "$TempPath\Claude.msix" -UseBasicParsing
Unblock-File -Path "$TempPath\Claude.msix"

# Stage into the system image (optional but avoids AppX Deployment Service races)
dism.exe /Online /Add-ProvisionedAppxPackage /PackagePath:"$TempPath\Claude.msix" /SkipLicense

Phase 5 — Install (PowerShell as Administrator — critical)

The MSIX contains a packaged service (CoworkVMService). Registering a packaged service requires admin — a non-elevated Add-AppxPackage will fail with 0x80073D28.

Add-AppxPackage -Path "C:\ClaudeTemp\Claude.msix" -ForceApplicationShutdown -ForceUpdateFromAnyVersion

No output = success.

Phase 6 — Verify and launch

Get-AppxPackage -Name "Claude*" | Select-Object Name, Version, PackageFullName
# Expect: Claude 1.3109.0.0 Claude_1.3109.0.0_x64__pzs8sxrjxfjjc

explorer.exe "shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude"

# Cleanup
Remove-Item "C:\ClaudeTemp" -Recurse -Force

---

Error-code quick reference

| HRESULT | Meaning | What it tells you |
| ------------ | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| 0x80073CFA | ERROR_INSTALL_PREREQUISITE_FAILED on Remove | The installer can't remove the old package (usually because CoworkVMService still has a handle on files). |
| 0x80073CF6 | ERROR_PACKAGE_NOT_REGISTERED / merge failure | The register half of the "remove-then-add" failed. Inner code is in the event log. |
| 0x80073D05 | ERROR_DELETING_EXISTING_APPLICATION_DATA_STORE_FAILED | The AppData hive is locked. Unregister + reboot + delete %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc. |
| 0x80073D28 | ERROR_DEPLOYMENT_BLOCKED_BY_POLICY (packaged service) | You're running Add-AppxPackage non-elevated. Re-run from an Administrator PowerShell. |
| 0x20 | ERROR_SHARING_VIOLATION (inside Get-AppPackageLog) | The exact file that's locked — grep the log for Error while deleting file to find which hive. |

---

Why the Anthropic installer alone can't fix this

• The bootstrapper self-elevates to Full but still uses AddPackage per-user, which can't purge the stuck AppData hives from other sessions.
• The CoworkVMService removal requires SCM admin access even when the bootstrapper is "elevated" through UAC, because of how it was registered by the prior install.
• The installer does not unregister the package before trying to reinstall; it tries remove-then-add in one pass, and when remove fails it still proceeds to add — which is what triggers 0x80073CF6.

Running the phases above separately — with the reboot in the middle — sidesteps all three issues.

Thank you for this and I have successfully completed all the phases, However in the desktop app, I still do not see a button for co work. There is a "Cowork" tab in the settings menu where I can turn on dispatch and assign global settings, but not button to start using the function of cowork

I found the missing piece:

Phase 7 — Enable Windows Virtualization Features (THE MISSING PIECE)
Even after a successful install, Cowork will not appear in the Claude app unless Windows virtualization features are enabled. Cowork runs a local VM and requires these to be active.
First, check their current state:
powershellGet-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V | Select FeatureName, State
Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform | Select FeatureName, State
Get-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform | Select FeatureName, State
If any show as Disabled, enable them:
powershellEnable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestart
Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All -NoRestart
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All -NoRestart

🔴 Phase 8 — Final Reboot (mandatory)
Restart Windows. After rebooting, launch Claude — the Cowork tab should now appear in the app.

Cleanup
powershellRemove-Item "C:\ClaudeTemp" -Recurse -Force -ErrorAction SilentlyContinue

Additional notes:

Several of the commands may return "path does not exist" or "service not found" errors — these are harmless and just mean those items were already cleaned up
If Cowork still doesn't appear after enabling virtualization, verify that CPU virtualization is enabled in your BIOS/UEFI settings (VT-x for Intel, SVM/AMD-V for AMD)
The Anthropic support team initially directed me to this Claude Code GitHub repo for a Claude Desktop app issue — hopefully this gets routed to the right team and the installer is improved to handle these cases automatically``

I had to translate the last portion of this reddit post:
https://www.reddit.com/r/ClaudeAI/comments/1smjejf/subscribed_to_claude_pro_but_the_cowork_tab_isnt/#:~:text=They%20changed%20the%20interface.%20Did,more%20tabs%20in%20claude%20desktop.

@ARHAEEM You absolute legend. This worked PERFECTLY.

I've been fighting this issue for over a week. Spent hours enabling Hyper-V, creating NAT rules, reinstalling, cleaning registry, disabling antivirus, restarting everything — nothing worked. Anthropic support was useless (their AI bot offered to refund me only if I cancelled my entire subscription). Multiple reinstalls failed. I was ready to give up entirely.

Your step-by-step guide fixed everything in 20 minutes. Cowork is back. Connectors are back. Claude Code in Desktop is back. All three features working perfectly.

The key insight that NOBODY else figured out — the locked User.dat/UserClasses.dat hives that only release after unregistering + rebooting — that's what made the difference. Every other guide out there just says "reinstall" without understanding WHY the reinstall keeps failing.

This is genuinely the most helpful GitHub comment I've ever seen. You did what Anthropic's own support team couldn't do.

Thank you from Barcelona. You saved my week. 🙏🙏🙏

@anthropics — please hire this person, or at the very least, add this procedure to your official troubleshooting docs. There are dozens of Windows users stuck on this exact issue right now.

Why is this closed? This is still happening.

Workaround worked for Version 1.3109 on Windows 11 Build 26200! Thank you, ARHAEEM !!!

UPDATE: Everything is broken again.

• ❌ Cowork: ERR_CONNECTION_RESET (same error as original report)
• ❌ Desktop Code: ECONNRESET
• ❌ VS Code extension: ECONNRESET
• ❌ CLI (v2.1.114): ECONNRESET
• ✅ Chat: works
• ✅ Direct API via curl: works (returns expected 405)
• ✅ Network: TcpTestSucceeded True, DNS resolves fine

Timeline:

1. Applied MSIX cleanup workaround from #49917 → Cowork worked briefly
2. API outage hit (status.claude.com showed degraded)
3. After outage resolved, NOTHING works anymore except Chat

Cowork is back to the original ERR_CONNECTION_RESET. Code gives ECONNRESET on all three surfaces (Desktop, VS Code, CLI). Even claude logout returns ECONNRESET.

The machine reaches api.anthropic.com perfectly via curl and Test-NetConnection. The problem is entirely inside Claude's application layer.

Kaspersky fully disabled — no difference. No proxy configured. DNS flushed. Fresh login attempted.

status.claude.com shows All Systems Operational.

Windows 11 Pro, Max Plan (€89/month), 10+ days of broken premium features.

@anthropics please acknowledge this. Multiple users affected.

Root cause identified: orphaned WebView2 processes lock registry hives in %LOCALAPPDATA%\Packages

I hit the same HRESULT 0x80073CF6 and traced the "somewhere" where the package family name is still claimed. Posting the diagnosis in case it helps the maintainers and other affected users.

Diagnosis

After failed installs, Get-AppxPackage -AllUsers *claude* returns empty and C:\Program Files\WindowsApps\Claude_* is also empty — but this folder remains:

C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\
└── SystemAppData\Helium\
    ├── User.dat            ← registry hive (locked)
    ├── User.dat.LOG1
    ├── User.dat.LOG2
    ├── UserClasses.dat     ← registry hive (locked)
    ├── UserClasses.dat.LOG1
    └── UserClasses.dat.LOG2

These .dat files are Windows registry hives. They're held open by orphaned WebView2 child processes (chrome-native-host.exe and friends) that survive the parent Claude process termination. takeown succeeds, icacls succeeds, but Remove-Item fails with "file in use" because the OS itself has the hive mounted.

As long as this folder exists, the package family name Claude_pzs8sxrjxfjjc remains claimed in the Appx store, and every subsequent AddPackage fails with 0x80073CF6 (ERROR_PACKAGE_REGISTRATION_FAILED).

Causal chain

1. CoworkVMService removal fails with Access Denied (ACL issue, even when elevated)
2. Installer ignores the RemovePackage failure (0x80073CFA) and proceeds with AddPackage anyway, reporting success — leaving the package in a partially-registered state
3. AppX deregistration partially completes, but WebView2 child processes survive and keep the registry hives in SystemAppData\Helium\ mounted
4. %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc cannot be deleted, family name claim persists
5. All future installs fail with 0x80073CF6

Workaround that worked

Standard Remove-Item and Remove-AppxPackage do not work because the hives are locked by live processes. Two reliable methods:

Method A — Reboot-time deletion via PendingFileRenameOperations:

$folder = "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc"
$items = Get-ChildItem -LiteralPath $folder -Recurse -Force | Sort-Object FullName -Descending
$paths = @($items.FullName) + @($folder)
$key = "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager"
$existing = (Get-ItemProperty -Path $key -Name "PendingFileRenameOperations" -ErrorAction SilentlyContinue).PendingFileRenameOperations
$newEntries = @()
foreach ($p in $paths) { $newEntries += "\??\$p"; $newEntries += "" }
$combined = if ($existing) { $existing + $newEntries } else { $newEntries }
Set-ItemProperty -Path $key -Name "PendingFileRenameOperations" -Value $combined -Type MultiString
Restart-Computer

Method B — Safe Mode deletion (simpler, recommended for non-experts):

Boot into Safe Mode, then Remove-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force. WebView2 doesn't start in Safe Mode, so no locks.

After either method, also remove %APPDATA%\Claude (contains another locked file: ChromeNativeHost\chrome-native-host.exe), then reinstall. Confirmed working on Windows 11 Pro build 26200, with installer version 1.5354.0 / 9a9e3d5a4a368f0f49a80dc303b0ed1a18bfedad.

Suggested fixes for the installer

In addition to the points already raised in this thread:

• Terminate WebView2 child processes during uninstall. The Claude parent process termination doesn't propagate to chrome-native-host.exe and other WebView2 children. They keep SystemAppData\Helium\*.dat registry hives mounted, blocking the AppData package folder cleanup. Consider walking the process tree (or using job objects) to ensure all descendants exit before RemovePackage.
• Explicit cleanup of %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc and %APPDATA%\Claude on uninstall, with retry-on-reboot via MoveFileEx(MOVEFILE_DELAY_UNTIL_REBOOT) if files are locked.
• Detect and surface this orphaned-folder state on install start. If the AppData package folder exists but no AppX package is registered, the installer is guaranteed to fail with 0x80073CF6 — it should detect this preflight and offer cleanup, not run AddPackage and fail 12 seconds later.

"Same issue. Windows 11 Pro build 26200. Claude Desktop 1.6259.1. Two stuck folders in WindowsApps (1.4758.0.0 and 1.5220.0.0). Get-AppxPackage, winget, DISM — none detect the package. takeown + icacls fail to delete the folders. Hyper-V was missing and has been enabled. Still fails with 0x80073CF6."

A "This will delete ALL your stuff" warning would have been nice. I lost all of my scheduled jobs , summaries... everything....

Same wedged state on Windows 11, with a few additional findings worth adding.

Environment

• Windows 11, x64 (Lenovo Legion, consumer hardware — not enterprise/managed)
• Claude Desktop: latest as of 2026-05-08
• Elevation: confirmed True via [Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent().IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

Symptoms

Identical to OP — same HRESULT pair from the install log:

WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied.
WARNING: Remove failed for Claude_1.6608.0.0_x64__pzs8sxrjxfjjc: RemovePackage failed with HRESULT 0x80073CFA
MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6
ERROR dialog: Administrator access is required to install Claude with full features. You can try again or install without Cowork.

The "install without Cowork" button promised in the dialog never rendered.

Additional findings not yet in this thread

1. WindowsApps folder accumulation is the actual root cause

After multiple failed install attempts, C:\Program Files\WindowsApps had accumulated six dead Claude_* folders:

Claude_1.1.3918.0_x64__pzs8sxrjxfjjc
Claude_1.1.4010.0_x64__pzs8sxrjxfjjc
Claude_1.1.4173.0_x64__pzs8sxrjxfjjc
Claude_1.1.7053.0_x64__pzs8sxrjxfjjc
Claude_1.1.7203.0_x64__pzs8sxrjxfjjc
Claude_1.6608.0.0_x64__pzs8sxrjxfjjc

None of these were visible to Get-AppxPackage *Claude* (returned empty), but the AppX deployment service still tracked them via StateRepository. Every new install attempt failed because RemovePackage couldn't clean them and AddPackage layered on top of un-removed packages.

2. CoworkVMService cannot be deleted even by LocalSystem

Tested every removal path, all failed:

• sc.exe delete CoworkVMService from elevated PowerShell → OpenService FAILED 5: Access is denied
• (Get-CimInstance Win32_Service -Filter "Name='CoworkVMService'").Delete() (elevated) → return code 2 (Access Denied)
• sc.exe delete CoworkVMService from a SYSTEM-level scheduled task (/ru SYSTEM) → service still present and stopped after task ran

This is a stronger ACL than the existing issues report. It suggests the service is being created with a security descriptor that explicitly denies even NT AUTHORITY\SYSTEM the DELETE right, which means the installer's own RemoveService logic can never succeed once the service enters this state.

Recovery procedure that worked

From elevated PowerShell:

# Nuke ghost WindowsApps folders
$folders = Get-ChildItem "C:\Program Files\WindowsApps" -Filter "Claude_*"
foreach ($f in $folders) {
    takeown /F $f.FullName /R /A /D Y | Out-Null
    icacls $f.FullName /grant "administrators:(F)" /T /C | Out-Null
    Remove-Item -Recurse -Force $f.FullName -ErrorAction Continue
}

Then reboot (mandatory — StateRepository ghost entries only flush during the boot-time AppX reconciliation pass), then re-run the installer. Install succeeded on first attempt post-reboot.

The CoworkVMService corpse remained but is harmless — the installer logs its removal failure as a WARNING and proceeds. Cowork is unavailable in the resulting install, but base Claude Desktop works fine.

Suggested fixes

1. Cleanup orphaned package folders. Installer should enumerate and clean C:\Program Files\WindowsApps\Claude_* directories that have no corresponding Get-AppxPackage entry before calling AddPackage.
2. Make CoworkVMService removable. Service should be created with a security descriptor that allows uninstall by the installer's elevation context (or at minimum by LocalSystem).
3. Implement or remove --no-cowork. This CLI flag is referenced in earlier issues but silently no-ops in the current installer.
4. Always render the "install without Cowork" fallback. When AddPackage fails on the Cowork component, the dialog should reliably offer the no-Cowork install path the dialog text promises.
5. Better error surfacing. The "Administrator access is required" message is misleading when Is elevated: true is already in the log. The real cause (ACL on a service handle, ghost WindowsApps folders) should be surfaced or at minimum linked to a remediation doc.

how do you get Claude Desktop to install without CoWork? Or when do I get my discounted Anthropic subscription now that I can only use half of the tools I am paying for?

# Workaround: Claude Desktop install fails on Windows 11 with 0x80073CF6 (and 0x80073D05) <img alt="Image" width="2000" height="1116" src="https://private-user-images.githubusercontent.com/63544079/579926978-ba95cf32-500a-46cd-bee7-3b0aafa3114c.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzkwODg1MjcsIm5iZiI6MTc3OTA4ODIyNywicGF0aCI6Ii82MzU0NDA3OS81Nzk5MjY5NzgtYmE5NWNmMzItNTAwYS00NmNkLWJlZTctM2IwYWFmYTMxMTRjLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA1MTglMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNTE4VDA3MTAyN1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTM5YWI3MGQzZGM4NmIwNGQ0NDEzY2FlMGI4OTZlMmNlZWUyYTBhYzI4YjI0ZDM4MmEwN2M1MjEzOWI1N2ZmNTUmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.G63C7dt193jlXZBrWbbHgNA6WPtVKrqu2vnv-vWY9Vk"> ‌ > TL;DR — If the Anthropic Squirrel/MSIX installer keeps failing with AddPackage failed with HRESULT 0x80073CF6, the cause is almost always a half-removed previous install that left: > > 1. A stale CoworkVMService service (non-removable by the installer without admin) > 2. A staged/registered MSIX package (Claude_pzs8sxrjxfjjc) stuck in an inconsistent state > 3. Locked per-package registry hives (User.dat / UserClasses.dat under SystemAppData\Helium) that block Windows from cleaning up old AppData. > > The installer doesn't elevate enough to fix any of this. The following procedure cleans up everything deterministically and re-registers the app. > ⚠️ A reboot in the middle is mandatory — do not skip it. The locked hives only release on sign-out/reboot after the package is unregistered. This worked on Windows 11 Pro (build 10.0.22631.6199) after 4 failed installer attempts producing 0x80073CF6. Same steps should resolve the related 0x80073D05 (ERROR_DELETING_EXISTING_APPLICATION_DATA_STORE_FAILED) and 0x80073D28 (Administrator privileges required to install packaged service) that you'll hit if you only do half the cleanup. ## Why the installer keeps failing Looking at %TEMP%\ClaudeSetup.log, the failure chain is: `` WARNING: CoworkVMService already exists (potential conflict) WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied. Removing: Claude_1.3109.0.0_x64__pzs8sxrjxfjjc WARNING: Remove failed ... RemovePackage failed with HRESULT 0x80073CFA Installing via AddPackage (current-user)... MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6 ` Then, if you pre-stage with DISM and retry, the deeper root cause surfaces in Get-AppPackageLog: ` 503 The file system entries for package Claude_pzs8sxrjxfjjc could not be cleaned up after reboot. 5224 Error while deleting file ...\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat. Error Code : 0x20. 5224 Error while deleting file ...\SystemAppData\Helium\UserClasses.dat. Error Code : 0x20. ` 0x20 = ERROR_SHARING_VIOLATION. Windows has the per-package registry hives mounted for your session. Killing claude.exe does **not** release them — only unregistering the package, then rebooting (so nothing re-mounts them), then deleting the folder works. ## Full fix (step by step) ### Phase 1 — Clean up (run in PowerShell as Administrator) # 1. Kill anything from the previous install Get-Process *claude*,*chrome-native-host*,*cowork* -ErrorAction SilentlyContinue | Stop-Process -Force # 2. Remove the registered package (per-user and all-users) Get-AppxPackage -Name "Claude*" | Remove-AppxPackage -ErrorAction SilentlyContinue Get-AppxPackage -AllUsers -Name "Claude*" | Remove-AppxPackage -AllUsers -ErrorAction SilentlyContinue # 3. Remove any provisioned (system-staged) copy so Windows doesn't auto-re-register on next login Get-AppxProvisionedPackage -Online | Where-Object { $_.DisplayName -like "Claude*" -or $_.PackageName -like "*Claude*" } | Remove-AppxProvisionedPackage -Online # 4. Delete the conflicting service (the installer can't do this non-elevated) sc.exe stop CoworkVMService sc.exe delete CoworkVMService Remove-Item "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" -Recurse -Force -ErrorAction SilentlyContinue # 5. Clean leftover Squirrel / Claude folders Remove-Item "$env:LOCALAPPDATA\AnthropicClaude" -Recurse -Force -ErrorAction SilentlyContinue Remove-Item "$env:LOCALAPPDATA\SquirrelTemp" -Recurse -Force -ErrorAction SilentlyContinue Remove-Item "$env:LOCALAPPDATA\SquirrelClowdTemp" -Recurse -Force -ErrorAction SilentlyContinue Remove-Item "$env:APPDATA\Claude" -Recurse -Force -ErrorAction SilentlyContinue Remove-Item "$env:TEMP\Claude-*.msix" -Force -ErrorAction SilentlyContinue ### Phase 2 — 🔴 REBOOT (mandatory — do NOT skip) Reboot Windows. This is the step that releases the locked User.dat / UserClasses.dat hives from your user session. Skipping this guarantees you'll get 0x80073D05 on the next install attempt. After rebooting, **do not** launch Claude, Cowork, or any Anthropic app. Go straight to PowerShell. ### Phase 3 — Delete the leftover AppData (PowerShell as Administrator) # Hives are now unloaded — these should succeed silently Remove-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force Remove-Item "C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force -ErrorAction SilentlyContinue # Sanity check — should return nothing reg query "HKU" | Select-String "Claude" If a hive is still mounted (the reg query returned a hit), unload it: reg unload "HKU\<the-exact-key-name-from-the-query>" Then re-run the two Remove-Item commands. ### Phase 4 — Download and stage the MSIX (PowerShell as Administrator) $TempPath = "C:\ClaudeTemp" New-Item -Path $TempPath -ItemType Directory -Force | Out-Null Invoke-WebRequest -Uri "https://claude.ai/api/desktop/win32/x64/msix/latest/redirect" -OutFile "$TempPath\Claude.msix" -UseBasicParsing Unblock-File -Path "$TempPath\Claude.msix" # Stage into the system image (optional but avoids AppX Deployment Service races) dism.exe /Online /Add-ProvisionedAppxPackage /PackagePath:"$TempPath\Claude.msix" /SkipLicense ### Phase 5 — Install (PowerShell **as Administrator** — critical) The MSIX contains a packaged service (CoworkVMService). Registering a packaged service **requires admin** — a non-elevated Add-AppxPackage will fail with 0x80073D28. Add-AppxPackage -Path "C:\ClaudeTemp\Claude.msix" -ForceApplicationShutdown -ForceUpdateFromAnyVersion No output = success. ### Phase 6 — Verify and launch Get-AppxPackage -Name "Claude*" | Select-Object Name, Version, PackageFullName # Expect: Claude 1.3109.0.0 Claude_1.3109.0.0_x64__pzs8sxrjxfjjc explorer.exe "shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude" # Cleanup Remove-Item "C:\ClaudeTemp" -Recurse -Force ## Error-code quick reference HRESULT Meaning What it tells you 0x80073CFA ERROR_INSTALL_PREREQUISITE_FAILED on Remove The installer can't remove the old package (usually because CoworkVMService still has a handle on files). 0x80073CF6 ERROR_PACKAGE_NOT_REGISTERED / merge failure The register half of the "remove-then-add" failed. Inner code is in the event log. 0x80073D05 ERROR_DELETING_EXISTING_APPLICATION_DATA_STORE_FAILED The AppData hive is locked. Unregister + reboot + delete %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc. 0x80073D28 ERROR_DEPLOYMENT_BLOCKED_BY_POLICY (packaged service) You're running Add-AppxPackage non-elevated. Re-run from an Administrator PowerShell. 0x20 ERROR_SHARING_VIOLATION (inside Get-AppPackageLog) The exact file that's locked — grep the log for Error while deleting file to find which hive. ## Why the Anthropic installer alone can't fix this * The bootstrapper self-elevates to Full but still uses AddPackage per-user, which can't purge the stuck AppData hives from other sessions. * The CoworkVMService removal requires SCM admin access even when the bootstrapper is "elevated" through UAC, because of how it was registered by the prior install. * The installer does not unregister the package before trying to reinstall; it tries remove-then-add in one pass, and when remove fails it still proceeds to add — which is what triggers 0x80073CF6`. Running the phases above separately — with the reboot in the middle — sidesteps all three issues.

so I only followed up to the reboot, and didn't reboot. and it still worked! thanks

Guys, forget about everything—just turn off your antivirus

Claude Relaunch Update fails with File in use by another process

Uninstall and reinstall fails with...

2026/05/20 11:36:20.973741 Checking for running Squirrel Claude processes...
2026/05/20 11:36:20.983813 No Squirrel Claude processes found
2026/05/20 11:36:20.983813 Checking for existing Claude MSIX packages...
2026/05/20 11:36:21.018329 Installing MSIX: C:\Users\Anil\AppData\Local\Temp\Claude-2218004046.msix
2026/05/20 11:36:21.019379 Extracted family name from MSIX manifest: Claude_pzs8sxrjxfjjc
2026/05/20 11:36:21.019379 Standard install (not split-account), using AddPackage
2026/05/20 11:36:21.019379 Installing via AddPackage (current-user)...
2026/05/20 11:36:31.819116 MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6
2026/05/20 11:36:31.819116 ERROR dialog (opening log): Installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6

Please share this log with us.
2026/05/20 11:36:40.229462 Elevated process exited with code 1
2026/05/20 11:36:40.229462 Elevation failed: elevated installer exited with code 1
2026/05/20 11:36:40.229462 ERROR dialog (with log path): Administrator access is required to install Claude with full features. You can try again or install without Cowork.

Cross-linking with #49655 because this appears to be the same Windows/MSIX installer failure family: CoworkVMService / Claude package processes can keep the MSIX package locked, and the service cannot be disabled/reconfigured by a normal elevated admin shell due to OpenService FAILED 5: Access is denied.

A confirmed no-reboot workaround was posted here: https://github.com/anthropics/claude-code/issues/49655#issuecomment-4498317708

Key extra detail from that repro: stopping CoworkVMService alone was not always enough; all claude.exe processes running from C:\Program Files\WindowsApps\Claude_* also had to be terminated before rerunning the updater.

Same issue here.

Is there an application or updated install package to fix the issue for the end user or do I have to play developer/sys-admin rooting around in powershell to get a desktop app to work? It would be good to have an executable that does whatever is required to fix all the windows internals so the end user doesn't have to do all this low level surgery.

We are not all windows developers here.

Same issue here. Is there an application or updated install package to fix the issue for the end user or do I have to play developer/sys-admin rooting around in powershell to get a desktop app to work? It would be good to have an executable that does whatever is required to fix all the windows internals so the end user doesn't have to do all this low level surgery. We are not all windows developers here.

Just run the commands in order, this post demonstrates how to fix and then you can install again just fine. It's just a few terminal commands.

https://github.com/anthropics/claude-code/issues/49917#issuecomment-4268321062

I don't understand all of the terminal commands, therefore it's not a trivial task and I find the attitude insulting. Is there a reliable way to remedy this issue without screwing around doing a bunch of obviously AI generated terminal commands on my system? What is the remedy if these unknown to me windows terminal commands further break my system?

By the way, this is exactly how my previous install was screwed up was following terminal commands to fix broken local MCPs.

On Thu, May 21, 2026, at 10:49 AM, Jesse Beckton wrote:

jbeckton left a comment (anthropics/claude-code#49917) <https://github.com/anthropics/claude-code/issues/49917#issuecomment-4509965748> > Same issue here. > > Is there an application or updated install package to fix the issue for the end user or do I have to play developer/sys-admin rooting around in powershell to get a desktop app to work? It would be good to have an executable that does whatever is required to fix all the windows internals so the end user doesn't have to do all this low level surgery. > > We are not all windows developers here. > Just run the commands in order, this post demonstrates how to fix and then you can install again just fine. It's just a few terminal commands. #49917 (comment) <https://github.com/anthropics/claude-code/issues/49917#issuecomment-4268321062> — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/49917#issuecomment-4509965748>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHMSVARAM46R2NF3MTM4XUL434QPVAVCNFSM6AAAAACX46HAAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKMBZHE3DKNZUHA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: @.***>

I don't understand all of the terminal commands, therefore it's not a trivial task and I find the attitude insulting. Is there a reliable way to remedy this issue without screwing around doing a bunch of obviously AI generated terminal commands on my system? What is the remedy if these unknown to me windows terminal commands further break my system? By the way, this is exactly how my previous install was screwed up was following terminal commands to fix broken local MCPs. […](#)

Here is copy paste into Windows Powershell/terminal https://github.com/anthropics/claude-code/issues/49655#issuecomment-4510576757

Hitting this on Windows 11 25H2 (build 26200). This bug has hit me 10+ times over the past few months. Each occurrence costs hours and the only release is sign-out or reboot — which is the workaround the thread already documents, and
which is unacceptable as a "fix" for a paying user.

Adding new technical signal that I haven't seen in the open threads: in my current state, no user-mode process holds the Helium hive. The holder is the kernel itself, via an orphaned mount in the Windows Container registry namespace.

Diagnostic evidence (Sysinternals handle64.exe + reg query HKLM\SYSTEM\CurrentControlSet\Control\hivelist):

``
Mount path: \REGISTRY\WC\Silo62ca473d-3d16-1ca6-2f11-c9a1918f4a91\{user_sid,user_classes,software,com}
Hive files: C:\Users\<me>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\{User.dat,UserClasses.dat}
Get-AppxPackage *claude*: (empty — package unregistered)
handle64.exe -a Silo62ca473d: No matching handles found
handle64.exe -a Claude_pzs8sxrjxfjjc: No matching handles found
handle64.exe -a pzs8sxrjxfjjc: No matching handles found
Result: hive is kernel-orphaned, no user-mode holder exists to kill.
``

Everything the existing threads document as failing also failed on my box this session:

• Service restarts (AppXSvc / StateRepository / ClipSvc / InstallService) — inert
• Reset-AppxPackage — already known to cause this state, never the cure
• Add-AppxPackage -Register and fresh Claude Setup.exe stub — fails 0x80073CF6 because AddPackage cannot mount on top of the orphaned silo
• Killing explorer / StartMenuExperienceHost / sihost — there is no user process holding it

What this means for the fix: workarounds based on "find and kill the user-mode holder" cannot work in this state. The orphan needs to be torn down at deploy time (Remove-AppxPackage should not leave the silo behind on failed unregister)
or via a documented recovery API. Right now there is no documented user-mode way to unmount a \REGISTRY\WC\ silo without ending the session.

Asks:

1. Acknowledge this issue is real and assign an owner. It's been open since April 17 with no Anthropic engagement and at least 10 related/duplicate issues filed.
2. Fix the installer's failed-unregister path so it doesn't orphan the silo.
3. Provide a supported recovery command for users already in this state — anything that doesn't require sign-out or reboot.

This deleted all my pinned and archived sessions from the lefthand column in Claude desktop. Groan.

Additional data point from another Windows 11 machine. This looks related to the 0x80073CF6 wedged state, but in my case I caught an earlier/lighter failure mode before the AppX registration was fully broken.

Initial state:

Get-AppxPackage *claude*

returned a registered package with Status: Ok:

Claude_1.10628.2.0_x64__pzs8sxrjxfjjc
PackageFamilyName: Claude_pzs8sxrjxfjjc

However, a process was still running from inside the package's user data folder:

chrome-native-host.exe
parent: cmd.exe
path: %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe

After stopping only that Claude-owned native host process, the installer could proceed further.

The AppXDeploymentServer event log then showed a second update path:

Add operation started for:
https://downloads.claude.ai/releases/win32/x64/1.10628.2/Claude-deee0a79e9070caed69480a2c8d2e09f895512c4.msix

Options:
NormalPriorityRequest
DeferRegistrationWhenPackagesAreInUse

Windows then reported that the affected app was still running:

The package was not updated because an affected app was running:
{Claude_pzs8sxrjxfjjc!Claude}

and marked the new package for deferred registration because the old package was still in use:

{Claude_1.10628.0.0_x64__pzs8sxrjxfjjc} is still running, marking
{Claude_1.10628.2.0_x64__pzs8sxrjxfjjc} for deferred registration.

When I manually tried Add-AppxPackage while Claude was running, it failed with:

0x80073D02: The package could not be installed because resources it modifies are currently in use.
The following apps need to be closed: Claude_1.10628.0.0_x64__pzs8sxrjxfjjc

After stopping all Claude.exe processes, Add-AppxPackage succeeded. Later, Windows also resolved the official 1.10628.2.0 deferred registration through:

RegisterByPackageFamilyName
Main package: Claude_pzs8sxrjxfjjc
Options: ForceApplicationShutdownOption

The same event sequence also shows PackagedServiceDEH terminating CoworkVMService successfully during the update:

TerminateSingleService succeeded for CoworkVMService
terminateService: true

Final state:

Claude_1.10628.2.0_x64__pzs8sxrjxfjjc
Status: Ok

After recovery, the same diagnostic script again found Claude-owned background processes:

chrome-native-host.exe
cowork-svc.exe

The package was still healthy (Status: Ok), but this shows the process residue can reappear even after a successful update. That makes it a good preflight target for future installer runs.

Why I think this matters:

This suggests at least two related failure modes:

1. A fully wedged state, as described above, where removal fails and future AddPackage calls hit 0x80073CF6.
2. An earlier state where AppX registration is still recoverable, but Claude-owned child processes keep package resources in use. In that state, Windows can recover if the installer reliably closes the app/native-host descendants and then resolves deferred registration.

The important distinction seems to be:

0x80073D02 = package resources are still in use; recoverable by closing/stopping Claude-owned processes
0x80073CFA = remove failed; should not be treated as success
0x80073CF6 = registration failed; likely later/broken state if the previous remove/update left the PFN wedged

Suggested installer-side changes:

• Before remove/update, terminate all Claude-owned descendants, not only the top-level Claude.exe.
• Specifically look for chrome-native-host.exe launched from %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\.
• Treat cowork-svc.exe / CoworkVMService as part of the same preflight.
• Use the AppX update path that handles running apps explicitly, e.g. DeferRegistrationWhenPackagesAreInUse, then complete with RegisterByPackageFamilyName + ForceApplicationShutdownOption.
• Surface 0x80073D02 separately from 0x80073CF6: 0x80073D02 is the recoverable "app still running" condition, while 0x80073CF6 appears to be the later broken-registration condition.
• If package removal fails with 0x80073CFA, do not proceed as if the install succeeded. Either force shutdown/retry or show a repair flow.

Safe user workaround that worked here:

$family = "Claude_pzs8sxrjxfjjc"
$pkgPath = Join-Path $env:LOCALAPPDATA "Packages\$family"

Get-CimInstance Win32_Process |
  Where-Object {
    $_.Name -ieq "claude.exe" -or
    $_.Name -ieq "chrome-native-host.exe" -or
    $_.Name -ieq "cowork-svc.exe" -or
    $_.ExecutablePath -like "$pkgPath*" -or
    $_.CommandLine -like "*$family*"
  } |
  ForEach-Object { Stop-Process -Id $_.ProcessId -Force -ErrorAction SilentlyContinue }

Add-AppxPackage -RegisterByFamilyName -MainPackage $family -ForceApplicationShutdown

I would treat deletion of %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc as a last-resort cleanup only when no Claude AppX package is registered anymore. In this case it was not necessary, because the package was still registered and recoverable.

One caveat: I would avoid calling this specifically a WebView2 issue unless a failing machine shows msedgewebview2.exe running with Claude package paths. In this local package, the stronger evidence points to Claude's packaged native messaging host and packaged service (CoworkVMService).

I was able to resolve this after multiple failed installer attempts (HRESULT 0x80073D28 / 0x80073CFA) on Windows 10 Home (build 10.0.26200), following the cleanup guide in this thread with a few modifications. Posting here in case it helps others.

What was different from the guide:

1. The download via Invoke-WebRequest failed with a connection error both on the redirect URL and the direct URL. I also got a certificate revocation error with curl.exe. The fix was to use curl.exe with the -k flag to skip the certificate check:

curl.exe -L -k -o "C:\ClaudeTemp\Claude.msix" "https://downloads.claude.ai/releases/win32/x64/1.12603.1/Claude-3df4fd263723119bc45f0af2d784afd5055e2ba9.msix"

1. Add-AppxPackage with -ForceApplicationShutdown -ForceUpdateFromAnyVersion still failed with 0x80073D28 (administrator privileges required to install packaged service). -AllUsers is not a valid parameter on this Windows edition.

1. The fix was to use DISM with /Region="all" to provision the package system-wide, then register it for the current user:

dism.exe /Online /Add-ProvisionedAppxPackage /PackagePath:"C:\ClaudeTemp\Claude.msix" /SkipLicense /Region="all"
Add-AppxPackage -RegisterByFamilyName -MainPackage Claude_pzs8sxrjxfjjc -ForceApplicationShutdown

After that, Claude installed and launched successfully with Cowork intact. Hope this saves someone else a few hours!

I was able to resolve this after multiple failed installer attempts (HRESULT 0x80073D28 / 0x80073CFA) on Windows 10 Home (build 10.0.26200), following the cleanup guide in this thread with a few modifications. Posting here in case it helps others. What was different from the guide: 1. The download via Invoke-WebRequest failed with a connection error both on the redirect URL and the direct URL. I also got a certificate revocation error with curl.exe. The fix was to use curl.exe with the -k flag to skip the certificate check: `` curl.exe -L -k -o "C:\ClaudeTemp\Claude.msix" "https://downloads.claude.ai/releases/win32/x64/1.12603.1/Claude-3df4fd263723119bc45f0af2d784afd5055e2ba9.msix" ` 2. Add-AppxPackage with -ForceApplicationShutdown -ForceUpdateFromAnyVersion still failed with 0x80073D28 (administrator privileges required to install packaged service). -AllUsers is not a valid parameter on this Windows edition. 3. The fix was to use DISM with /Region="all" to provision the package system-wide, then register it for the current user: ` dism.exe /Online /Add-ProvisionedAppxPackage /PackagePath:"C:\ClaudeTemp\Claude.msix" /SkipLicense /Region="all" Add-AppxPackage -RegisterByFamilyName -MainPackage Claude_pzs8sxrjxfjjc -ForceApplicationShutdown `` After that, Claude installed and launched successfully with Cowork intact. Hope this saves someone else a few hours!

Dont forget to change path to your computers claudeTemp folder and rename to claude.msix name. İf doesnt work follow another step:

Press Windows Key + R, type gpedit.msc, and press Enter.

Navigate to the following path in the left pane:

Computer Configuration > Administrative Templates > Windows Components > App Package Deployment

In the right pane, look for the policy named "Allow all trusted apps to install".

Double-click it, set it to Enabled, and click Apply then OK.

I've now had this issue twice, the second time this weekend. Came up with a simplified repair process that worked for me, mentioning it here for additional context in the hope it might be useful.

Hitting the same wedge, different machine — adding this as a second data point since my log shows the "tail end" state (package already fully gone, not mid-transition).

Environment

• OS: Windows 10, build 10.0.19045 (Core edition)
• Architecture: x64
• Package family: Claude_pzs8sxrjxfjjc
• A second laptop, same Windows build, same Anthropic account, still installs/updates fine — so this isn't account- or policy-wide.

Sequence of events

1. Claude Desktop was working normally.
2. The Filesystem extension stopped being usable in chats (still showed installed/enabled in the Extensions UI).
3. The Extensions page started throwing Error loading extensions — TypeError: u._parse is not a function (screenshot no longer available, exact text preserved from when it occurred — possibly unrelated front-end bug, flagging in case it's connected).
4. An update attempt failed.
5. Claude Desktop is now fully uninstalled (confirmed via Apps & Features — no entry present).
6. Every reinstall attempt since fails identically with AddPackage failed: AddPackage failed with HRESULT 0x80073CF6, surfaced in the UI as An internal error occurred with error 0x80073D05 during registration of windows.stateExtension (per Event Viewer).

Log excerpt (matches the "Runs 2/3/4" pattern in this issue)

2026/07/15 17:39:07.047249 Checking for existing Claude MSIX packages...
2026/07/15 17:39:07.066809 Installing MSIX: C:\Users\eastb\AppData\Local\Temp\Claude-2849373251.msix
2026/07/15 17:39:07.067809 Extracted family name from MSIX manifest: Claude_pzs8sxrjxfjjc
2026/07/15 17:39:07.067809 Standard install (not split-account), using AddPackage
2026/07/15 17:39:07.067809 Installing via AddPackage (current-user)...
2026/07/15 17:39:32.575687 MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6
2026/07/15 17:39:32.575687 ERROR dialog (opening log): Installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6
2026/07/15 17:46:18.534161 Elevated process exited with code 1
2026/07/15 17:46:18.534161 Elevation failed: elevated installer exited with code 1
2026/07/15 17:46:18.534161 ERROR dialog (with log path): Administrator access is required to install Claude with full features. You can try again or install without Cowort.

Same signature noted above: no Removing: line — the enumeration step finds nothing to remove, yet AddPackage is rejected ~25s in. Package family name still appears claimed somewhere outside what the deployment API enumerates.

Diagnostics already ruled out

• DISM /Online /Cleanup-Image /ScanHealth — no component store corruption
• sfc /scannow — no integrity violations
• winget --version — healthy (v1.29.280)
• Get-AppxPackage -AllUsers | Where PackageFamilyName -like "*pzs8sxrjxfjjc*" — no results (nothing enumerable)
• Get-AppxProvisionedPackage -Online | Where DisplayName -like "*Claude*" — no results
• Get-AppxPackage -AllUsers | Where IsPartiallyStaged -eq $true — no results
• Confirmed via Event Viewer (Microsoft-Windows-AppXDeploymentServer/Operational): errors 0x80073CF6, 0x80073FA, and 0x80073D05 all logged around the same timestamp, with the 0x80073D05 tied specifically to registration of windows.stateExtension.

This is consistent with #49917's diagnosis: an MSIX left in a state that isn't visible to Get-AppxPackage/Remove-AppxPackage but is still holding the package family name in the deployment/state-repository layer, blocking any fresh AddPackage.

+1 on the suggested fixes in the original report, especially:

• Not claiming success when a prior removal/registration step fails
• A "repair" / "force clean" recovery path in the installer, since neither Remove-AppxPackage nor reinstall can currently clear this once wedged
• Reconciling the 0x80073CF6 (log) vs 0x80073D05 (dialog) codes so they're consistent for whoever's debugging

Happy to run further diagnostics (Get-AppPackageLog with an ActivityId, WindowsApps folder contents, etc.) if it helps — currently fully blocked from reinstalling on this machine.