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

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Summary

On Windows 11 (Claude Desktop MSIX package Claude_*_x64__pzs8sxrjxfjjc), after an
auto-update without a reboot, or after Claude crashes and is relaunched, Windows
shows "another program is using this file" pointing at
C:\Program Files\WindowsApps\Claude_<version>\.... AppX/Store reports
StoreAgentInstallFailure 0x80073d02 (resource in use). Only a full reboot reliably clears it.

Root cause (diagnosed)

The packaged service CoworkVMService (app\resources\cowork-svc.exe, DisplayName
"Claude", WIN32_PACKAGED_PROCESS, AUTO_START, LocalSystem) keeps a handle on the
package's cowork-svc.exe, so AppX cannot replace/clean up the old-version files during
update. It is declared auto-start in AppxManifest.xml and also has a service trigger on
\pipe\cowork-vm-service, so killing it alone doesn't help — it restarts via the manifest
auto-start + pipe trigger + AppX re-registration. Restart Manager attributes the lock to
cowork-svc.exe.

Repro

1. Be on version N with CoworkVMService running.
2. Let Claude auto-update to N+1 (or crash + relaunch) without rebooting.
3. Error appears; old-version files under WindowsApps can't be removed until reboot.

Observed across versions 1.17377.1.0 → 1.18286.0.0.

Expected

The updater should stop CoworkVMService (and its child processes) before applying the
AppX update, then restart it afterward — so no reboot is needed.

Workaround

Manually (elevated) sc stop CoworkVMService + taskkill /IM claude.exe /F +
taskkill /IM cowork-svc.exe /F before updating/relaunching releases the lock without a reboot.

Environment: Windows 11 Pro. Happy to attach C:\ProgramData\Claude\Logs\cowork-service.log
and AppXDeploymentServer event logs.

What Should Happen?

The Claude Desktop updater should stop the packaged service "CoworkVMService"
(cowork-svc.exe) and its child processes BEFORE applying the MSIX/AppX update,
then restart it afterward. Updating (or relaunching after a crash) should complete
without the "another program is using this file" error (AppX 0x80073d02) and
WITHOUT requiring a full Windows reboot.

Error Messages/Logs

Steps to Reproduce

Environment: Windows 11 Pro. Claude Desktop MSIX package
"Claude__x64__pzs8sxrjxfjjc" (observed 1.17377.1.0 and 1.18286.0.0),
which bundles Claude Code.

1. Have Claude Desktop installed and running. Confirm the packaged service is up:
   sc.exe queryex CoworkVMService -> STATE: RUNNING (cowork-svc.exe)
   sc.exe qc CoworkVMService -> START_TYPE: AUTO_START, LocalSystem,
   BINARY: ...\app\resources\cowork-svc.exe
   sc.exe qtriggerinfo CoworkVMService -> trigger on \pipe\cowork-vm-service
2. Let Claude auto-update to a newer version (or force-crash Claude and relaunch)
   WITHOUT rebooting Windows.
3. AppX tries to replace / clean up files under
   C:\Program Files\WindowsApps\Claude_..., but cowork-svc.exe still
   holds a handle on ...\app\resources\cowork-svc.exe.
4. Result: dialog "another program is using this file" (Chinese UI: 另一程序正在使用此文件),
   and Store logs StoreAgentInstallFailure with 0x80073d02 (ERROR_INSTALL_RESOLVE_HCNS...
   / resource in use). Old-version files cannot be removed.
5. Killing cowork-svc.exe alone does NOT fix it — the service restarts via manifest
   auto-start + the \pipe\cowork-vm-service trigger + AppX re-registration. Only a full
   Windows reboot reliably releases the lock.

Workaround that avoids the reboot (elevated):
taskkill /IM claude.exe /F
sc.exe stop CoworkVMService
taskkill /IM cowork-svc.exe /F
-> then update / relaunch works with no reboot.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

claude --version = 2.1.198 (Claude Code) desktop version= 1.18286.0.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Root cause: the packaged Windows service CoworkVMService (host controller for Claude's
Cowork/HCS-backed VM) holds a file handle on the MSIX package's cowork-svc.exe, blocking
AppX from replacing/cleaning up package files during update. Restart Manager attributes
the lock to cowork-svc.exe.

Relevant evidence:

• AppxManifest.xml declares the service: Category="windows.service",
  Executable="app\resources\cowork-svc.exe", Name="CoworkVMService",
  StartupType="auto", StartAccount="localSystem",
  trigger DataItem Value="\pipe\cowork-vm-service".
• System log / Service Control Manager: 7045 (service installed, auto-start, LocalSystem),
  7040 (start type changed), 7034 (terminated unexpectedly).
• AppXDeploymentServer/Operational: RegisterByPackageFullName + "TerminateSingleService
  for update ... CoworkVMService"; WER StoreAgentInstallFailure1 with 0x80073d02.
• Service log: C:\ProgramData\Claude\Logs\cowork-service.log
  ("Starting CoworkVMService as Windows service", "Listening on \.\pipe\cowork-vm-service").

Happy to attach cowork-service.log and the AppXDeploymentServer event export.
Suggested fix: have the auto-updater (or an MSIX update task) stop CoworkVMService and
terminate cowork-svc.exe/claude.exe before the package swap, then restart the service.