[Windows] AppX update/relaunch fails with "another program is using this file" (0x80073d02) — CoworkVMService (cowork-svc.exe) holds package file lock

From my claude when looking into the same issue:

Confirming + adding diagnostics (Windows 11 26200, Claude 1.20186.9.0):

The culprit is the packaged Windows service CoworkVMService (DisplayName "Claude"), binary inside the package:
…\WindowsApps\Claude_1.20186.9.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe, running as LocalSystem, AUTO_START, depends on staterepository.

Ending all claude.exe processes in Task Manager does not stop this service, so the MSIX update can't replace cowork-svc.exe (in use) → file lock → reboot required.

One correction to the thread: sc qc / sc qfailure show TYPE: 210 WIN32_PACKAGED_PROCESS with no failure/recovery actions (RESET_PERIOD 0, no actions). So it isn't a "recovery: restart" setting — it's a packaged service, which Windows won't let you sc config/disable, and which the running app appears to respawn. That's why it resists being stopped.

Suggested fix: the updater must stop (and ideally the app should shut down) CoworkVMService before Add-AppxPackage, since a packaged service running from inside the package folder structurally self-blocks its own update. Also consider DelayedAutoStart/on-demand start, or terminating the service on app close / when an update is pending.

thanks

---- Replied Message ----
| From | Jack W. @.*> |
| Date | 07/14/2026 18:47 |
| To | @.*> |
| Cc | @.>@.> |
| Subject | Re: [anthropics/claude-code] [Windows] AppX update/relaunch fails with "another program is using this file" (0x80073d02) — CoworkVMService (cowork-svc.exe) holds package file lock (Issue #73694) |
jackwjensen left a comment (anthropics/claude-code#73694)

From my claude when looking into the same issue:

Confirming + adding diagnostics (Windows 11 26200, Claude 1.20186.9.0):

The culprit is the packaged Windows service CoworkVMService (DisplayName "Claude"), binary inside the package:
…\WindowsApps\Claude_1.20186.9.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe, running as LocalSystem, AUTO_START, depends on staterepository.

Ending all claude.exe processes in Task Manager does not stop this service, so the MSIX update can't replace cowork-svc.exe (in use) → file lock → reboot required.

One correction to the thread: sc qc / sc qfailure show TYPE: 210 WIN32_PACKAGED_PROCESS with no failure/recovery actions (RESET_PERIOD 0, no actions). So it isn't a "recovery: restart" setting — it's a packaged service, which Windows won't let you sc config/disable, and which the running app appears to respawn. That's why it resists being stopped.

Suggested fix: the updater must stop (and ideally the app should shut down) CoworkVMService before Add-AppxPackage, since a packaged service running from inside the package folder structurally self-blocks its own update. Also consider DelayedAutoStart/on-demand start, or terminating the service on app close / when an update is pending.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

Confirmed on Windows 10 Pro (19045), v1.24012.9 — caught the lock live: the update's Add step fails with 0x80070020 creating app\resources\cowork-svc.exe, leaving the package Modified, NeedsRemediation and the app unregistered (gone from the Start menu). Full details + a no-reboot recovery (kill package-dir processes incl. cowork-svc.exe, then Add-AppxPackage -Register the staged package) posted in #76357.

Adding corroborating event-log forensics from another machine (Windows 11 Home 26200, app 1.24012.9.0 — current as of today — bundled CLI 2.1.219). Same root cause as described here and in #81756, with one variant note: on this machine the service is still registered in the SCM (Get-Service CoworkVMService → Running, StartType Automatic) — the auto-restart variant rather than the SCM-orphan variant in #81756. Three data points that may help the fix:

**1. The service re-blocks servicing within a single Repair pass.** Settings → Repair re-downloads the MSIX and runs Add + Register. The platform force-terminated the service ~30 s before the Register step — yet by the time Register ran, something in the package was active again and the repair's Register failed (AppXDeploymentServer/Operational, 2026-07-27):

14:41:09  RegisterByPackageFullName (ForceTargetApplicationShutdown):
          "TerminateSingleService for update successful ... in package CoworkVMService, terminateService: true"
          "TerminateApplications successful"          <- running app force-killed here
14:41:26  second forced Register runs
14:41:42  user Repair, step 1: Add (re-download from downloads.claude.ai) OK, 29 s
14:42:04  user Repair, step 2: Register -> 0x80073D02
          #419  "Unable to install because the following apps need to be closed Claude_..."
          #638  "Packages were not updated because affected apps are still running: {Claude_pzs8sxrjxfjjc!Claude}"
          #9641 "Deployment aborts due to active service Claude_pzs8sxrjxfjjc!Claude"
14:42:10  app launches anyway (the attempt's ACL repair + status-flag clearing is enough)

An identical repair cycle with the same failed Register step (0x80073D02, same #638/#9641 events) ran at 14:34:49 the same day — two Repair cycles ~8 minutes apart, both failing their Register step, both followed by a successful launch anyway. So from the user's chair "Repair fixes it", but the register step never actually succeeds while the package's service/processes are alive; the fix is incidental.

2. The force-shutdown remediation is what users experience as "the app crashed". The 14:41:09 ForceTargetApplicationShutdown register terminated the live app mid-session (all windows gone). Combined with (1) this is self-sustaining: hang → remediation force-kills app → service comes back → next servicing blocked → user repairs again.

3. No crash telemetry for the app's own deaths. Both app deaths that day left no WER record, and the Crashpad directory (%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\Crashpad) contains only settings.dat — matches the "terminated externally, does not crash" observation in #81756. Historical Application-log entries on this machine: MoAppHang for claude.exe on 2026-06-14 and 2026-06-28, RADAR_PRE_LEAK_64 for claude.exe 2.1.187.0.

Minor related defect: after restart the new instance logs [Chrome Extension MCP] Failed to copy native host binary: EBUSY — the previous chrome-native-host.exe (parented by the browser, not the app) survives app restarts and holds the destination binary; the failure is only logged.

Non-elevated workaround (no reboot, no re-download): this is the same Register + force-shutdown operation the platform itself ran successfully at 14:41:09, so the deployment service does the terminating and it should not need elevation:

taskkill /f /t /im claude.exe
Add-AppxPackage -Register -DisableDevelopmentMode -ForceApplicationShutdown ((Get-AppxPackage Claude).InstallLocation + '\AppxManifest.xml')

Happy to attach the full filtered AppXDeploymentServer export if useful.

🤖 Generated with Claude Code

Another confirmed case on Windows 10 Pro (19045), package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc — with a worse failure mode than "reboot required": the failed update cycle left the package deregistered, so the app appeared to have uninstalled itself (Start-menu entry gone, service would not start). The user had to manually reinstall — twice in one morning, because the updater retried and hit the same lock.

Timeline from Microsoft-Windows-AppXDeploymentServer/Operational (2026-07-30, all within ~25 minutes):

| Time | Event |
|---|---|
| 10:00:15 | Register fails 0x80073D02 — "apps need to be closed" |
| 10:04:50 | Register succeeds (after manual reinstall) |
| 10:06:37 | Remove fails 0x80073CFA — "PreserveApplicationData flag can only be used on a package that was deployed in development mode" |
| 10:06:45 | Add of Claude-866493742.msix succeeds |
| 10:09–10:10 | Register fails 0x80073D02 twice more |
| 10:14:13 | Add of Claude-857647155.msix fails 0x80070020 — sharing violation "Creating file ...\app\resources\cowork-svc.exe failed" |
| 10:25:26 | Remove fails 0x80073CFA again |
| 10:25:33 | Add of Claude-3333753079.msix finally succeeds; cowork-svc.exe restarts same second |

Two data points beyond the original report:

1. 0x80073CFA on the remove leg: the updater's Remove call apparently passes PreserveApplicationData, which Windows rejects for non-development-mode packages. Combined with the locked cowork-svc.exe on the Add leg, a half-completed remove-then-add cycle can leave the machine with no registered package at all — not just stale files awaiting reboot. That's the "app uninstalled itself" symptom.
2. CoworkVMService was confirmed as the lock holder: Win32_Service shows it Running/Auto with PathName inside the package folder, and its cowork-svc.exe process restarted at the exact second the final Add succeeded (manifest auto-start re-registration, as described in the OP).

Same expected fix as the OP: the updater must stop CoworkVMService (and suppress its pipe-trigger/auto-start restart) before the AppX remove/add, and restart it after. Note for anyone else recovering from the "uninstalled" state: user data in %APPDATA%\Claude survives these cycles, and the downloaded installer is still in %LOCALAPPDATA%\Temp\Claude-*.msix — elevated Stop-Service CoworkVMService, quit Claude fully, then Add-AppxPackage that file.