[BUG] Windows MSIX: staged update leaves old instance running from WindowsApps\Deleted for 15h — 0x12C cleanup loop crashes it repeatedly, then servicing force-terminates it mid-session

Related issues (fragments of the same failure chain)

• #73694 — CoworkVMService/package file locks block AppX cleanup until reboot. Almost certainly the same underlying mechanism as the 0x12C cleanup loop below (though here the locked files were the Electron resources app\resources.pak / app\v8_context_snapshot.bin, held by the app processes themselves).
• #82277 — package servicing disables the package while running, silently killing Claude Code work. Matches the forced-termination end state below.
• #85174 / #82134 — other corruption/data-loss variants of update-vs-running-instance.

What this report adds: the failure mode where the old instance keeps running for ~15 hours out of WindowsApps\Deleted\… after the update is staged, while servicing's retry loop incrementally deletes the folder it is executing from — so instead of one silent kill or a failed update, the user experiences repeated app crashes all day, ending in a forced mid-session termination. Includes a minute-level correlation between the AppX servicing events and the crash interruptions in a live Claude Code session transcript.

Summary

On Windows, the Claude desktop app (MSIX/Store package) kept crashing for ~15 hours because a staged app update fought the running instance the whole time. The update moved the old package to WindowsApps\Deleted\…, but the running instance never fully exited, so it kept executing out of the deletion-staging folder while AppX servicing retried cleanup every ~6–15 minutes. Each partial cleanup risked deleting a file the live app still needed (app\resources.pak, app\v8_context_snapshot.bin), producing repeated crashes/session interruptions. Servicing eventually escalated to a forced re-registration that terminated the app mid-session. Only a machine reboot cleared the locks and let the update land; the app has been stable since.

Environment

• Windows 11 Pro, OS build 26200 (26100.9278-era servicing)
• Claude desktop app, MSIX package family Claude_…_pzs8sxrjxfjjc, x64
• Versions involved: 1.37937.1.0 (running) → 1.37937.3.0 (staged update) → 1.40609.0.0 (next update, immediately re-entered the same deferred state)

Timeline (from Microsoft-Windows-AppXDeploymentServer/Operational)

• Day 1, ~20:30 — update to 1.37937.3.0 staged; old package Claude_1.37937.1.0 moved to C:\Program Files\WindowsApps\Deleted\…. First event 471: error 0x12C: Deleting file …\Deleted\Claude_1.37937.1.0…\app\resources.pak.
• Day 1 20:30 → Day 2 11:28 — 130 logged event-471 retries (0x12C, ~every 6–15 min) failing to delete resources.pak / v8_context_snapshot.bin — locked by the still-running old instance. Throughout this window the user's Claude Code sessions were repeatedly interrupted; the active session transcript shows 7 abrupt gaps (4–20 min) whose times line up with retry bursts. Relaunching the app did not recover — the half-dead background process appears to have kept catching relaunches (single-instance behavior) instead of a fresh start from the new package.
• Day 2, 11:32 — servicing escalated: RegisterByPackageFullName with ForceTargetApplication, then events 9648/9650 TerminateSingleService for update successful … in package CoworkVMService, terminateService: true — the app was killed mid-session (transcript dies at 11:32:08).
• Day 2, 11:35 — user rebooted (coincidentally prompted by a pending Windows update; the reboot is what cleared the file locks).
• Day 2, 12:09 — package files for 1.37937.3.0 finalized; app started cleanly and has been stable since.
• Day 2, 13:14 — next update (1.40609.0.0) downloaded and parked the same way: event 638 Packages were not updated because affected apps are still running, event 658 Marking package … for deferred registration because … is still running. The cycle is set up to repeat.

Expected behavior

Some combination of:

1. The app should notice a pending/staged MSIX update and prompt for (or schedule) a clean self-restart, instead of running indefinitely from a package staged for deletion while servicing shreds it.
2. On update, the app (including any background/tray/service process — CoworkVMService was the named holdout) should fully exit and release file locks so deferred registration can complete at next launch.
3. Servicing being forced to TerminateSingleService a live app mid-session should be treated as a bug signal — the user loses their session with no explanation.

Diagnostics gaps that made this hard to self-diagnose

• The app truncates its logs (%LOCALAPPDATA%\Claude\logs\*.log) on every start, so after each crash+relaunch the evidence of the previous run is destroyed. Keeping at least one prior-run log (rename to *.old instead of truncating) would have shortened this investigation from hours to minutes.
• Crashpad (%APPDATA%\Claude\Crashpad) retained zero dumps across all of these crashes, and nothing reached Windows Error Reporting, so from the OS's perspective the app never crashed at all.

Repro sketch

1. Windows + Store-distributed Claude desktop app; keep a Claude Code session running (background process alive).
2. Let a Store update for Claude stage while the app is in use, and leave the app running past the staging (e.g. overnight).
3. Observe AppXDeploymentServer/Operational event 471 0x12C retry loop on WindowsApps\Deleted\Claude_<old>…\app\resources.pak, intermittent app crashes, and eventually a forced termination.

---

Investigated and written by Claude Code running on the affected machine, at the user's request.

🤖 Generated with Claude Code