[BUG] Windows/MSIX: auto-update never stops the old package — CoworkVMService orphans, locks WindowsApps, app cannot relaunch (Event 658/7034 evidence)

Confirming #83968 with a live before/after capture (Win11 zh-TW)

Reproduced just now on the same failure mode. Captured Event Log before clicking Relaunch and again at the moment of the dialog.

Environment

• OS: Windows 11, build 10.0.26200, locale zh-TW
• Install: Claude Desktop MSIX (Claude_pzs8sxrjxfjjc)
• Before: Claude_1.24012.11.0
• After (package registered, app cannot launch): Claude_1.25927.0.0

Timeline (local time, UTC+8, 2026-08-05)

| Time | Signal |
|---|---|
| 16:27:20 | AppXDeploymentServer Event 658: Marking package {Claude_1.25927.0.0_…} for deferred registration because {Claude_1.24012.11.0_…} is still running. |
| 16:59:24 | User clicked in-app Relaunch / Update |
| 16:59:24 | Windows dialog: “Another program is currently using this file.” (title bar path …\WindowsApps\Claude_1.25927.0.0_…) |
| 16:59:24 | AppModel-Runtime Event 215: 0x80070020: Cannot create the Desktop AppX container … converting the job |
| 16:59:24 | AppModel-Runtime Event 208: 0x80070020: Cannot create the process … [LaunchProcess] |
| 16:59:24 | cowork-service.log: service stop → immediate restart from new path …\Claude_1.25927.0.0_…\cowork-svc.exe, plus recurring Warning: failed to open service for recovery config: Access is denied. |

After-fail state (no reboot yet)

• Get-AppxPackage reports 1.25927.0.0 / Status Ok
• Helium hive still locked: exclusive open of %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat → sharing violation
• CoworkVMService RUNNING; chrome-native-host.exe also present
• UI claude.exe not running (activation fails)

Recovery attempt without reboot (failed)

Tried the thread workaround: Stop-Service CoworkVMService, kill package-related processes / chrome-native-host, Add-AppxPackage -Register, Start-Service, relaunch.

Result: still fails. Fresh Event 215/208 0x80070020 at 17:02:54 (FinishPackageActivation). Matches the “wedged AppX container / kernel hive lock — reboot only” path described in #42776.

Happy to provide ProcMon / full .evtx exports privately if useful. This is an independent confirmation of the Event 658 → 215/208 sequence on a second machine.

Correction to the root-cause analysis in the opening post

Two independent reports since I filed this have moved the diagnosis forward, and one of them contradicts part of what I wrote. Consolidating here so maintainers don't have to reconstruct it from three threads.

What I got wrong

I attributed the file lock to cowork-svc.exe holding handles inside the package directory. That is not the mechanism. Credit to @gannonlawlor, who established this in https://github.com/anthropics/claude-code/issues/42776#issuecomment-5193866362 with a test I hadn't thought to run: with zero Claude processes alive (verified via Win32_Process), HKLM\SYSTEM\CurrentControlSet\Control\hivelist still contained mounted container-silo hives pointing at the package's Helium state.

That report also rules the service out directly — stopping CoworkVMService and holding it dead in a kill loop did not allow activation to succeed. The service is a bystander. So is chrome-native-host.exe.

The actual failure is at the Desktop Bridge container layer: when the app's AppX container is torn down abnormally, its registry hives stay mounted. The next activation collides with those mounts and fails with 0x80070020 (ERROR_SHARING_VIOLATION), surfacing as AppModel-Runtime Events 215 + 208 and the "Another program is currently using this file" dialog. That is also why elevated admin can't clear it — NtUnloadKey2 returns 0xC0000022 unless run as SYSTEM.

What still holds

The Event 658 ordering bug stands, and has now been reproduced on three machines including a second locale (@stantheman0128, Win11 26200 zh-TW, in https://github.com/anthropics/claude-code/issues/83968#issuecomment-5189808528):

Marking package {Claude_<new>_x64__pzs8sxrjxfjjc} for deferred registration
because {Claude_<old>_x64__pzs8sxrjxfjjc} is still running.

Best current reading of the chain — 658 is the trigger, the hive leak is the mechanism that makes it unrecoverable:

update fires while old package is still running        → Event 658, deferred registration
  → old container torn down abnormally mid-swap
    → \REGISTRY\WC\Silo* hives left mounted
      → next activation collides                       → 0x80070020
        → Events 215 + 208, "file in use" dialog
          → dead until reboot (or SYSTEM-level hive unload)

The service-level findings in the opening post (ERROR_CONTROL: IGNORE, empty qfailure, failed to open service for recovery config: Access is denied on every start, HcsShutdownComputeSystem → 0x80070032 so every VM stop is a hard kill) are still real bugs and still worth fixing — but they explain why the failure is silent, not why it happens.

Retracting the workaround

The Stop-Service + kill + Add-AppxPackage -Register sequence I posted does not work — independently confirmed failing by both reporters above, with fresh 215/208 events after the attempt. Please disregard it. The only non-reboot recovery reported working is NtUnloadKey2(..., REG_FORCE_UNLOAD) on the stale \REGISTRY\WC\Silo* hives as SYSTEM with SeRestore/SeBackup.

Diagnostic step, and a healthy-state baseline

For anyone triaging, this lists the mounted silo hives belonging to the Claude package (read-only, no elevation needed):

$k = Get-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\hivelist'
$k.GetValueNames() |
  Where-Object { $k.GetValue($_) -like '*pzs8sxrjxfjjc*' } |
  ForEach-Object { [PSCustomObject]@{ Hive = $_; Target = $k.GetValue($_) } } |
  Format-List

Match on the publisher ID pzs8sxrjxfjjc alone, not on Claude_pzs8sxrjxfjjc — the version-pinned paths below read Claude_<version>_x64__pzs8sxrjxfjjc, so the narrower filter silently drops exactly the entries of interest.

Run on my machine while the app is running normally (1.25927.0.0, healthy — so this is a baseline, not a fault state), it returns eight entries under four silo GUIDs. Five are family-scoped:

\REGISTRY\WC\Silo213c4dda-…software      -> …\ProgramData\Packages\Claude_pzs8sxrjxfjjc\<SID>\SystemAppData\Helium\Cache\c2a806bfd448d00e.dat
\REGISTRY\WC\Silo213c4dda-…user_sid      -> …\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat
\REGISTRY\WC\Silo213c4dda-…user_classes  -> …\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\UserClasses.dat
\REGISTRY\WC\Silo213c4dda-…com           -> …\ProgramData\Packages\Claude_pzs8sxrjxfjjc\<SID>\SystemAppData\Helium\Cache\c2a806bfd448d00e.dat
\REGISTRY\WC\Silo8e191471-…com           -> …\ProgramData\Packages\Claude_pzs8sxrjxfjjc\<SID>\SystemAppData\Helium\Cache\c2a806bfd448d00e_COM15.dat

and three are on a version-pinned path:

\REGISTRY\WC\Silo82ceabc8-…software      -> …\ProgramData\Microsoft\Windows\WindowsApps\Claude_1.25927.0.0_x64__pzs8sxrjxfjjc\Cache\c2a806bfd448d00e.dat
\REGISTRY\WC\Silo82ceabc8-…com           -> (same .dat)
\REGISTRY\WC\Silofc9d833b-…com           -> …\Claude_1.25927.0.0_x64__pzs8sxrjxfjjc\Cache\c2a806bfd448d00e_COM15.dat

One observation I'd flag rather than claim: that second set is keyed to a path containing Claude_1.25927.0.0, the exact version string. The family-scoped hives survive an update unchanged; these version-pinned ones point at a directory that ceases to be the registered version the moment an update lands. If they aren't unmounted as part of the swap, they become mounts referencing a superseded package path — which is precisely the collision shape being reported. I'm not asserting this is the leak; I'm flagging it as worth checking against a machine that is actually wedged, since I only have a healthy sample.

For comparison on the same machine, other MSIX apps (WhatsApp, Windows Terminal, WidgetsPlatformRuntime, Client.WebExperience) each show a single silo GUID family on package-family paths only. Intel Arc Software is the one other app showing the version-pinned WindowsApps\<name>_<version>\Cache shape.

Updated fix suggestions

Superseding items 1–6 in the opening post, in priority order:

1. Don't start the package swap while the old package is running. Event 658 is Windows telling you this outright, on three machines.
2. Ensure the container is torn down cleanly on quit/relaunch, so its hives unmount. If the current teardown kills the process before the container is released, that's the bug.
3. Detect and self-heal on startup. The signature is unambiguous: activation failing 0x80070020 plus \REGISTRY\WC\Silo* entries referencing your own package family. Surface a real error instead of silently doing nothing — right now the user sees a dead icon and nothing else.
4. Fix the silent-failure enablers regardless: ERROR_CONTROL: IGNORE, the runtime SERVICE_FAILURE_ACTIONS call that always fails under MSIX (declare it in the manifest instead), and the guest ACPI shutdown path so HcsShutdownComputeSystem stops returning ERROR_NOT_SUPPORTED.
5. Offer a supported way to disable the Cowork VM service (#57371) — even though it's not the cause here, it's still unstoppable by design under MSIX.

Three machines, two locales, two independent reporters, and a documented non-reboot recovery. @gannonlawlor's write-up in #42776 is the most complete account of the mechanism and is worth reading in full.

Same failure here on Windows 11 Pro 26200, Claude 1.32352.0.0, non-admin corporate account.
Adding one detail I have not seen stated in the existing reports: an ordinary user can stop
the blocking service, so a non-admin workaround exists and the updater could do the same thing
itself.

The blocker:

Name     : CoworkVMService
State    : Running
StartMode: Auto
PathName : "C:\Program Files\WindowsApps\Claude_<version>_x64__<pub>\app\resources\cowork-svc.exe"

The service image lives inside the package directory it is blocking, and it is not a child of
the app, so quitting from the tray never stops it. That is why a reboot is the only thing that
has worked for me.

The security descriptor grants Authenticated Users both start (RP) and stop (WP):

> sc.exe sdshow CoworkVMService
D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-...)

So Stop-Service CoworkVMService succeeds without elevation, which makes two things true:

1. Users stuck in the "Another program is currently using this file" loop can stop the service,

kill leftover Claude.exe processes, and relaunch, instead of rebooting.

1. The quit-for-update path could stop its own service before handing over to the MSIX

servicing, with no additional privilege required.

Happy to attach a full process/service dump from the next failure if that is useful.