[BUG] Claude Desktop (Windows MSIX): package's own LocalSystem service CoworkVMService blocks every update with 0x80073D02 — closing the app cannot fix it

Summary

On Windows, Claude Desktop ships as an MSIX package (Claude_pzs8sxrjxfjjc). Updates stage fine but registration fails with 0x80073D02 — "Unable to install because the following apps need to be closed", surfaced to the user as a generic "another program is currently using this file" error. The app then silently stays on the old version, sometimes for days and across multiple releases.

#63397 reports the same HRESULT and attributes it to claude.exe respawning. That is only part of it. The blocker that survives every action a user can take is a Windows service declared inside the package itself — one that the UI never mentions and that the user cannot reconfigure, even as an administrator.

The service

From AppxManifest.xml of Claude_1.25927.0.0_x64__pzs8sxrjxfjjc:

<desktop6:Extension Category="windows.service"
    Executable="app\resources\cowork-svc.exe"
    EntryPoint="Windows.FullTrustApplication">
  <desktop6:Service Name="CoworkVMService" StartupType="auto" StartAccount="localSystem">
    <desktop6:TriggerEvents>
      <desktop6:TriggerCustom Action="ActionStart" Subtype="1f81d131-3e60-4c76-9860-37334e4ffce3">
        <desktop6:StringData><desktop6:DataItem Value="\pipe\cowork-vm-service" /></desktop6:StringData>
      </desktop6:TriggerCustom>
    </desktop6:TriggerEvents>
  </desktop6:Service>
</desktop6:Extension>

sc qc CoworkVMService:

TYPE               : 210  WIN32_PACKAGED_PROCESS
START_TYPE         : 2   AUTO_START
BINARY_PATH_NAME   : "C:\Program Files\WindowsApps\Claude_<ver>_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
DISPLAY_NAME       : Claude
SERVICE_START_NAME : LocalSystem

It is auto-start, runs as LocalSystem, and its image lives inside the versioned package folder. So it runs from boot whether or not Claude Desktop has been opened in that session, and it keeps WindowsApps\Claude_<oldver>\ mapped. Registration has to move that folder aside, so it fails.

Why this matters more than the claude.exe race — the user can neither see it nor fix it:

• Its DisplayName is just Claude, so in Task Manager it appears under Services, unassociated with the app.
• Quitting Claude Desktop does not stop it. This is exactly why "close Claude and retry" advice fails and the bug keeps getting re-reported.
• It cannot be reconfigured, even elevated. sc config CoworkVMService start= demand returns error 5 (access denied) from an elevated prompt, because the packaged-service DACL grants no SERVICE_CHANGE_CONFIG to Administrators:

``
> sc sdshow CoworkVMService
D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-<service-sid>)
``

Authenticated Users get query/start/stop only. There is no admin ACE at all, so there is no user-side mitigation short of stopping the service by hand before every update.

Observed timeline

Microsoft-Windows-AppXDeploymentServer/Operational:

08-03 14:20  id=658  Marking package {Claude_1.24012.11.0} for deferred registration
                     because {Claude_1.24012.9.0} is still running.
08-03 14:20  id=400  Deployment Add ... Claude_1.24012.11.0 ... finished successfully
08-04 17:10  id=658  Marking package {Claude_1.25927.0.0} for deferred registration
                     because {Claude_1.24012.9.0} is still running.
08-04 17:10  id=400  Deployment Add ... Claude_1.25927.0.0 ... finished successfully
08-05 00:33  id=419  error 0x80073D02: Unable to install because the following apps
                     need to be closed Claude_1.24012.9.0_x64__pzs8sxrjxfjjc.
08-05 22:58  id=419  (same)
08-06 03:34  id=400  Deployment Register ... Claude_1.25927.0.0 ... finished successfully

Three days, with 1.24012.11 skipped entirely and the app reporting appVersion: '1.24012.9' throughout. The user-facing update prompt clears each time, so there is no indication anything failed.

Second, independent defect: stale Chrome native messaging host

Claude copies chrome-native-host.exe into its package container, but Chrome launches it, so its parent is chrome.exe and it outlives Claude Desktop. Claude then cannot refresh that binary on next start:

[error] [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked,
copyfile 'C:\Program Files\WindowsApps\Claude_<ver>\app\resources\chrome-native-host.exe'
      -> 'C:\Users\<user>\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe'

Result: the browser extension keeps running an older host against a newer app. On this machine the container copy was three weeks older than the package copy (different SHA-256) and had been live for 10 hours with Claude Desktop closed. [info] Native host sync complete is logged immediately after the failure, so the error is swallowed.

This one does not block registration — it was running during the successful 08-06 03:34 registration — but it is a real and silent version-skew bug.

Suggested fixes

1. Stop CoworkVMService before attempting registration, or register with -ForceTargetApplicationShutdown so the deployment engine tears the package down itself rather than racing a manual kill.
2. Make the service demand/trigger start only. It already declares a \pipe\cowork-vm-service start trigger, so StartupType="auto" looks unnecessary and is precisely what makes it a permanent lock holder.
3. Give it a distinguishable DisplayName (e.g. Claude Cowork VM Service) so users and support can identify it in Task Manager.
4. Surface the real deployment HRESULT in the UI instead of a generic file-in-use message, and do not clear the "update available" state when registration actually failed.
5. Retry the native-host copy after releasing the running host (or version the filename), and stop logging Native host sync complete after a failed copy.

Environment

• Windows 11, build 26200.8894, x64
• Claude Desktop 1.24012.9 → 1.25927.0.0, MSIX, SignatureKind: Developer
• Reproduced across releases 1.24012.11 and 1.25927.0

Related: #63397 — same HRESULT, diagnosed as the claude.exe respawn race only, closed as not planned.