[BUG] Windows MSIX updater repeatedly fails: CoworkVMService locks its own file (0x80070020), PreserveApplicationData removal rejected (0x80073CFA), stale-retry race (0x80070002)
Environment
- Claude Desktop: 1.24012.11.0 → 1.25927.0.0 (auto-update path)
- OS: Windows 11 Pro, Insider Dev build 29639 (also reproduced on 29634)
- Install type: MSIX (
Claude_*_x64__pzs8sxrjxfjjc), Developer Mode enabled - Related issues: #76357 (file lock on update), #25162 (0x80073CFA, closed as Not Planned)
Summary
Every significant app update degenerates into a multi-failure loop that ends with the Windows dialog "You need to go to Advanced Options for Claude and select Repair". On 2026-08-05 a single version upgrade (1.24012.11.0 → 1.25927.0.0) required three install attempts over 20 minutes, including one full uninstall + reinstall, before it succeeded. Event Viewer (Microsoft-Windows-AppXDeploymentServer/Operational) captured three distinct failure mechanisms, all reproducible on this machine across two consecutive days.
Mechanism 1 — CoworkVMService locks its own binary during install (0x80070020)
9:50:55 Id 404 AppX Deployment operation failed for package Claude_1.25927.0.0_x64__pzs8sxrjxfjjc
with error 0x80073CF9. The specific error text for this failure is:
Error 0x80070020: Failed to create file
\\?\C:\Program Files\WindowsApps\Claude_1.25927.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe0x80070020 = ERROR_SHARING_VIOLATION. The file being locked is cowork-svc.exe — the binary of CoworkVMService itself, which is installed as an auto-start Windows service and keeps running while the updater tries to replace it. This confirms the diagnosis in #76357 with a direct smoking-gun log line: even a full uninstall + fresh reinstall fails while the service is running, because the service outlives the app.
A second lock-holder in the same family: chrome-native-host.exe (the Claude-in-Chrome bridge, %APPDATA%\Roaming\Claude\ChromeNativeHost\) is spawned and kept alive by Chrome, not by the Claude app — closing Claude does not release it, and it locks the app data directory the installer also touches.
Mechanism 2 — PreserveApplicationData removal rejected (0x80073CFA), recurs on every update
9:38:39 / 9:40:10 / 9:44:53 / 9:50:54 / 9:53:54 Id 717
Windows cannot remove Claude_*_x64__pzs8sxrjxfjjc because the PreserveApplicationData flag
can only be used on a package that was deployed in development mode.Developer Mode is ON on this machine. The restriction is on how the installed package was deployed, not the system toggle: once a package has been installed via a normal Add (which is exactly what the updater's own fallback and the "Repair" flow produce), the next update's RemovePackage(PreserveApplicationData) is rejected — a self-perpetuating loop. This is the same error as #25162, which was closed as Not Planned; it is still occurring in 1.25927.
Mechanism 3 — updater retries with an already-consumed temp package (0x80070002)
9:38:49 Id 400 Deployment Add ... from: (Claude-3301875423.msix) finished successfully.
9:46:56 Id 403 error 0x80070002: Failure to get staging session for:
file:///C:/Users/<user>/AppData/Local/Temp/Claude-3301875423.msixThe msix that "cannot be opened" at 9:46:56 had already been successfully installed (and cleaned up) by the updater itself 8 minutes earlier. Nothing external deleted it — Storage Sense (low-disk trigger only; 726 GB free) and antivirus were ruled out. The updater appears to enqueue duplicate/stale install attempts (note also the duplicated 404/717 event pairs within the same second) and later retries them against a temp file it has already consumed.
Full timeline (2026-08-05, from Event Viewer)
| Time | Event |
|---|---|
| 9:35–9:36 | 2× Register (Repair) of 1.24012.11.0 succeed |
| 9:38:39 | Remove 1.24012 fails 0x80073CFA (×2, same second) |
| 9:38:49 | Add 1.25927 succeeds (Claude-3301875423.msix) |
| 9:40:10 | Remove 1.25927 fails 0x80073CFA (×2) |
| 9:40:20 | Add succeeds (Claude-3250378823.msix) |
| 9:44:53 | 0x80073CFA (×2) |
| 9:45:03 | Add succeeds (Claude-1555630770.msix) |
| 9:46:56 | 0x80070002 — stale retry of already-consumed Claude-3301875423.msix |
| 9:47:10 | User performs full Remove — succeeds |
| 9:48:38 | Fresh Add succeeds (Claude-180895928.msix) |
| 9:50:55 | 0x80070020 — cowork-svc.exe locked by running CoworkVMService |
| 9:53:54 | 0x80073CFA (×2) |
| 9:54:03 | Add finally succeeds — app functional on 1.25927.0.0 |
Workaround that reliably works (verified)
Run before any install/repair/update attempt:
Stop-Service CoworkVMService -Force
Get-Process claude, chrome-native-host -ErrorAction SilentlyContinue | Stop-Process -ForceWith locks cleared first, the install succeeds on the first attempt.
Suggested fixes
- Before applying an MSIX update, the updater should stop
CoworkVMServiceand wait for all package-owned processes to exit (includingchrome-native-host.exe, which is parented by Chrome and survives app shutdown), then restart the service afterwards. - Stop using
PreserveApplicationDataon packages that were not deployed in development mode (detect deployment type, or migrate app data explicitly) — this removes the recurring 0x80073CFA loop. - De-duplicate the update queue so stale retries don't reference temp packages that a previous successful attempt already consumed (0x80070002 noise, duplicated same-second failure events).
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
Independent reproduction on retail Windows 11 25H2 (26200.8875) — not an Insider build, so Mechanism 1 is not Insider-specific.
Environment
Claude_*_x64__pzs8sxrjxfjjc),SignatureKind: Developer, Developer Mode enabledHKLM:\SOFTWARE\Microsoft\WindowsSelfHost\Applicabilitypresent butBranchName/Ring/IsBuildFlightingEnabledall empty)Precondition confirmed
The service binary lives inside the very package folder the updater must replace, and the service outlives closing the window / quitting from the tray.
Symptom variant worth noting — no Event Log trace
On this machine the user-visible failure is a plain Win32 dialog titled with the package path, body
このファイルはほかのプログラムで使われています("This file is in use by another program"), OK button only:But
Microsoft-Windows-AppXDeploymentServer/Operational(7,283 events spanning 2026-07-29 → 08-05) contains zero failure events for Claude — no Id 404/419/717/403, no0x80070020, no0x80073CFA. Every logged Claude deployment operation succeeded:| Time (2026-08-05, JST) | Event |
|---|---|
| 07:18:38 | package folder
Claude_1.25927.0.0_x64__pzs8sxrjxfjjccreated || 07:21:15 | Id 400 — Deployment Add of 1.25927.0.0 finished successfully |
| — | user sees the "file in use" dialog; workaround used = full PC reboot |
| 09:18:07 | Id 400 — Register finished successfully (Id 613 perf summary: overall 40,954 ms) |
| 09:18:31 | Id 400 — Register again successfully (1,922 ms); Id 9650
Succesfully terminated service Claude_1.25927.0.0_x64__pzs8sxrjxfjjc in package CoworkVMService|So the staged Add succeeds, the update then sits unregistered for ~2 hours until the machine is rebooted, and the failure surfaces to the user only as that dialog. This suggests the lock is hit by the in-app updater, before/outside the AppX deployment path — which means affected users get no Event Viewer evidence at all, and the issue is likely under-reported.
Impact on ordinary users
Without knowing the service exists, the only discoverable workaround is rebooting the PC on every update — which is what this user had been doing. Closing the window and quitting from the tray don't help, because
CoworkVMServiceis an auto-start Windows service. The localized dialog text also means non-English users searching for the error string won't find this issue.Suggested fix 1 in the original report (stop
CoworkVMService, wait for all package-owned processes to exit, restart the service afterwards) would cover this variant as well.Update — recurred again on 2026-08-06 (same machine as OP, now on 1.25927.0.0 with no version change involved). Two new data points:
Mechanism 4 — profile-type determination fails during Register (0x80073D19)
Two Register operations fired within the same second; the second failed with a transient "cannot determine profile type" (inner 0x80070002). The account is a healthy local profile (
ProfileListState=0, FullProfile=1, non-domain machine — verified immediately after), so this is not a broken profile: it looks like the duplicate same-second operations racing each other, consistent with the duplicated 404/717 pairs in the original report.Stale retry queue persists across days AND reboots
The msix consumed on Aug 5 was retried again a full day later (with reboots in between). The retry queue is evidently persisted somewhere and never pruned after success. Related garbage: this episode also left a 0-byte orphan
Claude-*.msixin%TEMP%(aborted download placeholder, never consumed by any deployment event).Recovery
2× Repair (Register) + full Remove at 15:11:25, fresh Add succeeded first-try at 15:20:38. Consistent with the lock-clearing precondition in the OP workaround.
Also thanks @frgfrm-ops for the retail 25H2 reproduction — the "no Event Log trace" variant matches the impact we suspected: this family is likely heavily under-reported.
Another independent reproduction, matching @frgfrm-ops's variant exactly
(dialog-only failure, no fix without reboot).
Environment:
archivo" pointing to C:\Program Files\WindowsApps\Claude_1.26832.0.0_...
— confirming the localization/under-reporting point.
Diagnostics:
container**: \Container_Claude_1.25927.0.0_x64__pzs8sxrjxfjjc-...
launch. The old container's Job in svchost survives everything except
a reboot — consistent with the orphaned Silo/Job Object described in
#53247.
The OP's workaround (stopping the service BEFORE the update) can't help
users who hit the dialog after the update already ran — at that point
the stale container job makes the reboot unavoidable. +1 for suggested
fix 1: the updater should stop CoworkVMService and tear down the
previous version's container before applying the update.
Independent corroboration from a second machine — Windows 10 Pro stable (10.0.19045, not Insider), same package family
Claude_pzs8sxrjxfjjc, update path 1.26832.0.0 → 1.28929.0.0 on 2026-08-11. SameAppXDeploymentServer/Operationalsignatures, plus two additional data points.Mechanism 2 confirmed (0x80073CFA on every update) — and Developer Mode does not mitigate it.
AllowDevelopmentWithoutDevLicense=1was set before this cycle; the removal is still rejected, because the requirement is on the package (Get-AppxPackageshowsIsDevelopmentMode: False, as it will for any normally installed MSIX), not on the system setting. So the "enable Developer Mode" workaround circulating for this error is a dead end by design:(Fires twice per cycle here — once against the outgoing package, once against the incoming one.)
Mechanism 3 confirmed (stale retry, 0x80070002). An hour after a repair reinstall, a recovered deployment request retried against a temp
.msixthat no longer existed:Additional: the self-repair path force-kills active sessions, apparently unnecessarily. The repair reinstall ran with
ForceApplicationShutdownOptionand killed the app mid-use:Forty seconds later, the actual version upgrade on the same machine used the polite path instead and completed cleanly once the app exited on its own:
If deferred registration is good enough for the upgrade, the force-shutdown on the repair path looks avoidable.
Exposure is constant: the app logs
[updater] Using GrowthBook check_interval_ticks=1 (default 4)— hourly update checks, so any of these failure modes gets many chances per day.User-facing outcome here matched #85174: earlier the same day the app was left broken/unlaunchable mid-session and only recovered after manually re-running Claude Setup — though in our case
%APPDATA%\Claudeuser data survived. Full event excerpts available on request.