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