[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.

Data point on the 0x80073D05 mapping you flagged as inconsistent — I hit the same outer 0x80073CF6 today via a different root cause, and in my case 0x80073D05 is recoverable from the logs. It just isn't in the installer's log; it's in the AppX deployment channel.

Environment: Windows 11 Pro 10.0.26100 x64, installer build 03c61d06f8e01a4db2273b9514e225f21d2ba62e, package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc.

No CoworkVMService involvement here. My installer log records Conflicting service: false, finds no existing MSIX package, and never attempts a RemovePackage — it goes straight to Standard install (not split-account), using AddPackage. So this is a separate path to the same HRESULT.

Where 0x80073D05 comes from. From Microsoft-Windows-AppXDeploymentServer/Operational:

Event 306: error 0x80073D05: While processing the request, the system failed to register
the windows.stateExtension extension due to the following error: An error occurred while
deleting the package's previously existing application data.

Event 316: error 0x80073D05: Cannot register the request because the following error was
encountered during the registration of the windows.stateExtension extension: ...

Event 404: AppX Deployment operation failed for package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc
with error 0x80073CF6. The specific error text for this failure is: An internal error
occurred with error 0x80073D05.

So 0x80073D05 is ERROR_DELETING_EXISTING_APPLICATIONDATA_STORE_FAILED, surfaced as the generic 0x80073CF6 by the time it reaches the installer. That likely explains why your dialog shows D05 while your installer log only has CF6 — the installer is reporting the outer code and the dialog the inner one.

What blocks the deletion. Event 5224 names the files, each with Error Code : 0x20 (ERROR_SHARING_VIOLATION):

C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat
                                       ...\Helium\User.dat.LOG1 / .LOG2
                                       ...\Helium\UserClasses.dat (+ .LOG1 / .LOG2)
C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc\<SID>\SystemAppData\Helium\Cache\<hash>.dat

These are mounted registry hives from a prior install, not ordinary files — mine were dated ~2 and ~4 months prior. That distinction matters for triage, because the usual cleanup advice can't work on them:

• No Claude process is running; killing processes changes nothing (the lock is held by the registry subsystem, not a visible process).
• The file cannot be deleted, and the parent folder cannot even be renamed — Rename-Item on ...\SystemAppData\Helium returns Access denied while elevated.
• Confirmed still locked out-of-band via [System.IO.File]::Open($path,'Open','ReadWrite','None') → "being used by another process".
• Note the installer's own pre-flight only checks for Squirrel-prefixed processes (Checking for running Squirrel Claude processes...), which wouldn't catch this class of conflict.

Fix: reboot, then run the installer before launching anything. The hive unmounts on restart and registration completes. Worth distinguishing from #48437, where the reporter tried a restart and it did not help — consistent with that being the CoworkVMService path rather than this one.

Two secondary bugs, both independent of the Windows-side cause:

1. The final dialog misattributes the failure to privileges. Mine read "Administrator access is required to install Claude with full features. You can try again or install without Cowork." — but the log four lines earlier says Elevation type: Full, Is elevated: true, Running in elevated context. The bootstrapper appears to map any non-zero exit from its elevated child onto the admin-rights message. That reliably sends people into UAC/sideloading/Developer Mode troubleshooting for a failure that has nothing to do with permissions; #48437's reporter ran the installer as Administrator repeatedly and enabled Developer Mode, which reads like the same misdirection. The child already writes the real cause to the shared log file the parent owns.
2. A failed upgrade deregisters the working install. Rollback moved the package to C:\Program Files\WindowsApps\Deleted\, and afterward Get-AppxPackage -Name *Claude* returns nothing. The user ends up with no Claude Desktop at all, and neither offered option ("try again" / "install without Cowork") resolves it. Surfacing "restart and retry" on 0x80073D05 specifically would close the loop.

Happy to supply the full scrubbed installer log or the AppX event export if useful.

claude-desktop-install-issue-report.txt

I'm hitting this same issue on Windows [10.0.26200], x64, Windows Core edition. Package: Claude_1.24012.9.0_x64__pzs8sxrjxfjjc.

Ran a full diagnostic cycle: confirmed elevation was genuine (Is elevated: true), package consistently shows NeedsRemediation after install/launch even though AppXDeploymentServer log shows the install itself completing successfully. Windows Repair and Reset both fail ("couldn't repair/reset this app"). CoworkVMService starts cleanly per its own log but gets stopped ~10-40s later before the app configures it — no crash dump or Application Error event generated. Ran the official Cowork Readiness Check: machine reports fully ready, and I independently confirmed via secedit that the VM service account (S-1-5-83-0) has correct SeServiceLogonRight with no deny entry — ruling out environment/config causes.

Full details attached. Also opened support ticket (Conversation ID 215475247858468) with no resolution yet.

claude-desktop-install-issue-report (1).txt

<html>
<body>
<!--StartFragment--><h1 dir="ltr" class="mt-3 -mb-1 text-[1.375rem] font-bold" data-sourcepos="1:1-1:69;0-68">Same failure on Windows 11 — with a recovery procedure that worked</h1>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="3:1-5:76;70-301">Hitting this on Windows 11 (26200) with the MSIX build. The issue currently
says no workaround was found; I got out of it, and the root cause turned out to
be narrower than the thread suggests. Full details below in case they help.</p>

<h2 dir="ltr" class="mt-3 -mb-1 text-[1.125rem] font-bold" data-sourcepos="7:1-7:15;303-317">Environment</h2>

<div dir="ltr" class="overflow-x-auto w-full px-2 mb-6 print:overflow-x-visible" data-sourcepos="9:1-14:56;319-528">
  |  
-- | --
OS | Windows 11, build 10.0.26200
Package | Claude_1.26832.0.0_x64__pzs8sxrjxfjjc
Original install source | Microsoft Store
Account type | AzureAD-joined, non-admin day-to-day

</div>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="67:1-67:26;2597-2622">Only two things survived:</p>

<div role="group" aria-label="Código" tabindex="0" data-sourcepos="69:1-72:4;2624-2746" class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg focus:outline-none focus-visible:ring-2 focus-visible:ring-accent-100"><div class="sticky opacity-0 group-hover/copy:opacity-100 group-focus-within/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"></div></div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">EXISTS: C:\Users\&lt;user&gt;\AppData\Roaming\Claude
EXISTS: C:\Users\&lt;user&gt;\AppData\Local\Packages\Claude_pzs8sxrjxfjjc</code></pre></div></div>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="74:1-77:72;2748-3053">So: <strong>no package registered, but the package's data container still present.</strong>
<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">AddPackage</code> then fails to create a container that already exists under a
mismatched identity, and registration fails. That is the whole bug — it does not
require the wedged-registration state described earlier in this thread.</p>

<h2 dir="ltr" class="mt-3 -mb-1 text-[1.125rem] font-bold" data-sourcepos="79:1-79:11;3055-3065">The fix</h2>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="81:1-82:31;3067-3177">Deleting those two directories was sufficient. No reboot, no registry edits, no
<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">WindowsApps</code> ownership games:</p>

<div role="group" aria-label="Código cmd" tabindex="0" data-sourcepos="84:1-87:4;3179-3273" class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg focus:outline-none focus-visible:ring-2 focus-visible:ring-accent-100"><div class="sticky opacity-0 group-hover/copy:opacity-100 group-focus-within/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"></div></div><div class="text-text-500 font-small p-3.5 pb-0">cmd</div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code class="language-cmd" style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre;">rd /s /q <span style="color: rgb(0, 128, 0);">"%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc"</span>
rd /s /q <span style="color: rgb(0, 128, 0);">"%APPDATA%\Claude"</span></code></pre></div></div>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="89:1-92:8;3275-3522"><code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">rd</code> rather than PowerShell's <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Remove-Item -Recurse</code> matters here: <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Roaming\Claude</code>
is full of junctions, and <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Remove-Item -Recurse</code> on PS 5.1 follows them and
deletes target contents. Delete the <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Packages</code> directory first so the junctions
dangle.</p>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="94:1-96:69;3524-3730">After that the installer succeeded on the first try, <strong>and the
<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Private dir leaf redirects</code> error was gone too</strong> — extensions now install
normally. Both symptoms trace back to the same half-removed package.</p>

<h2 dir="ltr" class="mt-3 -mb-1 text-[1.125rem] font-bold" data-sourcepos="98:1-98:21;3732-3752">Suggested changes</h2>

<ol dir="ltr" class="[li_&amp;]:mb-0 [li_&amp;]:mt-1 [li_&amp;]:gap-1 [&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-decimal flex flex-col gap-1 pl-8 mb-3 print:block print:space-y-1" data-sourcepos="100:1-109:75;3754-4503">
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="100:1-101:69;3754-3901"><strong>Abort when <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">RemovePackage</code> fails</strong> instead of proceeding to <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">AddPackage</code>.
This is already noted in the thread and is the highest-value fix.</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="102:1-104:80;3902-4137"><strong>Have the uninstaller remove its data container</strong>, or have the installer
detect an orphaned <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">LocalCache</code> container and offer to clear it. A leftover
container with no registered package is unambiguous — it is safe to reclaim.</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="105:1-107:66;4138-4347"><strong>Surface the real sub-error.</strong> <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">0x80073CF6</code> alone sends people toward
registry cleanup that, in this case, was entirely unnecessary. The
<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">AppXDeploymentServer/Operational</code> channel had nothing either.</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2" data-sourcepos="108:1-109:75;4348-4503"><strong>Revisit the path-planting check against the app's own MSIX layout</strong> — under
the Store build, that check makes extensions permanently uninstallable.</li>
</ol>

<h2 dir="ltr" class="mt-3 -mb-1 text-[1.125rem] font-bold" data-sourcepos="111:1-111:64;4505-4568">Downstream: MSIX virtualization breaks <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">uv</code>-based extensions</h2>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="113:1-114:40;4570-4687">Worth flagging separately, same root theme. After recovery, the <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Windows-MCP</code>
extension (<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">command: uv</code>) still failed:</p>

<div role="group" aria-label="Código" tabindex="0" data-sourcepos="116:1-119:4;4689-4848" class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg focus:outline-none focus-visible:ring-2 focus-visible:ring-accent-100"><div class="sticky opacity-0 group-hover/copy:opacity-100 group-focus-within/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"></div></div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">error: Missing expected target directory for Python minor version link at
C:\Users\&lt;user&gt;\AppData\Roaming\uv\python\cpython-3.13.14-windows-x86_64-none</code></pre></div></div>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="121:1-126:9;4850-5238">The files were all present and that <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">python.exe</code> ran fine standalone. <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">uv</code>
creates a minor-version junction (<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cpython-3.13</code> -&gt; <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cpython-3.13.14</code>) inside
<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">%APPDATA%\uv\python</code>. Because MCP servers are spawned inside the MSIX
container, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">%APPDATA%</code> is virtualized — but junction resolution happens in the
kernel, below that layer, so the stored target does not resolve the way <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">uv</code>
expects.</p>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="128:1-130:20;5240-5385">Workaround: install <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">uv</code>'s Python outside AppData
(<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">UV_PYTHON_INSTALL_DIR=C:\Users\&lt;user&gt;\uv-python</code>) and let the extension's
<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">.venv</code> bind to it.</p>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="132:1-139:9;5387-5940">One caveat for anyone copying this: setting <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">UV_PYTHON_INSTALL_DIR</code> as a user
environment variable was <strong>not</strong> what made it work. Claude builds a curated
environment for MCP child processes, and the variable does not reach them — I
verified it is present in the registry but absent from the spawned process. What
actually fixed it was the <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">.venv</code> created while that variable was set, which
pins <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">home = C:\Users\&lt;user&gt;\uv-python\cpython-3.13-windows-x86_64-none</code> in
<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">pyvenv.cfg</code>. If the venv is ever rebuilt from inside the container, this will
regress.</p>

<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="141:1-144:33;5942-6211">That suggests a fifth request: <strong>let extensions declare environment variables
that reach the spawned server</strong>, or pass through the user environment. Right now
there is no supported way to point a <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">uv</code>-based extension at a Python install
outside the virtualized AppData.</p><!--EndFragment-->
</body>
</html>

Reproducing this on Windows 11, and adding one detail about how the machine got into this state that may narrow down the trigger.

Environment

OS             : Windows 11 x64
Claude Code    : native 2.1.245 (installed separately, still present and functional as a binary)
Desktop app    : previously installed and running, then reinstall attempted

What the installer shows

Claude Setup
Installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6
Please share this log with us.
The log file will be opened in Explorer.

Same code as the original report: 0x80073CF6 / ERROR_PACKAGE_REGISTRATION_FAILED.

The sequence that produced it — possibly the useful part

This did not start from a broken install. It started from a working desktop app, and the reinstall is what wedged it.

1. The desktop app was installed and launching normally, but every authenticated request in its Code surface was failing with ECONNRESET (that is a separate issue — see #87424, where I have posted a full elimination pass showing the network is not involved).
2. Because the CLI's own claude install stable / claude install also failed — repeatedly, at the download stage, with The connection dropped while downloading the update (attempt 3/3: aborted) — I fell back to running the desktop app installer to get a clean install.
3. That installer run failed with AddPackage failed with HRESULT 0x80073CF6.

So the reproduction path here is: working installed package → run the installer again → package now unregisterable. The user does not have to have had a prior failed install for this to happen. That may matter for triage, since the issue title assumes an "earlier failed install" as the precondition.

Worth noting as a secondary observation: one of the failed claude install attempts also left the CLI in a degraded state — subsequent claude -p runs began emitting Execution errorClient.listTools() called but server does not advertise tools capability - returning empty list, which they did not do before. A failed install appears not to roll back cleanly in either the CLI or the MSIX path.

Why the user-facing dialog is the wrong shape

"Please share this log with us" gives no destination. There is no link, no address, no in-app path, and the built-in /bug and /feedback flows are unusable in this state because they depend on the same API path that is failing. The user is told to share a log with nobody in particular. A URL to this repo, or a copy-to-clipboard button, would close that loop.

Suggestions, in addition to those already in this thread

• If RemovePackage fails, do not proceed to AddPackage. Abort and report the removal failure instead of producing a wedged package family. This is the actual defect; the rest is fallout.
• Retry failed removals with ForceApplicationShutdown and RemoveForAllUsers before giving up.
• Ship a --repair / force-clean path in the installer, since Remove-AppxPackage, -AllUsers, and registry cleanup are all reported here as ineffective once the state is reached.
• Surface the actual failing step in the dialog, not just the terminal HRESULT.

Happy to provide the installer log or run diagnostic commands (Get-AppxPackage -AllUsers, Get-AppxProvisionedPackage -Online, service state) if that is useful for characterising the wedged state — the thread notes nobody has managed to describe it precisely yet.

Hitting this on Windows 11 Pro (10.0.26200) too. Adding a data point that's a bit different from most reports here: mine self-recovered without a reboot or manual cleanup.

Sequence: the desktop app stopped opening after several attempts, so I uninstalled and reinstalled. The reinstall then hit this bug:

• 3:14 AM — AddPackage failed: AddPackage failed with HRESULT 0x80073CF6
• - 3:17 AM — same failure again, both times followed by the misleading "Administrator access is required" dialog (already elevated per the log)
• - - 3:21 AM — a subsequent automatic retry succeeded on its own, no reboot, no registry/AppData cleanup, no admin PowerShell steps

So at least in my case the package wasn't permanently wedged — it cleared on its own after two failures. Might be useful for narrowing down whether this is a hard registration deadlock or a timing/lock race that a longer backoff before retry could avoid.

Full ClaudeSetup.log covering all 5 install attempts (1:24 AM through 3:21 AM):

<details>
<summary>ClaudeSetup.log</summary>

2026/09/03 01:24:53.516226 Log file: C:\Users\otobo\AppData\Local\Temp\ClaudeSetup.log
2026/09/03 01:24:53.516955 === Claude Setup 194d93c2558cfbfcd2b8b7a90e02774c489d1875 started ===
2026/09/03 01:24:53.518545 AllowDevelopmentWithoutDevLicense found with value: 1
2026/09/03 01:24:53.518545 Windows edition: Professional
2026/09/03 01:24:53.519243 WARNING: CoworkVMService already exists (potential conflict)
2026/09/03 01:24:53.519243 Windows version: 10.0.26200
2026/09/03 01:24:53.519243 Native arch: x64
2026/09/03 01:24:53.519243 Elevation type: Limited
2026/09/03 01:24:53.519243 Is elevated: false
2026/09/03 01:24:53.520070 Sideloading enabled: true
2026/09/03 01:24:53.520070 S Mode: false
2026/09/03 01:24:53.520070 Conflicting service: true
2026/09/03 01:24:53.520070 Running in non-elevated context
2026/09/03 01:24:53.520070 User can elevate — installing MSIX directly
2026/09/03 01:24:53.614412 MSIX URL: https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect
2026/09/03 01:24:53.614412 Downloading MSIX to C:\Users\otobo\AppData\Local\Temp\Claude-764087801.msix
2026/09/03 01:25:38.450704 Download complete: 264932954 bytes, SHA256: 38aa4ebd4a2a91a64c696a89a3d4011955a0555007046050ef73b6fba3b007d6
2026/09/03 01:25:38.482124 Self-elevating: C:\Users\otobo\Downloads\Claude Setup (6).exe --elevated --msix-path "C:\Users\otobo\AppData\Local\Temp\Claude-764087801.msix" --log-path "C:\Users\otobo\AppData\Local\Temp\ClaudeSetup.log"
2026/09/03 01:25:42.381070 Elevation type: Full
2026/09/03 01:25:42.381070 Is elevated: true
2026/09/03 01:25:42.381070 Conflicting service: true
2026/09/03 01:25:44.324650 Extracted family name from MSIX manifest: Claude_pzs8sxrjxfjjc
2026/09/03 01:25:44.335726 Removing conflicting CoworkVMService...
2026/09/03 01:25:44.335726 WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied.
2026/09/03 01:25:44.344696 Removing: Claude_1.44121.4.0_x64__pzs8sxrjxfjjc
2026/09/03 01:25:44.352035 Windows rejected data-preserving removal for Claude_1.44121.4.0_x64__pzs8sxrjxfjjc (0x80073CFA, requires developer mode); relying on in-place update
2026/09/03 01:25:44.365316 Installing via AddPackage (current-user)...
2026/09/03 01:25:49.615919 MSIX package installed successfully
2026/09/03 01:25:49.742807 === Claude Setup completed successfully ===
2026/09/03 01:25:49.759339 Elevated process exited with code 0

[--- Update 2, ~3:13 AM: same pattern as Update 1 (Conflicting service: true, RemovePackage rejected 0x80073CFA, AddPackage still succeeds) — completed successfully ---]

2026/09/03 03:14:32.366661 === Claude Setup 0d57a2f7d9b22cb8cd8804faae00208185608888 started ===
2026/09/03 03:14:32.368252 Elevation type: Limited
2026/09/03 03:14:32.368252 Is elevated: false
2026/09/03 03:14:32.368252 Conflicting service: false
2026/09/03 03:15:16.012885 Self-elevating: C:\Users\otobo\Downloads\Claude Setup (7).exe --elevated --msix-path "C:\Users\otobo\AppData\Local\Temp\Claude-2622996958.msix" --log-path "C:\Users\otobo\AppData\Local\Temp\ClaudeSetup.log"
2026/09/03 03:15:18.269116 Elevation type: Full
2026/09/03 03:15:18.269116 Is elevated: true
2026/09/03 03:15:18.269116 Conflicting service: false
2026/09/03 03:15:20.122018 Extracted family name from MSIX manifest: Claude_pzs8sxrjxfjjc
2026/09/03 03:15:20.131807 No Squirrel Claude processes found
2026/09/03 03:15:20.131807 Checking for existing Claude MSIX packages...
2026/09/03 03:15:20.149469 Standard install (not split-account), using AddPackage
2026/09/03 03:15:20.149469 Installing via AddPackage (current-user)...
2026/09/03 03:15:33.430613 MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6
2026/09/03 03:15:33.430613 ERROR dialog (opening log): Installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6
Please share this log with us.
2026/09/03 03:16:41.417308 Elevated process exited with code 1
2026/09/03 03:16:41.417930 Elevation failed: elevated installer exited with code 1
2026/09/03 03:16:41.417930 ERROR dialog (with log path): Administrator access is required to install Claude with full features. You can try again or install without Cowork.

2026/09/03 03:17:06.090856 === Claude Setup 0d57a2f7d9b22cb8cd8804faae00208185608888 started ===
2026/09/03 03:17:06.092398 Elevation type: Limited
2026/09/03 03:17:06.092398 Conflicting service: false
2026/09/03 03:17:43.549892 Self-elevating: C:\Users\otobo\Downloads\Claude Setup (7).exe --elevated --msix-path "C:\Users\otobo\AppData\Local\Temp\Claude-1520731820.msix" --log-path "C:\Users\otobo\AppData\Local\Temp\ClaudeSetup.log"
2026/09/03 03:17:43.562771 Elevation type: Full
2026/09/03 03:17:43.562771 Is elevated: true
2026/09/03 03:17:43.562771 Conflicting service: false
2026/09/03 03:17:45.458687 Extracted family name from MSIX manifest: Claude_pzs8sxrjxfjjc
2026/09/03 03:17:45.467767 No Squirrel Claude processes found
2026/09/03 03:17:45.486488 Standard install (not split-account), using AddPackage
2026/09/03 03:17:45.486488 Installing via AddPackage (current-user)...
2026/09/03 03:17:59.270717 MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6
2026/09/03 03:17:59.270717 ERROR dialog (opening log): Installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6
Please share this log with us.
2026/09/03 03:18:05.406142 Elevated process exited with code 1
2026/09/03 03:18:05.406142 Elevation failed: elevated installer exited with code 1
2026/09/03 03:18:05.406820 ERROR dialog (with log path): Administrator access is required to install Claude with full features. You can try again or install without Cowork.

2026/09/03 03:20:15.503750 === Claude Setup 0d57a2f7d9b22cb8cd8804faae00208185608888 started ===
2026/09/03 03:20:15.506985 Elevation type: Limited
2026/09/03 03:20:15.506985 Conflicting service: false
2026/09/03 03:20:20.983342 Attempt 1/3 failed: read failed: read tcp 10.240.123.25:59012->35.190.46.17:443: wsarecv: An existing connection was forcibly closed by the remote host.
2026/09/03 03:20:21.984201 Attempt 2/3 failed: HTTP request failed: Get "https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect": read tcp 10.240.123.25:59011->160.79.104.10:443: wsarecv: An established connection was aborted by the software in your host machine.
2026/09/03 03:21:18.826294 Download complete: 264936762 bytes, SHA256: 332639f6435a71b59de4b609f4ac437fab56f40db2c59d535ea1e04b0f0b1fe4
2026/09/03 03:21:18.871203 Self-elevating: C:\Users\otobo\Downloads\Claude Setup (7).exe --elevated --msix-path "C:\Users\otobo\AppData\Local\Temp\Claude-1243920485.msix" --log-path "C:\Users\otobo\AppData\Local\Temp\ClaudeSetup.log"
2026/09/03 03:21:23.785392 Elevation type: Full
2026/09/03 03:21:23.785392 Is elevated: true
2026/09/03 03:21:23.785392 Conflicting service: false
2026/09/03 03:21:25.832119 Extracted family name from MSIX manifest: Claude_pzs8sxrjxfjjc
2026/09/03 03:21:25.837832 No Squirrel Claude processes found
2026/09/03 03:21:25.856744 Installing MSIX: C:\Users\otobo\AppData\Local\Temp\Claude-1243920485.msix
2026/09/03 03:21:25.857770 Standard install (not split-account), using AddPackage
2026/09/03 03:21:25.857770 Installing via AddPackage (current-user)...
2026/09/03 03:21:35.358333 MSIX package installed successfully
2026/09/03 03:21:35.406588 MSIX installation succeeded
2026/09/03 03:21:35.595770 Launching Claude...
2026/09/03 03:21:35.693153 === Claude Setup completed successfully ===
2026/09/03 03:21:36.069855 Elevated process exited with code 0
2026/09/03 03:21:36.069855 No Squirrel installation found, skipping uninstall

</details>

(Trimmed the repetitive download-progress lines for readability; happy to post the completely unedited log if that's more useful for triage.)

Correction to my comment above: I said the 3:21 AM success happened "on its own, no reboot" — that's wrong. I rebooted the whole computer between the failed attempts and the one that worked, so this actually confirms the reboot-clears-it pattern already established in this thread, not a new automatic-recovery case. The HRESULT/timing details in the log are still accurate, just that one claim about no reboot was mistaken. Sorry for the noise.

My boss had this issue, I found a workaround:

Environment: Windows 11 Pro. A previously working Claude Desktop install stopped working; all reinstall attempts then failed.

Failure:

Installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6
Elevated process exited with code 1
Elevation failed: elevated installer exited with code 1
ERROR dialog (with log path): Administrator access is required to install Claude with full features.
You can try again or install without Cowork.

The log says the "install without Cowork" option was offered. It never rendered. The only dialog shown had a single OK button, so there was no way to take that path.

Tried, all failed:

• Installer run normally and elevated
• Get-AppxPackage *Claude* | Remove-AppxPackage, then clean re-run
• Sideloading keys (AllowAllTrustedApps, AllowDevelopmentWithoutDevLicense) + reboot
• Confirmed default app install location is C:
• Freshly downloaded installer after all of the above

---

Workaround: deploy the non-MSIX build

Skipping MSIX entirely gets you the exact configuration the fallback dialog was offering. Claude Desktop runs normally; no Cowork, no auto-update.

Windows11Pro-Deploy-ClaudeDesktop.txt

Script attached. Attached as .txt since GitHub won't accept .ps1. Rename to Windows11Pro-Deploy-ClaudeDesktop.ps1 before running. It's a fork of Cheng's Fix-ClaudeDesktop.ps1 (wuweiai.io, MIT) with the version detection fixed — PowerShell 5.1 returns .Content as a byte[] for the RELEASES endpoint, so the original regex never matched and always exited with "Could not detect version from RELEASES."

Unblock-File .\Windows11Pro-Deploy-ClaudeDesktop.ps1
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\Windows11Pro-Deploy-ClaudeDesktop.ps1 -MigrateData

If auto-detection still fails, read the version manually and pass it:

$r = Invoke-WebRequest -UseBasicParsing "https://downloads.claude.ai/releases/win32/x64/RELEASES"
[System.Text.Encoding]::UTF8.GetString($r.Content)

Two notes for anyone using it. It registers the claude:// handler — without that, OAuth sign-in loops on the sign-in screen (email + verification code works either way). And if Claude Code sessions don't appear in the Code sidebar afterward, they aren't lost; claude --resume from a terminal in the project directory finds them. See #67118.

Unofficial and unsupported. Read it before you run it.

---

For whoever picks this up: the reduced install is demonstrably viable — #49540 reports Claude installing successfully every time with only Cowork failing. The bug is that when AddPackage fails there is no reachable path to it. Making that fallback actually clickable would unblock a lot of people well ahead of a root-cause fix.

Related: #48437, #49540, #49655, #53504, #56949, #60319, #62116, #76510, #81747

Thanks. Will try that

On Thu, Sep 3, 2026, 9:31 AM DROutsourcing-Jason @.***>
wrote:

DROutsourcing-Jason left a comment (anthropics/claude-code#49917) <https://github.com/anthropics/claude-code/issues/49917#issuecomment-5528833345> My boss had this issue, I found a workaround: Environment: Windows 11 Pro. A previously working Claude Desktop install stopped working; all reinstall attempts then failed. Failure: Installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6 Elevated process exited with code 1 Elevation failed: elevated installer exited with code 1 ERROR dialog (with log path): Administrator access is required to install Claude with full features. You can try again or install without Cowork. The log says the "install without Cowork" option was offered. It never rendered. The only dialog shown had a single OK button, so there was no way to take that path. Tried, all failed: - Installer run normally and elevated - Get-AppxPackage Claude | Remove-AppxPackage, then clean re-run - Sideloading keys (AllowAllTrustedApps, AllowDevelopmentWithoutDevLicense) + reboot - Confirmed default app install location is C: - Freshly downloaded installer after all of the above ------------------------------ Workaround: deploy the non-MSIX build Skipping MSIX entirely gets you the exact configuration the fallback dialog was offering. Claude Desktop runs normally; no Cowork, no auto-update. Windows11Pro-Deploy-ClaudeDesktop.txt <https://github.com/user-attachments/files/31799617/Windows11Pro-Deploy-ClaudeDesktop.txt> Script attached. Attached as .txt since GitHub won't accept .ps1. Rename to Windows11Pro-Deploy-ClaudeDesktop.ps1 before running. It's a fork of Cheng's Fix-ClaudeDesktop.ps1 (wuweiai.io, MIT) with the version detection fixed — PowerShell 5.1 returns .Content as a byte[] for the RELEASES endpoint, so the original regex never matched and always exited with "Could not detect version from RELEASES." Unblock-File .\Windows11Pro-Deploy-ClaudeDesktop.ps1Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass .\Windows11Pro-Deploy-ClaudeDesktop.ps1 -MigrateData If auto-detection still fails, read the version manually and pass it: $r = Invoke-WebRequest -UseBasicParsing "https://downloads.claude.ai/releases/win32/x64/RELEASES" [System.Text.Encoding]::UTF8.GetString($r.Content) Two notes for anyone using it. It registers the claude:// handler — without that, OAuth sign-in loops on the sign-in screen (email + verification code works either way). And if Claude Code sessions don't appear in the Code sidebar afterward, they aren't lost; claude --resume from a terminal in the project directory finds them. See #67118 <https://github.com/anthropics/claude-code/issues/67118>. Unofficial and unsupported. Read it before you run it. ------------------------------ For whoever picks this up: the reduced install is demonstrably viable — #49540 <https://github.com/anthropics/claude-code/issues/49540> reports Claude installing successfully every time with only Cowork failing. The bug is that when AddPackage fails there is no reachable path to it. Making that fallback actually clickable would unblock a lot of people well ahead of a root-cause fix. Related: #48437 <https://github.com/anthropics/claude-code/issues/48437>, #49540 <https://github.com/anthropics/claude-code/issues/49540>, #49655 <https://github.com/anthropics/claude-code/issues/49655>, #53504 <https://github.com/anthropics/claude-code/issues/53504>, #56949 <https://github.com/anthropics/claude-code/issues/56949>, #60319 <https://github.com/anthropics/claude-code/issues/60319>, #62116 <https://github.com/anthropics/claude-code/issues/62116>, #76510 <https://github.com/anthropics/claude-code/issues/76510>, #81747 <https://github.com/anthropics/claude-code/issues/81747> — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/49917?email_source=notifications&email_token=CMFFNGP3HQL3IZVMJCMIX5L5NGME7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJSHA4DGMZTGQ22M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5528833345>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CMFFNGK72QRKMKIXGWJO6FD5NGME7AVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TIMRYGI3TAOJQGI4KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CMFFNGLBI55GM2XN2LYJHND5NGME7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJSHA4DGMZTGQ22M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/CMFFNGN6PAXXTG23SEHYY6D5NGME7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJSHA4DGMZTGQ22M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: @.***>

I had the same 0x80073CF6 family of failure, but found an additional
root cause that may explain why some machines remain broken even
after cleaning the stale package/service state.

On Windows 10 Pro, AppXDeploymentServer showed:

Event 5282
0x800700B7

Event 306/316
windows.stateExtension registration failure

Event 331
0x800703FA during rollback

The decisive finding was a damaged ACL on:

C:\ProgramData\Packages

SYSTEM / TrustedInstaller / Administrators were missing and the
folder had effectively been made user-owned.

I also found stale Claude StateRepository PackageFamily and
PackageFamilyUser records.

After backing everything up, repairing the parent Packages ACL and
removing only Claude-specific stale state, Claude installed normally
and CoworkVMService started successfully.

So if the cleanup procedure in this issue doesn't work, I'd strongly
recommend checking Event 5282 and the ACL of C:\ProgramData\Packages
before doing more registry/database cleanup.

@ARHAEEM After an hour of troubleshooting this method worked the first time. Thank you so much for the guide!

Same 0x80073CF6 on Windows 11, and I have a recovery path that worked — plus a follow-on bug after the clean install.

Environment

Windows 11 · i7-13620H · 16 GB · CPU virtualisation enabled
Was on Claude Desktop 1.32352.x since 18 Aug 2026 · now on 1.49585.0.0

Timeline

• 09 Sep 2026: Cowork device shell worked normally.
• 10 Sep 2026, first call of the day: device_bash started failing with sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared. File tools (list / stage / commit) kept working throughout.
• Uninstall + reinstall → AddPackage failed with HRESULT 0x80073CF6.

Root cause of the install failure

Get-AppxPackage -AllUsers *claude* returned nothing, but C:\Program Files\WindowsApps still held two orphaned package directories:

Claude_1.32352.0.0_x64__pzs8sxrjxfjjc  (18/08/2026)
Claude_1.32352.1.0_x64__pzs8sxrjxfjjc  (18/08/2026)

Remove-AppxPackage -Package <fullname> -AllUsers silently did nothing on both.

AppXDeploymentServer/Operational at the moment of failure:

• 613: Add on Claude_1.49585.0.0 — "Failed to reach state RegistrationChanged" (staging 5765 ms OK, registration 6547 ms then fail)
• 9660: error 0xD0074005: cannot notify BrokerInfrastructure of package Claude_1.49585.0.0 and state change 2
• 404: 0x80073CF6, internal error 0x80073D05

BrokerInfrastructure, StateRepository, AppXSvc, ClipSVC, TimeBrokerSvc: all Running, normal StartType.

Recovery that worked

(The issue says none exists — this one did.) Elevated PowerShell:

takeown /f "<each orphaned dir>" /r /d S
icacls  "<each orphaned dir>" /grant *S-1-5-32-544:F /t
Remove-Item -LiteralPath "<each orphaned dir>" -Recurse -Force

then reboot, then run the installer. 1.49585 installed cleanly.

Also: a leftover "Claude Setup" process from the failed run keeps files open — worth killing before retrying.

The follow-on bug, still open

After the clean install the app runs, but the Cowork device shell still cannot see connected folders. The message changed from "The isolated Linux environment on this device failed to start" to the Plan9 one above, so the VM now boots and the connected folder is never mounted into it.

Ruled out: reconnecting the folder (5+ times), full machine reboot, quitting Docker Desktop (hypervisor contention), restarting the app so the VM boots with the folder already connected, and a brand-new Cowork session (fails identically).

This worked on 1.32352 the day before and does not on 1.49585.

Log: %TEMP%\ClaudeSetup.log (attached)

Update: Anthropic support confirms the shell failure is a separate, known active
incident — a Windows update published 8 Sep 2026 stops the Cowork workspace from
accessing the device drive. Microsoft has a patch pending release. So the
version numbers above are a red herring: the installer bug and the shell failure
are two different problems that happened to land the same week.

The recovery procedure below is still the point of this comment: it unblocks the
0x80073CF6 install failure, which this issue reports as having no known fix.
ClaudeSetup.log

One addition to my comment above, from the setup log: the mechanism that creates the orphaned WindowsApps directories in the first place.

From an earlier run that reported success (05 Sep):

Removing: Claude_1.46388.4.0_x64__pzs8sxrjxfjjc
Windows rejected data-preserving removal for Claude_1.46388.4.0_x64__pzs8sxrjxfjjc
  (0x80073CFA, requires developer mode); relying on in-place update

Windows refuses the data-preserving removal, setup logs the refusal, proceeds to AddPackage anyway, and ends with === Claude Setup completed successfully ===. The old package directory stays behind in C:\Program Files\WindowsApps. Two had accumulated that way on this machine before anything visibly broke:

Claude_1.32352.0.0_x64__pzs8sxrjxfjjc  (18/08/2026)
Claude_1.32352.1.0_x64__pzs8sxrjxfjjc  (18/08/2026)

Neither was enumerable — Get-AppxPackage -AllUsers *claude* returned nothing and Remove-AppxPackage -Package <fullname> -AllUsers silently did nothing — but the family name is still claimed on disk, and every later AddPackage fails with 0x80073CF6.

Same "remove failed → add anyway → report success" pattern that ARHAEEM and NamZ976 describe, but reached through a different call: a data-preserving removal refused with 0x80073CFA because it requires developer mode. If the installer is changed to abort when removal fails, this path needs covering too — here the installer treats the refusal as expected ("relying on in-place update") rather than as a failure.

Same signature on Windows 11 Home 25H2 (build 26200.9445) — two wedged WindowsApps folders left by a background update

Two data points that may help narrow the trigger:

1. Edition is not a factor. This reproduced on Windows 11 Home, whereas #49917, #56949, #59471 and #49104 are all on Professional.

1. Build 26200 may be. #59471 (10.0.26200) and #58174 (10.0.26200) both hit the same AddPackage failure, and #58174 already raised the possibility that MSIX deployment behaves differently on this branch. My system is 25H2, build 26200.9445. That makes three independent reports on 26200 across two different editions — worth checking whether the failure rate is concentrated on this branch.

Environment

OS: Windows 11 Home, version 25H2, build 26200.9445, x64
Developer Mode: enabled
Previous install: worked normally until 2026-09-03
Installer log (excerpt)

Standard install (not split-account), using AddPackage
Installing via AddPackage (current-user)...
WARNING: AddPackage failed over an existing install (AddPackage failed with HRESULT 0x80073CF6);
removing wedged package(s) and retrying — app data will not be preserved
WARNING: DeprovisionPackageForAllUsers failed for Claude_pzs8sxrjxfjjc (HRESULT 0x80070490)
Removing wedged package: Claude_1.44121.4.0_x64__pzs8sxrjxfjjc
WARNING: Windows rejected PreserveApplicationData for Claude_1.44121.4.0_x64__pzs8sxrjxfjjc
(0x80073CFA, requires developer mode); retrying removal without it
MSIX installation failed: AddPackage failed even after removing wedged packages:
AddPackage failed with HRESULT 0x80073CF6
ERROR dialog: Administrator access is required to install Claude with full features.

Two stale folders remain in WindowsApps

03.09.2026 05:09 Claude_1.44121.2.0_x64__pzs8sxrjxfjjc
03.09.2026 05:19 Claude_1.44121.4.0_x64__pzs8sxrjxfjjc

Both were created ten minutes apart, at 05:09 and 05:19, with no user present. This points to the background update flow: the new version was staged before the previous one was cleaned up, and both ended up wedged. That matches the trigger described in #53504.

What I verified

Get-AppxPackage -AllUsers Claude → returns nothing
Get-AppxProvisionedPackage -Online → no Claude entry
Get-AppxLog → empty, so the deployment subsystem has no record of the failure at all
HKCU:\...\AppModel\Repository\Packages\ → no Claude_* key (screenshot below)

So no standard tool reports the package as present, yet the family name Claude_pzs8sxrjxfjjc is still claimed and AddPackage keeps failing.

Impact
The user-facing dialog says administrator access is required, which is misleading — the installer was already running elevated, and the actual failure is MSIX registration. Following that message leads users to retry elevation instead of looking for the stale packages, which is why several of the reports above start on the wrong track.

Happy to attach the full ClaudeSetup.log or run any diagnostic commands that would help.

<img width="1483" height="812" alt="Image" src="https://github.com/user-attachments/assets/0370408b-c325-4141-93a9-f3e9beeff442" />

Helped me:
https://josuedikoma.pro/en/blog/claude-desktop-erreur-0x80073cf6/