[BUG] Windows desktop app won't launch after package upgrade: "Another program is currently using this file" (0x80070020) -- old version's AppX container silo pinned by an orphaned elevated Claude Code child process

This isn't a one-off. It's a recurring family of Windows launch/update failures that all surface the same "Another program is currently using this file" MessageBox (the raw Win32 string for error 32) and all clear on reboot:

Open: #53247, #61635, #42776, #77379, #77421, #76357, #75337
Closed: #67911, #59934, #61342, #51847

The common thread across every one is "reboot is the only known cure." That now makes sense: reboot works because it kills the leftover processes keeping the old package's AppX container job alive in the kernel. Nobody's machine is special -- everyone is just rebooting, so the actual fault (a leaked container silo) never gets pinned down and each report reads as isolated.

What I found on mine that the reboot-only reports approximate but miss: the job wasn't held by a service holding a handle. It had live MEMBER processes still inside it -- an elevated child (llama-svc.exe -i -elevated) that a Claude Code session had spawned inside the old desktop app's container, plus its conhost. The non-elevated teardown can't kill an elevated descendant (PROCESS_TERMINATE is denied across the elevation boundary), so it's left behind and pins Container_Claude_<oldversion>_..._<usersid> across the upgrade. taskkill /f on those two member PIDs made the stale job vanish from the kernel namespace immediately and the app launched. No reboot.

That's the practical difference from #77379, where killing the svchost that held a job HANDLE just respawned under a new PID and the block persisted. On the reboot-only reports it's worth checking whether there's a leftover elevated MEMBER process still inside the container job (open the job and query JobObjectBasicProcessIdList), not only a service holding a handle -- if there is, killing it clears the block with no reboot.

The fix ask stands: reap the container's descendants with SYSTEM privilege at teardown (the packaged Cowork service already runs as SYSTEM and can open the job regardless of elevation), and self-heal on launch -- when activation fails with 0x80070020, find the stale Container_Claude_<oldversion> job and terminate its members before retrying. That turns a months-long recurring hard failure into a one-time hiccup.

Full live diagnosis (event IDs 215/208, everything I ruled out, the repro) is in the issue body above.

Same 0x80070020 container-silo collision, but with a different (and I suspect more common) trigger: the app's own packaged CoworkVMService, not a leftover Claude Code child.

Hit this today on Windows 11 (26200) after an in-place MSIX update to Claude_1.24012.1.0_x64__pzs8sxrjxfjjc. Identical symptom and the same Microsoft-Windows-AppModel-Runtime/Admin fingerprint you documented (208 [LaunchProcess] + 215 "converting the job"), but there was no orphaned elevated Claude Code process anywhere — no llama-svc.exe, no leftover Claude.exe, nothing to taskkill. Restart Manager reported no file lock, confirming it's purely a kernel Job/silo collision, not an open handle.

What was actually pinning the container

The package's own service, CoworkVMService (app\resources\cowork-svc.exe):

• TYPE = WIN32_PACKAGED_PROCESS, START_TYPE = AUTO_START, SERVICE_START_NAME = LocalSystem
• plus a named-pipe start trigger (\pipe\cowork-vm-service)

So it runs as LocalSystem in session 0, creates the package's Desktop AppX container first, and the interactive Claude.exe (session 1) then can't create/convert its own. Event order on every launch attempt:

210  Created Desktop AppX container {…} for package Claude_1.24012.1.0…
211  Added process <cowork-svc PID> to Desktop AppX container {…}      <- LocalSystem, session 0
215  0x80070020: Cannot create the Desktop AppX container … converting the job
208  0x80070020: Cannot create the process … configuring runtime. [LaunchProcess]
217  Destroyed Desktop AppX container {…}                              <- the interactive attempt

Why the taskkill workaround doesn't apply here — and why nothing in userland fixes it

• There's no orphan to kill; the pinner is a live packaged service that restarts on the pipe trigger the instant you launch the app.
• sc config CoworkVMService start= disabled → Access Denied even from an elevated admin shell. The service SD grants DC/WD (change-config) only to NT SERVICE\AppXSvc; Administrators and LocalSystem get only RP/WP (start/stop), no reconfigure.
• Stop-Service succeeds, but it trigger-restarts on the next launch.
• Editing HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService\Start = 4 (the key is admin-writable) → AppXSvc reverts it to Automatic on the next package activation.

What fixed it

A reboot. The update had left C:\Program Files\WindowsApps\Deleted reporting "116 files failed to delete" and re-fired a package Register op on every launch — i.e. servicing was only half-applied. The reboot completed the deferred servicing and cleared the stale kernel container job. After reboot, CoworkVMService (session 0) and interactive Claude.exe (session 1) coexist fine, exactly as before the update — Cowork works, no 208/215 at all. On this machine a reboot was the only reliable recovery, because the racing process is the app's own AppXSvc-managed service that can't be disabled from userland.

Suggestion for the self-heal (item #2 in the OP)

The "enumerate stale container job members, terminate, then retry" idea should also cover the case where the container is held by the package's own CoworkVMService in session 0 racing the interactive session — not just leftover elevated Claude Code descendants. Sequencing interactive activation to own the container before the LocalSystem service starts (or having the service defer to / join a session-1 container) would prevent the post-update race entirely.

Env: Windows 11 Pro 26200 · Claude Desktop 1.24012.1.0 · package family Claude_pzs8sxrjxfjjc.

Still live six weeks later, and on much newer builds than the one I filed against. I hit it again here yesterday. This machine is now on 1.30096.1.0, the same package version as the report below.

#86555 was filed today against package 1.30096.1.0. Mine was 1.17377.1.0 -> 1.17377.2.0. Same dialog, same "only a reboot clears it", same "every update", so nothing across that whole span of versions changed the outcome.

Six tickets have link-cited this one since I filed it: #76980, #80286, #76357, #84962, #53247, #86555. The family anchors are much bigger than any single report: #42776 is at 55 upvotes and 119 comments, #53247 at 11. This is not machine-specific.

What the last month actually added is that the one symptom now has three separate pinners, and only the first is fixable from userland:

1. An orphaned elevated child that is still a live member of the old container job (this ticket). Killing it clears the block with no reboot. That has worked on my machine every time it has bitten, across every update.
2. The package's own CoworkVMService racing the interactive session from session 0 (albertomenache above, plus #83968 and #76357). Nothing to kill. sc config is Access Denied even from an elevated shell, Stop-Service loses to the named-pipe start trigger, and AppXSvc reverts the registry Start value on the next activation.
3. The mounted Helium hives (User.dat / UserClasses.dat) held by PID 4 System and PID 180 Registry (#53247). Kernel holders, so no user-mode kill exists at all, and enumerating by package identity returns zero processes in the container.

Three causes, one dialog, and two of the three cannot be cleared by anything the user is able to run. That is the case for item 2 of my original ask: reap the container's members from the packaged SYSTEM service at teardown, and self-heal on launch when activation fails with 0x80070020, rather than leaving a reboot as the only recovery.

One diagnostic correction worth carrying forward, from afram123 in #80286: 0x80070020 does not show up in AppXDeploymentServer/Operational, because this is an activation failure and not a deployment one. Get-AppxPackage reports Status: Ok. The events are in Microsoft-Windows-AppModel-Runtime/Admin, IDs 215 and 208.