[BUG] Windows (MSIX): quit-for-update never completes; stale processes hang the relaunched app or block later launches ("Another program is currently using this file") until reboot

Update: three more updates since filing — same root cause, worse outcome. The
relaunch-blocked variant reported in #76357 / #75337 has now reproduced on this machine too,
and the logs tie both symptoms to the same incomplete quit-for-update.

Every update since this report shows the same signature in %APPDATA%\Claude\logs\main*.log:
beforeQuitForUpdate handler fired, going down for update is the last line the old
instance ever writes — none of the quit-completion lines a normal shutdown produces
(onQuitCleanup results, readyForQuit, beforeQuit, willQuit) appear in any of the four
updates.

| Update (KST) | Versions | Outcome |
|---|---|---|
| 07-14 17:57 | 1.20186.1 → 1.20186.9 | The AppHang described in this issue. |
| 07-15 13:36 | 1.20186.9 → 1.21459.0 | Registration marked "deferred … because {Claude_1.20186.9.0…} is still running" (AppX Event 658); relaunch took ~2.5 minutes. |
| 07-16 17:30 | 1.21459.0 → 1.21459.3 | Relaunch looked fine — but at least one 1.21459.0 process survived the swap (see below). |
| 07-17 10:01 | 1.21459.3 → 1.22209.0 | Register succeeded (10:01:47), but every launch attempt (10:02:08, 10:02:34 — each a RegisterByPackageFullName resume of the pending deployment) died with the "Another program is currently using this file" dialog. Only a reboot (10:03:23) cleared it; the app then started normally (10:04:19). |

How long the leftovers live: on 07-17 at 09:58 — ~16 hours after 1.21459.0 was replaced —
Windows still could not delete that version's app\icudtl.dat /
app\v8_context_snapshot.bin from WindowsApps\Deleted\... (Event 471, error 0x12C).
Those files stay locked only while a process has them mapped, so an old-version process
survived from the 07-16 update all the way to the 07-17 reboot.

# Microsoft-Windows-AppXDeploymentServer/Operational + main.log, 2026-07-17 (KST)
09:58:03  471  error 0x12C: Deleting file ...\WindowsApps\Deleted\Claude_1.21459.0.0_...\app\icudtl.dat failed.
09:58:03  471  error 0x12C: Deleting file ...\WindowsApps\Deleted\Claude_1.21459.0.0_...\app\v8_context_snapshot.bin failed.
10:01:16  main.log: beforeQuitForUpdate handler fired, going down for update    # last line, again
10:01:47  400  Deployment Register ... Claude_1.22209.0.0_... finished successfully.
10:02:08  603  RegisterByPackageFullName (launch attempt resumes pending deployment) -> file-in-use dialog
10:02:34  603  RegisterByPackageFullName (second attempt) -> same dialog
10:03:23  (Windows reboot)
10:04:19  main.log: Starting app { appVersion: '1.22209.0' }                    # clean start

So the visible failure is intermittent — a hang (this issue), a slow relaunch, or an
unlaunchable app that costs a full reboot (#76357, #75337) — but the root cause in the logs
is identical every time: quit-for-update never finishes, and old-version processes outlive
the package swap.

Workaround verified locally: ending every leftover Claude process (they run as the current
user — Task Manager or Stop-Process is enough) and relaunching recovers without a reboot.

Fifth data point, and I think a fourth distinct visible outcome.

Environment

• Windows 11 25H2, OS Build 26200.8875
• Claude Desktop 1.26832.0.0, MSIX
• Hung update completing to 1.26832.0.0 on 2026-08-09
• A long-running Cowork task was active throughout

Same signature as your four-update table, roughly three weeks and many releases later — so this is
still live well past 1.22209.0.

The outcome I hit doesn't match any of the three you listed. The app wasn't hung, wasn't slow to
relaunch, and launched fine. It was fully usable — except:

Newly created sessions accepted no keyboard input at all, while pre-existing sessions continued
working normally. The input box rendered but was completely inert: no cursor, no characters, Enter
and Ctrl+Enter both dead. Switching to a session that already existed, typing worked fine.

So alongside "hang", "slow relaunch" and "unlaunchable", there's a quieter fourth mode: app appears
healthy, but new sessions can't be used. That's arguably the worst one to diagnose, because nothing
looks broken. There's no error, no spinner, no dialog, no indication anything is mid-update. It
presents as a keyboard or keybinding fault — I spent a while testing Ctrl+Enter, Ctrl+J and terminal
keybinding fixes before realising an update was stalled. "My keyboard works in one tab but not
another" doesn't lead anyone toward the updater.

Workarounds that did NOT help: Ctrl+Enter; clicking into the box then Tab to force focus;
resizing the window; closing the tab and opening a fresh session; File → New Window. Logging out
wasn't viable — the long-running Cowork task would have been lost.

A full app restart fixed it and simultaneously let the stalled update complete, which is consistent
with your leftover-process finding. I hadn't seen your verified workaround at the time — ending the
leftover processes rather than restarting everything would presumably have done the same job, and
I'll use that next time.

One suggestion, separate from fixing the quit sequence: a session that can't initialise should
surface an error rather than rendering an inert input box. Even a banner reading "update in progress"
would collapse the diagnosis time from ~30 minutes to zero. That seems cheap next to the underlying
lifecycle fix, and it would help with all four failure modes rather than just this one.

Sixth data point, and I think it names the leftover process the earlier comments were looking for: it is not a stray Claude.exe — it is a Windows service that ships inside the package folder, so it survives the quit by design.

Environment

• Windows 11 Pro 26200 (25H2), x64
• Claude Desktop MSIX, package family Claude_pzs8sxrjxfjjc
• 1.28929.0 → 1.30096.0 → 1.30096.1, both updates on 2026-08-13/14
• Originally a Squirrel install, later migrated to Store ([MSIX] Filesystem not virtualized … (likely Squirrel upgrade))

A fifth visible outcome: the app never comes back at all

The previous reports end in a hang, a slow relaunch, or an unlaunchable app. Here the old instance quits and nothing starts — no relaunch attempt, no new Starting app, no further log output of any kind. The user is left with the "another program is currently using this file" dialog and an app that is simply gone until they start it by hand. Twice in one evening, ~1.5 h each:

2026-08-13 22:53:13 [info] [stealth-update] Triggering stealth update after idle timeout
2026-08-13 22:53:13 [info] [stealth-relaunch] Saved z-order anchor: 0x10cd6 (above our 0x3085e)
2026-08-13 22:53:13 [info] [stealth-relaunch] Saved navigation history (2 entries, active=1)
2026-08-13 22:53:13 [info] [popout-restore] Saving 0 session popout(s) for next launch
2026-08-13 22:53:13 [info] [remote-tools-device] close
2026-08-13 22:53:13 [info] beforeQuitForUpdate handler fired, going down for update
2026-08-13 22:53:13 [info] Windows session ending (close-app) - quitting the app
        --- 1 h 38 min, no further output ---
2026-08-14 00:31:44 [info] Starting app { appVersion: '1.30096.0' }        <- started by hand
2026-08-14 00:31:44 [info] [updater] Version changed since last launch: 1.28929.0 -> 1.30096.0

2026-08-14 01:41:57 [info] [stealth-update] Triggering stealth update after idle timeout
2026-08-14 01:41:58 [info] beforeQuitForUpdate handler fired, going down for update
2026-08-14 01:41:58 [info] Windows session ending (close-app) - quitting the app
        --- 1 h 21 min, no further output ---
2026-08-14 03:03:21 [info] Starting app { appVersion: '1.30096.1' }        <- started by hand

Same signature as everyone else's: beforeQuitForUpdate is the last line the old instance ever writes, with none of the quit-completion lines a clean shutdown produces.

What holds the package: CoworkVMService

Service : CoworkVMService     (Auto start, WIN32_PACKAGED_PROCESS, STOPPABLE)
Binary  : C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

A service registered by the package, running from inside the package directory, with no dependency on the app's lifetime. It does not stop when the app quits, and a running process always holds a section lock on its own image — so the old package directory can never be released. This is not a race or a stray child process that sometimes lingers; it is guaranteed on every update as long as the service is running.

During both dead windows the service can be seen restarting in a loop, which is what a deployment retrying and failing looks like (Application event log, source CoworkVMService):

13.08. 22:53:43, 22:53:55, 22:53:56, 22:55:37       (app quit 22:53:13)
14.08. 01:42:29, 01:42:30, 01:46:39, 01:47:56, 01:47:57   (app quit 01:41:58)
14.08. 02:47:47, 02:47:54, 02:50:23, 02:53:48, 02:54:09, 02:54:14, 03:02:47

This would also explain the 16-hour leftover in the comment above: if the service is what pins the old package, nothing short of stopping it or rebooting will free the directory, and killing leftover Claude.exe processes only helps when the service happens to have been restarted into the new package already.

Related: the same lock one level down

Every single app start logs this — 402 times since 2026-08-07 on this machine:

[error] [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked,
copyfile 'C:\Program Files\WindowsApps\Claude_1.30096.1.0_x64__pzs8sxrjxfjjc\app\resources\chrome-native-host.exe'
      -> '%APPDATA%\Claude\ChromeNativeHost\chrome-native-host.exe'
    at async Object.copyFile (node:internal/fs/promises:622:10)

The destination is locked by a chrome-native-host.exe process that Chrome keeps alive across app restarts (observed starting at 03:03:02, ~20 s before the app itself at 03:03:21). Net effect: the native host binary is never refreshed after the first copy. Same package-owned-process-outlives-the-app family; see #84792.

Suggested fix

Stop CoworkVMService — and any other package-hosted service or helper — inside the beforeQuitForUpdate path, before handing over to the deployment. A watchdog would also cover the rest: if the app has not come back within N seconds of a stealth relaunch, relaunch it and log the failure instead of leaving the user with a modal dialog and no application.

Trigger, for anyone trying to reproduce

Two conditions, per #85962 and confirmed here: an update must be staged ([updater] Update downloaded and ready to install), and the app must then be untouched for ~10 minutes. In the second case above it was exactly 10 minutes after staging (01:31:57 → 01:41:57); in the first the machine was in use until ~22:43, so it fired 77 minutes after staging.