[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

Summary

After a Claude Desktop (Windows) package upgrade, launching the app fails every time with a MessageBox saying "Another program is currently using this file". No process holds the file. The real failure is AppX container creation returning 0x80070020 (ERROR_SHARING_VIOLATION) at the job-to-silo conversion step, because the PREVIOUS version's Desktop AppX container job was still alive in the kernel, pinned by an orphaned elevated child process of a Claude Code session the old app had spawned. Root cause confirmed live on my machine: killing the two pinning processes cleared the stale silo instantly and the new version launched. No reboot.

I have hit this on many upgrades over months. Reboot was the only known cure, which now makes sense: reboot kills the orphans.

Environment

• Windows 11 IoT Enterprise 10.0.26200
• Upgrade Claude 1.17377.1.0 -> 1.17377.2.0 (new package folder created 04:02, old app instance exited ~08:02 when I tried to relaunch)
• No reboot between versions

Symptom

Every launch method (Start Menu, taskbar, explorer.exe shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude) yields:

[Window Title]
C:\Program Files\WindowsApps\Claude_1.17377.2.0_x64__pzs8sxrjxfjjc\app\Claude.exe

[Content]
Another program is currently using this file.

[OK]

Sysinternals handle64 finds no handles on Claude.exe or the package folder. Defender real-time off makes no difference. Add-AppxPackage -Register of the manifest succeeds and changes nothing.

Underlying error

Microsoft-Windows-AppModel-Runtime/Admin, on every attempt:

Event 215: 0x80070020: Cannot create the Desktop AppX container for package
           Claude_1.17377.2.0_x64__pzs8sxrjxfjjc because an error was encountered
           converting the job.
Event 208: 0x80070020: Cannot create the process for package Claude_1.17377.2.0_...
           because an error was encountered while configuring runtime. [LaunchProcess]

0x80070020 = HRESULT_FROM_WIN32(ERROR_SHARING_VIOLATION), from the job-to-silo conversion (NtSetInformationJobObject(JobObjectCreateSilo)). The MessageBox is just the raw Win32 string for error 32. Misleading, since no file is in use at all.

Root cause (confirmed, not a hypothesis)

The kernel object namespace (NtQueryDirectoryObject on \) still contained the OLD version's app container job after the upgrade:

Job  Container_Claude_1.17377.1.0_x64__pzs8sxrjxfjjc-S-1-5-21-<usersid>

Opening that job elevated and querying JobObjectBasicProcessIdList showed exactly 2 remaining members: an elevated tool-install console (llama-svc.exe -i -elevated -pause, started hours before the upgrade by a Claude Code session running inside the old desktop app) and its conhost.

The chain:

1. Claude Code sessions spawned by the desktop app run inside the app's Desktop AppX container, and every descendant inherits the silo job, invisibly.
2. One session started an elevated child. The elevated process still lands in the container job.
3. At teardown, the non-elevated parent cannot terminate the elevated descendant (OpenProcess with PROCESS_TERMINATE is denied across the elevation boundary), so it is silently left behind.
4. The orphan keeps the old version's container job/silo alive across the package upgrade.
5. Every activation of the new version then fails to create its container for the same package family + user + session: STATUS_SHARING_VIOLATION at silo conversion, surfaced as the "file in use" MessageBox.

Control observation: in the same second a launch failed, the packaged CoworkVMService's own container (session 0) was created successfully. The collision is per user session, not machine-global, which is why nothing else on the system misbehaves.

Proof: taskkill /f of the two PIDs (elevated) made the stale job vanish from the kernel namespace immediately, and the app launched normally on the next attempt.

Ruled out live

• Defender real-time scanning (disabled, still failed)
• Launch method (raw exe vs AUMID activation, identical failure)
• Package registration (Add-AppxPackage -Register succeeded, ACLs repaired, still failed)
• Stale RuntimeBroker (killed, still failed)
• CoworkVMService and its container (service stopped, container destroy confirmed in the event log, still failed)

Reproduction

1. Run Claude Desktop on Windows, open a Claude Code session in it.
2. From that session, start a long-lived elevated process.
3. Exit Claude Desktop, let the package upgrade.
4. Launch the new version: the MessageBox appears on every attempt until the elevated orphan exits or the machine reboots.

Suggested fix

1 - Reap container descendants with SYSTEM privileges at teardown. CoworkVMService already runs as SYSTEM. On app exit (or service stop) it could terminate remaining members of the app's container job, which it can open regardless of elevation.

2 - Self-heal on launch: when activation fails with 0x80070020, look for a stale Container_Claude_<oldversion>_..._<usersid> job in the kernel namespace and have the service terminate its members, then retry. That turns a months-long recurring hard failure into a one-time hiccup.

3 - At minimum, surface a better error than the raw Win32 string. "Another program is currently using this file" sends the user hunting for file locks that do not exist.

Additional context

Diagnosed live in a Claude Code CLI session (the desktop app being down). Happy to provide the full transcript or run further diagnostics on this machine. I keep a local workaround script now that enumerates the stale container job and kills its members, so I can repro/verify a fix on the next upgrades.