Windows: every Claude Desktop MSIX auto-update fails to register (0x80073CF6 / windows.stateExtension Access Denied) and forces a reboot when 'New apps will save to' is a secondary drive

Summary

Claude Desktop for Windows (MSIX) fails to register every single auto-update with 0x80073CF6 (inner 0x80070005 Access Denied) on machines where Windows Settings → System → Storage → "Where new content is saved" → "New apps will save to" points at a secondary drive. Relaunching does not help — the only thing that unblocks the update is a full reboot, and even then the first post-reboot registration attempt fails once more before succeeding.

Given the current release cadence this is hugely annoying: today alone there were two releases (1.21459.1 and 1.21459.3), each of which forced a reboot of the machine — two reboots in one morning just to keep using the app. Every Claude Desktop release currently costs affected users a reboot.

Environment

• Windows 11 Pro 10.0.26100
• Claude Desktop MSIX, package family Claude_pzs8sxrjxfjjc, binary installed on C:\Program Files\WindowsApps (Settings → Apps confirms "currently installed on: Local Disk (C:)")
• "Where new content is saved" → "New apps will save to" = D: — because of this, Windows placed the package's per-user state on the secondary drive: %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\{AC,AppData,LocalCache,LocalState,RoamingState,Settings,TempState} are all junctions to D:\WpSystem\<SID>\...
• AppX default volume: D:\WindowsApps
• CoworkVMService (the packaged service declared in the app manifest) running, StartType Automatic

Timeline (2026-07-16, from Microsoft-Windows-AppXDeploymentServer/Operational)

Upgrade 1: 1.21459.0 → 1.21459.1

| Time | Event |
|---|---|
| 03:35:58 | 1.21459.1 staged (Deployment Add, target volume C:) |
| 10:02 – 10:16 | 7 registration attempts fail with 0x80073CF6 (user repeatedly relaunching the app) |
| 10:19:52 | Reboot #1 |
| 10:21:56 | Post-reboot registration attempt fails again |
| 10:26:49 | Registration succeeds; app finally launches on 1.21459.1 |

Upgrade 2: 1.21459.1 → 1.21459.3 (staged 10:27:57, ~1 minute after the app came back up)

| Time | Event |
|---|---|
| 10:54, 10:55, 11:04 | Registration attempts fail with the identical signature |
| 11:06:57 | Reboot #2 |
| 11:07:57 | Post-reboot registration attempt fails again |
| 11:14:47 | Registration succeeds; app launches on 1.21459.3 |

Failure signature (identical on every attempt, and reproduced for at least three consecutive releases since 1.21459.0)

5233 Warning: State DEH failed to load existing application data settings store. Error Code: 0x80070005
5250 Warning: Verification of the application data synchronization lock failed with error code: 0x80070005
306  Error:   error 0x80070005: ... failed to register the windows.stateExtension extension due to the following error: Access is denied.
5258 Warning: error 0x80070005: Windows failed to unregister the state lock for the Claude_pzs8sxrjxfjjc package
300  Error:   error 0x80073CF6: Cannot register the Claude_pzs8sxrjxfjjc package ... Package could not be registered.
649  Info:    Trying to repair ACLs for \\?\C:\Program Files\WindowsApps\Claude_1.21459.3.0_x64__pzs8sxrjxfjjc
649  Info:    ACLs repaired successfully ... Register next time should succeed.
404  Error:   AppX Deployment operation failed ... 0x80073CF6 ... internal error 0x80070005

On one occasion the failed rollback additionally corrupted the repository entry for the previous version (751 Warning: Windows failed to undo changes ... The package needs to be reinstalled, 323 Error: 0x80070490 Element not found for Claude_1.21459.1.0).

Analysis

Two factors appear to combine:

1. Package state redirected to the secondary drive. The windows.stateExtension registration must ACL/verify the per-user state, which lives under D:\WpSystem\... via junctions. It fails with Access Denied. Windows' automatic ACL repair (event 649) only repairs the C: package folder, not the redirected state on D:, so back-to-back retries in the same session keep failing.
2. Something holds the application data settings store open across update attempts (event 5233: the settings store cannot even be loaded). The app's own processes are terminated by the deployment engine (TerminateApplications successful), but the packaged CoworkVMService survives app shutdown, which would keep the state hive loaded — consistent with #76357 and #49655. Only a reboot releases it; after reboot, one more fail + ACL-repair cycle finally lets registration through.

Related issues (none match this signature)

• #76357 — same user-facing symptom (unlaunchable after every update until reboot), different mechanism (0x80070020 file locks from orphaned processes)
• #49655 — 0x80073CF6 caused by CoworkVMService holding registry hive locks
• #35281 — same root Windows setting ("new apps save to" ≠ C: → WpSystem), different failure (CoworkVMService won't start); closed
• #60075 — same "extension registration Access Denied during update" pattern, but for windows.firewall

Suggested fixes

• Updater should stop/restart CoworkVMService around package registration so the state store is released without a reboot.
• Handle (or pre-repair ACLs for) per-user package state redirected to WpSystem on a non-system volume — or detect this configuration and warn/migrate, since "New apps will save to: D:" is a plain Settings toggle many users with small C: drives have enabled.
• Failing that, retry registration automatically after the OS's own ACL repair instead of leaving the app unlaunchable with no feedback.

Workaround for affected users

None found short of rebooting (twice today). Relaunching the app repeatedly does not help — 7 attempts over 14 minutes all failed identically. Moving the app itself back to C: via Settings → Apps does not apply (it already reports installed on C:); the redirected state is the problem.