Windows (MSIX): after auto-update relaunch, Claude cannot start (0x80070020) - old app container stays mounted with no process holding it

Status Open

Maintainer reply None cached

Activity 7 comments · opened Sep 18, 2026

Summary

On Windows 11, after the desktop app's in-app auto-update quits and relaunches itself ("stealth update"), the new version sometimes cannot start at all. Every launch fails with Windows error 0x80070020 ("The process cannot access the file because it is being used by another process") before any app code runs, so main.log shows nothing. Settings > Apps > Claude > Repair does not help (tried 5x). The old version's Desktop AppX container is still mounted, and on the second machine we confirmed that no user-mode process holds any handle into it — so the leftover reference is on the Windows side, and only signing out of Windows (or rebooting) clears it.

Seen on two different PCs, two different updates:

PC 1: 2026-09-11, update 1.52386.0 -> 1.52386.3. Unusable until a reboot on 2026-09-13.
PC 2: 2026-09-17, version 2.2553.0.0 (stale container from the previous version's relaunch). Fixed by sign-out/in.

Environment

Claude desktop, Microsoft Store / MSIX build (Claude_pzs8sxrjxfjjc), versions above
Windows 11 Home 10.0.26200 (PC 1); Windows 11 (PC 2)
Claude Code (Code tab) sessions were open in the app at the time of the update on PC 1

What the logs show (PC 1, 2026-09-11 14:36)

main.log:

14:36:57 [stealth-update] Triggering stealth update after idle timeout
14:36:57 [CCD] Killing 1 PTY process tree(s) on quit
14:36:57 beforeQuitForUpdate handler fired, going down for update
14:36:57 Windows session ending (close-app) - quitting the app
(no "Starting app" line until after the reboot on 09-13 06:37)

Event log Microsoft-Windows-AppModel-Runtime/Admin, same second:

14:36:58  217 Destroyed Desktop AppX container {3EC63A37-...} for package Claude_1.52386.0.0_...
14:36:58  215 0x80070020: Cannot create the Desktop AppX container for package Claude_1.52386.3.0_... because an error was encountered converting the job.
14:37:01  208 0x80070020: Cannot create the process for package Claude_1.52386.3.0_... because an error was encountered while configuring runtime. [LaunchProcess]

The old version had two containers (3EC63A34 and 3EC63A37, created 2026-09-10 16:26 by the previous update's relaunch). The update destroyed only 3EC63A37; 3EC63A34 survived until the user signed out on 2026-09-13 06:29:17, and every launch attempt and every Repair in between produced the same 215/208 pair. Repair recycled the CoworkVMService container fine each time; the app container never came back.

What the diagnostics show (PC 2, 2026-09-17, run elevated)

Installed package: Claude_2.2553.0.0_x64__pzs8sxrjxfjjc
No Claude processes are running.            (tasklist /apps + Win32_Process, elevated)
User.dat        : LOCKED
UserClasses.dat : LOCKED                    (...\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium)
hivelist: \REGISTRY\WC\Silof39f9b06-e6a6-59fc-488a-0eb0e534d01cuser_sid     = ...\Helium\User.dat
hivelist: \REGISTRY\WC\Silof39f9b06-e6a6-59fc-488a-0eb0e534d01cuser_classes = ...\Helium\UserClasses.dat
handle -a f39f9b06-e6a6-59fc-488a-0eb0e534d01c  ->  No matching handles found.

and on each launch:

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

So the silo that holds the per-user package hive is still mounted, no Claude process exists, and no process at all has a handle into the silo. Stopping/restarting CoworkVMService does not release it.

Workarounds found

Sign out of Windows and back in (reliable, no full reboot needed).
If an old-version process is still alive (compare tasklist /apps against Get-AppxPackage Claude), killing it works.

Expected

Either the update relaunch waits for / tears down the old container before starting the new version, or the launcher detects this state and tells the user to sign out instead of failing silently (the user only sees a generic "file in use" dialog and Repair does nothing).

Suspicion

The relaunch after beforeQuitForUpdate starts the new version while the previous container is still being torn down (the second container of the old version was created by the previous update's relaunch and is destroyed only at sign-out). Something in that sequence leaks a reference to the old app container/silo.

View original on GitHub ↗

3 Comments

nimbice · 26 days ago

Cause found: a detached process started from a Claude Code session keeps the old container alive.

On PC 2 it happened again today (2.2553.0 -> 2.2553.1.0). No Claude process was running, the Helium hive was locked, and handle.exe found nothing. The holder was the Android adb server (adb.exe), started earlier by an adb command that Claude Code ran in the Code tab. Stopping it released the hive at once and Claude launched:

03:48:56 Baseline hive: LOCKED
03:49:09   launch: 0 Claude proc, 6 new 0x80070020
03:49:09 --- 1 Gradle daemons
03:49:09   kill PID 18544
03:49:12   hive: LOCKED
03:49:25   launch: 0 Claude proc, 6 new 0x80070020
03:49:25 --- 2 adb
03:49:29   hive: free
03:49:42   launch: 11 Claude proc, 0 new 0x80070020
03:49:42 RESULT: FIXED BY adb kill

Commands run by Claude Code start inside the app's Desktop AppX container. adb forks a server that detaches from its shell, so it survives the update's quit and has no package identity (tasklist /apps does not list it). It has no Claude parent and holds no handle into the hive, but as a member of the container it keeps the container and its mounted hive alive. The new version's container then fails with 0x80070020. A Gradle daemon started the same way did not release the hive when killed on its own. This corrects my earlier guess that the leftover reference was "on the Windows side". Any detached long-lived child (dev servers, emulators, watchers) is presumably able to cause the same thing.

Workaround: adb kill-server (or end adb.exe), then start Claude. No sign-out needed. Script and write-up: https://github.com/nimbice/claude-launch-fix

Suggested fixes:

Start Code-tab tool processes outside the app's container, or in a job the app terminates on quit.
Before the update relaunches the app, find and end (or warn about) remaining processes in the container.
When launch fails with 0x80070020, tell the user which process is holding it.

brasileirimm · 25 days ago

I can confirm the same failure on another Windows PC, now on Claude Desktop 2.2553.1.0.

Package: Claude_2.2553.1.0_x64__pzs8sxrjxfjjc

After Claude Desktop closes unexpectedly, every relaunch fails with the Windows message:

“Há um outro programa usando este arquivo no momento.”

Diagnostics:

Get-AppxPackage reports Status: Ok
CoworkVMService / cowork-svc.exe is involved
Stopping CoworkVMService does not recover the app
Killing Claude/cowork processes does not recover it
Windows Settings > Apps > Claude > Repair does not recover it
AppModel-Runtime logs repeatedly show:
Event 215
0x80070020: cannot create the Desktop AppX container for package
Claude_2.2553.1.0_x64__pzs8sxrjxfjjc due to an error converting the job.

Event 208
0x80070020: cannot create the process for package
Claude_2.2553.1.0_x64__pzs8sxrjxfjjc due to an error configuring runtime. [LaunchProcess]

Signing out of Windows and signing back in immediately fixes the problem without requiring a full reboot.

This is recurring and disruptive because after Claude crashes/closes, it cannot simply be reopened. A self-healing cleanup of the stale AppX container/job state before relaunch would be very helpful.

ValThomasTirith · 22 days ago

Same failure:, Windows 11 Pro build 26200, MSIX, update 2.2553.1.0 -> 2.2553.13.0 on 2026-09-22 via the idle stealth update. This has been recurring for months.

main.log (%LOCALAPPDATA%\Claude\Logs\main.log):

12:44:08 [info] [updater] Using GrowthBook check_interval_ticks=1 (default 4)
12:44:19 [info] [updater] Update downloaded and ready to install { releaseName: 'Claude 2.2553.13' }
12:54:49 [info] [stealth-update] Triggering stealth update after idle timeout
12:54:51 [info] beforeQuitForUpdate handler fired, going down for update

AppModel-Runtime/Admin:

12:54:53 217 Destroyed Desktop AppX container {0E5AA8FA-...} for package Claude_2.2553.1.0_x64__pzs8sxrjxfjjc
12:54:54 onward 215/208 0x80070020 for Claude_2.2553.13.0 on every launch (12:54, 15:03, 15:05)

AppXDeploymentServer/Operational:

12:44:18 658 Marking package {Claude_2.2553.13.0...} for deferred registration because {Claude_2.2553.1.0...} is still running

State while the failure was active, elevated:

handle64 -a Container_Claude
svchost.exe pid: 2572 type: Job \Container_Claude_2.2553.1.0_x64__pzs8sxrjxfjjc-S-1-5-21-...

No orphaned processes found: I checked for processes inside a job with no package identity and a dead parent, plus git, node, npx, gpg, adb, shells, and the bundled CLI by name. Nothing. Same as your PC 2: the old container's job survives with no user-mode member, held only by a system svchost.

Only one 217 for the old version appears. The other container's 210 predates my event log retention, which fits your finding that the second container comes from the previous update's relaunch and survives until sign-out.

One addition: the updater applies a GrowthBook override of check_interval_ticks=1 against a default of 4.

Showing cached comments. Read the full discussion on GitHub ↗