[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.

Same 0x80070020 on Claude_1.32352.1.0_x64__pzs8sxrjxfjjc, Windows 11 26200. Posting because I have a control that rules out pinner 2 cleanly (using leifclaesson's numbering from the comment above — 1: orphaned elevated container member, 2: CoworkVMService racing from session 0, 3: kernel-held Helium hives), which I don't see elsewhere in this family.

Ruled out live, in one elevated sequence:

powershell
Stop-Service CoworkVMService -Force
Start-Sleep -Seconds 3
Get-CimInstance Win32_Process | Where-Object { $_.ExecutablePath -like 'WindowsApps\Claude_' } # returned EMPTY
explorer.exe shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude

Service stopped, zero processes carrying Claude package identity, direct AUMID activation. Still failed:

19:07:34.286 217 Destroyed container {3A10A453} for Claude_1.32352.1.0
19:07:34.286 215 0x80070020: ...converting the job
19:07:34.308 217 Destroyed container {3A10A454}
19:07:34.308 215 0x80070020
19:07:34.308 208 0x80070020 [LaunchProcess]
19:07:35.056 210 Created container {3A10A457} for Claude_1.32352.1.0
19:07:35.056 211 Added process 42868
19:07:35.171 217 Destroyed container {3A10A45B}
19:07:35.171 215 0x80070020
19:07:35.191 217 Destroyed container {3A10A45C}
19:07:35.191 215 0x80070020
19:07:35.192 208 0x80070020 [LaunchProcess]

The 215 precedes any 211 — no session-0 container existed to collide with. Not the CoworkVMService race from albertomenache's comment.

Also ruled out: package healthy (Get-AppxPackage: single version 1.32352.1.0, Status: Ok, no duplicates); no Claude entries in WindowsApps\Deleted (only 1Password / WindowsAppRuntime / WindowsStore leftovers), so no deferred servicing; no orphaned elevated container member — full Win32_Process walk from an elevated shell found nothing parented to the desktop app. My MCP servers are parented to a separate editor process, not Claude Desktop, so the pinner-1 inheritance path doesn't apply on this machine.

By elimination that leaves pinner 3, the kernel-held Helium hives, consistent with #53247. Logoff cleared it; no reboot needed.

Separate observation, possibly its own bug: Microsoft.DesktopAppInstaller_1.29.280.0 activates within ~0.5s of every failed Claude launch — 18:47:07.932, 18:47:50.436, 19:07:35.548, three for three across separate attempts. I launched via shell:AppsFolder AUMID directly, so no shortcut stub is involved. Something in the activation-failure path is firing an App Installer operation. If that's a repair/re-register retry, it may be re-entering the same failing path and explaining why the state never self-heals.

The failure is self-perpetuating. Every attempt fails against the prior attempt's container, destroys it ~0.7s too late, then creates a fresh container and puts a new process in it (211 at 19:07:35.056) — which becomes the next attempt's blocker. Each retry cleans up its predecessor and installs a replacement, so retrying can never converge.

The 'Another program is currently using this file' message is a red herring here, the real failure is 0x80070020 on the AppX container silo, you can confirm it in Microsoft-Windows-AppModel-Runtime/Admin events 215/208. If you open the old Container_Claude_* container job and taskkill the elevated member PID that's still pinned inside it, most launches come back without needing a reboot. Btw, I keep a portable Hermes OTG on a USB stick as my rescue agent for these messy Windows upgrade moments, https://github.com/MilkyWay008/Hermes-OTG if you want to poke at it.

Confirmed again on a newer Claude Desktop build, with the same stale AppX Job failure and a successful no-reboot recovery.

Environment

• Windows 11 build 26200
• Previous package: 1.32885.1.0
• Updated package: 1.34493.1.0
• AppModel-Runtime/Admin events: 208 and 215
• HRESULT: 0x80070020

Instance-specific observation

In this occurrence, the stale Container_Claude_1.32885.1.0... Job had 18 live members at the time of diagnosis. The count and process identities are specific to this machine and workload; they are not a general Claude process signature. The reusable diagnostic signal is simply that the previous-version AppX Job still had live members.

A direct TerminateJobObject attempt returned 0xC0000022 (access denied). The recovery that worked was:

1. Re-query the stale Job's current process membership immediately before cleanup.
2. Validate that each PID still belongs to that exact Job.
3. Terminate only those current member PIDs.
4. Confirm that the old Job disappears.
5. Launch the updated Claude Desktop package again.

Result

• The old Job disappeared.
• Claude Desktop 1.34493.1.0 launched successfully.
• No new 0x80070020 event appeared.
• No Windows restart was required.

This reinforces an important safety constraint for any workaround or future self-healing implementation: do not terminate processes by executable name, and do not act on a stale PID snapshot. Job membership should be refreshed and validated at action time because processes can exit and PIDs can be reused.

The self-healing proposal in the original report still looks correct: on activation failure with 0x80070020, have an appropriately privileged service identify the previous-version container Job, clean only its validated current members, and retry activation.

This happens to me on every claude upgrade. I've had success asking codex to kill all claude processes, but this time it required a bit more - I'll let codex tell you all about it:

I independently reproduced and confirmed the stale AppX container-job mechanism described here. I was able to recover without rebooting, reinstalling, resetting the package, or losing Claude data.

Environment

• Windows 11 Pro 25H2, build 26200.9168, x64
• Installed package: Claude_1.37937.1.0_x64__pzs8sxrjxfjjc
• Package status: Ok
• Stale container: Claude_1.34493.1.0_x64__pzs8sxrjxfjjc
• Failure occurred immediately after upgrading and attempting to relaunch Claude

Symptom

Launching Claude produced:

C:\Program Files\WindowsApps\Claude_1.37937.1.0_x64__pzs8sxrjxfjjc\app\Claude.exe

Another program is currently using this file.

The registered AUMID launch (Claude_pzs8sxrjxfjjc!Claude) failed in exactly the same way.

What Windows logged

Microsoft-Windows-AppModel-Runtime/Admin recorded:

Event 215:
0x80070020: Cannot create the Desktop AppX container for package
Claude_1.37937.1.0_x64__pzs8sxrjxfjjc because an error was encountered
converting the job.

Event 208:
0x80070020: Cannot create the process for package
Claude_1.37937.1.0_x64__pzs8sxrjxfjjc because an error was encountered
while configuring runtime. [LaunchProcess]

This was not an actual lock on Claude.exe. After stopping the Claude packaged service, I tested every file under the current package directory with an exclusive open. All 3,056 files accepted it; none reported a sharing violation.

The AppX deployment log also showed that package repair/registration completed successfully:

Event 400:
Deployment Register operation ... finished successfully.

Events 9648/9650:
TerminateSingleService for update successful for CoworkVMService.

Despite the successful service termination and package registration, activation continued to fail at the Desktop AppX job-conversion stage.

Why stopping Claude processes did not work

Initially, no ordinary claude.exe process was running. The only visible Claude component was:

CoworkVMService
  executable: cowork-svc.exe
  account: LocalSystem
  session: 0

Stopping CoworkVMService released the current package files, but it was not the root cause. It restarted during the next activation attempt, and activation still failed.

This also explains why killing processes by image name, stopping the service, repairing registration, and searching for handles on Claude.exe can all appear ineffective.

Kernel object evidence

Enumerating the Windows object-manager root for objects of type Job revealed two Claude jobs:

Container_Claude_1.34493.1.0_x64__pzs8sxrjxfjjc-S-1-5-21-<redacted>
Container_Claude_1.37937.1.0_x64__pzs8sxrjxfjjc-PackagedService

The second job was the expected container for the current CoworkVMService.

The first job belonged to the old 1.34493.1.0 package and the interactive user session. It still existed even though that package version was no longer current.

Querying the stale job required elevation. NtOpenJobObject(JOB_OBJECT_QUERY) followed by QueryInformationJobObject(JobObjectBasicProcessIdList) showed that it still contained 35 processes:

• 16 tail.exe processes
• 15 grep.exe processes
• 4 WSL-related processes: wsl.exe, wslhost.exe, and conhost.exe

These processes had been started between August 22 and August 24 by earlier Claude sessions. Most were abandoned log-monitoring pipelines. One WSL chain had been started with:

wsl.exe sudo redis-server --daemonize yes

None of these processes was named Claude, and none had an executable path inside the old WindowsApps package. Nevertheless, they had inherited the old Claude Desktop AppX job and kept its user-session container alive across the upgrade.

This appears to be the decisive point: the misleading 0x80070020 was caused by a collision with the stale user-session container job, not a file handle on the new package.

Recovery that worked

I left the current Claude_1.37937.1.0-...-PackagedService job alone.

For the stale Claude_1.34493.1.0-...-<user SID> job, I:

1. Opened it elevated with JOB_OBJECT_QUERY.
2. Retrieved its members using JobObjectBasicProcessIdList.
3. Terminated only those returned PIDs.
4. Verified that none of the 35 member processes survived.
5. Launched Claude through its registered AUMID.

Claude opened immediately and displayed its normal new-chat window.

Attempting to open the stale job with JOB_OBJECT_TERMINATE and call TerminateJobObject returned 0xC0000022 even while elevated, so terminating the queried member PIDs individually was necessary on this machine.

Important: processes such as wsl.exe, tail.exe, and grep.exe should not be killed broadly by image name. Only PIDs confirmed as members of the stale Claude job should be terminated, because unrelated processes may have the same names.

Outcome

• Claude 1.37937.1.0 now launches normally.
• No reboot was required.
• No package reset or reinstall was required.
• No local Claude state was removed.
• The current CoworkVMService remained intact.

This strongly supports the issue’s conclusion that descendants launched from Claude sessions can inherit the Desktop AppX job and keep an obsolete package container alive after an upgrade. The launcher/updater needs to enumerate and reap all members of the old user-session job—including descendants whose executables live outside the Claude package—before attempting to activate the new package.

Confirmed the same issue after updating Claude Desktop from 1.37937.1.0 to 1.37937.3.0. Had to get Codex to debug and close processes to open the app again. Action report from Codex >

AppModel-Runtime events 208/215 reported 0x80070020 while converting the Desktop AppX job. The stale job was:

Container_Claude_1.37937.1.0_x64__pzs8sxrjxfjjc-<SID>

It still contained five orphaned Git helper processes—four tail.exe instances and one sleep.exe. Every parent process had already exited. Stopping CoworkVMService and re-registering the package did not resolve the launch failure.

After terminating only those five confirmed job members, the old container disappeared immediately and Claude 1.37937.3.0 launched successfully without a reboot or reinstall. CoworkVMService also resumed normally.

This confirms that the “Another program is currently using this file” dialog can be caused by orphaned descendants pinning the previous AppX container, rather than a file handle on Claude.exe.

I'm sorry but how is this still an issue? If the team at Anthropic wants people to use their desktop app, this must be fixed. We can not be rebooting our entire workstations after every update of this app (especially since the updates are constant). Please, for the love of god, fix this.

this has been driving me insane for months. please fix it.

This is happening daily to me now

Independent confirmation on Windows 11 Pro build 26100 after Claude Desktop updated from 1.44121.4.0 to 1.46388.1.0.

We saw the identical dialog and AppModel Runtime events 215/208 with 0x80070020. Stopping CoworkVMService and re-registering the package both succeeded but did not restore launching.

An elevated JobObjectBasicProcessIdList query found the stale user-session job:

Container_Claude_1.44121.4.0_x64__pzs8sxrjxfjjc-<SID>

Its members included a shared Chrome process tree, Vite servers, ADB, Node, shell, and console helpers inherited from earlier Claude sessions. None were Claude.exe, and several were still doing legitimate work.

After terminating only the PIDs confirmed as members of that stale job, the container disappeared and Claude 1.46388.1.0 launched immediately. CoworkVMService resumed normally, and no new 208/215 launch errors appeared. No reboot, reinstall, package reset, or data deletion was required.

This further supports reaping every inherited member of the obsolete user-session job during update/teardown, plus self-healing when activation encounters 0x80070020. Strong +1 to prioritizing this—the reboot workaround is especially disruptive when Claude descendants include active browsers and development servers.

_Disclosure: this report was written and posted by ChatGPT/Codex, which performed the diagnosis and recovery on the affected machine._

Guys seriously.... you've got unlimited (I assume) Fable use in-house. This is crazy. It's been happening to me for months. Each and every update to Claude Code (If it's been used). An update from a clean reboot will work ok, but once a process has been kicked off by Claude, I avoid that update button like the plague. The easiest fix is a full system reboot. That's the easiest fix, and an absolute pain.

Can 1 of you (Just 1), please, please, test this on a Windows device. Not from a clean reboot. Have Claude go work on something, and then try to install an update. Please. An update to Claude Code is the worst part of my day, while Codex, Cursor, Grok Bot, etc. all update without an issue. It's just Claude.
In the spirit of helping, here is the report from my machine.
----------------------------------------------------------------------------
Another x64 confirmation, with the service-side half of the mechanism captured
from the deployment log rather than inferred.

Environment

• Windows 11 Home 10.0.26200, x64 (not ARM64)
• Package family Claude_pzs8sxrjxfjjc
• Four versions inside 24 hours: 1.46388.1.0 -> .2.0 -> .3.0 -> .4.0

What the deployment log shows

Microsoft-Windows-AppXDeploymentServer/Operational, twice on consecutive
updates:

event 638  Packages were not updated because affected apps are still running.
           Running apps: {Claude_pzs8sxrjxfjjc!Claude}
event 10000 About to service package Claude_1.46388.3.0_x64__pzs8sxrjxfjjc.
            Setting the package state to disabled returned with 0x0.

and the update that closed the running app overnight without warning:

event 603  Started deployment RegisterByPackageFamilyName operation on a package
           with main parameter Claude_pzs8sxrjxfjjc and Options
           ForceApplicationShutdownOption

The part I think is worth re-opening #46179 for

CoworkVMService is an Auto-start Windows service whose executable lives
inside the MSIX package directory:

Name       : CoworkVMService   (display name "Claude")
StartMode  : Auto
State      : Running
PathName   : "C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"

and Microsoft-Windows-AppModel-Runtime shows Windows placing that service's
process into the package's own AppX container:

event 210  Created Desktop AppX container {BFC18372-...} for package Claude_1.46388.4.0_x64__pzs8sxrjxfjjc
event 211  Added process 3112 to Desktop AppX container bfc18372-... for package Claude_1.46388.4.0_x64__pzs8sxrjxfjjc

Process 3112 is CoworkVMService.

So an auto-start service is holding open the very directory the updater has to
replace, and is pinning the container job whose survival produces
0x80070020 on the next launch. That is not an orphaned user process or a stray
MCP server that the user can be expected to manage - it is shipped with the app,
starts itself, and restarts itself. It explains why a reboot is the reliable
cure: the reboot is what stops the service.

#46179 reported the CoworkVMService lock and was closed in April 2026. The
service still runs from inside the package folder in 1.46388.4.0.

Suggested fixes, in order of how much they would help

1. Install cowork-svc.exe outside the MSIX package directory, or stop the

service for the duration of servicing and restart it afterwards. A service
that lives inside the package it must not lock is the root cause.

1. Have the updater stop CoworkVMService before it calls the deployment API,

rather than relying on ForceApplicationShutdownOption for the window only.

1. If neither is possible, detect the failure on launch and offer to stop the

service and re-register, instead of a MessageBox that only says a file is in
use and leaves the user to reboot.****

it happened again. i don't even use cowork.

Independent confirmation on Windows 11 Home 10.0.26200, Claude Desktop 1.46388.1 → 1.46388.3 (MSIX). Same dialog, same AppModel-Runtime 215/208 with 0x80070020, only a reboot (or killing the old container's survivors) recovers. Two data points that may help prioritise:

1. The forced restart is automatic and hits unattended work. The updater stages the build with DeferRegistrationWhenPackagesAreInUse, then later calls RegisterByPackageFamilyName with ForceApplicationShutdownOption on its own. Both unattended cases here fired ~10 minutes after the last write to a Claude Code session transcript, during a multi-subagent job (06:06 → 06:16 and 23:39 → 23:49). Nobody was at the keyboard at 06:16.

AppXDeploymentServer/Operational
09-04 04:16:07  658  Marking {Claude_1.46388.1.0} for deferred registration because {Claude_1.44121.4.0} is still running
09-04 06:16:15  603  RegisterByPackageFamilyName Claude_pzs8sxrjxfjjc  Options: ForceApplicationShutdownOption
09-04 18:40:00  658  Marking {Claude_1.46388.3.0} for deferred registration because {Claude_1.46388.1.0} is still running
09-04 23:49:33  603  RegisterByPackageFamilyName Claude_pzs8sxrjxfjjc  Options: ForceApplicationShutdownOption
09-04 23:49:36  400  Register Claude_1.46388.3.0 finished successfully

2. The old container outlived the update by 16.5 hours. The relaunch of the new version failed immediately after the forced register, and the previous version's container was only destroyed when the machine was put to sleep the next afternoon. Windows' automatic RepairAppRegistration ran on every failed launch (5× on 09-04 08:14, again 16:59, 17:02, 09-05 16:10) and never helped.

AppModel-Runtime/Admin
09-04 23:49:35  217  Destroyed container {4291A86A-…} for Claude_1.46388.1.0      <- forced shutdown of the main app
09-04 23:49:36  215  0x80070020: Cannot create the Desktop AppX container for Claude_1.46388.3.0 ... converting the job
09-04 23:49:41  208  0x80070020: Cannot create the process for Claude_1.46388.3.0 ... configuring runtime [LaunchProcess]
09-05 16:10:18  215  0x80070020 (x2)
09-05 16:27:23  217  Destroyed container {4291AB45-…} for Claude_1.46388.1.0      <- old-version container finally dies on sleep
09-05 16:32:45  201  Created process for Claude_1.46388.3.0                       <- launch succeeds

Not a crash: no Crashpad/WER records for Claude.exe, Sentry session status: ok, memory healthy. The packaged CoworkVMService also logs failed to configure SCM recovery actions ... Access is denied on every start and "terminated unexpectedly" (System 7034) during two of the repair bursts, matching #91736.

Child process tree spawned inside the container on this machine: Claude Code CLI (Roaming\Claude\claude-code\<ver>\claude.exe), uvx MCP servers (workspace-mcp, blender-mcp), python MCP servers, PowerShell + conhost. Any of these surviving the forced shutdown is enough to pin the old silo.

Ask: don't force-register while a Claude Code session/subagent is active (or at all without a click), and on shutdown terminate the whole container job so the old silo can't outlive the update.

Same mechanism on Windows 11 Pro 26100 (every report above is 26200), twice in two days, with a clean control on the same machine.

Environment: Claude Desktop MSIX Claude_pzs8sxrjxfjjc, x64. 2026-09-10 1.49585.0.0 -> 1.52386.0.0, 2026-09-11 1.52386.0.0 -> 1.52386.3.0. Both fired unattended via the app's own [stealth-update] Triggering stealth update after idle timeout.

Control: the three previous stealth updates on this machine (09-03 1.44121.4 -> 1.46388.1, 09-04 -> .2, 09-05 -> .4) relaunched fine, Starting app logged 1 to 2 s after beforeQuitForUpdate. Difference at quit time: the good ones logged [CCD] Killing 0-1 PTY process tree(s) on quit; the two failing ones logged 3 and 4 PTY trees (open Claude Code sessions, one with Remote Control active).

What the event logs show for 09-11 (local time):

16:45:10  main.log                 beforeQuitForUpdate ... "Windows session ending (close-app) - quitting the app"   <- last line from old process
16:45:10  AppXDeploymentServer 603 RegisterByPackageFamilyName ... ForceApplicationShutdownOption
16:45:10  AppModel-Runtime 217     Destroyed container {0FB0D870} for 1.52386.0.0   (this was CoworkVMService's, created at boot)
16:45:12  AppModel-Runtime 210/211 Created container {C6683272} for 1.52386.3.0, process 18332 added  <- never logs "Starting app"
17:21:59  AppModel-Runtime 215/208 0x80070020 "converting the job" on manual launch; Windows runs RegisterByPackageFullName
          ...RepairAppRegistrationOption twice (ACL repair, service reinstall), still 0x80070020
17:25:01  reboot
17:25:10  AppModel-Runtime 217     Destroyed container {0FB0DB08} for 1.52386.0.0   <- the OLD app's container (created 09-10 19:00:58
                                   at the previous "Starting app"), alive through ForceApplicationShutdown and both repairs

So: the old main instance's container job survived the update's forced shutdown and Windows' own repair passes, and was only torn down by the reboot. The new-version process is created (event 211) but hangs before its first log line. No Application Hang (1002) or WER (1001) event is ever produced, so nothing on the machine points at the real cause.

One detail worth adding to the diagnosis notes: package identity is not job membership. On a healthy instance here, an elevated QueryInformationJobObject(JobObjectBasicProcessIdList) on \Container_Claude_1.52386.3.0_x64__pzs8sxrjxfjjc-<SID> returns 25 members, 9 of which are not Claude.exe: two python MCP servers (plus their child interpreters), two claude-code\2.1.266\claude.exe helpers, and four conhost.exe. GetPackageFullName returns APPMODEL_ERROR_NO_PACKAGE for every one of those 9. Any "no Claude processes running" check based on Get-Process, ExecutablePath or package identity will therefore miss the pinners; only the job member list is reliable, as baizhufbb and austencloud found.

Logs (main.log, exported AppModel-Runtime and AppXDeploymentServer channels for both windows) available on request.

Android’s ADB server can keep Claude’s old Windows app container alive after an update. In this case, adb kill-server released it and Claude relaunched without signing out or rebooting. This temporarily interrupts Android debugging connections.

Independent reproduction on Windows 11 (26200), Claude Desktop MSIX 2.110.0.0 → 2.110.1.0, 2026-09-17. Same symptom: after the self-update the app would not open until a reboot.

What the OS logs show, which may help pin the holder:

• 16:21:06 — update staged; the old package's folder is removed while its AppModel state stays non-zero (still in use).
• 16:21:43 and 16:25:33 — two activation attempts, both served by the old package identity (AppModel-Runtime/Admin event 201 LaunchProcess, TWinUI event 1621). That folder no longer exists, so nothing opens. No application-level log line and no crash entry is produced — the app never starts.
• 16:27:25 reboot → 16:28:04/05 the old package is released → 16:28:24 the app finally launches from the new package.

In my case the holder is the packaged Windows service CoworkVMService (display name "Claude"; WIN32_PACKAGED_PROCESS, AutoStart, LocalSystem) whose binary path is pinned to the versioned package folder. It is running even though no Cowork session was in use, and it survives closing the app window.

Workaround that avoids the reboot: stop the service before relaunching (sc stop CoworkVMService) — the app re-configures it at start. Same idea as the adb kill-server report above: releasing whatever still runs from the old folder is what unblocks activation.

Follow-up from the same machine (Win 11 Pro 26100), now with the job member list captured on a live failure, and a no-reboot recovery confirmed.

Two more occurrences: 2026-09-17 2.110.1.0 -> 2.2553.0.0 and 2026-09-18 2.2553.0.0 -> 2.2553.1.0. Both were unattended stealth updates, and both failed with AppModel-Runtime 215/208 0x80070020 "error converting the job".

Members of the stale job \Container_Claude_2.2553.0.0_x64__pzs8sxrjxfjjc-<SID> (elevated JobObjectBasicProcessIdList query, 2h18m after the failed update). There were exactly two processes. Neither was elevated and neither carried a package identity:

tail.exe  "C:\Program Files\Git\usr\bin\tail.exe" -n +1 -f <logfile>
grep.exe  "C:\Program Files\Git\usr\bin\grep.exe" -E --line-buffered -i <pattern>

This is a tail -f | grep pipeline started by a Claude Code background Bash/Monitor in a desktop Code session (Git Bash). The parent shells of both processes had already exited. main.log shows [CCD] Killing 4 PTY process tree(s) on quit immediately before beforeQuitForUpdate, so the PTY shells are killed, but background-task descendants such as this pipeline are not.

Recovery: Stop-Process on those two PIDs was followed within 1 s by event 217 "Destroyed Desktop AppX container ... 2.2553.0.0". The new version launched 3 s later. No reboot or sign-out was needed.

What this suggests: the holder does not need to be elevated (contrary to the issue title) or exotic (adb). Any orphaned descendant of a Claude Code session is enough. A fix on the app side could terminate the whole container job on quit-for-update rather than only the PTY trees. A simpler alternative is TerminateJobObject on the old container, or an equivalent.

Another reproduction, two occurrences four days apart on the same machine. Both follow the auto-update pattern described here, and both needed a reboot. The event-log timelines below may help separate the updater's part from the stale-container part.

Environment

• Windows 11 Pro 10.0.26200, x64
• Claude Desktop (MSIX), package family Claude_pzs8sxrjxfjjc
• Heavy Claude Code use inside the desktop app: several concurrent Code-tab sessions, each spawning bash / node / cmd children (dev servers, scripts, MCP servers)
• Claude Code CLI 2.1.280 (%APPDATA%\Claude\claude-code\2.1.280\claude.exe)

Occurrence 1: 2026-09-22, 2.2553.1.0 → 2.2553.13.0

All times local, from AppXDeploymentServer/Operational, AppModel-Runtime/Admin, Application, System and C:\ProgramData\Claude\Logs\cowork-service.log.

| Time | Event |
|---|---|
| 12:58:15 | Updater stages the new MSIX: Add with DeferRegistrationWhenPackagesAreInUse (app is in use, so registration is deferred) |
| 15:14:46 | RegisterByPackageFamilyName Claude_pzs8sxrjxfjjc with ForceApplicationShutdownOption, which kills the running app mid-session. The cowork-service log shows Persistent RPC: connection ended: failed to read length: EOF at the same second. |
| 15:15:19 | CoworkVMService stopped for servicing; failed to disarm SCM recovery actions for this stop ... open service: Access is denied |
| 15:15:20 | Old folder moved to WindowsApps\Deleted\Claude_2.2553.1.0_... |
| 15:15:20–22 | AppModel-Runtime 215 / 208 0x80070020: Cannot create the Desktop AppX container for package Claude_2.2553.13.0 ... error converting the job → user sees "Another program is currently using this file" |
| 15:15 → 16:19 | AppXDeploymentServer 493 every ~6 min: 107–108 additional files failed to be deleted under WindowsApps\Deleted (old package files still held open) |
| 16:21:22 | Repair attempt: RegisterByPackageFullName with ForceTargetApplicationShutdownOption,RepairAppRegistrationOption → ACLs repaired successfully ... Register next time should succeed |
| 16:21:21–25 | Same 215 / 208 0x80070020 again on the launch attempts around the repair |
| 16:22:00 | User reboot (event 1074). The app launched normally afterwards. |

Occurrence 2: 2026-09-18, 2.2553.0.0 → 2.2553.1.0

Same shape: package staged at 10:03:54 with DeferRegistrationWhenPackagesAreInUse, then RegisterByPackageFamilyName with ForceApplicationShutdownOption at 16:54:31. The old folder moved to Deleted at 16:55:27. Between 16:55:27 and 16:56:20 there were nine 215 / 208 0x80070020 failures, interleaved with three RepairAppRegistrationOption re-registers (16:55:52, 16:56:07, 16:56:18). All three reported success and none fixed the launch. The user rebooted at 16:56:43.

For contrast, the same morning's update (2.110.1.0 → 2.2553.0.0, applied at 09:05:14) went through cleanly, with no 215/208 and no reboot. It happened at the start of the day, before Code sessions had spawned long-lived children.

What this adds to the thread

1. The "crash" is the updater itself. From the user's side, ForceApplicationShutdownOption looks like a crash, followed by a relaunch that cannot succeed. A staged update applied while Code sessions are running reproduced this 2 out of 2 times on this machine. The one clean update ran before any sessions had started for the day.
2. Repair / re-registration does not help. Four repair re-registers across both occurrences reported success, and the container creation still failed with 0x80070020 each time. This matches #80286.
3. The old files stay locked the whole time. The 107–108 undeletable files under WindowsApps\Deleted persisted from 15:15 until the reboot. That is consistent with processes from the previous container, presumably Code-session children, still running.
4. CoworkVMService cannot manage its own recovery settings. Every service start on both days logs failed to configure SCM recovery actions ... open service: Access is denied, and every servicing stop logs failed to disarm SCM recovery actions for this stop.
5. The desktop app's logs stopped. %APPDATA%\Claude\logs\main.log (and the LocalCache\Roaming\Claude\logs copy) was last written on 2026-08-20. None of these failures left app-level logs (see #89992's secondary issue).
6. Possibly related: WER logged RADAR_PRE_LEAK_64 for claude.exe 2.2553.1.0 on 2026-09-21 at 11:34.

Limits of this report

The container job's member list was not captured during the failure: the reboot cleared it, and opening \Container_Claude_* returns STATUS_ACCESS_DENIED without elevation. So which processes held the old container is inferred from the pattern above and from #73107 / #96095, not observed on this machine.

Suggested fixes

• Don't apply a staged update with ForceApplicationShutdownOption while Code sessions are running. Defer the swap to the next time the user quits, or prompt first.
• Before the swap, terminate or detach processes spawned by Code sessions (the whole job tree), or launch them outside the package container.
• When container creation fails with 0x80070020, show the actual cause and list the processes still in the old job, instead of the generic "file in use" dialog.
• Fix the CoworkVMService ACL so the service can set and clear its own SCM recovery actions.

<img width="715" height="250" alt="Image" src="https://github.com/user-attachments/assets/b635c2e7-7c63-4d9c-8d2a-ec892d0c3bfa" />

Additional confirmed case: stale Claude container held by Flutter / Android processes; recovered without reboot

I encountered the same launch failure after a Claude Desktop package update on Windows. We confirmed that the previous version's desktop AppX container job was still present with 14 surviving processes. Terminating those verified job members released the old container, and the updated Claude Desktop launched successfully without restarting Windows.

Environment

• Date: October 7, 2026
• OS: Windows 11 Pro, version 10.0.26200, build 26200, x64
• Previous Claude package: Claude_2.19675.0.0_x64__pzs8sxrjxfjjc
• Current Claude package: Claude_2.19675.1.0_x64__pzs8sxrjxfjjc
• Current installation: C:\Program Files\WindowsApps\Claude_2.19675.1.0_x64__pzs8sxrjxfjjc
• Get-AppxPackage *Claude* reported Status: Ok.

Failure and diagnostic evidence

Launching Claude displayed a Windows dialog saying “Another program is currently using this file.” No Claude.exe process was running before the repair. Launching through the registered application entry point also failed:

explorer.exe shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude

The Microsoft-Windows-AppModel-Runtime/Admin log recorded the following errors. These are English translations of the Chinese messages on this machine:

Event 215 — 0x80070020:
Cannot create the desktop AppX container for
Claude_2.19675.1.0_x64__pzs8sxrjxfjjc because an error occurred
while converting the job.

Event 208 — 0x80070020:
Cannot create the process for
Claude_2.19675.1.0_x64__pzs8sxrjxfjjc because an error occurred
while configuring the runtime. [LaunchProcess]

Using NtOpenDirectoryObject and NtQueryDirectoryObject to enumerate the root object namespace revealed both of these job objects; the user SID is redacted:

Container_Claude_2.19675.0.0_x64__pzs8sxrjxfjjc-<user-SID>
Container_Claude_2.19675.1.0_x64__pzs8sxrjxfjjc-PackagedService

Opening the jobs without elevation failed with 0xC0000022 (access denied). An elevated diagnostic run opened them with NtOpenJobObject and queried QueryInformationJobObject(JobObjectBasicProcessIdList).

The old user container contained these 14 processes:

| Process name | Count |
| --- | ---: |
| adb.exe | 1 |
| dart.exe | 4 |
| dartvm.exe | 1 |
| tail.exe | 1 |
| bash.exe | 1 |
| cmd.exe | 1 |
| emulator.exe | 1 |
| qemu-system-x86_64-headless.exe | 1 |
| crashpad_handler.exe | 2 |
| netsimd.exe | 1 |

These were Flutter/Dart, Android SDK/emulator, and Git shell utilities. Their process creation dates were October 6, before the failed launch attempts on October 7.

The current version's separate packaged-service job contained cowork-svc.exe.

Recovery and verification

With permission to interrupt the remaining Flutter/Android runtime and debugging processes, we:

1. Re-enumerated the old container and checked its members against the diagnostic snapshot.
2. Verified process names and creation times to guard against PID reuse.
3. Terminated only the 14 verified members of the old user container.
4. Confirmed that the old container job disappeared from the object namespace.
5. Launched Claude again using the same registered application entry point.

At 09:02:41 local time (UTC+8), the runtime log recorded:

Event 210 — Created the desktop AppX container for the current Claude package.
Event 211 — Added the new Claude process to that container.
Event 201 — Created the application process successfully. [LaunchProcess]

A responding window titled Claude appeared. No Windows reboot, Claude reinstall, package re-registration, service restart, or application-data deletion was needed.

What this case establishes

This provides another observed case supporting the stale-container mechanism described in issue #73107: surviving members of the previous version's job blocked the new version from launching, and releasing those members restored launch immediately.

The surviving processes did not have Claude-specific names, so searching only for Claude.exe would have missed them. Direct job-membership inspection identified the affected processes precisely.

This was one observed failure and successful recovery, not a controlled reproduction across multiple updates. We did not verify each surviving process's elevation state or directly trace the internal kernel call that failed. Access denial when opening the job without elevation does not by itself establish that every member process was elevated.

A useful product fix would detect surviving members of the previous version's container during update/relaunch, explain the blocked launch, and offer to stop the identified processes with appropriate permission. The prompt should disclose that running development tools or emulators may be interrupted.