Windows desktop app (MSIX) wedges on every auto-update - crash-loops until reboot, 3 reboots in one day

Independent confirmation on another x64 machine, same version chain as yours — including the second push to 1.37937.1.0. Two details here are not yet in this thread or in #89680 / #88429: the deferred registration fails with 0x5 mid-teardown, and the CoworkVMService → Manual fix proposed in #57221 is not actually applicable.

All identifiers below are redacted: user SID, account name, and the MAC-derived node portion of the container GUIDs (XXXXXXXXXXXX).

Environment

| | |
|---|---|
| OS | Windows 11 Pro 10.0.26200 |
| Arch | x64 |
| Package | Claude_pzs8sxrjxfjjc, MSIX, 1.37937.0.0 → 1.37937.1.0 |
| Update source | downloads.claude.ai (in-app updater, not the Store) |
| Claude Code CLI | installed, unaffected |
| Reboots required | 3 in one day |

Timeline (2026-08-26, local)

| Time | Event |
|---|---|
| 08:28–08:41 | AppModel-Runtime 215/208 0x80070020 for 1.37937.0.0 — an earlier incident on the previous update, uptime 12 days. Reboot at 08:50 cleared it |
| 10:47:12 | App launched. 210 creates container {122FB97E-A112-11F1-9761-XXXXXXXXXXXX} for 1.37937.0.0; 211 adds PID 16272 |
| 10:47:47 | AppXDeploymentServer 603 — Started deployment Add operation ... Options NormalPriorityRequest and DeferRegistrationWhenPackagesAreInUse |
| 10:47:49 | 854 https://downloads.claude.ai/releases/win32/x64/1.37937.1/Claude-<hash>.msix · 855 Claude_1.37937.0.0 is updating to Claude_1.37937.1.0 |
| 10:47:57 | 400 Deployment Add finished successfully |
| 11:10:58 | 211 adds PID 7252 to the same container {122FB97E…} — old version still live |
| 11:49:25 | 217 destroys container {122F9D83…} for 1.37937.0.0, then 67 Failed with 0x5 modifying AppModel Runtime status for package Claude_1.37937.0.0 (current status = 0x280000, desired status = 0x480000) |
| 11:49:28 → | Every launch of 1.37937.1.0: 215 ×2 0x80070020 ... error was encountered converting the job, then 208 Cannot create the process ... configuring runtime. [LaunchProcess] |
| 12:14 | Reboot. Fixed |

Container {122FB97E…} has no matching event 217 anywhere in the log. It was created at 10:47:12 for the old version and never destroyed, while both its member PIDs (16272, 7252) are long gone. Every subsequent launch collides with it.

The 0x5 at 11:49:25 looks like the actual failure point: the deferred registration finally fires when the old processes exit, hits access-denied while moving the old package's runtime status to 0x480000, and abandons the teardown with the container still alive.

Who holds it

Resolving the logging PID on the failing events reproduces #88429's finding on this machine:

• Events 215 / 208 (the failures) — logged by svchost.exe PID 2256, hosting Appinfo among others.
• Event 210 that succeeds — logged by services.exe PID 1352, and it is the packaged service cowork-svc.exe getting its container, not the app.

So session-0 service activation works throughout; only interactive Desktop Bridge activation via Appinfo fails.

The dialog is misleading — there is no file lock

Opened the packaged binary with FileShare.None, which Windows grants only when no other handle exists:

exe: C:\Program Files\WindowsApps\Claude_1.37937.1.0_x64__pzs8sxrjxfjjc\app\claude.exe
EXCLUSIVE OPEN SUCCEEDED - no other process holds a handle to this file

No process had the package directory open, yet Explorer reported "another program is currently using this file".

NEW: #57221's fix is not applicable — the service cannot be reconfigured

#57221 recommends setting CoworkVMService from AutoStart to Manual. On a current build that is impossible for any user, including elevated administrators:

elevated: True
before:   Auto
Set-Service FAILED: Service 'Claude (CoworkVMService)' cannot be configured due to
  the following error: Access is denied
sc.exe fallback: [SC] OpenService FAILED 5:  Access is denied.
after:    Auto

The registry Start value under HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService is protected the same way, despite the key's owner being BUILTIN\Administrators. The packaged-service DACL admits only the deployment engine. Anyone following that advice will hit a wall — this is related to the ACL restriction noted in #83494.

WARNING: do not stop the Appinfo service

Since Appinfo demonstrably holds the leaked job, stopping it looks like the obvious non-reboot recovery. It is not, and it makes things considerably worse. Appinfo brokers UAC and activates every packaged app on the system. Stopping it here caused:

1. Claude still failed to launch (different error),
2. Windows Terminal — itself MSIX — stopped launching with the same "another program is currently using this file" message,
3. every Claude Code session froze, including one started in conhost,

and forced an extra reboot with the session in a worse state than before. #61635 flags the same hazard. Worth an explicit note in any workaround guidance, because the diagnosis points straight at it.

Everything that did not work

• Stop-Service CoworkVMService -Force → succeeded, relaunch still failed with fresh 215/208 at 11:56:45. The service is demand-restarted by the activation attempt itself.
• Windows' own automatic package repair at 11:52:59 — event 649 ACLs repaired successfully, event 400 finished successfully — launches still failed at 11:53:02 and 11:56:47.
• Restart-Service AppXSvc → denied unelevated; per #53247 it does not help elevated either.
• Killing processes — there were none left to kill.

Only a reboot recovered it, matching every other report here.

Ask

Same as this issue's, with one addition: the 0x5 failure while moving 1.37937.0.0 to status 0x480000 at 11:49:25 is the last thing that happens before the container is orphaned. If the deferred-registration teardown ran with enough privilege to complete — or if the post-update launcher detected 0x80070020 and released the stale job instead of dying silently — this whole class of report would go away.

Full event-log extracts available on request.

Third occurrence on this machine in under 48 hours — one per update, no exceptions. Same x64 box as my comment above. This capture adds two things that should narrow the fix considerably.

Identifiers redacted as before.

Incident 3 — 2026-08-27, 1.37937.1.0 → 1.37937.3.0

| Time | Event |
|---|---|
| 06:58:37 | AppXDeploymentServer 603 — Add, Options NormalPriorityRequest and DeferRegistrationWhenPackagesAreInUse |
| 06:58:40 | 854 https://downloads.claude.ai/releases/win32/x64/1.37937.3/Claude-<hash>.msix · 855 1.37937.1.0 is updating to 1.37937.3.0 |
| 06:58:47 | 658 Marking package {1.37937.3.0} for deferred registration because {1.37937.1.0} is still running |
| 06:58:48 | 400 Add finished successfully |
| 07:09:19 | 603 RegisterByPackageFamilyName ... ForceApplicationShutdownOption — the app force-shuts itself to register |
| 07:09:20 | 400 Register finished successfully — and in the same second, AppModel-Runtime 215 ×2 + 208, 0x80070020. Wedged from the first launch onward |
| 08:36:44 | 603 self-initiated repair, RegisterByPackageFullName ... ForceTargetApplicationShutdownOption,RepairAppRegistrationOption → 400 success at 08:36:45 → 215/208 again at 08:36:44 and 08:36:46 |
| 08:56:40 | Same repair again → 400 success at 08:56:42 → 215/208 again at 08:56:40 and 08:56:42 |
| 09:07:27 | Sign-out / sign-in. Fixed instantly |

Note 1.37937.2 was skipped entirely — this fires on whatever gets pushed, not on a specific build.

NEW: the stale job is session-scoped, and logoff already tears it down correctly

This is the useful one. Sign-out cleared it without a reboot — and the Appinfo host survived that sign-out untouched:

215/208 logged by svchost PID 2156  (services: Appinfo, BITS, HNS, ... Winmgmt, wuauserv)
Appinfo PID after the successful sign-in: 2156   <- same process
svchost 2156 CreationDate: 2026-08-26 12:15:07   <- boot time, never restarted
Last boot: 2026-08-26 12:14:55                   <- unchanged across the fix

So the process holding the leaked container job was never restarted, yet the wedge cleared. The job dies with the session, not with Appinfo. Two consequences:

1. Nobody needs to restart or kill Appinfo to fix this — and nobody should try (see my warning above; it breaks UAC and every other MSIX app system-wide).
2. Windows already destroys this job correctly at session teardown. Whatever the deferred-registration path fails to do at 07:09:20, logoff does right. That is a much smaller gap to close than "reboot required" implies.

NEW: successful registration is not sufficient

Three separate deployment operations reported event 400 finished successfully (07:09:20, 08:36:45, 08:56:42) and the app was unlaunchable within the same second each time. Any repair logic gated on "did registration succeed" will report green while the app stays dead — which matches the crash-loop in this issue's Incident 3.

Full pattern on this machine

| # | Date | Update | Recovery |
|---|---|---|---|
| 1 | 08-26 ~08:28 | wedged on 1.37937.0.0 | reboot 08:50 |
| 2 | 08-26 10:47 → 11:49 | 1.37937.0.0 → 1.37937.1.0 | reboot 12:14 |
| 3 | 08-27 06:58 → 07:09 | 1.37937.1.0 → 1.37937.3.0 | sign-out 09:07 |

Three updates, three wedges, three forced session losses in under two days.

Request: please escalate

Sign-out is not a workaround in any meaningful sense. It closes every open session, editor, terminal and browser on the machine — for many of us the desktop app is the least expensive thing being destroyed to recover it. The practical cost is a full working-context rebuild several times a week, triggered by an update nobody asked for at a time nobody chose.

Concretely, any one of these would end it:

1. Detect and recover. The post-update launcher already knows it failed — it retries registration twice. Have it treat 0x80070020 on container creation as "stale job", release it, and relaunch, instead of silently dying and re-registering into the same wall.
2. Do not defer into a live container. If 658 fires (still running), do the registration at a real quit rather than force-shutting the app and registering into a container the OS has not finished tearing down.
3. Failing both, tell the user the truth. "Another program is currently using this file" is actively misleading — there is no file lock, as the FileShare.None test in my earlier comment shows. A message naming the real condition and the sign-out remedy would at least stop people killing processes that do not exist.

Happy to run any diagnostic on a live wedge — I can reproduce this on the next update push, which on current cadence means tomorrow morning.

Same failure on 1.37937.1.0, Windows 11 Home (build 26200). Event-log timeline that may help triage (cross-ref #89676):

• Aug 25 22:13:23 — Microsoft-Windows-AppXDeploymentServer/Operational Event 658: Marking package {Claude_1.37937.1.0_x64__pzs8sxrjxfjjc} for deferred registration because {Claude_1.37937.0.0_x64__pzs8sxrjxfjjc} is still running. The update stays staged-but-unregistered as long as the app keeps running.
• Aug 26 12:35:24 — Event 603 RegisterByPackageFamilyName with ForceApplicationShutdown forces registration through, killing the running app mid-session.
• Aug 26 12:35–13:35 — every relaunch fails; Microsoft-Windows-AppModel-Runtime/Admin Events 215/208 with 0x80070020 (Cannot create the Desktop AppX container ... error was encountered converting the job). The shell dialog reads "Another program is currently using this file."
• Root of the hang: the OLD version's AppX container (container {B58CB5C4-...}, package Claude_1.37937.0.0, created Aug 25 18:13:18) survived the forced shutdown by a full hour — it was destroyed only at 13:35:36. The first successful launch (Event 201, package 1.37937.1.0) came at 13:37:07, 91 s after that stale container finally died. ~61-minute outage, and there is no crash dump and no WER report — the app never faulted; the relaunches were blocked by the stale container, not by a crash.
• Matches #89711: at the kill moment (12:35:24) CoworkVMService logs failed to disarm SCM recovery actions for this stop.
• Recurred on 08-25 and 08-26 (both re-confirmed from the Admin log) and earlier on 08-21, which is now rolling off the short-retention AppModel-Runtime/Admin log.

Happy to pull raw event XML for any of these if it helps.