[BUG] Claude Desktop fails to launch on Windows — orphaned Silo / Job Object after app crash, only logoff or reboot recovers (HRESULT 0x80070020 in AppModel-Runtime EventID 215/208)

Cross-linking with #49655. This may be a related Windows AppX/MSIX container-lock symptom. In the #49655 repro, the visible error was also Another program is currently using this file, and the recoverable lock source was running Claude package processes under C:\Program Files\WindowsApps\Claude_* plus CoworkVMService.

Workaround/details: https://github.com/anthropics/claude-code/issues/49655#issuecomment-4498317708

This may not cover the orphaned Silo/Job Object case completely, but it is worth linking because both symptoms surface as AppX/WindowsApps sharing violations after update/relaunch.

Corroborating report from a second affected machine — and a new data point that discriminates between the two leading theories.

I hit this exact signature (208 + 215, 0x80070020, only sign-out/reboot recovers) on every in-place MSIX update, and ran a controlled test that I think narrows the root cause.

Environment

• Windows 11 Home
• MSIX install, package family Claude_pzs8sxrjxfjjc
• Most recent triggering transition: 1.11187.1.0 → 1.11847.5
• Companion service CoworkVMService (cowork-svc.exe)
• Reproduces on a fresh Windows install (not residual profile corruption)

Signature (identical to this issue)

Microsoft-Windows-AppModel-Runtime/Admin, every failed launch:

• 208: 0x80070020: Cannot create the process for package Claude_<ver>_x64__pzs8sxrjxfjjc ... [FinishPackageActivation]
• 215: 0x80070020: Cannot create the Desktop AppX container ... because an error was encountered converting the job.

Dialog: path in the title bar, body "Another program is currently using this file." claude.exe never spawns. Sign-out/login or reboot clears it every time.

NEW: a pre-update CoworkVMService mitigation does NOT prevent the wedge

The competing theory (#57221) is that the AutoStart CoworkVMService owns the package Job Object across the version transition, so neutralizing it before the update should help. I tested that directly:

Before clicking "Relaunch to update", as Administrator, with Claude still running:

1. Set CoworkVMService start type to Disabled (via SCM as NT AUTHORITY\SYSTEM, since the service DACL blocks Set-Service for Administrators)
2. Stop-Service CoworkVMService -Force
3. Killed cowork-svc.exe, parsecd, chrome-native-host
4. Verified no Claude/cowork processes remained (cold state)
5. Clicked "Relaunch to update", let it apply

Result: the post-update launch still wedged with the same 208/215 / 0x80070020, and a reboot was again required.

Since the service was disabled, stopped, and process-killed before the file swap, the "running service owns the Job Object" path is eliminated for this signature. That leaves the model described in this issue: the new version crashes during its first launch, kernel-side Silo/Job cleanup does not run, and the orphaned handle bound to the package family persists until the session is torn down (sign-out/reboot). The fix needs to be in the launch/crash path, not in service startup config.

Also ruled out on this machine (none prevented or recovered it)

Defender (real-time, BAFS, MAPS, sample submission, Tamper Protection all off); Smart App Control (Eval; CodeIntegrity/Operational empty during repro — no 3076/3077/3091/3092); SmartScreen for Apps (Off); ASR (none configured); Controlled Folder Access (Disabled); static file lock (File.Open FileShare.None succeeds, handle.exe finds no holders); Reset-AppxPackage; Add-AppxPackage -Register -ForceApplicationShutdown; restart of AppXSvc/ClipSVC/AppIDSvc/StateRepository/vmcompute; Explorer + RuntimeBroker + ApplicationFrameHost recycle; deleting the orphan prior-version WindowsApps folder; stopping CoworkVMService after the wedge.

Asks (same as OP, reinforced)

1. Guarantee Silo/Job cleanup when the launcher exits/crashes during startup, so a failed first launch after an update can't orphan a handle bound to the package family.
2. Provide a supported way to clear the orphaned handle without sign-out/reboot (or have activation detect and reset a stale Silo for the family before failing).
3. Fix the misleading "Another program is currently using this file" dialog — the failure is at the container/Silo layer, not a file lock.
4. Ship the chat-only fallback (#28231) — if CoworkVMService/the VM fails, launching chat-only would avoid the crash that appears to trigger the leak.

Happy to provide ETW captures (AppModel-Runtime, AppXDeploymentServer/Operational, Hyper-V-Compute-Operational) of a failed post-update launch on request.

Same failure on Windows 11 x64 (Claude_1.12603.1.0_x64__pzs8sxrjxfjjc), triggered by an MSIX auto-update rather than a crash, but the end state is identical to this report: orphaned Silo/Job → 0x80070020 in Microsoft-Windows-AppModel-Runtime/Admin (Event 215 "error encountered converting the job" + Event 208 "configuring runtime / LaunchProcess") → the process is created and added to the container, then the container is destroyed and the app dies before any window. Zero entries in ...\LocalCache\Roaming\Claude\Crashpad\reports, confirming it dies at the container layer, not in app code.

Confirming your finding that Add-AppxPackage -Register does NOT recover — it repairs the package registration (status → 0x0) but the leaked silo hives stay locked, so the app is still unlaunchable. (This is why the Add-AppxPackage -Register workaround in #59934 is insufficient for this signature.)

Re your ask #2 — a way to clear the orphaned handle without sign-out/reboot

This worked here. The leaked Silo surfaces as orphaned registry hives under \REGISTRY\WC\Silo<guid>... (visible in HKLM\SYSTEM\CurrentControlSet\Control\hivelist) that hold the package's SystemAppData\Helium\User.dat and UserClasses.dat open — CreateFile on them returns ERROR_SHARING_VIOLATION (32). Force-unloading just those hives releases the lock:

• For each Claude \REGISTRY\WC\Silo... entry: NtUnloadKey2(<OBJECT_ATTRIBUTES of the silo hive path>, REG_FORCE_UNLOAD).
• Elevated administrator gets 0xC0000022 STATUS_ACCESS_DENIED on these even with SeRestorePrivilege enabled — they must be unloaded as NT AUTHORITY\SYSTEM (e.g. via a one-shot scheduled task created with /RU SYSTEM /RL HIGHEST), with SeRestorePrivilege + SeBackupPrivilege enabled in the SYSTEM token.

After the unload: hivelist shows no Claude silos, the hive files open cleanly, and Claude Desktop launches normally via shell:AppsFolder\<PackageFamily>!Claude — no reboot, no sign-out, every other app left running. Verified: post-unload launch logged Created process ... for application Claude with no 0x80070020.

So the recovery that holds when re-register fails is: re-register (to fix the registration) + SYSTEM force-unload of the leaked \REGISTRY\WC\Silo... hives. Ideally activation should detect and reset a stale Silo for the package family before failing, as you suggest.

(Full writeup with the complete event-log signatures was filed separately; closing that as a duplicate of this issue.)

Still reproduces on the latest version — Claude Desktop 1.14271.0 (sideloaded MSIX)

Adding a fresh data point confirming this is not fixed. The signature is identical to the OP and it reproduces on every auto-update for me, including the most recent one (which postdates the closed duplicates #67911 / #59934 / #48003).

Environment

• OS: Windows 11 Pro 10.0.26200 (x64)
• Package: Claude_1.14271.0.0_x64__pzs8sxrjxfjjc (sideloaded MSIX, publisher "Anthropic, PBC")
• Updater self-reports: MSIX detected: windowsStore=true, appPathMatch=true, source=windowsStore
• Update applied: 1.13576.4.0 → 1.14271.0.0

Timeline (single auto-update, 2026-06-22, local time)

| Time | Source | Event |
|---|---|---|
| 11:50:43 | AppXDeploymentServer/Operational [400] | Add operation — new MSIX staged (Claude-c8f4d811….msix), old version still running |
| 12:20:03 | app logs\main.log | beforeQuitForUpdate handler fired, going down for update |
| 12:20:03 | AppXDeploymentServer/Operational [603] | Started deployment RegisterByPackageFamilyName … Claude_pzs8sxrjxfjjc and Options ForceApplicationShutdownOption |
| 12:20:35 | AppXDeploymentServer/Operational [400] / [613] | Register operation … Claude_1.14271.0.0 … finished successfully (Overall time: 31891 ms) — package update itself SUCCEEDS |
| 12:20:35–36 | AppModel-Runtime/Admin [215] / [208] | container creation FAILS (see below) — 0–1s after the Register succeeded |
| 12:20–13:11 | — | repeated failed launches; zero entries in …\LocalCache\Roaming\Claude\Crashpad\reports and no app main.log activity → dies at the container layer, not in app code |
| 13:11:04 | AppModel-Runtime/Admin [201] | after a full reboot: Created process … for application Claude_pzs8sxrjxfjjc!Claude → app launches normally as 1.14271.0 |

AppModel-Runtime/Admin failure signature (every failed launch)

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

(0x80070020 = ERROR_SHARING_VIOLATION)

Recurs every update. The exact same [215]/[208] 0x80070020 pair is present for the previous version too — package Claude_1.13576.4.0_x64__pzs8sxrjxfjjc on 2026-06-18 (Events 16:24:14 → 16:29:03, multiple failed retries before recovery).

Notable: the Register operation runs with ForceApplicationShutdownOption, so the old instance is force-killed and the new container is created almost immediately — consistent with the Job Object / Silo not having been released yet (the race described in this issue and #59934). Only a reboot/logoff has reliably recovered it on my machine; I have not yet attempted the SYSTEM \REGISTRY\WC\Silo… force-unload workaround from the thread above.

Confirming this on build Claude_1.14271.0.0_x64__pzs8sxrjxfjjc, Windows 11 Pro 26200. Adding a data point because
my case diverges from the reported recovery path in a way that may matter.

Key divergence: a full reboot did NOT recover for me. The issue body lists logoff/reboot as working recovery; in my
case it did not.

Sequence I went through:

1. Initial failure: app stopped launching after a crash on June 22. Saw the documented Event 215/208 with

0x80070020 initially.

1. Did a full Remove-AppxPackage + clean reinstall from the downloaded installer. This cleared the 215/208

sharing-violation errors entirely.

1. Rebooted to clear any orphaned Silo/Job handle.
2. After reboot, the app still fails to launch, but the signature changed. A launch attempt now produces ~1,300

Event 217 (Destroyed Desktop AppX container) entries in Microsoft-Windows-AppModel-Runtime/Admin within a single
second, all for this package, with zero Event 215/208 and zero sharing-violations. The container is created and
torn down in a tight loop until the app gives up.

Additional observations at this stage:

• No Crashpad dump is written.
• The package userData folders (LocalCache, LocalState, AppData under Local\Packages\Claude_pzs8sxrjxfjjc) are

created fresh but stay completely empty; the process dies at the earliest Electron bootstrap, before anything is
written.

• Controlled Folder Access is disabled and Windows Defender reports no detections, so neither is implicated.

So there appear to be at least two failure modes in this family: the orphaned-Silo variant that a reboot clears,
and a second state where the container create/destroy loop persists across a clean reinstall and reboot. Echoing
the request for a chat-only fallback when the Cowork container layer cannot initialize; the app is currently
unusable with no recovery path short of a downgrade.

Reproduced the SYSTEM hive-unload fix a second time on the next auto-update (now 1.15962.0.0). A few practical refinements for anyone trying it — these are the difference between "it worked" and "it silently did nothing":

• The silo GUIDs change on every incident — don't hardcode them. Enumerate HKLM\SYSTEM\CurrentControlSet\Control\hivelist: each value's name is the \REGISTRY\WC\Silo<guid>... key to unload, the data is the backing hive file. Unload the ones whose data path contains the Claude package (...\Packages\Claude_<pfn>\...Helium\... / ...\WindowsApps\Claude_<ver>\...).

• It must run as NT AUTHORITY\SYSTEM (elevated admin still gets 0xC0000022 ACCESS_DENIED even with SeRestorePrivilege+SeBackupPrivilege). A one-shot scheduled task with /RU SYSTEM /RL HIGHEST works — but on a laptop the task stays Status: Queued and silently never runs while on battery. AC power is required (a task-XML <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries> did not override this for me). Plug in first, then run.

• It can take two passes — some silos are momentarily in-use on the first unload (e.g. 8 → 2 left); the operation is idempotent, a second run clears the remainder to 0.

• Re-register isn't always required. This time the update self-registered cleanly (AppModel Runtime status for package Claude_... successfully updated to 0x0), so only the silo unload was needed — no Add-AppxPackage -Register at all. Worth checking the package's registration status first; if it's already 0x0, the leaked silos are the sole blocker.

Success signal is the silo count, not any log: after the unload hivelist shows zero Claude silos, User.dat/UserClasses.dat open cleanly (no ERROR_SHARING_VIOLATION), and shell:AppsFolder\<PFN>!Claude launches with Created process ... for application Claude and no 0x80070020 — again no reboot, no sign-out, every other app left running.

Adding another current x64 repro. I did not open a new issue because this issue matches the failure exactly.

Environment:

• OS: Windows 11 Pro 10.0.26200, 64-bit
• Claude Desktop package: Claude_1.17377.1.0_x64__pzs8sxrjxfjjc
• Get-AppxPackage Claude reports Status: Ok

Observed after upgrade from Claude_1.15962.1.0_x64__pzs8sxrjxfjjc to Claude_1.17377.1.0_x64__pzs8sxrjxfjjc:

• The package registration/upgrade completed successfully; AppXDeploymentServer logs show the old 1.15962 package was moved aside and 1.17377 registered successfully.
• Launching from the Start/App identity starts/restarts only CoworkVMService / cowork-svc.exe; no Claude.exe UI process survives.
• %APPDATA%\Claude\logs\main.log does not advance. The last normal entry remains from the prior update path: beforeQuitForUpdate handler fired on 2026-06-28.
• Microsoft-Windows-AppModel-Runtime/Admin repeats the same pair on every launch:
• Event ID 215: 0x80070020: Cannot create the Desktop AppX container for package Claude_1.17377.1.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.
• Event ID 208: 0x80070020: Cannot create the process for package Claude_1.17377.1.0_x64__pzs8sxrjxfjjc because an error was encountered while configuring runtime. [LaunchProcess]
• Stopping CoworkVMService cleanly does not recover launch.
• Direct launch of C:\Program Files\WindowsApps\Claude_1.17377.1.0_x64__pzs8sxrjxfjjc\app\Claude.exe fails with: The process cannot access the file because it is being used by another process.
• Windows Restart Manager queried directly against app\Claude.exe reports no owner: RmGetList result=0 needed=0 count=0 rebootReasons=0.
• The user-facing dialog is still the misleading Another program is currently using this file against the new Claude_1.17377.1.0... package path.

So this still reproduces on the current x64 MSIX package after a successful package upgrade and after CoworkVMService is stopped; it is not just a stale 1.15962 install or a visible userspace file-lock problem.

Follow-up on the Claude_1.17377.1.0_x64__pzs8sxrjxfjjc repro above: the no-reboot SYSTEM hive-unload recovery described in this thread did work here.

Recovery details:

• Enumerated HKLM\SYSTEM\CurrentControlSet\Control\hivelist and targeted only \REGISTRY\WC\Silo* hives whose backing path contained \Packages\Claude_pzs8sxrjxfjjc\.
• Ran the unload helper as NT AUTHORITY\SYSTEM with SeRestorePrivilege and SeBackupPrivilege enabled.
• Five Claude hives were found. Four unloaded on pass 1 with NtStatusHex: 0x00000000; one COM hive returned 0xC0000121 on pass 1 and then unloaded successfully on pass 2.
• Pass 3 found no targets remaining.
• After that, hivelist showed zero remaining Claude_pzs8sxrjxfjjc WC/Silo hives.
• Launching shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude then succeeded without logoff/reboot: AppModel-Runtime/Admin logged Event ID 201 Created process ... for application Claude_pzs8sxrjxfjjc!Claude, Claude.exe stayed alive, and %APPDATA%\Claude\logs\main.log advanced again.

Impact note, strongly stated: logoff/reboot must not be treated as an acceptable user recovery path for this. Users should not have to tear down an entire Windows session, lose active work, kill unrelated dev tools, break running terminals/processes, and burn time reconstructing state because Claude Desktop's MSIX/AppX update or launch path leaves the machine wedged. This is especially damaging for people running long-lived coding sessions, IDEs, terminals, browsers, local services, and other agent tools. A desktop app update failure should not make the only reliable official recovery "restart your computer." Anthropic needs to prevent this state or ship a supported no-reboot recovery path.

Adding a follow-up from the same Windows/MSIX failure class, now on Claude_1.18286.0.0_x64__pzs8sxrjxfjjc.

Environment:

• Windows build 26200, x64
• Failing package before recovery: Claude_1.18286.0.0_x64__pzs8sxrjxfjjc
• Get-AppxPackage Claude reported Status: Ok
• Start app identity before recovery: Claude_pzs8sxrjxfjjc!Claude
• CoworkVMService existed as WIN32_PACKAGED_PROCESS, AUTO_START, binary under C:\Program Files\WindowsApps\Claude_1.18286.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

Failure signature:

• Launching through Start/App identity did not leave a surviving Claude.exe UI process.
• Each launch attempt started or restarted only CoworkVMService / cowork-svc.exe.
• Microsoft-Windows-AppModel-Runtime/Admin repeated the same pair:
• Event ID 215: 0x80070020: Cannot create the Desktop AppX container for package Claude_1.18286.0.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.
• Event ID 208: 0x80070020: Cannot create the process for package Claude_1.18286.0.0_x64__pzs8sxrjxfjjc because an error was encountered while configuring runtime. [LaunchProcess] / [FinishPackageActivation]
• Directly invoking C:\Program Files\WindowsApps\Claude_1.18286.0.0_x64__pzs8sxrjxfjjc\app\claude.exe from PowerShell failed before app logging with Unknown error (0xc0070020).

Attempts that did not recover launch:

Stop-Service -Name CoworkVMService -Force
Add-AppxPackage -DisableDevelopmentMode -Register <InstallLocation>\AppxManifest.xml
winget repair --id Anthropic.Claude --source winget --exact --silent --force

After each of those, launch still recreated the packaged service and then failed again with Event ID 215/208 0x80070020.

Recovery that did work without logoff or reboot:

winget uninstall --id Anthropic.Claude --source winget --exact --silent --force
winget install --id Anthropic.Claude --source winget --exact --silent --force

Important detail: this did not appear to repair the MSIX/AppX state in place. It changed the installed Desktop distribution:

• Start app identity after reinstall: com.squirrel.AnthropicClaude.claude
• Running executable after reinstall: C:\Users\<user>\AppData\Local\AnthropicClaude\app-1.18286.0\claude.exe
• CoworkVMService was no longer installed (sc qc CoworkVMService returned service not found)
• claude.exe stayed alive and responsive after launch.
• No new Claude 0x80070020 AppModel failures appeared after the Squirrel install launch.

So for this 1.18286.0.0 incident, winget repair was insufficient, while uninstall/install through the current Anthropic.Claude winget manifest restored Desktop launch by moving off the failing MSIX/AppX packaged-service path. I am not treating this as a fix for the leaked MSIX silo/job state; it is a useful no-reboot recovery data point and may have feature-set implications because the packaged service is absent afterward.

<html>
<body>
<!--StartFragment--><html><head></head><body><hr>
<h1>Windows: Crash exit leaves stale AppContainer job (<code>Container_Claude_...</code>) held by <code>svchost.exe</code>, blocking relaunch with "Another program is currently using this file" — only reboot clears it</h1>
<p><strong>Version:</strong> Claude_1.20186.7.0 (Windows)</p>
<h2>What's wrong</h2>
<p>After Claude Desktop terminates unexpectedly (crash, not a normal close), attempting to reopen the app fails:</p>
<ol>
<li>
<p><code>cowork-svc.exe</code> spawns in Task Manager (~13.6 MB), then a popup appears: <code>Another program is currently using this file</code>, referencing <code>C:\Program Files\WindowsApps\Claude_1.20186.7.0_...</code> — main window never opens.</p>
<p><em>(attach screenshot here — the dialog you shared earlier)</em></p>
</li>
<li>
<p>On at least one occasion, a "Please wait a moment, we are updating the app" message appeared instead, then nothing further happened (no completion, no error, no retry).</p>
</li>
</ol>
<h2>Root cause (identified via Resource Monitor / Process Explorer)</h2>
<p>No visible Claude process holds the lock. Instead, <code>svchost.exe</code> (running <code>netsvcs -p</code>) holds a Job handle to <code>\Container_Claude_1.20186.0.0_x...</code> — the AppContainer job object for the packaged app. This job object survives the crash and is never released, blocking the next launch attempt from acquiring the package's file lock.</p>
<p>A related lead: <code>services.exe</code> holds multiple Semaphore handles named <code>DaxUseSemaphore_Claude_1.20186...</code> (tied to the Desktop Bridge / Desktop App Converter runtime used to run the packaged Win32 app). These may be contributing to, or be a symptom of, the same underlying teardown failure.</p>
<h2>Tested (all failed to resolve without reboot)</h2>
<ul>
<li>Manually killing <code>cowork-svc.exe</code> in Task Manager — no effect</li>
<li>Restarting the AppX Deployment service (<code>Restart-Service -Name AppXSvc -Force</code>) — no effect</li>
<li>Confirmed via <code>Get-AppxPackage -Name "Claude" | Select Name, PackageFullName, Status</code> that the package registration itself is healthy (<code>Status: Ok</code>) — not a corrupted registration issue</li>
<li>Killing the specific <code>svchost.exe</code> PID holding the <code>Container_Claude_...</code> job handle (via Resource Monitor) — Windows immediately respawned a new <code>svchost.exe</code> under a new PID to take over the same service group; the block persisted</li>
<li>Full system reboot → only fix that works</li>
</ul>
<h2>Confirmed underlying cause (Event Viewer + folder check)</h2>
<p>Windows Event Viewer shows Event ID 2562 from <code>Microsoft-Windows-AppXDeploymentServer/Operational</code>, logged around the time of a failed relaunch attempt:</p>
<pre><code>MSIXDeployment / windows.applicationData / DeleteMachineFolder
Package Claude_1.20186.0.0_x64__pzs8sxrjxfjjc removed machine folder
C:\ProgramData\Microsoft\Windows\AppRepository\Families\ApplicationData\Claude_pzs8sxrjxfjjc:
The system cannot find the path specified.
</code></pre>
<p>Manually verified afterward:</p>
<pre><code class="language-powershell">Test-Path "C:\ProgramData\Microsoft\Windows\AppRepository\Families\ApplicationData\Claude_pzs8sxrjxfjjc"

Returns: False

</code></pre>
<p>This folder is missing even outside the crash window (confirmed while the app was otherwise stuck/unable to launch), not just transiently during the failed relaunch. This means:</p>
<ul>
<li>On relaunch after a crash, Windows' AppX deployment service attempts an MSIX servicing operation that includes a <code>DeleteMachineFolder</code> step against this path.</li>
<li>That step fails immediately because the folder doesn't exist.</li>
<li>The deployment operation appears to error out mid-flight without rolling back cleanly, leaving the AppContainer job object (<code>Container_Claude_...</code>, see below) stuck in a "still in use" state under <code>svchost.exe</code>'s job tracking.</li>
<li>Because the underlying missing-folder condition is persistent (not cleared by reboot), this will recur on every subsequent crash until the app's data folder is properly repaired/recreated.</li>
</ul>
<h2>Timeline reconstructed from <code>C:\ProgramData\Claude\Logs\cowork-service.log</code></h2>
<p>The service log (not reviewed at the time of the original write-up) corroborates the crash/stuck-relaunch pattern with a precise, quantified timeline for one occurrence on 2026-07-13:</p>

Time | Preceded by clean stop? | Notes
-- | -- | --
(before 21:16) | — | Original unexpected app closure. Not visible in this log — cowork-svc.exe crashing doesn't log its own death.
21:16:01 | ✅ (stop at 21:16:00) | User manually stopped the service as a troubleshooting step, then restarted it — relaunch still fails.
21:16:34 | ❌ | First occurrence of the no-clean-stop signature.
21:19:11 | ❌ |  
21:19:16 | ✅ (stop at 21:19:12) |  
21:22:52 | ❌ |  
21:25:09 | ✅ (stop at 21:25:09) |  
21:25:40 | ❌ |  
21:26:54 | ✅ (stop at 21:26:53) |  
21:32:05 | ❌ |  
21:47:32 | ❌ |  
21:47:33 – 22:21:24 | — | 34-minute gap, nothing logged — likely the window spent on the workarounds listed above, before proceeding to a full reboot.
22:21:24 | ❌ (different cause — see below) | This attempt succeeded — app launched normally, matching "only reboot fixed it." No-stop here reflects the OS killing everything at reboot, not a repeat of the stuck-lock failure.

<p><strong>Net result:</strong> 7 of the 11 restarts during troubleshooting (21:16:34, 21:19:11, 21:22:52, 21:25:40, 21:32:05, 21:47:32, 22:21:24) show no clean stop logged beforehand. Of those, 6 (all but the final, post-reboot one) share the same mechanism: the previous attempt's <code>cowork-svc.exe</code> never registered a proper shutdown before the next attempt started. The 4 "clean stop" restarts (21:16:01, 21:19:16, 21:25:09, 21:26:54) are the moments something in between — a manual kill, or a Windows timeout — let it register a stop before the next attempt.</p>
<p>This is the more precise failure mode: it isn't just "the app crashed once, then relaunch fails" — it's "when the launch hits the file lock, the service itself doesn't shut down cleanly, so each retry piles a new attempt on top of a service that never cleanly exited from the last one." That's consistent with the AppContainer job staying alive in the background even though nothing appears to be running, and it's a stronger signal than a simple one-time crash: the failure to open <em>is itself</em> what prevents a clean stop, which is exactly what you'd expect if the stuck job/file-lock is blocking the shutdown path too, not just the startup path.</p>
<p>One log line present on every single start (both clean and crashed) is worth flagging separately in case it's relevant: <code>Warning: failed to open service for recovery config: Access is denied.</code> This appears consistently regardless of shutdown type and may be an unrelated SCM permission quirk — but it's worth Anthropic ruling out explicitly rather than assuming it's benign.</p>
<h2>Post-reboot contrast</h2>
<p>After rebooting, the app launched successfully. The <code>CoworkVMService</code> event logged on this successful start was simply "Claude VM Service starting" with a reference to detailed logs at <code>C:\ProgramData\Claude\Logs\cowork-service.log</code> — no folder-not-found or deployment error accompanied it. This is a clean contrast to the failed relaunch attempts, which specifically triggered the <code>DeleteMachineFolder</code> path-not-found error.</p>
<p>This strongly suggests a repair or reinstall (not just a reboot) is needed to permanently resolve this, since reboot only clears the immediate stuck job/lock state — it does not recreate the missing <code>ApplicationData</code> folder, so the same failure will repeat after the next crash.</p>
<h2>Why this matters</h2>
<p>Even directly targeting and killing the process holding the job handle doesn't release it — Windows simply reassigns the service group to a fresh <code>svchost.exe</code> instance rather than releasing the stale job object. This indicates the AppContainer job's state is tracked at a level that isn't cleared by process-level intervention, only by a full session/kernel reset (reboot).</p>
<p>The <code>cowork-service.log</code> timeline above sharpens this conclusion: the failure mode isn't just "the app crashed once, and relaunch happens to fail afterward." It's that <strong>the failed-launch path itself doesn't shut the service down cleanly</strong> — 6 of 7 no-clean-stop restarts occur specifically when retrying on top of the stuck file lock, not as isolated one-off crashes. That means the same stuck-lock condition that blocks startup is also preventing a clean stop, which is consistent with the AppContainer job never being released: the job stays alive in the background even though nothing user-visible appears to be running, so neither the next launch attempt nor the current instance's own shutdown can complete cleanly.</p>
<p>Sign-out was not tested as a lighter-weight alternative to reboot, since it also risks unsaved app state — but if it were confirmed to work, that would narrow the stale state to session-level rather than full boot-level. Untested here, but worth Anthropic checking as a possible faster user-facing recovery path if the underlying job can't be fixed to release cleanly on crash.</p>
<h2>Ask</h2>
<ul>
<li>The app (or its installer/updater) should ensure <code>C:\ProgramData\Microsoft\Windows\AppRepository\Families\ApplicationData\Claude_pzs8sxrjxfjjc</code> exists and is valid, and should tolerate/recreate it if missing, rather than letting the <code>DeleteMachineFolder</code> MSIX servicing step fail outright when the path is absent.</li>
<li>The AppX deployment operation triggered on relaunch should roll back cleanly if a step like <code>DeleteMachineFolder</code> fails, instead of leaving the AppContainer job object (<code>Container_Claude_...</code>) in a stuck "in use" state.</li>
<li>Would help to know if the failed-launch path skips releasing the AppContainer job object when it hits the stuck file lock, and whether that can be fixed so a clean job teardown happens even when launch fails (not just on a graceful exit). The service log shows 6 of 7 no-clean-stop restarts occurring specifically on retries against the stuck lock — i.e. the failure to open is itself preventing a clean shutdown, not just blocking startup. Worth checking whether <code>cowork-svc.exe</code> can be made to log (or attempt) cleanup even when a launch attempt fails partway through.</li>
<li>Is there a way to force-release the job/lock via a repair/reset routine (similar to <code>wsreset</code> for other AppX apps) without requiring a full OS reboot, once the missing-folder condition is fixed?</li>
<li>Worth investigating whether the <code>DaxUseSemaphore_Claude_...</code> semaphores held by <code>services.exe</code> are related or a separate leak.</li>
<li>Worth ruling out whether <code>Warning: failed to open service for recovery config: Access is denied.</code> (logged on every single service start, clean or crashed) is related or a separate, benign permission issue.</li>
</ul>
<h2>Suggested workaround for other affected users</h2>
<p>After the next unavoidable reboot, run a Repair (not just relaunch) via Settings → Apps → Installed apps → Claude → Advanced options → Repair, to attempt to recreate the missing <code>ApplicationData</code> folder. If Repair doesn't recreate it, a full uninstall/reinstall may be required — a plain reboot only clears the immediate stuck lock, it does not fix the underlying missing folder, so the same crash-triggered lock is expected to recur.</p>
<h2>Environment</h2>
<ul>
<li>OS: Windows 11 Home, build 10.0.26200</li>
<li>Claude Desktop version: 1.20186.7.0 (confirmed current via <code>Get-AppxPackage -Name "Claude"</code>)</li>
<li>Trigger: unexpected/crash shutdown of the app (not a normal close)</li>
<li>Confirmed via: Task Manager, Resource Monitor (Associated Handles), Process Explorer (Sysinternals), <code>C:\ProgramData\Claude\Logs\cowork-service.log</code></li>
</ul></body></html><!--EndFragment-->
</body>
</html>

+1 — we hit what looks like the same post-crash lockout, with extra data that may help.

Windows 11 Pro 26200, Claude Desktop (MSIX Claude_1.24012.9.0_x64__pzs8sxrjxfjjc). Timeline on 2026-07-27:

• App crashed 3 times in ~2h (every time while Claude Code sessions were running parallel subagents; Event Viewer shows Application Hang on conhost.exe before each crash).
• After the last crash the app refused to relaunch. In-place Repair failed near the end every time, Reset failed with "we cannot reset this app's data at this time" — matching the failed-workaround list in this issue. Only a full restart recovered it.
• Interesting extra signature: while the app was still alive, Microsoft-Windows-AppXDeploymentServer/Operational logged cascades of 404 ... 0x80073D02 (files in use), 8107 (package integrity validation) and 8104 (Trust Label, 0x80070057) — i.e. Windows was attempting deployment operations against the package while orphaned child processes still held package files open. The repair only succeeded during the restart window.

So from our side the sequence is: subagent process storm → app crash without cleanup → orphaned handles keep the package "in use" → Repair/Reset/relaunch all fail until session teardown. Consistent with the orphaned Silo/Job hypothesis here. Happy to provide Event Viewer exports.

Confirming another occurrence of the orphaned Silo/Job launch failure, as a follow-up to the GPU-crash → MSIX brick reports in #81840 / #81756.

Environment: Windows 11 Pro 26200, Claude Desktop (MSIX). 5th GPU-crash → Modified, NeedsRemediation brick on this machine since 2026-07-28.

Timeline (2026-08-04, JST):

1. 14:35:10 — GPU process crashed (GPU process gone: reason: 'crashed' in main.log, app version 1.24012.9.0). Package immediately became Modified, NeedsRemediation.
2. Repaired via over-the-top Add-AppxPackage -ForceUpdateFromAnyVersion -ForceApplicationShutdown with the latest official MSIX → package updated to 1.24012.11.0, Status: Ok.
3. Every subsequent activation attempt fails silently (no window, no main.log write). Event log shows exactly the pattern described in this issue:

• Microsoft-Windows-AppModel-Runtime/Admin EventID 215: 0x80070020: ... error during job conversion, cannot create Desktop AppX container for package Claude_1.24012.11.0_x64__pzs8sxrjxfjjc (twice per attempt)
• EventID 208: 0x80070020: ... cannot create process [LaunchProcess]
• Interestingly, a first container is created successfully and the packaged service process gets added to it; the failure hits the next container conversion.

Ruled out: the packaged Windows service (CoworkVMService / cowork-svc.exe). From an elevated shell I stopped the service, verified the process was gone, and retried activation — identical 0x80070020 job-conversion failure with zero package processes running. So this is not a process/file lock that can be cleared from user land, consistent with the orphaned Silo/Job diagnosis in the OP.

Will follow up to confirm whether logoff/reboot restores activation (expected per this issue).

Follow-up to my previous report above.

The 2026-08-04 occurrence did recover after a full Windows reboot: Windows booted at 21:47 JST and Claude Desktop 1.24012.11.0 launched successfully at 21:49.

However, the exact Event ID 215/208 + 0x80070020 launch failure recurred on 2026-08-05 during the normal auto-update path from 1.24012.11.0 to 1.25927.0.0.

Importantly, this recurrence was not preceded by a GPU crash.

Environment

• Windows 11 Pro 25H2, build 26200.8875, x64
• Install type: Microsoft Store/MSIX package
• Package family: Claude_pzs8sxrjxfjjc
• Package full name after update: Claude_1.25927.0.0_x64__pzs8sxrjxfjjc
• This is not the Squirrel / standalone EXE build
• Update: 1.24012.11.0 → 1.25927.0.0
• Locale: ja-JP

The registered installation path is under:

C:\Program Files\WindowsApps\Claude_1.25927.0.0_x64__pzs8sxrjxfjjc

Timeline (2026-08-05, JST)

• 07:49:43 — The updater starts an AppX Add using DeferRegistrationWhenPackagesAreInUse.
• 07:49:56 — AppX Deployment Event 658 reports that Claude_1.24012.11.0 is still running, so Claude_1.25927.0.0 is marked for deferred registration.
• 11:34:22 — main.log records:

``
beforeQuitForUpdate handler fired, going down for update
``

• 11:34:53 — AppX Event 9648 reports successful TerminateSingleService for the old CoworkVMService.
• At the same time, C:\ProgramData\Claude\Logs\cowork-service.log records:

``
Graceful shutdown failed, forcing termination:
HcsShutdownComputeSystem failed with HRESULT 0x0/0x80070032
``

• 11:34:54 — AppX Event 400 reports that registration of Claude_1.25927.0.0 completed successfully.
• Immediately afterward, AppModel-Runtime logs Event ID 215 twice and Event ID 208 once with 0x80070020 during Desktop AppX container/job conversion.
• 11:35:30 — Automatic RepairAppRegistration terminates and reinstalls CoworkVMService, then again reports Event 400 success.
• 11:35:31 — The same Event ID 215/208 + 0x80070020 sequence repeats.

Current state

• Get-AppxPackage -Name Claude: Version 1.25927.0.0, Status Ok
• CoworkVMService: Running / Automatic, using the new 1.25927.0.0 package path
• No Claude GUI process survives
• hcsdiag list shows no remaining compute system
• A chrome-native-host.exe process from the previous version remains alive and its copied binary hash differs from the current package binary, but this appears separate from the AppX job-conversion failure

This recurrence appears to connect the updater/service shutdown problem discussed in #83968 and #84005 with the orphaned Silo/Job activation failure in this issue. Deployment and service replacement both report success, but the user-session AppX activation state is left unusable.

The current occurrence has not yet been cleared by logoff/reboot. I will update again after confirming the recovery result.

Additional diagnostic data confirming the leaked-silo theory, and pinpointing the specific kernel object that stays pinned.

Environment: Claude Desktop 1.25927.0.0 (MSIX, Claude_pzs8sxrjxfjjc), Windows 11 26200.8893, x64, Fast Startup disabled.

Repro on this machine: the app launches successfully exactly once per boot. After it exits, every subsequent launch fails with "Another program is currently using this file" and the same events you cited:

Microsoft-Windows-AppModel-Runtime/Admin
215  0x80070020: Cannot create the Desktop AppX container for package
     Claude_1.25927.0.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.
208  0x80070020: Cannot create the process for package ... while configuring runtime. [LaunchProcess]

The pinned object is the package's Helium registry hives

The leaked silo shows up as a measurable, still-mounted pair of package registry hives:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\UserClasses.dat

Both are locked. Restart Manager (RmGetList) attributes the handles to:

PID 4   | System
PID 180 | Registry

Because the holders are the kernel and the Registry process, no amount of killing user-mode processes can release them — which I think explains a lot of the confusion across the duplicate reports.

Control experiment: locked hives ⟺ app running, Claude is the sole exception

I tested User.dat lock state across all 25 installed MSIX packages on this machine and cross-referenced whether each app was running:

| Result | Count | Examples |
|---|---|---|
| Locked and running | 5 | MSTeams, WhatsApp, WindowsTerminal, WidgetsPlatformRuntime, Client.WebExperience |
| Unlocked and not running | 19 | OpenAI.Codex, Copilot, Paint, Notepad, Photos, ScreenSketch, … |
| Locked and NOT running | 1 | Claude |

The invariant holds perfectly for every package except Claude. Its hives are stranded — mounted with no process to justify them.

No process is running in the Claude container

Enumerating by package identity rather than by path — GetPackageFamilyName() on every PID, since Get-Process cannot read .Path for protected packaged processes — returns zero processes in the Claude container, while correctly listing 60+ for Teams, Outlook, WhatsApp, etc.

This rules out the "orphaned packaged child process pins the container" explanation offered in #73107, #84792 and #77379, at least for this reproduction. There is nothing left to kill; only the hive mount survives.

Verified non-fixes

All performed elevated, with the app not running, re-testing hive lock state after each:

| Attempt | Hives released? |
|---|---|
| Stop-Service CoworkVMService -Force (confirmed Stopped, process gone) | No |
| Restart-Service AppXSvc -Force | No |
| Add-AppxPackage -DisableDevelopmentMode -Register ...\AppxManifest.xml (reported success) | No |
| Full reboot | Yes |

Note this contradicts the suggestion in #49655 that the Helium hive locks are held by cowork-svc.exe: I stopped that service completely and confirmed the process was gone, and the hives stayed locked. cowork-svc.exe is not the holder — the kernel is.

One-line detection

Useful for anyone triaging this, and as a post-fix regression check — with Claude not running, this should print UNLOCKED:

$f = "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat"
try { $s=[IO.File]::Open($f,'Open','ReadWrite','None'); "UNLOCKED"; $s.Close() } catch { "LOCKED - relaunch will fail" }

Red herrings ruled out on this machine

In case they're absorbing triage time elsewhere: package registration status is Ok; ACLs on the package folder are byte-for-byte the same shape as a healthy package (compared against MSTeams); claude.exe itself is not locked (opens cleanly even with FileShare.None); AppxSignature and declared dependencies are fine; Defender has zero detections and no relevant ASR/CFA blocks; and the Code Integrity was unable to load ...\AppxMetadata\CodeIntegrity.cat (0xC000003A) warnings are benign — the OpenAI Codex package logs them too and launches fine, since directly-distributed MSIX packages don't ship that catalog.

Also worth flagging: once the app is in this state it writes nothing to %APPDATA%\Claude\logs\main.log — the last entry is from the final successful launch. Anyone relying on the app's own logs will see no evidence at all; the signal is only in Microsoft-Windows-AppModel-Runtime/Admin.

Ask

Whatever cleans up the silo on exit isn't unmounting these two hives. If teardown can't be made reliable, an explicit unmount (or a self-heal that detects the stranded hives at launch and clears them) would turn a reboot-per-session bug into a non-issue.

3rd occurrence on this machine in 9 days — this time captured end-to-end with event logs: deferred-registration update + slow old-app shutdown → post-update relaunch hits 0x80070020, and the condition then persists (orphaned Job/Silo)

Follow-up to my 2026-08-04 comment. Environment: Windows 11 Pro 25H2 (build 26200), Claude Desktop MSIX updating 1.26832.0.0 → 1.28929.0.0.

Timeline (JST, 2026-08-12)

1. 08:58:36 — Auto-updater staged 1.28929 (Add operation with DeferRegistrationWhenPackagesAreInUse, AppXDeploymentServer Event 603; source downloads.claude.ai). At 08:58:46, Events 638/658: "package could not be updated because the affected app is running" → marked for deferred registration. Correct behavior so far; 1.26832 kept running all day.
2. 17:28:32 — User clicked restart-to-update. main.log: beforeQuitForUpdate handler fired, going down for update. Simultaneously the deferred Register ran (RegisterByPackageFamilyName, ForceApplicationShutdownOption 0).
3. 17:28:32 → 17:29:03 — The old Electron instance took ~31 seconds to fully exit (10 processes, ~2.2 GB RSS; main.log was still writing at 17:28:50). The old version's Desktop AppX container {C8D22D79-…} was destroyed at 17:29:03 (Event 217), CoworkVMService stopped.
4. 17:29:04 — Auto-relaunch of 1.28929, ~1 s after teardown: AppModel-Runtime Event 215 ×2 (0x80070020: … error converting the job — container creation failed) then Event 208 (LaunchProcess failed). The app never reappeared; no further main.log writes.
5. 17:29:05 — Nuance worth noting: a fresh container {99AEB409} was created successfully and cowork-svc.exe (PID 70148) was added to it ("Service ready" in cowork-service.log). So container creation is not blocked wholesale — it is the app's launch that stays broken.
6. 17:39:48 — Manual relaunch via shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude, ~11 minutes later: identical Event 215 ×2 + Event 208 with 0x80070020. So this is not a one-shot race; once hit, the failure persists exactly as described in the OP (orphaned Silo/Job, per-user-session), until sign-out/reboot.

Reading of the data

The deferred-registration mechanism itself worked as designed. The failure is in the post-update auto-relaunch racing the teardown of the old version's AppX container job: a heavy Electron instance can take tens of seconds to exit, and the relaunch fired ~1 second after the old container was destroyed, hitting the job-conversion sharing violation. Once that first launch fails, the kernel is left in the known orphaned-Job/Silo state that only sign-out or reboot clears — so a single lost race bricks the app for the rest of the user session.

Suggestion

After beforeQuitForUpdate, the updater/relaunch step could wait for the old package's Desktop AppX container to be fully destroyed (or retry the launch with backoff when hitting 0x80070020) instead of launching immediately after teardown.

History on this machine

• 2026-08-04 — after a GPU crash (my earlier comment above)
• 2026-08-07 — after update to 1.26832 (restart-to-update flow)
• 2026-08-12 — this report, update to 1.28929 (restart-to-update flow)

Two of the three were triggered by the restart-to-update flow. Likely related: #83932 (auto-update deploying into running claude.exe), #48003 (same 0x80070020 after update).

Independent confirmation on Claude Desktop 1.30096.1.0: five orphaned WC/Silo hives and successful no-reboot recovery

Environment

• Windows 11 Home, build 26200, x64
• Claude Desktop update: 1.28929.0.0 to 1.30096.1.0
• Package family: Claude_pzs8sxrjxfjjc
• This failure has occurred after every Claude Desktop update on this machine, not just this version.

Failure

After the update, launching Claude displayed:

Another program is currently using this file.

Windows reported that the Claude package status was Ok, but AppModel-Runtime recorded:

• Event 215: Desktop AppX container creation failed while converting the job, error 0x80070020.
• Event 208: process activation failed while configuring the runtime, error 0x80070020.

Automatic package re-registration and the Windows Repair operation did not resolve the failure.

Important distinction from a normal lingering-process problem

• CoworkVMService was stopped with PID 0.
• No Claude.exe or cowork-svc.exe processes remained.
• No vmwp.exe or vmmem.exe process was present.
• Stopping CoworkVMService and killing Claude-related processes did not restore launching.
• Restarting the shared Hyper-V compute service was neither necessary nor appropriate.

Despite there being no remaining Claude process, the Windows hivelist contained five Claude-specific registry hives under \REGISTRY\WC\Silo.

These consisted of:

• One software hive
• One user_sid hive backed by %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat
• One user_classes hive backed by %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\UserClasses.dat
• Two COM hives

Both User.dat and UserClasses.dat remained exclusively locked. This appears to be an orphaned AppX silo or container state rather than a Claude executable file being used by another ordinary process.

No-reboot recovery

Using the community recovery approach already discussed in this issue, a narrowly restricted helper was run as NT AUTHORITY\SYSTEM. It enabled only the required backup and restore privileges and used NtUnloadKey2 with REG_FORCE_UNLOAD.

Targets were enumerated dynamically. A hive was eligible only when:

• Its native name began with \REGISTRY\WC\Silo
• Its backing path contained Claude_pzs8sxrjxfjjc or the Claude WindowsApps package
• No Claude or Cowork process was running

No GUIDs, usernames, SIDs, or profile paths were hardcoded.

Result

• Claude silo hive count changed from five to zero.
• User.dat and UserClasses.dat became accessible again.
• No restart or sign-out was required.
• The Claude package remained in Status Ok.
• Claude then launched through its registered application identity.
• The complete Claude window rendered normally.
• The expected Claude process group remained stable after launch.
• AppModel-Runtime recorded a successful Event 201.
• No new Event 208 or 215 was generated.

This recovery method is experimental and community-derived. It should not be treated as a general-purpose registry cleanup operation. Killing System, Registry, or vmcompute would be unsafe and was not done.

The recovery result strongly suggests that the update or immediate post-update relaunch can leave the old Desktop AppX container's WC/Silo hives mounted after its user-mode processes have exited.

Could Anthropic please investigate:

1. Waiting for complete teardown of the previous AppX container before relaunching the updated package.
2. Detecting and safely recovering Claude-owned orphaned silo state.
3. Providing a supported self-repair operation for this condition.
4. Replacing the misleading "another program is using this file" message with an error that identifies the failed AppX container stage.

I can provide sanitised diagnostics or the restricted helper source privately if a maintainer needs them.

Confirming this on Windows 11 Pro 10.0.26200, and I have four data points that I don't think are in the thread yet. One of them identifies which container is the orphan, which may point straight at the missing teardown.

1. The trigger was a clean quit-for-update, not a crash

The issue describes the orphan arising after a crash. Mine arose from a completely orderly shutdown. %APPDATA%\Claude\logs\main.log ends with a textbook graceful Electron quit — no exception, no renderer/GPU crash, no truncation:

2026-08-13 22:29:29 [info] [stealth-update] Triggering stealth update after idle timeout
2026-08-13 22:29:29 [info] [stealth-relaunch] Saved z-order anchor: 0x30926
2026-08-13 22:29:29 [info] [stealth-relaunch] Saved navigation history (13 entries, active=12)
2026-08-13 22:29:29 [info] [popout-restore] Saving 0 session popout(s) for next launch
2026-08-13 22:29:29 [info] [remote-tools-device] close
2026-08-13 22:29:29 [info] beforeQuitForUpdate handler fired, going down for update
2026-08-13 22:29:29 [info] Windows session ending (close-app) - quitting the app
2026-08-13 22:29:29 [info] [EventLogging] Flushing 9 events
2026-08-13 22:29:32 [info] [process-memory] trigger=interval tree_rss_sum=2226MB

The log then simply ends because the process exited on purpose. 33 seconds later (22:30:02) the first 0x80070020 appears, and the app never launched again. Greps across all log rotations for unhandled, renderer/GPU crash markers, quitAndInstall, EPERM, sharing violation, singleton return nothing anywhere near the incident.

The same beforeQuitForUpdate flow had succeeded 18 hours earlier on the previous build: 2026-08-12 04:30:38 beforeQuitForUpdate → 04:31:09 Starting app { appVersion: '1.28929.0' }, a 31-second quit-and-relaunch.

So the orphan is not exclusive to the crash path — a normal stealth-update package swap reproduces it. That widens the repro considerably.

2. The orphaned container belongs to the previous package version — probably the key detail

This is the part I haven't seen reported. At logoff, Windows logs the orphan being destroyed and names it:

Microsoft-Windows-AppModel-Runtime/Admin
08:21:09.657  id=217  Destroyed Desktop AppX container {B1E5026D-96CD-…}
                      for package Claude_1.28929.0.0_x64__pzs8sxrjxfjjc

1.28929.0.0 is the OLD build. Its package folder had been removed from C:\Program Files\WindowsApps\ during the 8/13 19:49 update — 34 hours earlier. The container object outlived its own package, its processes, and the entire update.

The container GUID epochs make the age visible. The orphan is {B1E5026D-96CD-…}; every container created after the recovery is {2529xxxx-989D-…} / {BC1Bxxxx-987B-…}. Different epoch, consistent with an object created before the swap and never released.

65 seconds after the orphan died, the launch that had failed on every attempt for 34 hours (20 × Event 215 — it fires twice per attempt, so ~10 attempts) succeeded on the first try:

08:22:14.225  id=210  Created Desktop AppX container {2529BC3C-989D-…} for Claude_1.30096.1.0…
08:22:14.225  id=211  Added process 19800 to container 2529bc3c-…
08:22:14.227  id=201  Created process 19800 for application Claude_pzs8sxrjxfjjc!Claude   [LaunchProcess]

Reading: because the package family name (Claude_pzs8sxrjxfjjc) is shared across versions, the outgoing build's container holds the family's container slot. The incoming build can never convert its own job to a silo, so every activation returns ERROR_SHARING_VIOLATION until the session dies. If that's right, the bug is a missing container teardown on the outgoing version during a package swap, not anything in the incoming build's startup.

3. Version boundary (the report's "Last Working Version" field is blank — here's mine)

Every Event 215 in my entire retained AppModel-Runtime/Admin log (1,569 records) belongs to one build:

| Version | Installed | Event-215 failures |
|---|---|---|
| 1.26832.0.0 | 8/06 | 0 |
| 1.28929.0.0 | 8/12 | 0 — a true zero, inside the retention window |
| 1.30096.0.0 | 8/13 16:18 | 0 (superseded 3h later, never activated) |
| 1.30096.1.0 | 8/13 19:49 | all 20 |

Failures began at 1.30096.1.0's first activation attempt, ~2h40m after install. Last known good: 1.28929.0.0. Also worth noting: 20 of 20 Event-215s on this machine are Claude — no other packaged app has ever hit "converting the job" here, so this isn't a general AppX-subsystem fault on my box.

4. cowork-svc.exe can be ruled out — there's a clean control

I saw #57221 attribute this to CoworkVMService claiming the Job Object. On this machine that's not it, and the recovery produced an unusually clean natural experiment.

First, direct test — with the service stopped and zero package processes alive, and the service's own container confirmed destroyed:

Stop-Service CoworkVMService -Force  →  Stopped
package processes alive: 0
07:34:10.240  id=217  Destroyed container {BC1B42E8-987B-…} for Claude_1.30096.1.0…
07:34:12.731  id=215  ERROR 0x80070020 … converting the job          ← still fails
07:34:13.119  id=210  Created container {2529A219-989D-…}            ← service only restarts AFTER

Second, and better: cowork-svc.exe runs in session 0, which a logoff does not touch. Across the recovery it was the same process instance — same PID, created 07:34:13 — running unchanged during every failure and during the 08:22:14 success. One variable changed between failure and success (the session, and with it the orphaned container), and the service wasn't it.

Invoke-CommandInDesktopPackage — a different activation path entirely — fails identically, which places the fault in container creation rather than in any launcher.

Two things that may save other people time

• Windows already auto-repairs the registration on every failed launch, so manual repair is a dead end. Each 215/208 is followed within ~20–50 ms by 603 RegisterByPackageFullName … RepairAppRegistrationOption → 649 ACLs repaired successfully … Register next time should succeed → 400 finished successfully. It ran ~11 times on my machine and never helped. Anyone matching those register events to the failures should note the millisecond ordering: the register follows the error and is a reaction to it, not a cause.
• Logoff/login is sufficient; a reboot is not required. My uptime was continuous at 2d 08:09 across the recovery — the package was never reinstalled, re-registered, or repaired, and it came back on the already-installed 1.30096.1.0.

Suggested repro

1. Run build N. Let a stealth update to build N+1 stage and apply via the idle-timeout path (beforeQuitForUpdate). No crash needed.
2. After the swap, launch the app.
3. If it fails, check Microsoft-Windows-AppModel-Runtime/Admin — then log off and inspect the Event 217 at logoff and read which package version the destroyed container names. On my machine it named build N, not N+1.

Environment

OS                : Windows 11 Pro 10.0.26200
Package           : Claude_1.30096.1.0_x64__pzs8sxrjxfjjc  (SignatureKind: Developer, sideloaded MSIX)
Last known good   : 1.28929.0.0
Failure window    : 2026-08-13 22:30:02 → 2026-08-15 07:40:29 (20 × Event 215, no reboot in window)
Recovered         : 2026-08-15 08:22:14, by logoff/login only
Packaged service  : CoworkVMService (WIN32_PACKAGED_PROCESS, AUTO_START, LocalSystem, session 0)

Happy to pull any further logs if useful — I still have the full deployment and runtime traces from the failure window.

Follow-up with a contrast case from the same machine ~2 hours later: an update swap that went correctly. Since this bug is intermittent, a clean swap sitting next to a failed one on identical hardware may be more useful than another failure report.

A successful swap, same machine, same day

1.30096.5.0 staged while I was on 1.30096.1.0, and Windows deferred it correctly:

638  Packages were not updated because affected apps are still running.
     Running apps: {Claude_pzs8sxrjxfjjc!Claude}
658  Marking package {Claude_1.30096.5.0…} for deferred registration
     because {Claude_1.30096.1.0…} [is still running]

I then closed the app by hand and reopened it. The swap applied and the new build launched first try:

08:33:30.528  id=217  Destroyed Desktop AppX container {2529BC3C-989D-…} for Claude_1.30096.1.0
08:33:30.536  id=217  Destroyed Desktop AppX container {2529A219-989D-…} for Claude_1.30096.1.0
08:33:30.707  id=42   Successfully updated AppContainer Claude_pzs8sxrjxfjjc
08:33:31.073  id=68   Claude_1.30096.5.0 status → 0x0 (previous = 0x80000)
08:33:31.183  id=210  Created Desktop AppX container {81D4CC05-98A4-…} for Claude_1.30096.5.0
08:33:31.228  id=201  Created process 38972 for Claude_pzs8sxrjxfjjc!Claude   [LaunchProcess]

Both outgoing-version containers were destroyed before the new one was created — precisely the teardown that did not happen on 8/13. Event 215 count unchanged at 20; the old package folder was removed from WindowsApps cleanly.

The difference — a lead, not a finding

| When | Quit path | Result |
|---|---|---|
| 8/13 22:29 | [stealth-update] Triggering stealth update after idle timeout — app quit itself while idle | container leaked |
| 8/15 08:33 | user closed the window by hand | clean teardown, swap applied, launched |

That points at the idle-timeout stealth-update path possibly not fully unwinding the container when nobody is at the keyboard.

Counter-evidence, so nobody over-reads this: my 8/12 04:30 swap was also a stealth beforeQuitForUpdate quit and it succeeded (04:31:09 Starting app { appVersion: '1.28929.0' }). So it is not "stealth always leaks" — it stays intermittent, and this is n=1 on the manual path. Treat it as a place to look, not a conclusion.

Net for anyone hitting this

The logoff recovery held. After it, a normal close-and-reopen and a full package swap both worked with no reboot, no reinstall, no repair, and no re-registration — the machine has now been up continuously for 2d 08h across the whole failure-and-recovery cycle.

If someone can reproduce on demand, the highest-value artifact would be the Event 217 at logoff naming which package version the surviving container belongs to. On my machine it named the outgoing build, which is what makes a missed teardown on the old container the most likely culprit.

Fresh occurrence today, updating 1.30096.5 to 1.32352.1.0. That starts from the build @HarvestEdge's successful swap landed on in their 8/15 contrast case, so the next swap from the same build failed here. I had written a much longer comment before reading this thread properly, then found most of it was already above, so I have cut it to the one thing I could not find anywhere here: a logged failure on the outgoing package during the swap, which looks like direct evidence for @HarvestEdge's missing-teardown theory.

Environment: Windows 11 Pro 10.0.26200, x64, MSIX Claude_pzs8sxrjxfjjc, SignatureKind Developer. Update 18 Aug 2026, clean beforeQuitForUpdate quit, no crash.

The outgoing package's runtime status transition fails with ACCESS_DENIED

@HarvestEdge's reading is that the outgoing build's container holds the family's container slot and is never torn down, so the incoming build can never convert its job. On my machine there is an event that shows the outgoing package failing to complete its state transition at exactly that moment. Microsoft-Windows-AppModel-Runtime/Admin, in order:

11:14:47  68   AppModel Runtime status for package Claude_1.30096.5.0 ... updated to 0x280000 (previous 0x200000)
11:14:47  217  Destroyed Desktop AppX container {DED5E10B-...} for package Claude_1.30096.5.0
11:14:47  67   Failed with 0x5 modifying AppModel Runtime status for package
               Claude_1.30096.5.0_x64__pzs8sxrjxfjjc (current status = 0x280000, desired status = 0x480000)
11:14:47  42   Successfully updated AppContainer Claude_pzs8sxrjxfjjc.
11:14:48  215  0x80070020: Cannot create the Desktop AppX container for package Claude_1.32352.1.0 ...

Event 67 with 0x5 is ACCESS_DENIED, it is the only failure logged against the outgoing package during the handover, and it lands one second before the first 0x80070020 on the incoming one. The outgoing package never reaches 0x480000.

I grepped the whole thread and could not find event 67, 0x280000 or 0x480000 mentioned by anyone, so flagging it in case it is useful. If the missing teardown is the bug, this looks like the moment it fails rather than an after-effect. @HarvestEdge saw the same thing from the other end, with the Event 217 at logoff naming the old build. Two views of one incomplete retirement, possibly.

For the record on my machine the container destroy at 11:14:47 did fire for the old package, so the object was not simply left undestroyed. Something in the status transition after it still failed.

Minor detail on the CoworkVMService question

@HarvestEdge's control experiment above (service stopped, zero package processes, launch still fails, service restarts only after the 215) is more rigorous than anything I ran, and my data is consistent with it rather than with the service being the blocker. Adding one small piece since the "just stop the service" advice keeps circulating from #57221, #76357 and #61635:

> sc.exe qfailure CoworkVMService
SERVICE_NAME: CoworkVMService
        RESET_PERIOD (in seconds)    : 0
        REBOOT_MESSAGE               :
        COMMAND_LINE                 :

No recovery actions configured, so when people report the service coming back seconds after they stop it, that is not the service restarting itself, it is activation starting it. I confirmed three of the cowork-svc.exe PIDs in my event 211 lines against Win32_Process creation times, and each was a brand new process created in the same second as its activation attempt: 17832 at 11:15:28, 19800 at 11:24:21, 8348 at 11:26:12. So stopping it beforehand cannot work on the launch path, which matches the ordering @HarvestEdge measured.

I also confirmed Set-Service CoworkVMService -StartupType Manual returns Access denied from an elevated prompt, same as the sc.exe config failure reported in #57371. There is no user-side mitigation available through the service.

Other details from my incident

• Between failed attempts, (Get-CimInstance Win32_Process | Where-Object { $_.ExecutablePath -like '*WindowsApps*Claude*' }).Count returned 0, and Get-AppxPackage -Name Claude reported 1.32352.1.0 with Status: Ok. Deployment succeeded, only activation was broken. Same as several reports above.
• The relaunch race is visible in main.log, if it helps confirm labolabo's 8/12 timeline: 11:14:17 beforeQuitForUpdate handler fired, then 11:14:27 Starting app { appVersion: '1.30096.5' } followed immediately by Not main instance, returning early from app ready. The relaunch fired ten seconds after the quit handler and still found the old instance alive.
• Every activation between 11:14 and 11:26 failed identically. I recovered with a reboot because I had not read this thread yet and did not know the SYSTEM hive-unload from @Ciki and @adpena, or that logoff alone is enough per @HarvestEdge. So no new recovery data from me, just confirmation that the failure is still present on 1.32352.1.0.

On the user experience side

I want to add support to the point @adpena made above, because I do not think it is a side issue.

The practical effect of this bug is that updating Claude Desktop has become something to avoid. That is a strange position to be in with a desktop app. On this machine an update has a meaningful chance of ending in an app that will not start, and until you find this thread the only visible information is a dialog naming a file, which points nowhere near the actual problem. The recoveries that work are a session logoff, a reboot, or force-unloading kernel registry hives as SYSTEM. None of those are reasonable things to ask a user to do, and the first two mean tearing down everything else you had open.

For anyone running long sessions, terminals, IDEs, local services or agent tooling, the cost of a failed update is not the app, it is the whole working session. So the rational response is to defer updates, which then leaves people on older builds. That seems like the opposite of what anyone wants, and it is worth weighing when this gets prioritised. A supported no-reboot recovery, or an updater that verifies the app actually launches before declaring the swap done, would change the calculation a lot.

Happy to pull more logs from this incident if any of the above is worth chasing. I still have the full AppModel-Runtime and AppXDeploymentServer traces for the failure window.

Consolidated index of related reports

Since I went looking anyway: below is every report of this bug and its immediate neighbours that I could find, with state as of 18 Aug 2026. Some are already linked individually in comments above, but not in one place, and about a third of them have never been linked here at all. The grouping is my reading of the signatures rather than anything authoritative, so corrections welcome.

Same activation failure as this issue (Event 215/208, 0x80070020, orphaned container or silo, recovered by logoff, reboot, or the SYSTEM hive unload described above):

• #53247 this issue
• #73107 (open) will not launch after package upgrade
• #76357 (open, 23 comments) fails on every update, has repro
• #77379 (open) crash exit leaves a stale Container_Claude_... job held by svchost.exe
• #84792 (open) auto-update leaves the app unlaunchable, "error converting the job"
• #87607 (open, filed today) launch blocked by leaked Cowork VM file handles, on 1.32352.0.0
• #48003 (closed, duplicate) same 215/208 and 0x80070020 signature
• #51847 (closed, duplicate) "Another program is currently using this file (AFTER UPDATE)"
• #81756 (closed, duplicate) orphaned cowork-svc.exe locks the package
• #59934 (closed, not planned) AppContainer job race on mid-session auto-update
• #67911 (closed, not planned) every MSIX auto-update leaks a container silo
• #61635 (closed, not planned) ARM64, identifies the job held by the AppInfo service

Deployment side, where the update or install fails rather than the launch (0x80073CF6, 0x80073CF9, 0x80073D02, 0x80073D28):

• #49655 (open, 20 comments) identifies the Helium hive locks, the same kernel-level lock discussed in this thread, on the deployment path
• #87610 (open, filed today) CoworkVMService blocks the update, leaving Modified, NeedsRemediation; independently reports the same Set-Service and sc.exe config access-denied result I hit, and attributes the service DACL to TrustedInstaller
• #83932 (open) update deploys into a running claude.exe and cowork-svc.exe
• #83968 (open) auto-update never stops the old package
• #84005 (open) CoworkVMService locks its own file
• #46179 (closed) file lock plus a stuck WindowsApps\Deleted, suggests moving to winget
• #51132 (closed) package stuck in Servicing and Staged after forced removal attempts, worth reading before escalating
• #57221 (closed) the clearest writeup of the WIN32_PACKAGED_PROCESS and AUTO_START manifest problem
• #63722 (closed, not planned) the same thing across an Intune-managed fleet

Service configuration:

• #57371 (open, 20 comments) asks for a supported way to disable the bundled service, and documents that sc.exe config is refused

Adjacent triggers that end in the same state:

• #42776 (open, 122 comments) orphaned process file lock on relaunch, by far the largest of these threads
• #81840 (open) in-app browser pane crashes the GPU process, which labolabo above ties to the resulting brick
• #25914, #28231, #50825 (all closed) older launch failures involving CoworkVMService

That comes to 27 reports, 14 open and 13 closed, spanning 15 Feb to 18 Aug 2026, on x64 and ARM64, on personal machines and on managed fleets, and still reproducing on 1.32352.1.0. Eight of the thirteen closures were duplicate or not planned.

Two of those, #87607 and #87610, were filed today, within minutes of each other and while I was writing this. That is probably the clearest argument for consolidating: people keep independently rediscovering the same mechanism, writing it up carefully, and filing fresh, because the existing reports are scattered across two dozen issues and the majority of the closed ones were never triaged.

One last thing that is easy to mistake for this bug and does not appear anywhere in this thread. If the symptom is "Couldn't finish loading" with error code 1XAF0WC, and logs\claude.ai-web.log shows Failed to fetch dynamically imported module, that is a stale renderer cache (#81961), cleared by deleting Cache, Code Cache and GPUCache from the app data directory with no session teardown required. Different bug, unrelated fix, but the two get conflated because the user-visible failure is again "the app broke after an update". On MSIX installs that directory is %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude, not %APPDATA%\Claude, which is another thing that costs people time.

Reproduced again today (2026-08-19), update-triggered variant — 3rd occurrence of the update-triggered pattern on the same machine (also 08-07, 08-12; 08-14 update was fine).

Environment: Windows 11 Pro 26200 (25H2), Claude Desktop MSIX 1.32352.1.0 → 1.32885.1.0

Timeline (AppModel-Runtime/Admin, JST):

• 15:44:22 old package Claude_1.32352.1.0 runtime status 0x280000 → 0x200000 (shutting down for update)
• 15:44:22 new package Claude_1.32885.1.0 Register completes (AppXDeployment 400/613, overall 36 s, Gap: 34515 ms = waiting for old processes)
• 15:44:22 EventID 219 → 215 0x80070020 ... error converting the job ×2 → 208 Cannot create the process ... [LaunchProcess] — the automatic relaunch fails
• 15:44:23 EventID 211: cowork-svc.exe (PID 91380) does get its container created successfully → the block is on the app launch path only, same as my 08-12 analysis
• 15:58:52 manual launch via shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude → identical 215/208 sequence, so once the race is lost the orphaned Job persists for the whole user session
• Get-AppxPackage Claude → Status: Ok the whole time (not a NeedsRemediation case), CoworkVMService Running/Automatic

Recovery expected to be sign-out/sign-in (as before). No new information on the root cause; posting for frequency tracking — on this machine the updater loses this race 3 out of 4 recent updates.

Follow-up to my report above (same 2026-08-19 incident, 1.32352.1.0 → 1.32885.1.0): recovered without sign-out/reboot using the SYSTEM force-unload workaround described earlier in this thread.

• hivelist showed 8 orphaned \REGISTRY\WC\Silo* hives backed by the package's Helium\User.dat / UserClasses.dat (both LOCKED, errno 13)
• Pass 1 of NtUnloadKey2(..., REG_FORCE_UNLOAD) under SYSTEM (one-shot scheduled task): 8 → 2 silos, both .dat files freed
• Pass 2: 2 → 0 (the partial first pass is consistent with earlier incidents — some hives are momentarily in-use; the operation is idempotent)
• Launch via shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude immediately succeeded — 10 WindowsApps\Claude_* processes, no new 215/208 events

No re-register needed this time either (package Status was Ok throughout). That keeps the pattern: the only broken piece after a lost update race is the leaked container silos holding the registry hives; once those are force-unloaded the new build starts fine in the same user session.

The orphaned silo here has a specific, findable cause on my machine: the package's Desktop Bridge ("Helium") registry hives stay mounted after a container crash.

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\UserClasses.dat

The adjacent .LOG1/.LOG2 files indicate a hive is currently mounted. Creating a Desktop AppX container requires loading those hives; they were already loaded, so the load failed with ERROR_SHARING_VIOLATION — the 0x80070020 in EventID 215, immediately followed by 208:

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

This is why the usual remedies do nothing. Silo-mounted hives live in the container's own registry namespace, not the global one — they are invisible to Task Manager, handle.exe, and reg query HKU, and are held by the kernel rather than by any user-mode process. So taskkill, Settings → Terminate, Repair, Reset, and stopping the packaged service all had no effect. Plain reboots failed too, because the still-registered package and its auto-starting packaged service (CoworkVMService, TYPE 210 WIN32_PACKAGED_PROCESS) re-mounted the hive at every boot.

What cleared it, in this order:

1. Get-AppxPackage *Claude* | Remove-AppxPackage — verify Get-AppxPackage *Claude* returns nothing.
2. Confirm nothing will re-mount at boot: sc.exe query CoworkVMService should report the service does not exist.
3. Reboot.
4. First action after login, before launching or installing anything: delete the package data folder — Remove-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force. This succeeds silently once nothing has mounted the hive.
5. Then run Setup.

Step 4 has to precede step 5. Installing first re-registers the package, re-mounts the hive, and puts you back where you started.

Two diagnostic traps that cost me time:

• Get-AppxPackage reporting Status : Ok does not rule this out. The registration is fine; the hive is the problem.
• Renaming the package data folder is blocked by design while the package is registered, so an access-denied there proves nothing.

Caveat: single machine, n=1. I have not reproduced this elsewhere, and I can't say from one host whether the initial container crash has a common trigger.

Recurrence on the same machine as my 2026-08-18 report. Windows 11 Business 25H2 (26200.9106), this time updating 1.32352.1.0 to 1.34493.1.0, recovered by restart. Same hardware and same reporter, so nothing here independently confirms my own earlier observations, and I've flagged inline where that matters.

Before anything else: most of what I was going to post as new is already in this issue family, in #76357 and #83968 rather than here. I went looking after drafting, and I'd rather say so than re-report other people's work. Credits and links at the bottom. The narrow thing I think is actually new is one log line, described next.

The narrow new bit: close-app without beforeQuitForUpdate

@tonydzi already showed (#76357, 2026-08-12) that the OS-driven deferred registration can fire on its own while the app is still logging [updater] Staged version ... is still current, with no beforeQuit line in main.log at all. My trace is the same path, with one additional detail: main.log here does record a shutdown line, and it is close-app with beforeQuitForUpdate absent.

That distinction matters because close-app on its own is not diagnostic. In the only other logs in this family that contain the line (HarvestEdge here, JeKie1408 in #87610), it appears immediately after a successful beforeQuitForUpdate, which is why JeKie1408 reasonably read it as reassurance that the app did its part. From my own log, the updater-driven path looks like this:

18/08 11:14:17  beforeQuitForUpdate handler fired, going down for update
18/08 11:14:17  Windows session ending (close-app) - quitting the app

And the 23/08 servicing path looks like this:

23/08 22:43:06  [updater] Staged version 1.34493.1 is still current
23/08 22:48:42  Windows session ending (close-app) - quitting the app     <-- no beforeQuitForUpdate

So close-app plus beforeQuitForUpdate means the updater drove it. close-app alone, with the updater still logging deferrals, means something else did. That is a one-line triage signal for anyone reading a main.log from this family, and it is the only part of this comment I would call new.

The trace

23/08 22:43:06  main.log   [updater] Staged version 1.34493.1 is still current
23/08 22:48:42  main.log   Windows session ending (close-app) - quitting the app
23/08 22:48:42  AppXDep 607  Register operation on Claude_1.34493.1.0 de-queued and running
23/08 22:48:42  AppXDep 855  updateList: Claude_1.32352.1.0 is updating to Claude_1.34493.1.0
23/08 22:49:14  AppModel  68   1.32352.1.0  0x200000 -> 0x280000
23/08 22:49:14  AppModel 217   Destroyed container DA52153B (1.32352.1.0)
23/08 22:49:14  AppModel  67   Failed with 0x5 modifying AppModel Runtime status for
                               Claude_1.32352.1.0 (current = 0x280000, desired = 0x480000)
23/08 22:49:14  AppModel  42   Successfully updated AppContainer Claude_pzs8sxrjxfjjc
23/08 22:49:14  AppModel  68   1.32352.1.0  0x280000 -> 0x200000   (rolled back)
23/08 22:49:14  AppXDep 613   Register operation: Overall time 32140 ms
23/08 22:49:14  AppXDep 821   During-logon registration ... finished with result: 0x0
--- no retained Claude AppModel or AppX deployment events, and no further main.log
    entries, for the next ~10h48m ---
24/08 09:37:16  AppModel 215/215/208   0x80070020   <-- first recorded activation failure

The instance ran continuously from 18/08 20:52 to 23/08 22:49 while three versions stacked up behind it (1.32885.1.0, 1.34493.0.0, 1.34493.1.0), with the updater logging Deferring auto-restart after 117/118/119 hours: Claude is working throughout. The deployment side had also been backing off: event 638 at 22/08 16:25:27 reads "Packages were not updated because affected apps are still running. Running apps: {Claude_pzs8sxrjxfjjc!Claude}, ... Number of previous attempts: 2, Is user session locked: true". That event is itself a deferral recording two prior attempts, so by the handover the deployment side had backed off at least three times.

Unchanged boot and logon timestamps rule out shutdown and logoff. The logs do not identify which operation requested the close: there is no event 603 for the 22:48:42 operation, which entered via 679 OnDemandRegisterPackageList and exited via 821 During-logon registration, unlike the 09:37 repairs that log 603 RegisterByPackageFullName ... ForceTargetApplicationShutdownOption. The same-second correlation with 607/855 associates the close with servicing, but I can't name the caller.

No GUI activation followed. In the pre-recovery capture the retained AppModel log contains no event 201 for 1.34493.1.0, while still retaining the old version's 18/08 event 201, so the interval had not rolled out of the roughly 5-day window. main.log ends at 22:48:42 and never advances again.

Practical consequence, which is really @repko-artem's point rather than mine: the failure only appears the next time someone launches the app, so "worked yesterday, broken this morning, I changed nothing" reports in this family are plausible rather than user error.

Two corrections to my own earlier reasoning

The 210/211 pairs after the swap are the packaged service, not the app. At 22:49:14 a container was created and PID 22740 added, which looks like a successful relaunch. It is cowork-svc.exe: C:\ProgramData\Claude\Logs\cowork-service.log logs Service ready at 22:49:14.789, and SCM 7045 installs the service the same second. Absence of event 201 corroborates that no application [LaunchProcess] creation was recorded. A 210/211 pair is not a universal service-versus-GUI discriminator on its own; here it is the service log and SCM lifecycle that identify these PIDs. @I083 made the more general version of this point in #77379: the package creates two containers, and deployment destroys only the service's.

File mtimes do not establish hive mount time. I initially read User.dat mtime 17/08 19:59 as evidence the hives had been mounted since the 18/08 launch. That is unsound: a mounted hive's mtime updates on flush, so a hive held continuously across five days of use should show a later mtime, not an earlier one.

One counting correction as well: this machine shows 8 hive entries across 4 distinct Silo... GUIDs, which is not "8 orphaned silos". Anyone comparing counts should check both sides are counting the same thing.

Confirmations, with the attribution straight

Mounted user hives with no GUI process. User.dat and UserClasses.dat were mounted and failed the exclusive-open test while no Claude Desktop GUI process was alive. I did not test whether CoworkVMService is the holder on this machine; that it is not was established by @tazbdp's and @DevHoracioRodriguez's controls here and by @ostrakographos's ProcMon trace in #42776. Package registration reported Status: Ok while activation failed.

Automatic ACL repair does not restore activation, per @HarvestEdge (2026-08-15). Reproduced: each repair cycle logs 649 ... ACLs repaired successfully ... Register next time should succeed, followed by successful registration (400/613) and SCM service reinstallation (7040/7045), and activation still fails. Registration succeeds; activation does not.

The 0x5 at event 67 on the outgoing package (0x280000 -> 0x480000) is the same signature I reported on 2026-08-18. Same machine and same reporter, so treat it as a recurrence rather than independent confirmation. It does establish that the 0x5 reproduces across successive update generations here (1.30096.5 to 1.32352.1.0, then 1.32352.1.0 to 1.34493.1.0). The bit semantics remain inferred: 0x400000 has never been observed succeeding anywhere in this family, so calling it "the hive-unload step" is still conjecture.

Ruled out here

Microsoft.WindowsAppRuntime.2 servicing is not involved. Its install completed at 22:48:56, 18 s before the handover, and all three stage operations were no-ops (735 Windows cannot install ... a higher version is already installed). Claude's Register had been de-queued and running since 22:48:42, before the Windows Update activity, so the ordering is backwards for a race.

Kernel-Power 566 at 09:36:46 reads "The system session has transitioned from 28 to 30. Reason InputAccelerometer", which I can't map to a documented state without SleepStudy data, so I'd treat it as noise rather than causal. It does follow that absence of Power-Troubleshooter events doesn't exclude Modern Standby, since Modern Standby doesn't log S3-style wake events.

Speculation, clearly labelled

No evidence for this, offered as something testable. The manifest declares runFullTrust, packagedServices, localSystemServices and unvirtualizedResources, and ships a LocalSystem packaged service inside the package identity, so the container's lifetime is referenced by both a user app and a system service. If silo teardown assumes the container dies with the user's app, a split lifetime could break it. That would fit @I083's two-container observation. In the retained logs on this machine, Claude accounts for all 215/208 events and MSTeams, Photos, Terminal and VS Code for none, but that is a roughly 5-day circular log, not a lifetime comparison.

Counterexamples worth respecting

I recovered by restart, but that is not universal and I don't want to add to the "just reboot" chorus:

• @MontessoriUA in #84792: a 0x80070002 variant where two full reboots did not recover, with chrome-native-host.exe inside the package app-data store as the holder.
• @bhodges624 above (2026-06-23): a reboot that did not recover, after which the signature changed to ~1,300 event 217s in one second with zero 215/208.
• @roopsikhaai-web above (2026-08-20): plain reboots failing because the auto-starting packaged service re-mounted the hive at every boot.

Ask

Seconding @roopsikhaai-web's explicit-unmount or launch-time self-heal request, with one addition that follows from @tonydzi's trace and mine: when servicing is applied outside the updater's own quit-and-relaunch, nothing verifies afterwards that the new version can activate. A post-servicing activation check would surface this immediately and attributably, even without fixing the teardown.

Prior work this refines

• https://github.com/anthropics/claude-code/issues/76357 - @repko-artem (2026-08-08) showed the updater always stages with DeferRegistrationWhenPackagesAreInUse, that Windows can then never come back to apply it, and that sign-out is the folk cure precisely because sign-out performs the pending registration. His cross-package control (event 215 over three days: Claude 44, every other package 0) also rules out a general AppX fault.
• https://github.com/anthropics/claude-code/issues/76357 - @tonydzi (2026-08-12) captured the OS-driven deferred registration firing on its own in an unattended 2h25m trace, with no beforeQuit line at all, followed by 28 activation attempts with zero package processes alive. This is the closest existing report to the path above; I add only the close-app detail.
• https://github.com/anthropics/claude-code/issues/83968 - @lmalma (2026-08-05) retracted their own cowork-svc.exe root cause and replaced it with the chain that still stands: event 658 deferred registration, abnormal container teardown mid-swap, silo hives left mounted, 0x80070020. Worth crediting the retraction as much as the finding.
• https://github.com/anthropics/claude-code/issues/49655 - @jun-ho-hong (2026-04-17) identified the Helium\User.dat / UserClasses.dat locks, that they are kernel-level and invisible to handle64, and that reg unload fails as Administrator. Four months before the same files were re-derived on the activation path.

Same failure, still open, worth consolidating

• https://github.com/anthropics/claude-code/issues/73107 - same 215/208, different pinner: an orphaned elevated process still a live member of the old container job, cleared with taskkill, no reboot. @leifclaesson's three-pinner framing is the clearest in this family.
• https://github.com/anthropics/claude-code/issues/77379 - @I083 (2026-08-14): two containers per package, deployment destroys only the service's, and svchost.exe holding \Container_Claude_* is normal for every packaged app, so chasing that handle is a dead end.
• https://github.com/anthropics/claude-code/issues/87607 - a third pinner: a leaked Cowork utility VM (vmmemCmZygote) holding kernel VSMB/HCS mappings, invisible to Restart Manager.

Closed without a fix while still reproducing

• https://github.com/anthropics/claude-code/issues/48003 - bot-closed as a duplicate of #45489, which is itself closed as a duplicate. Identical 208/215 0x80070020, never seen by a human.
• https://github.com/anthropics/claude-code/issues/61635 - stale-bot closed, also labelled invalid. Contains @TurielD's first report (2026-06-06) that sign-out alone recovers and no reboot is needed.
• https://github.com/anthropics/claude-code/issues/59934 - stale-bot closed. Same activation failure, plus an Add-AppxPackage -Register recovery that needs no admin.
• https://github.com/anthropics/claude-code/issues/67911 - independently derived the silo mechanism, self-closed as a duplicate of this issue.

One triage note. The only maintainer action I can find across this family is #81756 being closed as a duplicate of https://github.com/anthropics/claude-code/issues/73694. That issue is open but already labelled stale, and it is scoped to 0x80073D02, the deployment file lock. That is a different mechanism from the 0x80070020 activation failure discussed here. If #73694 is the designated canonical issue for this family, it may be pointing at the wrong bug.

Environment and method

Windows 11 Business 25H2, 26200.9106. Package Claude_pzs8sxrjxfjjc, sideloaded (SignatureKind: Developer), 1.32352.1.0 to 1.34493.1.0.

Recovery: after restart, the exclusive-open test on User.dat and UserClasses.dat returned free at 11:21:59, about 13 s before first launch. No Claude GUI process was running then, though the packaged service had been up since 11:20:32. That was an interactive check and is not captured in my snapshots. First launch succeeded and logged event 201 at 11:22:12. Once the app is running those hives are locked again, and that is the healthy state: the signature is locked with no process in the container, not locked as such.

For anyone gathering evidence here, Microsoft-Windows-AppModel-Runtime/Admin ships at about 1 MB and rolls in roughly 5 days, so raise it before you need the history. Microsoft-Windows-AppXDeploymentServer/Operational carries the deployment side (603/607/613/638/649/679/821/855) and is where the servicing correlation is visible at all.

Independent reproduction, plus a more specific trigger than "crash at startup" — and two more workarounds to cross off the list.

Still present on a much newer build: Claude Desktop 1.37937.1, Windows 11 Home 10.0.26200 (de-DE), non-managed machine. Three occurrences observed: 2026-08-21 (on 1.34493.1), 2026-08-25, 2026-08-26. Same 0x80070020, same AppModel-Runtime/Admin 215/208 pair.

The trigger looks like a deferred-registration race, not a startup crash

In my logs the app does not crash. It quits itself deliberately for the stealth update, then re-activates before the old package's container is gone.

Microsoft-Windows-AppXDeploymentServer/Operational — the new version is installed with registration deferred, because the old one is still running:

08:03:48  Add ... options NormalPriorityRequest, DeferRegistrationWhenPackagesAreInUse
08:03:53  [658] Package {Claude_1.37937.1.0_x64__pzs8sxrjxfjjc} is marked for deferred
               registration because {Claude_1.37937.0.0_x64__pzs8sxrjxfjjc} is still running.

%LOCALAPPDATA%\Claude\Logs\main.log — the app then quits and the swap is attempted ~3 seconds later:

08:14:25  [stealth-update] Triggering stealth update after idle timeout
08:14:25  beforeQuitForUpdate handler fired, going down for update
08:14:26  Windows session ending (close-app) - quitting the app

Microsoft-Windows-AppModel-Runtime/Admin:

08:14:28  [215] 0x80070020: cannot create the Desktop AppX container for package
                Claude_1.37937.1.0_x64__pzs8sxrjxfjjc ... error converting the job
08:14:29  [208] 0x80070020: cannot create the process for package ... [LaunchProcess]

Wedged from then on — every launch reproduces the pair (08:18:26, 08:21:11, 08:26:02, 08:26:04 …). Interestingly one attempt partially succeeds: event 210 creates a container and 211 assigns a process to it, then subsequent container creations fail — so the main process gets in and the children can't follow.

Quit type correlates with whether it wedges

| Quit | Next launch |
|---|---|
| beforeQuitForUpdate (stealth) 08-21 00:53 | OK ~8 h later, no reboot |
| beforeQuitForUpdate (stealth) 08-21 09:09 | wedged, failed continuously 10:26 → 16:23 |
| normal Windows session ending (shutdown) 08-25 22:18 | OK next morning |
| beforeQuitForUpdate (stealth) 08-26 08:14 | wedged |

The one stealth quit that recovered had a long gap before the next activation; the wedging ones re-activate within seconds. Consistent with a teardown race, though not proof.

Two more things that do NOT recover it

Adding to the list already in this issue:

• sc.exe stop CoworkVMService (elevated) — no effect. In my case the service went STOP_PENDING and auto-restarted, but that's not the reason it failed: the container errors at 08:21:11 / 08:21:12 are after the stop. This is worth stating explicitly because #57221 proposes the service as the cause and stopping it as the fix; it isn't sufficient here.
• IPackageDebugSettings::TerminateAllProcesses (the API behind Settings → Advanced options → Terminate), called on both package full names — returns S_OK, hives stay locked, next launch still 0x80070020.

Windows' own repair registration (RegisterByPackageFullName with ForceTargetApplicationShutdownOption, RepairAppRegistrationOption) runs automatically on every launch attempt and succeeds each time — which is why Get-AppxPackage keeps reporting Status: Ok while the app is completely dead. That mismatch sends people down the wrong diagnostic path; the deployment logs look clean and only AppModel-Runtime/Admin shows the failure.

Confirming the workaround: logoff + login is enough, no full reboot needed.

Partial user-side mitigation

For anyone stuck on this daily: setting the documented disableAutoUpdates policy stops the stealth updater, so the race never fires — then update manually with the app closed.

# elevated
New-Item -Path 'HKLM:\SOFTWARE\Policies\Claude' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Claude' -Name 'disableAutoUpdates' -Value 1 -Type DWord

Documented for MDM deployments, but it's a plain registry policy read and appears to work on an unmanaged machine. Obvious cost: no automatic updates, on an app that currently ships roughly daily.

Suggested fix

Since DeferRegistrationWhenPackagesAreInUse was requested, the platform will apply the deferred registration on the next natural activation anyway. So:

1. On source=windowsStore, drop the self-managed stealth relaunch and let the platform apply the deferred registration at the next launch.
2. If the self-relaunch is kept, wait for the old package's container to actually be released rather than re-activating after ~3 s — and fail soft, leaving the old version launchable, instead of wedging the package family.
3. At minimum, detect the 0x80070020 activation failure and say "sign out and back in to finish updating" instead of surfacing a generic file-in-use error.

For those stuck with this bug, I asked Kiro/Claude to build a Powershell script which (for most cases) resolves the issue: https://github.com/Bestehorn/claude-desktop-update-unblock

In some cases, even killing a bunch of depending processes does not resolve this, so you have to log out and then back in, but it mostly works and then let's you update Claude Code properly.

Adding a deterministic trigger plus fresh forensics for this — hit it twice in the last two days with the exact signature described here (Event 215/208 0x80070020 "error converting the job" on every launch attempt, only reboot recovers, user-facing dialog "Another program is currently using this file").

Trigger identified: the in-app updater's forced shutdown. The app deadlocks while shutting down for the update's register operation, WER hard-kills it mid-servicing, and that kill is what orphans the silo/job.

Timeline reconstructed from AppXDeploymentServer/Operational, AppModel-Runtime/Admin, WER, and the cowork-service log (2026-08-26, local time, updating 1.37937.1.0 → 1.37937.3.0):

• 21:38:18 — updater stages the new MSIX in the background (Add operation, deferred registration) while the app is running. No problem at this point.
• 21:49:19 — deployment log: RegisterByPackageFamilyName starts with ForceApplicationShutdownOption. Same second, cowork-service log shows the app's persistent RPC connection drop (EOF) — the app begins shutting down.
• 21:49:54 — the app never finishes exiting. WER records MoAppHang: "claude.exe 1.37937.1.0 stopped interacting with Windows and was closed" (hard kill). Servicing proceeds over the killed app; register completes 21:49:55.
• From then on, every launch fails with Event 215 0x80070020 "error converting the job" / Event 208, containers created then immediately destroyed. Only a reboot recovers.

Recurrence data: WER shows MoAppHang for claude.exe 3× in 14 days — 08-13 (1.28929.0.0), 08-15 (1.30096.1.0), 08-26 (1.37937.1.0). Each hang is on exactly the version being replaced that day, i.e., every recorded hang coincides with an update register.

Verified NOT to recover the wedge (all attempted before rebooting):

• killing an orphaned chrome-native-host.exe that survived from the pre-update package
• killing the Appinfo svchost (which held a leaked \Container_Claude_<version> job handle in an earlier occurrence — not this time)
• stopping CoworkVMService (cowork-svc.exe)
• elevated Sysinternals handle64 sweep: zero handles matching Container_Claude or the package family string — this round the stale job appears GUID-named / kept alive by membership, so there is no user-mode handle to close
• clean-context launch via explorer.exe "shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude" — fails identically

Suggested fix direction: either the Electron main process needs to shut down cleanly when the MSIX deployment issues the force-shutdown, or the updater should defer the register until the app has actually exited (staging while running is fine; the forced register racing a hung shutdown is what wedges the machine).

Environment: Windows 11 Pro 10.0.26200, sideloaded MSIX build (Claude_pzs8sxrjxfjjc).

Same failure here on a current build (1.37937.x), and I have two additions that
aren't in the thread yet: the trigger is the in-place MSIX update, not only a
crash, and the occupant of the container is cowork-svc.exe itself - with a
workaround that actually sticks.

Environment

• Windows 11 Pro 26100 (x64)
• Claude Desktop 1.37937.3.0, MSIX, SignatureKind=Developer, auto-updated from

downloads.claude.ai (not Microsoft Store)

• Reproduced on 1.37937.0 -> 1.37937.1 (2026-08-26) and 1.37937.1 -> 1.37937.3 (2026-08-27)

The trigger is a normal, successful update - no crash needed

Microsoft-Windows-AppXDeploymentServer/Operational:

10:53:26  [638] package not updated, app still running {Claude_pzs8sxrjxfjjc!Claude}
10:53:26  [658] registration deferred
12:44:37  [603] RegisterByPackageFamilyName, ForceApplicationShutdownOption
12:45:07  [9650] 0x0: terminated service CoworkVMService of Claude_1.37937.1.0
12:45:10  [400] Register completed
12:45:10  [472] moved old package folder to WindowsApps\Deleted, result 0x0

The updater downloads, defers registration because the app is running, then ~10
minutes later re-registers with ForceApplicationShutdownOption. Windows kills
the running app to apply it. Deployment reports success at every step. The app is
unlaunchable from that moment on.

The container is occupied by cowork-svc.exe

Microsoft-Windows-AppModel-Runtime/Admin:

12:45:10  [211] added process 59092 to the Desktop AppX container for
                Claude_1.37937.3.0_x64__pzs8sxrjxfjjc
12:45:12  [215] 0x80070020: Cannot create the Desktop AppX container for package
                Claude_1.37937.3.0_x64__pzs8sxrjxfjjc because an error was
                encountered converting the job.
12:45:12  [208] 0x80070020: Cannot create process for package ... [LaunchProcess]
          identical 215 + 208 at 13:01:13, 13:01:17, 13:01:48, 13:01:51, 13:01:52
13:08:52  reboot
13:09:21  [210] container created successfully -> app launches normally

PID 59092 is cowork-svc.exe (CoworkVMService), confirmed by process lookup at
that timestamp. The packaged service is added to the package's container right
before every failure to create one.

Confirming there is no file lock

While the dialog was on screen I ran a Restart Manager (RmGetList) query against

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

Result: zero holding processes. Add-AppxPackage -Register <AppxManifest.xml>
also returned success and changed nothing. This matches the thread's conclusion
that "file in use" is only how 0x80070020 surfaces.

The dialog itself is owned by sihost.exe (window class #32770), title = the
package's app\claude.exe path.

Stopping the service is NOT enough - it comes straight back

13:01:02  Stop-Service CoworkVMService -> Stopped (verified)
13:01:16  [211] process 59100 added to the container   <- service already back

CoworkVMService is WIN32_PACKAGED_PROCESS with START_TYPE 2 (AUTO_START), so
it restarts within seconds and re-takes the container. That is probably why
"restart the service" is reported as not working.

Workaround that does stick

reg add "HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService" /v Start /t REG_DWORD /d 4 /f

plus, so the app does not expect the VM:

HKLM\SOFTWARE\Policies\Claude
  secureVmFeaturesEnabled       = 0 (DWORD)
  isClaudeCodeForDesktopEnabled = 1 (DWORD)

Applied on 2026-08-27; service is now Stopped / Disabled, no cowork-svc.exe
running. Cost: Cowork is unavailable. I have not yet been through an update cycle
with this in place, so I can't confirm it prevents the failure - I'll report back.
Note this is not a supported configuration; Anthropic support explicitly said so.

Side effect worth fixing too

Every update leaves the old package directory behind. On this machine:

14 leftover Claude_* folders in C:\Program Files\WindowsApps, 8,344 MB total
only the newest one is registered

AppXDeploymentServer event 1230 warns on every update about hardlinks shared
with those stale folders (app\chrome_100_percent.pak across 1.30096.1.0,
1.32352.1.0, ...).

Suggested fix

Don't let the packaged service join or hold the package's Desktop AppX container,
or ship CoworkVMService as Manual/Demand start so only the app spins it up.

Correcting my earlier comment, and confirming the preceding report's key claim with a controlled contrast.

Correction

I wrote that stopping CoworkVMService showed it was "not the holder — eliminated." That overreached, and I'd rather it not steer anyone away from the right suspect. The defensible version of my observation is narrower:

**Stopping the service is not sufficient.** It is WIN32_PACKAGED_PROCESS with START_TYPE 2 (AUTO_START), so it returns within seconds and re-takes the container. That is a statement about the workaround, not about causation — and I stated it as the latter.

Confirmation: success and failure path on one machine, 18 minutes apart

I happened to catch both paths on the same box today (Windows 11 Home 10.0.26200, 1.37937.1 → 1.37937.3).

Successful launch — the app's own process joins the container:

10:34:22  [210] Desktop AppX container {2A0A4B8D-...} created for Claude_1.37937.1.0_x64__pzs8sxrjxfjjc
10:34:22  [211] process 19824 added to container 2a0a4b8d-...
10:34:22  [201] process 19824 for application Claude_pzs8sxrjxfjjc!Claude in package Claude_1.37937.1.0

Event 201 identifies 19824 as the app. cowork-svc.exe was PID 10400, running since boot, and was never added. App launched normally.

Failed launch after the in-place update — cowork-svc.exe joins instead:

10:52:45  [217] container {A68C8893-...} for Claude_1.37937.1.0 destroyed
10:52:45  [67]  error 0x5 changing AppModel Runtime state for Claude_1.37937.1.0 (state 0x280000)
10:52:47  [217] container {234A6002-...} for Claude_1.37937.3.0 destroyed
10:52:47  [215] 0x80070020: cannot create the Desktop AppX container for Claude_1.37937.3.0
10:52:47  [210] container {234A6003-...} created for Claude_1.37937.3.0
10:52:47  [211] process 31808 added to container 234a6003-...
10:52:48  [217] container {234A6009-...} for Claude_1.37937.3.0 destroyed
10:52:48  [215] 0x80070020: cannot create the Desktop AppX container for Claude_1.37937.3.0
10:52:48  [208] 0x80070020: cannot create process for package ... [LaunchProcess]

PID 31808 is cowork-svc.exe, created 10:52:47 — verified by process lookup while it was live:

ProcessId Name           CreationDate
    31808  cowork-svc.exe 27.08.2026 10:52:47

No corresponding event 201 appears in the window I captured, consistent with this not being an application activation — the packaged service is placed into the new package's container on its own. The app's subsequent container creations then fail with 0x80070020, and the package stays wedged.

So the contrast is: app process in the container → launches fine; service process in the container → every subsequent container creation fails. Same machine, same package family, 18 minutes apart, no reboot in between. That's consistent with the preceding comment's PID 59092 finding rather than with my "eliminated" phrasing.

What I think this narrows it to

The service is AUTO_START, so after the forced re-registration terminates it (event 9650) it races back up and is placed into the new package's container before the app is activated. Whoever gets there first appears to determine whether the package family is usable until the session ends.

That would explain all of the otherwise-confusing observations in this thread at once: why deployment reports success at every step, why Get-AppxPackage reports Status: Ok, why re-registration and Reset-AppxPackage change nothing, why stopping the service alone doesn't help — and why only logoff/reboot recovers, since that is what finally tears the silo down.

Shipping CoworkVMService as Manual/demand-start, so only the app spins it up after its own container exists, looks like it would remove the race entirely — as the preceding comment suggests.

Still unverified

I have not tested whether disabling the service prevents the failure across an update cycle; neither has the preceding reporter. Worth someone confirming before it's treated as a fix. Note also that the two policy values in that workaround (secureVmFeaturesEnabled, isClaudeCodeForDesktopEnabled) do not appear in the published enterprise configuration docs, and it costs Cowork.

The documented disableAutoUpdates=1 policy avoids the trigger instead of the occupant, and is supported — but it means updating by hand on an app currently shipping close to daily.

Same signature today (Windows 11 Education 26200, de-DE, sideloaded MSIX, in-place update 1.34493.1.0 to 1.37937.3.0, updater-driven beforeQuitForUpdate quit, first 215/208 one second after the Register completed, then on every launch for 14 hours). I want to add one thing the thread does not have yet: an enumeration of what was actually inside the leaked silo, because on this machine it was neither cowork-svc.exe nor a kernel-only artifact, and ending those members recovered the app without logoff, reboot, or the SYSTEM hive unload.

The leaked silo had live members, and they were not Claude processes

hivelist showed the familiar picture (as @Ciki, @adpena, @AccountZero and others documented): one \REGISTRY\WC\Silo<guid> set with Helium\User.dat / UserClasses.dat mounted, zero processes with the package identity (tasklist /apps empty for Claude_), all six Helium\*.dat* files failing an exclusive open.

Enumerating every Job object on the system (NtQuerySystemInformation SystemExtendedHandleInformation, then QueryInformationJobObject with JobObjectSiloBasicInformation = 36 and JobObjectBasicProcessIdList = 3, script below) found exactly one silo that no running app accounted for:

SILO id=772 procs=8; total=1667739 active=8; telemetryId=656bd3b7-9cd3-11f1-...
pids=[23340,15212,17264,31008,11776,30896,30052,14136] :: holder 12060:svchost.exe (AppInfo)

telemetryId sits in the same sequential UUID series as the old app's container {656BD05C-9CD3-11F1-...} from event 217, and 1.67 million processes created over its lifetime is what days of the Desktop app's embedded Claude Code sessions look like. The eight survivors:

23340 tail.exe  -f -n +1 .../Temp/claude/<project>/<session>/scratchpad/.../ratio2.log   parent DEAD
15212 grep.exe  -E --line-buffered RATIO|error|DONE                                      parent DEAD
17264 tail.exe  -f -n +1 .../<session>/tasks/b7q2zp0ou.output                            parent DEAD
31008 grep.exe  -E --line-buffered "Finished|^error|exited with"                         parent DEAD
... (four more of the same shape)

Git-for-Windows tail | grep pipelines that a Claude Code session running inside Claude Desktop had started five days earlier as background log monitors. Their parent bash.exe / claude.exe processes died when the app quit for the update; the grandchildren stayed job members, so the silo never terminated and the hives never unloaded.

Three consequences that match observations elsewhere in this thread:

• They carry no package identity. tasklist /apps does not list them and GetPackageFamilyName() per PID returns nothing, so @DevHoracioRodriguez's identity-based sweep (which is the right tool for identity-inheriting children) cannot see this class of pinner. Job membership and package identity are different things; only the former keeps a silo alive.
• Name-based sweeps miss them too (taskkill /IM claude*, cowork-svc*, chrome-native-host*, parsecd*): ordinary tail.exe/grep.exe names, dead parents, session 2.
• handle.exe finds nothing because nothing user-mode holds the hive files or the WC key paths; the pin is membership, as @ZHANGV25 suspected ("kept alive by membership, so there is no user-mode handle to close"). This is the same class as the orphaned elevated member in #73107.

The service was not the occupant here

Tested with hivelist re-read after each step, before touching the members:

• Stop-Service CoworkVMService (elevated, confirmed Stopped, no cowork-svc.exe left): the service's own silo (software + com hives under ProgramData\Microsoft\Windows\WindowsApps\Claude_<ver>\Cache) disappeared. The leaked user silo with user_sid / user_classes stayed, 6/6 files still locked.
• Restart-Service vmcompute: no change.

So the 210/211 pair right after each Register (service added to a container, as @DrRIH and @Abtomation traced) is real but is a second, separate silo. The one that blocks activation is the old app's user silo, and on this machine it was held up by app-descended processes. That does not rule out the service (or a leaked Cowork VM, #87607) as the pinner in other people's cases; it just means "who is still a member of the old silo" is the question to ask before "who holds a handle".

Recovery without logoff (and without the SYSTEM unload)

taskkill /F /PID 23340 /PID 15212 /PID 17264 /PID 31008 /PID 11776 /PID 30896 /PID 30052 /PID 14136

Seconds later hivelist had no entries for the package, all six hive files opened exclusively, and the next shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude logged 210/211/201 instead of 215/215/208. 1.37937.3 has been running since, with two terminal-launched Claude Code sessions on the same desktop untouched throughout. Compared with the NtUnloadKey2(REG_FORCE_UNLOAD) route this needs no SYSTEM context and does not yank hives out from under anything.

Suggested procedure for anyone stuck

1. hivelist check with no Claude Desktop GUI running: a Silo…user_sid entry for pzs8sxrjxfjjc means the old silo is alive.
2. Run the scan below elevated and look for a SILO line whose pids you cannot attribute to a running app. Check each PID's parent; dead parent plus a shell/tool name is the tell.
3. End those PIDs, re-check hivelist, launch. If the silo shows procs=0 and still persists, you are in the handle-pinned case and the SYSTEM unload from earlier in the thread is the next step.

<details>
<summary>PowerShell: list every silo on the box with its live PIDs (read-only, run elevated)</summary>

Add-Type -TypeDefinition @'
using System; using System.Collections.Generic; using System.Runtime.InteropServices;
public static class JobScan {
  [StructLayout(LayoutKind.Sequential)] public struct HandleEntry { public IntPtr Object; public IntPtr UniqueProcessId; public IntPtr HandleValue; public uint GrantedAccess; public ushort CreatorBackTraceIndex; public ushort ObjectTypeIndex; public uint HandleAttributes; public uint Reserved; }
  [DllImport("ntdll.dll")] public static extern int NtQuerySystemInformation(int cls, IntPtr buf, int len, out int retLen);
  [DllImport("kernel32.dll", SetLastError=true)] public static extern IntPtr OpenProcess(uint access, bool inherit, int pid);
  [DllImport("kernel32.dll", SetLastError=true)] public static extern bool DuplicateHandle(IntPtr srcProc, IntPtr srcHandle, IntPtr dstProc, out IntPtr dstHandle, uint access, bool inherit, uint options);
  [DllImport("kernel32.dll")] public static extern IntPtr GetCurrentProcess();
  [DllImport("kernel32.dll")] public static extern bool CloseHandle(IntPtr h);
  [DllImport("kernel32.dll", SetLastError=true)] public static extern bool QueryInformationJobObject(IntPtr hJob, int cls, IntPtr info, int len, out int retLen);
  [DllImport("kernel32.dll", SetLastError=true, CharSet=CharSet.Unicode)] public static extern IntPtr CreateJobObject(IntPtr attr, string name);
  public static List<HandleEntry> GetHandles() {
    int len = 0x400000; IntPtr buf = Marshal.AllocHGlobal(len); int ret; int status = NtQuerySystemInformation(64, buf, len, out ret); int tries = 0;
    while (status == unchecked((int)0xC0000004) && tries++ < 8) { Marshal.FreeHGlobal(buf); len = ret + 0x100000; buf = Marshal.AllocHGlobal(len); status = NtQuerySystemInformation(64, buf, len, out ret); }
    if (status != 0) { Marshal.FreeHGlobal(buf); throw new Exception("NtQuerySystemInformation 0x" + status.ToString("X")); }
    long count = Marshal.ReadInt64(buf); long basePtr = buf.ToInt64() + 16; int sz = Marshal.SizeOf(typeof(HandleEntry)); var list = new List<HandleEntry>((int)count);
    for (long i = 0; i < count; i++) list.Add((HandleEntry)Marshal.PtrToStructure(new IntPtr(basePtr + i * sz), typeof(HandleEntry)));
    Marshal.FreeHGlobal(buf); return list;
  }
  public static IntPtr DupJob(int pid, IntPtr handle) { IntPtr hp = OpenProcess(0x40, false, pid); if (hp == IntPtr.Zero) return IntPtr.Zero; IntPtr dup; bool ok = DuplicateHandle(hp, handle, GetCurrentProcess(), out dup, 0x0004, false, 0); CloseHandle(hp); return ok ? dup : IntPtr.Zero; }
  public static string Describe(IntPtr job) {
    string s = ""; IntPtr buf = Marshal.AllocHGlobal(8192); int ret;
    try {
      if (QueryInformationJobObject(job, 36, buf, 16, out ret)) s += "SILO id=" + Marshal.ReadInt32(buf, 0) + " procs=" + Marshal.ReadInt32(buf, 8) + "; "; else return null;
      if (QueryInformationJobObject(job, 1, buf, 48, out ret)) s += "total=" + Marshal.ReadInt32(buf, 36) + " active=" + Marshal.ReadInt32(buf, 40) + "; ";
      if (QueryInformationJobObject(job, 44, buf, 16, out ret)) { byte[] g = new byte[16]; Marshal.Copy(buf, g, 0, 16); s += "telemetryId=" + new Guid(g) + "; "; }
      if (QueryInformationJobObject(job, 3, buf, 8192, out ret)) { int n = Marshal.ReadInt32(buf, 4); s += "pids=["; for (int i = 0; i < n && i < 64; i++) s += Marshal.ReadInt64(buf, 8 + i * 8) + (i < n - 1 ? "," : ""); s += "]"; }
    } finally { Marshal.FreeHGlobal(buf); }
    return s;
  }
}
'@
$myJob = [JobScan]::CreateJobObject([IntPtr]::Zero, $null)
$handles = [JobScan]::GetHandles()
$jobType = ($handles | Where-Object { $_.UniqueProcessId.ToInt64() -eq $PID -and $_.HandleValue -eq $myJob } | Select-Object -First 1).ObjectTypeIndex
$procs = @{}; Get-CimInstance Win32_Process | ForEach-Object { $procs[[int64]$_.ProcessId] = $_.Name }
foreach ($g in ($handles | Where-Object { $_.ObjectTypeIndex -eq $jobType } | Group-Object { $_.Object.ToInt64() })) {
  foreach ($e in $g.Group) {
    $p = [int]$e.UniqueProcessId.ToInt64(); if ($p -eq $PID) { continue }
    $dup = [JobScan]::DupJob($p, $e.HandleValue); if ($dup -eq [IntPtr]::Zero) { continue }
    $d = [JobScan]::Describe($dup); [JobScan]::CloseHandle($dup) | Out-Null
    if ($d) { "{0} :: holder {1}:{2}" -f $d, $p, $procs[[int64]$p] }
    break
  }
}

Class 36 fails with error 1505 on ordinary (non-silo) jobs, which is how the script filters them out. Then look up the listed PIDs with Get-CimInstance Win32_Process -Filter "ProcessId = N" and check whether their ParentProcessId still exists.
</details>

What this suggests for the fix

At least one path into the wedge is not a crash or a deployment race at all: the app quits for an update while descendants of an embedded Claude Code session are still running, they keep the old silo alive, and the new version can never mount the hives. Terminating the container job on quit-for-update (or at minimum the process trees of embedded sessions and their Monitor/background tasks) would close this path regardless of what the deployment side does. And the dialog text still sends people hunting for a file lock that does not exist.

n=1 machine, so treat the mechanism as one confirmed pinner among the several this thread has now identified, not the only one.

Adding data from another affected machine. Same symptom, but my error code is
0x80073D02 rather than the 0x80070020 in the original report — posting here
since #76357 was consolidated into this issue. If maintainers judge this a
sibling defect rather than the same one, happy to split it out.

Environment

• Windows 11 Pro 26200 (x64)
• Claude Desktop 1.40609.0.0, MSIX, package family Claude_pzs8sxrjxfjjc
• Updates are self-downloaded .msix files, not via Microsoft Store

(SignatureKind: Developer)

The event that names the blocker

Get-AppPackageLog on a failed register writes AppXDeploymentServer event
638, which states the blocking app explicitly. This seems underused in the
existing reports and is the fastest way to confirm the cause:

Packages were not updated because affected apps are still running.
Running apps: {Claude_pzs8sxrjxfjjc!Claude}
Directly serviced packages: {Claude_1.40609.0.0_x64__pzs8sxrjxfjjc}
Number of previous attempts: 0, Is user session locked: false

Every failure fails at the same state handler:

Error 0x80073D02: Failure in the ResolvedDeferredRegistrations state handler.

This is specific to the Claude package, not a broken deployment queue

Control test, same minute, same elevated shell:

| Package | Result |
|---|---|
| Microsoft.WindowsCalculator | registered successfully, 656 ms |
| Claude_1.40609.0.0 | failed at ResolvedDeferredRegistrations, 78 ms |

So the machine's MSIX subsystem is healthy; only the Claude package is blocked,
because only the Claude package has something of its own still running.

Timing: how long between the download and the forced shutdown

The updater downloads, then ~10 minutes later force-closes the app to apply.
Four consecutive update cycles:

download 08-25 13:48  ->  force shutdown 08-25 13:59    +00:10
download 08-25 19:38  ->  force shutdown 08-25 21:34    +01:55
download 08-26 15:54  ->  force shutdown 08-26 16:05    +00:10
download 08-28 11:36  ->  force shutdown 08-28 11:48    +00:12

Practical consequence: the whole cycle completes inside one working session, so
"shut down at the end of the day" does not avoid it. The app is killed
mid-session, and clicking the icon during the swap window produces the dialog.

A full uninstall + reinstall does NOT fix it

Worth recording so others do not spend the time. I uninstalled Claude Desktop
completely, confirmed no package remained registered, reinstalled from the
official download, signed in — and the very next register attempt failed
identically at ResolvedDeferredRegistrations with 0x80073D02.

An orphaned package folder also survives the uninstall

C:\Program Files\WindowsApps\Claude_<older-version>_x64__pzs8sxrjxfjjc
2667 files, 591.6 MB

No package record in the repository — AppXDeploymentServer logs event 1230
("these hardlinks did not have packages in repository", ~100 entries) on every
deployment operation. It persisted through the uninstall/reinstall and had to be
removed manually after taking ownership. Its large files all report hardlink
count = 1, so it is genuinely dead space, not shared with the live package.

CoworkVMService ships with the app and is not opt-in

Confirming a detail from #76357: CoworkVMService (cowork-svc.exe, display
name "Claude") is declared in AppxManifest.xml, starts automatically at boot,
and runs from inside the package directory. It is not a consequence of
enabling Cowork:

• After the reinstall, with vm_bundles and claude-code-vm both absent

(zero Cowork data provisioned), the service was still State=Running,
StartMode=Auto

• Its first installation predates the first Cowork session on this machine by

several days

So every Claude Desktop install carries a service that holds the package folder
open regardless of whether the user closes the window.

A debugging trap worth flagging

Do not count package processes with

Get-CimInstance Win32_Process | Where-Object { $_.ExecutablePath -like '*WindowsApps*Claude*' }

cowork-svc.exe reports an empty ExecutablePath via WMI, so that filter
silently misses it and reports zero processes while the package is still in use.
That false reading cost me several hours and one unnecessary reinstall. Match on
process name, or better, just read event 638 and let Windows tell you.

Suggested fix (same as #76357, restating with the extra evidence)

The updater should, before applying the package:

1. Stop-Service CoworkVMService
2. terminate all package-owned Claude.exe processes
3. apply the MSIX update
4. restart the service and relaunch the app

A reboot should never be required.

Also seeing this on Claude Desktop 1.40609.0.0 (MSIX). Symptom matches exactly: launch/update fails with "This file is in use by another program" referencing C:\Program Files\WindowsApps\Claude_1.40609.0.0_....

In my case, the Application event log shows repeated warnings from CoworkVMService around each occurrence:

Claude VM Service: failed to configure SCM recovery actions; if the service
crashes it will not restart until the machine reboots: open service: Access is denied.

Claude VM Service: failed to disarm SCM recovery actions for this stop; if the
stop overrun, the service may be auto-restarted during package servicing: open
service: Access is denied.

Get-CimInstance Win32_Service for CoworkVMService also fails to return details (StartName/PathName) with Access is denied under a normal (non-elevated) session — consistent with the TrustedInstaller-only DACL mentioned in #87610.

Occurred 3 times over ~2 weeks; only recoverable via full PC reboot. Most recent: 2026-08-29 14:39-14:45.

Full event log export attached.

claude_event_log.txt

The orphaned Silo is held by a stale RuntimeBroker.exe — recoverable without logoff/reboot

I hit this again today and traced the handle that keeps the orphaned container alive. It is not
cowork-svc.exe. It is the per-package RuntimeBroker.exe instance that Windows spawned for the
old package version. Killing that one process destroys the orphaned container immediately and the
app launches — no logoff, no reboot.

This does not appear anywhere in this issue or in #48003 / #57221 / #76357, so posting the full trace.

Environment

| | |
|---|---|
| OS | Windows 11 Home China, 25H2, Build 26200.9168 |
| Package family | Claude_pzs8sxrjxfjjc |
| Old → new | Claude_1.37937.3.0_x64 → Claude_1.40609.0.0_x64 |

---

What actually happens

1. The app is running, so the updater correctly defers registration

Microsoft-Windows-AppXDeploymentServer/Operational, event 603:

01:41:41  Add       Claude-f65e386d….msix
                    options = NormalPriorityRequest, DeferRegistrationWhenPackagesAreInUse
01:42:35  Add       completed successfully

2. …then registration is forced through anyway, killing the running app

01:53:06  RegisterByPackageFamilyName  Claude_pzs8sxrjxfjjc
                    options = ForceApplicationShutdownOption

ForceApplicationShutdownOption terminates the running old-version process instead of waiting for it
to exit. That is the trigger — the container teardown path never runs.

3. The old container is never destroyed

Microsoft-Windows-AppModel-Runtime/Admin:

2026-08-28 18:41:39  210  Desktop AppX container {329ECD8F-…} created for Claude_1.37937.3.0_x64
2026-08-28 18:41:39  211  process 30520 added to container 329ecd8f-…
2026-08-28 18:41:39  201  process 30520 created for Claude_pzs8sxrjxfjjc!Claude  [LaunchProcess]

PID 30520 was gone; no matching 217 (destroy) event ever fired.

4. Every subsequent launch fails

215  ERROR  0x80070020: cannot create Desktop AppX container for Claude_1.40609.0.0_x64
                        — error encountered converting the job
208  ERROR  0x80070020: cannot create process for Claude_1.40609.0.0_x64  [LaunchProcess]

Windows retries RegisterByPackageFullName with ForceTargetApplicationShutdownOption,
RepairAppRegistrationOption on every launch attempt, repairs the package ACLs, logs
Register next time should succeed — and the next launch fails identically. On 2026-08-28 that loop
ran 11 times before I gave up and rebooted.

---

The handle holder: a stale per-package RuntimeBroker.exe

RuntimeBroker.exe is spawned by svchost.exe hosting DcomLaunch / BrokerInfrastructure, and each
instance is bound 1:1 to a single AppX package. Verified via GetPackageFullName() on live brokers:

PID    Created              Package
13728  2026-08-28 18:40:10  MicrosoftWindows.Client.CBS_1000.26100.344.0_x64__cw5n1h2txyewy
29304  2026-08-28 18:40:52  AppleInc.iCloud_15.9.60.0_x64__nzyj5cx40ttqa
27172  2026-08-28 20:30:05  Microsoft.Windows.ShellExperienceHost_10.0.26100.8115_neutral…
27700  2026-08-29 00:58:41  A-Volute.Nahimic_1.10.13.0_x64__w2gh52qy24etm

The broker created at 18:41:26 — 13 s before the Claude container at 18:41:39 — was still alive
~19 h later, still pinned to the replaced package Claude_1.37937.3.0_x64.

Result of killing it (PID 14700, no elevation needed):

14:01:28  217  Desktop AppX container {329ECD8F-…} for Claude_1.37937.3.0_x64 DESTROYED
14:01:47  210  Desktop AppX container {329EEEE4-…} created for Claude_1.40609.0.0_x64
14:01:47  211  process 24416 added
14:01:47  201  process 24416 created for Claude_pzs8sxrjxfjjc!Claude  [LaunchProcess]

App launched normally, 9 processes, cowork-svc client connected and signature-verified. No reboot.

Caveat for accuracy: I did not run GetPackageFullName against PID 14700 before killing it, so the binding is inferred from (a) the 1:1 broker↔package rule verified on the live brokers above and (b) the 217 destroy event for the Claude container firing within seconds of the kill.

---

Why the workarounds in this thread don't work

• Stop-Service CoworkVMService — the service runs in session 0; the orphan is a user-session

container. Different silo, so stopping it changes nothing. (Matches the "service restart doesn't
work" note in this issue.)

• Re-register / Reset-AppxPackage / reinstall — none of these close a kernel job-object handle held

by a live process.

• Logoff / reboot work only because they tear down the session and kill the broker along with it.

---

Recovery script (no admin required)

$installed = (Get-AppxPackage -Name Claude).PackageFullName

# 1. Find containers created (210) with no matching destroy (217), for a package
#    version other than the one currently installed.
$c=@{}; $pkg=@{}; $d=@{}
Get-WinEvent -LogName 'Microsoft-Windows-AppModel-Runtime/Admin' -MaxEvents 4000 |
  Where-Object { $_.Message -match 'Claude_\d' -and ($_.Id -eq 210 -or $_.Id -eq 217) } |
  ForEach-Object {
    if ($_.Message -notmatch '\{([0-9A-Fa-f-]{36})\}') { return }
    $g = $matches[1].ToUpper()
    if ($_.Id -eq 210 -and -not $c.ContainsKey($g)) {
      $c[$g] = $_.TimeCreated
      $pkg[$g] = if ($_.Message -match '(Claude_[\d.]+_x64__\w+)') { $matches[1] } else { '?' }
    }
    if ($_.Id -eq 217) { $d[$g] = $_.TimeCreated }
  }
$orphans = @($c.Keys | Where-Object { -not $d.ContainsKey($_) -and $pkg[$_] -ne $installed })
$orphans | ForEach-Object { "ORPHAN $_  $($pkg[$_])  created $($c[$_])" }
if (-not $orphans) { 'No orphaned container found - this is a different failure mode.'; return }

# 2. Kill RuntimeBroker instances started before the orphan container was created.
#    Windows respawns them on demand, so this is safe.
$cutoff = ($orphans | ForEach-Object { $c[$_] } | Measure-Object -Maximum).Maximum
Get-CimInstance Win32_Process -Filter "Name='RuntimeBroker.exe'" |
  Where-Object { $_.CreationDate -le $cutoff } |
  ForEach-Object { "killing broker $($_.ProcessId) ($($_.CreationDate))"
                   Stop-Process -Id $_.ProcessId -Force -ErrorAction SilentlyContinue }

Start-Sleep 3
Start-Process 'shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude'

To identify the exact broker instead of killing several, resolve each broker's package with
GetPackageFullName (P/Invoke kernel32, PROCESS_QUERY_LIMITED_INFORMATION = 0x1000) and kill only
the one reporting the stale Claude_<old-version>_x64__pzs8sxrjxfjjc.

---

Suggested fixes

1. Stop using ForceApplicationShutdownOption. The Add already staged correctly with

DeferRegistrationWhenPackagesAreInUse; let registration happen on next natural app exit rather
than force-killing the running instance 11 minutes later.

1. If a forced shutdown is unavoidable, have the updater terminate the package's RuntimeBroker

instance as part of teardown, or verify a 217 destroy event fired before registering.

1. Detect the condition at launch: if a 210 without a matching 217 exists for a superseded package

version, clean it up instead of looping on RepairAppRegistrationOption.

---

Unrelated but visible in the same logs

CoworkVMService logs this on every stop and start:

Warning: failed to disarm recovery actions for this stop: open service: Access is denied.
Warning: failed to configure recovery actions (a crashed service will stay down until reboot):
         open service: Access is denied.

The service cannot open its own SCM handle with SERVICE_CHANGE_CONFIG. Per its own log text this
means a crashed service stays down until reboot, and during package servicing SCM may auto-restart it
mid-update. Probably worth a separate issue — it's not what caused the launch failure here.

Another affected machine, and one detail I don't see stated explicitly in the thread yet: on this machine the wedge also forms after a plain close, with no update anywhere near it — and it is recoverable without logoff or reboot.

Environment: Windows 11 x64, Claude_1.40609.0.0_x64__pzs8sxrjxfjjc, MSIX, SignatureKind Developer, self-downloaded .msix (not Store).

Wedge without an update. I closed the app normally with the window X, no deployment activity at all in AppXDeploymentServer/Operational in that window. 13 orphan Claude.exe processes were still alive and CoworkVMService was still Running. Log from the launcher wrapper I now use:

2026-08-30 17:09:12  LOCK DETECTED - leftover processes: 13, service: Running
2026-08-30 17:09:13  service stopped
2026-08-30 17:09:13  13 processes terminated
2026-08-30 17:09:16  launch requested

Stopping the service and killing the leftover package processes before activation recovers it — no logoff, no reboot. Consistent with the "membership, not handles" reading earlier in the thread: stopping the service alone was not enough here either, killing the leftovers is what matters. This also explains the days when the app died in the morning with no update in the logs at all: I had been treating those as a separate failure until I looked.

Update-driven occurrences. Four automatic updates in four days, each with the two-step signature already documented here — stage with NormalPriorityRequest, DeferRegistrationWhenPackagesAreInUse, then RegisterByPackageFamilyName with ForceApplicationShutdownOption 6 to 12 minutes later:

| staged | forced shutdown | version |
|---|---|---|
| 2026-08-25 22:25 | 22:31 | 1.34493.1.0 → 1.37937.0.0 |
| 2026-08-26 04:31 | 04:42 | → 1.37937.1.0 |
| 2026-08-27 04:06 | 04:17 | → 1.37937.3.0 |
| 2026-08-28 19:38 | 19:50 | → 1.40609.0.0 |

The 19:50 one hit while I was working. Adding a user-side observation to the "misleading error message" point already raised: from the user's side the window simply vanishes, and there is no Application event, no WER report and no crash dump for any of these, because the process is terminated rather than crashing. Standard troubleshooting therefore finds nothing at all, and a normal user has no way to tell an update from a crash. It took a full deployment-log analysis to work out what was happening.

Windows' repair paths, for the record on 1.40609.0.0. Repair (RegisterByPackageFullName + RepairAppRegistrationOption) completes and changes nothing. Reset (ResetPackageOperation) fails at step 1 of 4 with 0x80073CF0 (ERROR_INSTALL_OPEN_PACKAGE_FAILED) — a different code from the 0x80073D02 reported above, presumably because the staged .msix had already been cleaned out of %TEMP%. Uninstall + reinstall did recover it on this machine, unlike some reports here, which is what I was doing several times a day before finding the process-kill route.

Two asks, echoing the thread: don't force-close a running app to apply an update, and make sure the package's processes are actually gone before registering. The documented disableAutoUpdates policy avoids the trigger, but it should not be the answer for an individual user on a consumer install.

Follow-up: recurrence on 1.40609.0.0 and second successful no-restart recovery

This follows my earlier report and successful recovery on 1.30096.1.0:

https://github.com/anthropics/claude-code/issues/53247#issuecomment-5293117363

The same failure recurred on 30 August 2026 after Claude Desktop updated to:

Claude_1.40609.0.0_x64__pzs8sxrjxfjjc

The visible message was again:

Another program is currently using this file.

AppModel-Runtime recorded the same signature:

• Event 215 with 0x80070020, failing to create the Desktop AppX container while converting the job.
• Event 208 with 0x80070020, failing to create the process while configuring the runtime.
• Package status remained Ok.

State before recovery

• CoworkVMService was running under the new 1.40609.0.0 package.
• No Claude.exe process was running.
• Eight Claude-specific \REGISTRY\WC\Silo hives were mounted.
• %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat was locked.
• %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\UserClasses.dat was locked.

Step 1: stop the Claude service and recheck

I stopped CoworkVMService and waited until it reported Stopped with PID 0.

That removed three service-related WindowsApps hives, but the result was still:

• Five Claude silo hives mounted.
• Zero named Claude or Cowork processes.
• Zero processes detected with the Claude package family identity.
• User.dat and UserClasses.dat still locked.
• Launch still blocked by the orphaned container state.

This cleanly separated the ordinary service-owned state from the deeper five-hive orphan. Stopping Cowork alone was not the recovery for this occurrence.

Step 2: targeted hive recovery

I reused the same narrowly restricted recovery described in my previous comment.

Before it ran, the helper reported:

TARGET_COUNT=5
PACKAGE_PROCESS_COUNT=0

The helper:

• Runs only as NT AUTHORITY\SYSTEM.
• Enables only SeRestorePrivilege and SeBackupPrivilege.
• Dynamically enumerates targets rather than hardcoding silo GUIDs.
• Accepts only value names beginning with \REGISTRY\WC\Silo.
• Accepts only backing paths containing Claude_pzs8sxrjxfjjc or the Claude WindowsApps package.
• Refuses to unload if a named Claude/Cowork process or a process with Claude package identity is detected.
• Uses NtUnloadKey2 with REG_FORCE_UNLOAD.
• Makes up to three idempotent passes.
• Runs through a temporary one-shot SYSTEM task that is deleted afterwards.

Independent checks after recovery showed:

TARGET_COUNT=0
PACKAGE_PROCESS_COUNT=0

Both Helium files could then be opened exclusively, the temporary task was absent, CoworkVMService remained stopped, and the Claude package still reported Status: Ok.

Step 3: restart Claude through the registered app identity

Claude was launched through its registered application identity:

Claude_pzs8sxrjxfjjc!Claude

The raw executable under C:\Program Files\WindowsApps was not launched directly.

Verification after launch:

• A real visible window titled Claude opened.
• The Claude process group remained stable for more than 10 seconds.
• A later check showed 14 responding Claude processes.
• AppModel-Runtime recorded Event 201 for Claude_pzs8sxrjxfjjc!Claude.
• No new Event 208 was recorded.
• No new Event 215 was recorded.
• Package status remained Ok.

No Windows restart or sign-out was used.

Repeated result

This targeted recovery has now successfully restarted the Claude application on the same machine twice:

1. 14 August, version 1.30096.1.0: five orphaned hives reduced to zero, then successful launch.
2. 30 August, version 1.40609.0.0: eight hives initially, three removed by stopping Cowork, five orphaned hives reduced to zero, then successful launch.

This suggests the recovery is not tied to a specific Claude version. It is tied to the package family and the stranded WC/Silo hive state.

Safety caveat based on newer reports

Newer comments have identified stale job-member processes that may not have a Claude name or Claude package identity. Future tooling should inspect and terminate only processes proven to be members of the superseded Claude container job before force-unloading hives.

I did not enumerate job membership during this recurrence, so I am not claiming the five remaining hives were necessarily memberless. I am only reporting the measured sequence and successful result. The hive-unload method remains an unsupported, last-resort recovery and should never be broadened to unrelated hives, processes, or services.

The engineering need remains a supported Claude or Windows-side equivalent that completely tears down the outgoing package container before relaunching the updated package.

ForceApplicationShutdownOption is the precondition, not the trigger. Measured on two of my own
machines, six forced registrations produced two failures. The discriminator sits one level down,
and it is the missing container teardown that @Antairez already identified.

I have been tracking this on two Windows 11 machines (both build 26200) since 2026-08-21, and after
reading @Antairez's trace from 08-29 and @EasyjetCZ's four-update table from 08-30 I went back
through my own deployment and runtime logs to check the claim. The forced-shutdown part reproduces
exactly. The causal claim does not, and I think the difference matters for whoever picks this up.

The forced registration is confirmed

Machine A, the failure of 2026-08-29, straight from
Microsoft-Windows-AppXDeploymentServer/Operational:

28.08 16:27:16  603  Add                          options = ..., DeferRegistrationWhenPackagesAreInUse
28.08 16:27:35  613  Add completed                Claude_1.40609.0.0
29.08 08:00:21  603  RegisterByPackageFamilyName  options = ..., ForceApplicationShutdownOption
29.08 08:00:25  400  Register succeeded           Claude_1.40609.0.0
29.08 10:14:25  603  RegisterByPackageFullName    (the repair attempt during the failed launch)

Same two-step signature as reported. Note the gap: the deferral sat for 15.5 hours before it was
forced through, so the "6 to 12 minutes later" timing in @EasyjetCZ's table is not a constant.

But forcing is not what breaks it

Across both machines my logs contain six registrations carrying
ForceApplicationShutdownOption. Two of them were followed by the launch failure. The other
four were completely uneventful, including one on the same machine 30 hours before the failure
above (28.08 01:26:29, package 1.37937.3.0, no failure).

So a fix that only removes the forced shutdown would probably work, but the reasoning behind it is
incomplete: forcing happens routinely here and usually causes no harm.

What actually separates the cases

Machine B has a runtime log that reaches far enough back to answer this. It had its own failure on
2026-08-26 (six 215/208 events with 0x80070020 at 10:43:11). Three forced registrations, one bad:

| forced registration | container teardown (event 217) | outcome |
|---|---|---|
| 25.08 23:30:49 | absent, arrives only 26.08 10:43 | launch failure |
| 28.08 01:29:47 | 01:30:21, 34 s later | fine |
| 28.08 16:41:16 | 16:41:16, same second | fine |

The two healthy updates tear down the outgoing package's containers immediately, create the new
ones (210) and start the process (201), all within the same second. The failing one does not.

The evidence for the bad case is the presence of the teardown eleven hours later, not its absence
at the time, because a container can only be destroyed once:

26.08 10:43:11  217  container 9565FC0C   Claude_1.37937.0.0   <- destroyed only now
26.08 10:43:11  215  0x80070020                                <- launch fails
26.08 10:43:11  208  0x80070020
26.08 10:43:39  217  container 6BD17A0B   Claude_1.34493.1.0   <- previous package, 11 h stale

Those containers survived the forced registration of the night before and were only torn down while
the failing launches were hammering at them. That is exactly the 210 without matching 217 that
@Antairez described. What I can add is the contrast case, where the same forced registration does
tear them down properly and nothing goes wrong.

What I cannot tell you

• Why the teardown is skipped. I measured the difference, not its cause. The obvious candidate

is how much of the process tree was still alive at the moment of the forced shutdown, which I do
not have for the failing runs.

• Machine A can only confirm the first half. Its runtime log ring buffer holds about two hours, so

the container question is permanently unanswerable there. Worth knowing for anyone else checking:
AppModel-Runtime/Admin is far shorter-lived than AppXDeploymentServer/Operational. On my two
machines the deployment log reaches back 4 and 11 days, the runtime log 2 hours and 5 days
respectively, so gather it early or not at all.

• On machine B the runtime log begins three seconds after the forced registration, so I cannot rule

out a teardown event inside that window. The argument above does not depend on it.

Suggestion

If someone at Anthropic instruments this: the cheap check is not "was the shutdown forced" but
"did a 217 follow the register for every 210 of the outgoing package". That is a single
condition, it is observable in the same log the updater already writes to, and on my data it
separates the failing runs from the healthy ones cleanly.

Following up on my earlier comment with the update-cycle result I promised, plus
one finding that matters for anyone using the Start=4 workaround.

One update cycle passed with the service disabled

1.37937.3 -> 1.40609.0, applied 2026-08-28 23:25 with CoworkVMService set to
Start=4 (disabled) beforehand.

23:14:36  updater: Update downloaded and ready to install (1.40609.0)
23:25:37  [217] containers for Claude_1.37937.3.0 destroyed
23:25:39  [210] container {EFBA5C58-...} created for Claude_1.40609.0.0
23:25:39  [210] container {EFBA5C5F-...} created for Claude_1.40609.0.0
23:25:39  [211] process 66216  added to container efba5c5f
23:25:42  [211] process 179716 added to container efba5c58
23:25:42  [201] process 179716 created for application Claude_pzs8sxrjxfjjc!Claude [LaunchProcess]

Zero 215 / 208 events. The app relaunched normally and no reboot was
needed - the machine has been up continuously since 2026-08-27 13:08, four days,
across this update.

PID 66216 is cowork-svc.exe (still running under that PID now, confirmed via
Win32_Service.ProcessId). Note it went into a different container
(efba5c5f) while the app got efba5c58 and produced its 201. Consistent with
the race model in this thread: with the service disabled at the moment of
re-registration, it comes up late enough that the app wins.

This is n=1 and I want to be explicit that it is not proof. The same machine
failed at this exact point on 2026-08-26 and 2026-08-27, so it is a change in
behaviour, not a demonstration of cause.

The workaround does not survive an update

More useful than the above: the update re-installs the service as AUTO_START,
silently undoing Start=4.

System log, 2026-08-28 23:25:38
[7045] A service was installed in the system.
       Service Name: Claude
       Service File Name: "C:\Program Files\WindowsApps\Claude_1.40609.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
       Service Start Type: auto start
       Service Account: LocalSystem

Checked three days later: Start=2, service Running. So the machine was
unprotected again from the moment the update finished, and the next update would
have hit the original failure. Event 7045 appears at every single package
registration in my logs going back to 2026-08-19, so this is not a one-off.

Anyone applying this workaround has to re-apply it after every update. That also
means a report of "the workaround worked" can silently become "it is no longer
applied" without the user noticing.

I have re-applied it and will report the next cycle too.

Practical note

This makes Start=4 unsuitable as a standing fix for non-technical users - it is
a per-update chore. The Manual/demand-start change suggested earlier in this
thread would have to come from the package itself to actually hold.

5th occurrence on this machine (2026-06-12 ×2, 07-25, 08-19, now 08-31), update-triggered again: 1.37937.1.0 → 1.40609.0.0, Windows 11 Pro 26200. Same 215/208 0x80070020 loop. Recovered without logoff/reboot for the 5th time via the SYSTEM NtUnloadKey2(REG_FORCE_UNLOAD) route (8 → 2 → 0 silo hives in two passes, then an immediately clean 210/211/201 launch).

I ran extra forensics this time specifically to test @Antairez's stale-RuntimeBroker finding, and the results add three data points the thread doesn't have yet:

1. The wedge exists with NO holder process at all. I enumerated every process I could open (356) and called GetPackageFullName(PROCESS_QUERY_LIMITED_INFORMATION) on each: zero processes carried any Claude_* package identity — no stale RuntimeBroker.exe (all live brokers belonged to other packages or had no package identity), no leftover container member, nothing. Yet 8 \REGISTRY\WC\Silo* hives were mounted and Helium\User.dat/UserClasses.dat were locked. This is consistent with how the registry works: a mounted hive is kernel-owned — the backing file stays locked with no process handle required. So the stale broker is one possible reason teardown never completes, but it is not the invariant; kill-the-holder recovery scripts have nothing to kill in this state.

2. Unlike the trace above, the old container DID get its 217. AppModel-Runtime/Admin shows Destroyed Desktop AppX container {8D0D5A26-…} for Claude_1.37937.1.0 at 16:04:10.016, right as the new version registered. The silos leaked anyway. Also in the same second: EventID 67 Failed with 0x5 (ACCESS_DENIED) modifying AppModel Runtime status for Claude_1.37937.1.0 (current 0x280000, desired 0x480000) — possibly a fingerprint of the teardown path dying halfway. So "verify a 217 fired" would not be a sufficient updater-side check; the 217 can fire while the hive unmount is still skipped.

3. The orphaned silo set is stable — failed launches don't compound it. While still wedged, I recorded the 8 silo GUIDs, deliberately triggered one more launch (fresh 215/208 pair logged), and re-enumerated: identical 8 GUIDs, nothing added. The interim 210/211 events (containers created, a process briefly added, then 217 + 215) do not leak additional mounts. The artifact is a fixed set of orphaned mounts from the moment the update raced, and every subsequent create fails against it.

Synthesis this suggests: the durable artifact across the thread's reports may be the mounted hives, not the job object or any particular holder process. 0x80070020 is ERROR_SHARING_VIOLATION — a file-sharing error — which is exactly what container creation would hit when it tries to mount Helium\User.dat/UserClasses.dat while they are still mounted in an orphaned silo. That unifies the observations: killing a stale RuntimeBroker (or whatever holder exists) recovers because its death lets teardown finally unmount the hives; when no holder exists (this incident), only force-unmount — or logoff, which unmounts user hives wholesale — clears it. An updater-side fix should therefore verify the hives are unmounted (no \REGISTRY\WC\Silo* entries backed by the package's Helium .dat files in hivelist) before registering the new version, rather than checking process exit or the 217 event.

Method notes for anyone reproducing: process→package mapping via kernel32!GetPackageFullName on a 0x1000-access handle (no elevation needed); hive enumeration via HKLM\SYSTEM\CurrentControlSet\Control\hivelist (value name = silo key, value data = backing file); unload procedure as in my earlier comments in this thread.

Third occurrence here, most recently 1.34493.1.0 to 1.40609.0.0, so 1.40609.0.0 is affected as @AccountZero and @Ciki also report. Recovered by restart again. Two things that might save others time.

Correcting my own dating of this one, since it matters for anyone reading the pattern: the handover was 28/08 21:54:03, with event 67 0x5 on the outgoing 1.34493.1.0 and then 215/215/208 for 1.40609.0.0 in the following second. So unlike the case I described on 24/08, this one failed loudly at swap time. The 01/09 events are just my next cold launch, three days later, rediscovering a wedge that had been there since Friday evening. I initially wrote this up as an 8-day-uptime failure, which conflated when I noticed it with when it happened.

Running a watcher, because the evidence expires

Each time, I reconstructed the diagnosis by hand hours later, and twice the useful window had nearly rolled out of the log. Microsoft-Windows-AppModel-Runtime/Admin ships at 1052672 bytes. On this machine that held about 5 days of history, which is shorter than my gap between occurrences.

What I now have running:

• Both relevant logs raised to 32 MB: AppModel-Runtime/Admin and AppXDeploymentServer/Operational. Note the Admin stock size is 1052672 bytes, not 1048576, so passing "1MB" silently shrinks it.
• A scheduled task triggered on AppModel-Runtime/Admin event 215 and on Application 1000/1002, with no delay. Container, service and package state move within seconds here, so a delayed capture can miss the state you wanted.
• The task runs as the logged-on user at normal privilege and writes a read-only snapshot: hivelist silo entries, the exclusive-open test on Helium\User.dat and UserClasses.dat, both event logs, SCM 7040/7045 churn, and the main.log tail.

Two things I got wrong first, in case they save someone a detour:

• Do not filter the 215 trigger by package. Event 215's EventData does carry PackageName, and an exact-value XPath match works, but it is the fully versioned string (Claude_1.40609.0.0_x64__...) and the Windows event XPath subset has no starts-with or contains (contains() is rejected outright as an invalid query). A package-filtered subscription therefore stops matching silently after the next update. Filter inside the collector instead.
• WER LocalDumps looks like the obvious way to catch the crash side, and is not. Chromium sets SEM_NOGPFAULTERRORBOX and Crashpad installs its own unhandled-exception filter, so for an Electron app the dump never lands, and LocalDumps does not fire for hangs (event 1002) under any configuration. I have not yet had a hang to test against, but ProcDump attached to the window-owning process looks like the only route that sidesteps both.

I can share the scripts if anyone wants them.

Orphaned background processes: worth one check, but not the pinner here

Following @hypercat's silo-member finding, I looked for leaked members and found the same class in a different shape: four nohup.exe wrappers around eight python.exe -m http.server processes, started by Claude Code sessions running inside Claude Desktop on 24 and 25 August, parents long dead, still alive a week later with no established connections.

Two notes:

• A name filter of tail|grep|bash|sh|node misses them. Include nohup, and better, look for any process with a dead parent rather than matching on names.
• Killing all twelve did not free the hives. User.dat and UserClasses.dat stayed locked and all 8 hive entries remained, so this machine was the handle-pinned case rather than the live-member case. That fits @Ciki's process enumeration on 31/08 finding nothing carrying Claude_* package identity.

So the member check is worth one pass before reaching for a restart, but if the silo has no attributable members it will not be a process you can kill. Separately, those orphaned trees survive for days regardless of this bug, which is worth knowing on its own.

Fresh recurrence on 1.40609.0 + signed portable A/B test (2026-09-01)

This has recurred on the same Windows machine after our earlier report in #76357, which was closed as a duplicate of this issue. This is not just another “same here”: the current state provides a clean A/B comparison between the MSIX/AppX identity and the exact signed application downloaded from Anthropic.

Affected installed package

Name          : Claude
Version       : 1.40609.0.0
PackageFamily : Claude_pzs8sxrjxfjjc
Status        : Modified, NeedsRemediation
SignatureKind : Developer

The visible launch error is again:

Another program is currently using this file.

At the start of diagnosis, no Claude.exe process was running. The registered package remains in Modified, NeedsRemediation after the failure.

Controlled A/B recovery without reboot

1. Anthropic's official latest endpoint resolved to 1.40609.1:

https://claude.ai/api/desktop/win32/x64/msix/latest/redirect

1. The downloaded MSIX had a valid Authenticode signature from Anthropic.
2. SHA-256: D0282066855A3CAC5990912350C0DE4D01BB48CA65B8B6B4CE1EC9F2C910A6F9
3. I extracted only its app directory to a normal user-writable directory, without registering the MSIX.
4. The extracted Claude.exe reports 1.40609.1, has a valid Anthropic signature, and starts immediately.
5. Two clean launches produced a visible Claude window and the Code UI; no new AppModel-Runtime 215/208 errors appeared. The installed MSIX identity still reports Modified, NeedsRemediation.

This strongly narrows the failure to the AppX/MSIX registration or servicing lifecycle: the current official binary and the existing user profile work, while the registered package identity does not. The workaround now has to maintain a custom launcher that selects the newest verified unpacked Anthropic build and explicitly ignores installed packages whose status is not Ok.

Request for maintainer ownership and status

This canonical issue now has 38 comments and several independent, detailed reproductions, but I cannot find a maintainer response or confirmation of an internal tracking item. Consolidating duplicates is useful, but affected users still have no supported no-reboot recovery and are being pushed into custom unpackaged launchers.

Could an Anthropic maintainer please confirm:

1. whether this is tracked internally and has an owner;
2. whether 1.40609.1 contains any change intended to address this failure;
3. the supported recovery path for Modified, NeedsRemediation that does not require a reboot or destructive profile reset; and
4. whether the Windows stealth/in-place update path will be disabled or guarded until package teardown is reliable.

Even a short status update or a request for a specific diagnostic bundle would be materially better than continued silence on the canonical issue.

I am experiencing this issue currently and I have done everything with no luck I am completely stuck. Have restarted, cant find anything running to do with Claude someone please help me I have a very important project wrapped up in Cladue

I am experiencing this issue currently and I have done everything with no luck I am completely stuck. Have restarted, cant find anything running to do with Claude someone please help me I have a very important project wrapped up in Cladue

Check my solution above: https://github.com/anthropics/claude-code/issues/53247#issuecomment-5470575588

> I am experiencing this issue currently and I have done everything with no luck I am completely stuck. Have restarted, cant find anything running to do with Claude someone please help me I have a very important project wrapped up in Cladue Check my solution above: #53247 (comment)

No nothing here has worked. Ive been trying to troubleshoot with codex for about 3 hours now

Still happening as of Sept 1, 2026 on Claude Desktop 1.40609.1.0, Windows 11 Home build 26200.

This recurs roughly weekly and is triggered by the app's overnight background auto-update — no user action, no "Relaunch" click. I go to bed with the app running fine and wake up to "Another program is currently using this file" on every launch attempt.

Ending claude.exe and cowork-svc.exe in Task Manager (including elevated taskkill) does not clear it. The only recovery is a full Windows sign-out and sign-in, which means saving and closing everything else I'm working on.

I can't tell you have annoying and disruptive this is. It's driving me nuts. This has been open since April. For a paid user on Windows, a weekly forced session reset is a workflow-breaking defect, not an inconvenience. FFS please fix this Anthropic. This is something you need to do on your side -- not tell users to hack into the bowels of their devices and disrupt their work. Please fix this on your side rather than having users work around it in the registry. Thank you.

OK, this was a real pain, but it has been resolved for me for over a month now:

This thread has recovery mechanisms, but not a cure. Here is what stopped it coming back for us:

Every fix in this thread restores one launch. Reboot, sign-out, and the SYSTEM silo-hive
unload all work, and all three have to be done again after the next update. Several people
here are on their fifth or sixth occurrence in a fortnight. That is the actual shape of this
bug: it is not that you cannot get back in, it is that you have to keep getting back in.

We had it repeatedly, on updates, until July. Since then it has not come back, across fourteen
updates.

What we did was this:

Settings > Apps > Installed apps > Claude > Advanced options > Terminate, then _Reset_.

Not Reset-AppxPackage, not Repair, not an installer. The GUI buttons, Terminate first.

That ordering may matter. Several people here report Reset failing outright, including with
"we cannot reset this app's data at this time", which is what you would expect while the
package still has something running. Terminate first, then Reset.

It is destructive and it cost us our projects, so the rest of this is why it is different from
the reinstalls you have already tried, and what you lose by doing it.

Why reinstalling never helps

Almost everyone here has reinstalled, and it does nothing. There is a reason for that, and it
took reading our own deployment logs to see it.

Installing over the top is not a reinstall. Windows processes it as an update: same
package family, per-user state left completely untouched. winget install, the downloaded
installer over the top, Add-AppxPackage -Register are all the same story. Whatever is
wedged survives every one of them, because none of them touch it.

We reinstalled several times over five months. Our deployment log shows no removal of the
Claude package in that entire period. We thought we had reinstalled. We had not.

That is also why sign-out is the only thing that reliably works: it is the only common
action that tears down state rather than replacing files.

How Reset is different

Reset destroys the package's per-user state and re-registers it. That is a deployment-level
operation on the package, not a file swap, which is why it reaches something the installers
never do. On our machine it is the only such operation that has ever run against this package.

What it costs

Reset permanently destroys local app state. Copy %APPDATA%\Claude somewhere safe first,
whatever else you decide.

• We lost our projects. Every old conversation survived, but they came back as one

undifferentiated list, no longer grouped under the project each belonged to. That structure
never returned.

• %APPDATA%\Claude\claude_desktop_config.json holds your MCP server configuration and is in

the wiped tree. Save it. Restoring is a file copy.

• The app mints a new device identity and signs you out.

Knowing what the alternative was, we would make that trade again. But it is a real trade, and
"just reset the app" is advice that sounds free and is not.

Note that several people here report Repair and Reset-AppxPackage failing outright, so this
may not be available to you in that state.

---

Evidence

Windows 11 Home 26200, MSIX package Claude_pzs8sxrjxfjjc. All of the below is from
Microsoft-Windows-AppXDeployment/Operational and filesystem timestamps, not recollection.

The reset, 2026-07-11. Recorded in a note written that same afternoon: "Windows Settings ->
Apps -> Installed apps -> Claude -> Advanced options -> Terminate -> Reset". At 13:51:43 the
per-user state was destroyed and recreated:
LocalState, RoamingState and Settings under %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc
all carry that exact creation second, against a package folder created in March.
%APPDATA%\Claude\Local Storage was recreated six seconds later. SystemAppData\Helium still
dates from March, so the package was not reinstalled and the hives were not rebuilt. Only the
per-user data went.

It is the only deployment-level event in seven months. Our log retains back to 2026-02-01.
Across those seven months it holds exactly five deployment-operation records (event 332) for
this package, all between 13:50:56 and 13:51:43 on 2026-07-11. None before, none after.

No uninstall ever happened. 25 entries in that log name a package being removed. Not one
names Claude.

Fourteen updates have landed since: 1.21459.1.0, 1.22209.0.0, 1.22209.3.0, 1.24012.1.0,
1.24012.9.0, 1.24012.11.0, 1.25927.0.0, 1.26832.0.0, 1.28929.0.0, 1.30096.5.0, 1.32352.0.0,
1.32352.1.0, 1.40609.0.0, 1.40609.1.0. Seven weeks, including an in-place update this week,
and the package currently reports Status: Ok on the latest version.

Being straight about which half is evidenced: the update history above is from the logs. That
none of them wedged the app is our experience, not something I can show you, because
AppModel-Runtime/Admin retains about eight hours on this machine, so the failures from
before July are long gone. If you want to hold this to one verifiable claim, hold it to this:
the reset is the only deployment-level event this package has ever had here, and the problem
was routine before it and absent after.

Also did not work here, for the record: winget install --id Anthropic.Claude over the
top, and stopping plus disabling CoworkVMService before a launch attempt, consistent with
the controlled test upthread.

Separately: a negative result on the missing ApplicationData folder

On the theory that a missing
C:\ProgramData\Microsoft\Windows\AppRepository\Families\ApplicationData\Claude_pzs8sxrjxfjjc
is the persistent condition causing the recurrence: on our machine that folder is also absent,
and has been absent throughout all fourteen updates above.

Test-Path "C:\ProgramData\Microsoft\Windows\AppRepository\Families\ApplicationData\Claude_pzs8sxrjxfjjc"
False

So its absence looks like the normal state for this package rather than the cause. Worth
checking on another healthy machine before more triage goes into it.

One machine, one incident, seven weeks of clean updates behind it.

Still happening on Claude_1.40609.1.0_x64__pzs8sxrjxfjjc, Windows 11 Pro 10.0.26200 (x64).

Same pattern as OP, recurring for weeks/months across updates: "Another program is currently using this file" on the WindowsApps package path when launching/updating. Killing all Claude processes does not recover it — only a reboot (or presumably logoff/login per this thread) clears it.

Still reproducing on Claude_1.40609.1.0_x64__pzs8sxrjxfjjc, Windows 11 Pro 10.0.26100.

I can confirm the 215/208 activation failures, but my logs also show the MSIX deployment-time
half that the OP ruled out, and the two interleave in the same 14-second window. Posting in
case the correlation is useful.

Deployment layer: registration is deferred because the old version never exits

Microsoft-Windows-AppXDeploymentServer/Operational, across my last two updates:

8/28 11:14:56  658 warn   Marking package {Claude_1.40609.0.0} for deferred registration
                          because {Claude_1.37937.3.0} is still running.
8/28 17:19:50  419 error  0x80073D02: Unable to install because the following apps need to be
                          closed Claude_1.37937.3.0_x64__pzs8sxrjxfjjc.
8/28 17:20:06  401 error  Register on Claude_1.40609.0.0 failed with 0x80073D02
8/28 17:20:18  613 info   Failed to reach state ResolvedDeferredRegistrations
9/1  14:57:10  658 warn   Marking package {Claude_1.40609.1.0} for deferred registration
                          because {Claude_1.40609.0.0} is still running.

The package's own auto-start service outlives the app window

The package declares a packaged service, StartMode: Auto:

Name       : CoworkVMService     DisplayName: Claude     State: Running
PathName   : ...\WindowsApps\Claude_1.40609.1.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

On my machine it ran continuously from the 8/29 12:54 boot until 9/2 09:31:47, restarting
only when the new package registered. Closing the Claude window does not stop it, so the old
package version stays "running" for days, which is what event 658 is reporting.

Cleanup then fails on exactly the memory-mapped Electron files

8/27 16:37 - 17:06  471  error 0x12C: Deleting file
  \?\C:\Program Files\WindowsApps\Deleted\Claude_1.37937.1.0_...\app\resources.pak failed
  \?\C:\Program Files\WindowsApps\Deleted\Claude_1.37937.1.0_...\app\v8_context_snapshot.bin failed

Retried every ~6 minutes for half an hour, and only those two files. Those are the two an
Electron process memory-maps for its lifetime, which is consistent with a live mapping rather
than an ordinary open handle. That may be why handle.exe shows nothing: a mapped section
does not present as a file lock, but still blocks deletion.

The two layers correlate in one window

At next logon, deployment recovers and activation fails repeatedly in the same seconds:

09:31:37  215/208  0x80070020  cannot create Desktop AppX container / configure runtime
09:31:42  215      0x80070020
09:31:43  649      Trying to repair ACLs for ...\Claude_1.40609.1.0...
09:31:43  215/208  0x80070020
09:31:46  9648/9650  TerminateSingleService for update successful (CoworkVMService)
09:31:47  10007    Finished servicing singleton package, state -> enabled (0x0)
09:31:47           CoworkVMService restarts (new PID, new package path)
09:31:48  613      Register completed, 5125 ms
09:31:48  215/208  0x80070020
09:31:51  215/208  0x80070020

Event 649 ("Trying to repair ACLs ... Register next time should succeed") firing on every
recovery suggests the failed update leaves the package directory ACLs damaged, which would
explain why only a logoff clears it: the repair runs on the next logon register.

Accumulated debris

1230 warn  These hardlinks did not have packages in repository:
           \Program Files\WindowsApps\Claude_1.32352.0.0_x64__pzs8sxrjxfjjc\app\chrome_100_percent.pak
           \Program Files\WindowsApps\Claude_1.37937.0.0_x64__pzs8sxrjxfjjc\...

Also worth noting: the scheduled task \Microsoft\Windows\AppxDeploymentClient\Pre-staged app
cleanup is Disabled on this machine, so the WindowsApps\Deleted residue is never
collected. I do not know whether that is a Windows default or something the installer changed.

Suggestion

Whatever the container-layer root cause turns out to be, an auto-start packaged service inside
the same MSIX that the in-app updater replaces is a self-inflicted ordering problem. Stopping
CoworkVMService and draining the app's processes before staging, rather than letting
registration defer, would at least remove the deployment-time half.

I have not yet been able to test whether pre-stopping the service prevents the failure, since
it only reproduces on a real update. Happy to run diagnostics on the next one if anything
specific would help.

Adding a data point on a current build — this is still reproducing as of September 2026.

Environment

• Claude Desktop for Windows, MSIX package Claude_1.32352.1.0_…_pzs8sxrjxfjjc under C:\Program Files\WindowsApps\
• Windows 11
• Claude Code / Cowork are used from the desktop app

Symptom
After the app updates itself, every launch attempt fails with the generic sharing-violation dialog:

[Window Title]
C:\Program Files\WindowsApps\Claude_1.32352.1.0_...
[Content]
Another program is currently using this file.

Retrying does not help; the app stays unlaunchable until a full Windows reboot, after which the new version starts normally. It recurs with updates — not a one-off. Same pattern as #76357 (closed into this one), #73107 and #83932.

Ask
Whatever the exact holder is on a given machine (CoworkVMService, lingering packaged processes, or the orphaned container silo / Helium hive), the failure is identical from the user's side: an update is applied underneath a package that is still alive, and the next activation dies with 0x80070020. Tearing the container down fully before servicing, or self-healing on 0x80070020 at launch, would close this for everyone in the thread. Until then, a meaningful message instead of "Another program is currently using this file" would at least stop people from hunting for file locks that don't exist.

@bcherny
Windows arch: x64 (AMD64);
claude --version: 2.1.199 (Claude Code);
C:\Program Files\WindowsApps\Claude_1.40609.1.0_x64__pzs8sxrjxfjjc;

Additional impact: session index corruption + data loss (pinned + project sessions) following this bug

Hit this exact issue this morning (Windows, dialog reads "Há um outro programa usando este arquivo no momento", same 0x80070020 pattern from cowork-svc.exe). Followed the standard remediation attempts before finding this thread: killing the process tree, Reset-AppxPackage, restarting AppXSvc. None worked, consistent with what's already reported here (container-layer failure, not a real file lock).

What's not yet documented: the eventual reboot triggered a side effect beyond just recovering app launch. It corrupted the local Claude Code session index (Desktop "Code" tab), silently dropping several pinned and project sessions from the UI.

Root cause (confirmed via filesystem investigation):

• Session index lives at %APPDATA%\Claude\claude-code-sessions\<accountUuid>\<orgUuid>\, one local_<sessionId>.json per session.
• Pinned state (pinnedOrder) lives separately, in Local Storage LevelDB (dframe-store, Zustand).
• I found a LevelDB key frame-pinned-empty-hint timestamped before my reboot, showing the pinned list was already reporting empty while the app was stuck in the crash-loop state. So the corruption started during the failed relaunch attempts, before the reboot.
• On successful relaunch post-reboot, the app ran what looks like an automatic index cleanup: several sessions were converted from local_*.json to deleted_*.json (contents overwritten with just a timestamp, losing customTitle and other metadata), timestamped exactly at relaunch.
• Underlying conversation data (.jsonl files in .claude\projects\) was not touched, only the Desktop's session index/UI state was affected. This made most sessions recoverable by cross-referencing .jsonl files against index entries, but this required manual filesystem forensics; nothing in the app itself surfaced the missing sessions or offered recovery.
• Out of 20 affected sessions (5 pinned, 9 under a project folder, 6 under another), 19 had intact .jsonl transcripts and were successfully reindexed manually. 1 session (created but likely never received a first message) had no .jsonl and was unrecoverable. Pinned state itself (pinnedOrder) was not preserved anywhere and had to be manually reapplied per session after reindexing.

Suggestion for the team: the crash recovery/cleanup logic that runs on relaunch should not silently drop sessions from the index without also checking for a corresponding .jsonl. Pinned/recent state should probably be more resilient to (or at least logged during) this cleanup, since right now data loss here is silent and only recoverable via manual file inspection.

Happy to share the full investigation trace (timestamps, LevelDB keys, index diffs) if useful for a proper repro/fix.

Confirming this on x64, package Claude_1.40609.1.0_x64__pzs8sxrjxfjjc, Windows 11. Same signature as the original report. Adding diagnostics that may help narrow the cause.

AppModel-Runtime/Admin — every failed launch produces the same triple:

Id 215: 0x80070020: Cannot create the Desktop AppX container for package
        Claude_1.40609.1.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.
Id 217: Destroyed Desktop AppX container {...} for package Claude_1.40609.1.0_x64__pzs8sxrjxfjjc.
Id 208: 0x80070020: Cannot create the process for package
        Claude_1.40609.1.0_x64__pzs8sxrjxfjjc because an error was encountered while configuring runtime. [LaunchProcess]

Failures occur only on explicit launch attempts. No background or timer-driven occurrences.

Ruled out — no file lock exists.

handle64.exe -a -u run as Administrator, with the error dialog on screen:

handle64.exe -a -u -nobanner "WindowsApps\Claude"
No matching handles found.

Ruled out — ACLs are not the cause. icacls on the failing binary and on a binary from the same package that starts fine returns byte-identical output:

...\app\claude.exe                    BUILTIN\Users:(I)(Rc,S,RD,REA,X,RA) ...
...\app\resources\cowork-svc.exe      BUILTIN\Users:(I)(Rc,S,RD,REA,X,RA) ...

Both list ALL APPLICATION PACKAGES, Users, TrustedInstaller, SYSTEM with identical rights. AppXDeploymentServer/Operational logs an ACL repair (RepairAppRegistrationOption) reporting success and "Register next time should succeed", but the failure persists.

Ruled out — package state is healthy.

Name   Version     Status
Claude 1.40609.1.0 Ok

Add-AppxPackage -DisableDevelopmentMode -Register against the manifest, run repeatedly as admin, completes without error and does not resolve the failure.

Control — AppX container creation works for other packages. With Claude failing, Microsoft.WindowsCalculator launches normally in the same session. The container layer is not broken system-wide; the failure is specific to this package.

Launch parent is irrelevant. Fails identically from Start menu, from Start-Process shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude, and from an elevated PowerShell. Stop-Process -Name explorer -Force does not clear it.

Procmon (~6.5k events filtered to the package path). No SHARING VIOLATION on any package file. ACCESS DENIED rows on claude.exe and cowork-svc.exe come from Explorer/Taskmgr/perfmon icon extraction and appear for the working binary too, so they are not the failure. cowork-svc.exe starts successfully and maps its own image during the same window in which claude.exe cannot be launched.

CoworkVMService. StartType Automatic, Status Running with the app closed. Stop-Service -Force followed by killing all package processes does not allow a successful launch, so on x64 the service does not appear to be the blocker. Note that Set-Service -StartupType Manual fails with Access is denied even from an elevated admin shell, since the service object is owned by TrustedInstaller — so users cannot apply that as a mitigation.

Recovery. Signing out and back in resolves it, without a full reboot. Consistent with a session-scoped job object being the blocker.

Impact. Recurs at each update. There is no user-side configuration that prevents it; sign-out is recovery only.

Correction to my own test from 2026-08-30: the 210-without-217 condition I proposed there is too
narrow. I hit the failure again on 2026-09-01 with the teardown present.

Machine A, update to 1.40609.1.0, package folder created 20:45:24. Failed launches at 22:22 and
22:26, both the usual 0x80070020. This time the AppModel-Runtime/Admin log reached back ten
hours and covered the whole update window:

21:34:37  217  container for Claude_1.40609.0.0 destroyed   <- old package torn down
21:34:38  210  container for Claude_1.40609.1.0 created
22:22:09  215/208  0x80070020

The old package's container was destroyed 48 minutes before the first failed launch. So the
teardown happened, and the launch still failed.

At the same moment, HKLM\SYSTEM\CurrentControlSet\Control\hivelist still listed eight Claude
silo hives, with no Claude.exe running. That is the point: event 217 reports the container,
not the silo. The two come apart, and the hivelist is the more reliable signal.

Two further measurements from the same night, in case they save anyone time:

• A full, successful Register deployment (event 400, 1594 ms, including ACL repair) completed

seconds before the second failed launch. Re-registering does not clear the silo.

• I scanned every handle in the system (NtQuerySystemInformation, then NtQueryKey on each

duplicated handle): 615,302 handles, 15,363 of them registry keys, none inside the Claude
silo. Six of the eight hives can be unloaded with NtUnloadKey from an elevated session
(stopping CoworkVMService alone takes it from 8 to 5); the last two return
STATUS_CANNOT_DELETE and stay. So there is no user-mode process holding them - the mount is
kernel-side and belongs to the silo object, which the session manager tears down at logoff.

That also explains why signing out is the only reliable fix, and why every lighter workaround I
tried stops short. If you are collecting data points, the useful question is not "did 217 fire?"
but "does the hivelist still show Claude silos after the update?".

Reporting back on the Start=4 test I said I would follow up on, plus a direct answer to
@aonsi55's point that users cannot apply the service mitigation.

Four consecutive clean update cycles

Since disabling CoworkVMService on 2026-08-27, this machine (Windows 11 Pro 26100) has taken
four in-place updates with no failure:

08-28 23:25  1.37937.3 -> 1.40609.0   0 x 215/208, event 201 OK
09-02 04:03  1.40609.0 -> 1.40609.1   0 x 215/208, event 201 OK
09-02 23:23  1.40609.1 -> 1.44121.1   0 x 215/208, event 201 OK
09-03 08:33  1.44121.1 -> 1.44121.2   0 x 215/208, event 201 OK

No reboot across any of them - the machine has been up since 08-31 15:49. The two updates
immediately before this change (08-26 and 08-27) both wedged and both needed a reboot.

I want to be careful about what that is and is not. It is one machine, n=4, against n=2
failures. @SpectraWorksVision and @aonsi55 both report that stopping and disabling the service
did not help them, so this is not a general fix and I am not claiming causation.

A distinction that might reconcile the conflicting results

The negative reports I can find describe stopping the service while already wedged. That
matches everyone's experience, mine included: once the silo hives are orphaned there is nothing
to kill, as @Ciki and @juergenbeck have both demonstrated with full handle enumeration.

What I changed is different in timing: the service was absent at the moment of
re-registration, not stopped afterwards. If the ordering hypothesis in this thread is right,
those are two different experiments, and only the second one can affect whether the silo leaks
in the first place.

That is testable and I would rather it be tested than believed. The falsifiable prediction is
that pre-emptive disabling changes the outcome and post-hoc stopping does not.

@aonsi55: the mitigation is applicable, just not through Set-Service

Set-Service -StartupType Manual fails with Access is denied even from an elevated admin shell, since the service object is owned by TrustedInstaller - so users cannot apply that as a mitigation.

Confirmed on the SCM path, but writing the registry value directly works from an elevated
shell:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService" /v Start /t REG_DWORD /d 4 /f

Verified after: Start = 4, service Stopped / Disabled, no cowork-svc.exe running, and it
survives reboots. So the mitigation is reachable; it just cannot be applied through the service
control manager.

Every update re-arms it - 4 out of 4

Following up on my 08-31 comment: the re-arm is not occasional. Event 7045 fired on every one
of the four updates above, each time reinstalling the service as auto start, silently
restoring Start=2.

This matters for anyone testing a mitigation here: a machine that "worked after the
workaround" may simply no longer have the workaround applied. Worth checking Start before
attributing a pass or a failure.

I automated the re-application with a scheduled task triggered on System event 7045 filtered to
ServiceName='Claude', 60-second delay, running as SYSTEM, which re-writes Start=4. It has
fired correctly on the last two updates:

09-02 23:22:59  7045 service reinstalled as auto start
09-02 23:24:02  task ran: found Start=2 / Running -> set Start=4 / Stopped
09-03 08:33:52  7045 service reinstalled as auto start
09-03 08:34:55  task ran: found Start=2 / Running -> set Start=4 / Stopped

Note for anyone copying this: unlike event 215, event 7045's EventData has a stable
ServiceName value (Claude), so an XPath-filtered subscription does keep matching after
updates - the versioned-string problem @DrRIH hit with 215 does not apply here.

Hivelist corroboration

@juergenbeck's point that the hivelist is the reliable signal matches what I see. With the app
running normally, this machine shows exactly 5 mounted Claude silo hives:

\REGISTRY\WC\Silo<guid>software / user_sid / user_classes / com   (4)
\REGISTRY\WC\Silo<other-guid>com                                  (1)

That is consistent with @juergenbeck's observation that stopping CoworkVMService takes the
count from 8 to 5 - i.e. the three that drop are the service's own silo. So "5 while the app is
running" looks like the healthy baseline, and hives present with zero Claude.exe
processes is the wedged state. I have added that as the primary check in my own tooling rather
than looking for file locks.

Log retention

Seconding @DrRIH: Microsoft-Windows-AppModel-Runtime/Admin ships at 1052672 bytes and held
only about six days here. AppXDeploymentServer/Operational shipped at 5 MB. I raised both to
32 MB. Anyone planning to report on their next occurrence should do this first, or the evidence
will already be gone by the time they look.

Still no maintainer response

Echoing @mySebbe: this issue has been open since April, is now past 50 comments with multiple
independent root-cause analyses, and there is still no confirmation that it is tracked
internally. A short acknowledgement, or a request for a specific diagnostic bundle, would let
the people in this thread stop duplicating each other's forensics.

Still broken on 2026-09-03. Claude Desktop MSIX 1.44121.4.0 (Claude_1.44121.4.0_x64__pzs8sxrjxfjjc), Windows 11.

This exact dialog (“Another program is currently using this file”, title bar C:\Program Files\WindowsApps\Claude_*) has been on the public tracker since at least April 2026 (#42776, #45400). The later cluster is the same bug, not a new one: #46179, #73694, #83932, #83968, #88101, #88181, #89680, #90031, and this thread. Months of duplicates, still shipping.

Reproduced today after [stealth-update] / beforeQuitForUpdate:

• CoworkVMService Running, WIN32_PACKAGED_PROCESS, AUTO_START, LocalSystem, binary inside the versioned package
• Stop-Service works without elevation; sc config start= demand and Set-Service Manual both Access denied
• AUMID launch respawns cowork-svc.exe; Claude.exe never starts
• AppModel-Runtime/Admin 215+208: 0x80070020 converting the job / LaunchProcess
• chrome-native-host.exe held by Edge/Chrome native messaging; desktop logs EBUSY copyfile on every stealth relaunch (#88181)

The no-reboot workaround is not enough once AUTO_START grabs the package job. Remaining recovery is still reboot or sign-out.

adding a data point on the CoworkVMService mitigation from @catseye82's comment above. on my machine the msix update reset the service start type back to auto, so it's worth re-checking the value after an update instead of assuming it stuck.

windows 11 home 26200, package family Claude_pzs8sxrjxfjjc.

timeline:

04:37  wedged on 1.44121.2.0, recovered with the SYSTEM NtUnloadKey2 route from this thread
       (4 hives returned 0x00000000, one COM hive returned 0xC0000121, User.dat and
        UserClasses.dat both freed)
04:41  set CoworkVMService Start=3 (manual), confirmed DEMAND_START
04:59  app auto updated itself 1.44121.2.0 -> 1.44121.4.0, unattended
06:10  CoworkVMService is back to START_TYPE : 2 AUTO_START

so the package re-registers its services when it registers, and anything you set under HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService does not survive an update. that also means "n clean update cycles since i changed it" might be measuring a setting that isn't applied anymore, so probably worth re-checking the value before reading much into it.

two smaller things:

Start=3 (manual) seems to be enough, i don't think you need Start=4. with manual the service still starts on demand when the app launches, so you don't have to give up cowork to get the mitigation. but i only have one clean update cycle on this and that same update reset the value, so treat it as untested rather than confirmed.

the 04:59 update itself was clean, with Start=3 in effect at the time:

04:59:07  210  Created Desktop AppX container ... for Claude_1.44121.4.0
04:59:11  211  Added process 12868 to container ...
04:59:11  201  Created process 12868 for application Claude_pzs8sxrjxfjjc!Claude

no 215/208 across the update or on any launch since. one sample though, not claiming cause.

on automating the recovery, the unload helper can be run from a scheduled task (SYSTEM, highest privileges) with an event trigger on EventID 215 in Microsoft-Windows-AppModel-Runtime/Admin, instead of running it by hand every time you get wedged. guard it so it does nothing while Claude.exe is running. the kernel refuses in-use hives with 0xC0000121 anyway so a stray run doesn't hurt.

might also be related to #86157, sc qtriggerinfo here shows the named pipe trigger registered as CUSTOM : 1f81d131-3e60-4c76-9860-37334e4ffce3 [ETW PROVIDER UUID] with DATA : \pipe\cowork-vm-service.

Still reproducing on a much newer build — confirming this is not fixed.

Environment

• OS: Windows 11 Pro 25H2 (OS build 26200.9168)
• Claude Desktop: 1.44121.2.0 x64 (Claude_pzs8sxrjxfjjc)

Same signature as the original report: on every failed launch, one container is
created (210) and a process is added to it (211), then the follow-up container
creations fail with 0x80070020 ... converting the job (215) and the launch
aborts (208). Seven consecutive attempts between 14:33 and 14:45, all identical.

Two data points that narrow the "already attempted" list:

1. CoworkVMService was already Stopped at the time of the failure.

Get-Service CoworkVMService reported Stopped while the error dialog was
showing; running Stop-Service -Force from an elevated prompt changed
nothing. So the leak survives the service being down, not just being
restarted.

1. Package state is clean — no leftover version, no remediation needed:

Name : Claude
Version : 1.44121.2.0
Status : Ok

I also see a container destroyed at activation time whose GUID belongs to an
earlier session ({683F0334-...} while everything else in that attempt is
FD0D4...), which seems consistent with the leaked-handle hypothesis.

In my case reinstalling the package also restores it, but the failure comes
back after roughly 4-5 hours of use.

Having the same issue:

TimeCreated : 4/09/2026 1:09:13 PM
Id : 208
LevelDisplayName : Error
Message : 0x80070020: Cannot create the process for package Claude_1.46388.1.0_x64__pzs8sxrjxfjjc because an
error was encountered while configuring runtime. [LaunchProcess]

Copy-paste version of the SYSTEM NtUnloadKey2 route from this thread, as one self-contained script. Worked for me today (2026-09-04) on Windows 11 Pro 26200, Claude 1.46388.1.0 (Claude_pzs8sxrjxfjjc), zero Claude processes, Event 215/208 0x80070020. Five Claude Silo hives were listed in hivelist; after the unload Claude launched immediately, no sign-out or reboot.

No PsExec or other tools needed. It self-elevates (one UAC prompt), re-runs itself as SYSTEM through a one-shot scheduled task, force-unloads only Silo hives whose backing file belongs to the Claude package family (max two passes), deletes the task, prints the log, and launches Claude.

Save as Rescue-ClaudeDesktop.ps1, then:

powershell -NoProfile -ExecutionPolicy Bypass -File .\Rescue-ClaudeDesktop.ps1

Do not run it while Claude is actually working; it unloads Claude's live hives.

# Rescue Claude Desktop after an update leaves its container registry hives
# mounted in an orphaned Silo (AppModel-Runtime Event 208/215, 0x80070020,
# zero Claude processes). Force-unloads only Claude package-family Silo hives
# as SYSTEM, then launches Claude. No PsExec or other external tools.
#
#   powershell -NoProfile -ExecutionPolicy Bypass -File Rescue-ClaudeDesktop.ps1
#
# Do not run while Claude Desktop is working: it unloads Claude's live hives.
param([switch]$AsSystem)

$ErrorActionPreference = 'Stop'
$family = 'pzs8sxrjxfjjc'

function Get-ClaudeSilos {
    (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\hivelist').PSObject.Properties |
        Where-Object { $_.Name -like '\REGISTRY\WC\Silo*' -and $_.Value -match $family }
}

if ($AsSystem) {
    Add-Type -TypeDefinition @"
using System;
using System.Runtime.InteropServices;
public static class NtReg {
    [StructLayout(LayoutKind.Sequential)] public struct UNICODE_STRING { public ushort Length; public ushort MaximumLength; public IntPtr Buffer; }
    [StructLayout(LayoutKind.Sequential)] public struct OBJECT_ATTRIBUTES { public int Length; public IntPtr RootDirectory; public IntPtr ObjectName; public uint Attributes; public IntPtr SecurityDescriptor; public IntPtr SecurityQualityOfService; }
    [DllImport("ntdll.dll")] public static extern int NtUnloadKey2(ref OBJECT_ATTRIBUTES TargetKey, uint Flags);
    [DllImport("ntdll.dll")] public static extern int RtlAdjustPrivilege(int Privilege, byte Enable, byte CurrentThread, out byte WasEnabled);
    public static int Unload(string ntPath) {
        byte was; RtlAdjustPrivilege(18, 1, 0, out was); // SeRestorePrivilege
        var us = new UNICODE_STRING(); us.Buffer = Marshal.StringToHGlobalUni(ntPath);
        us.Length = (ushort)(ntPath.Length * 2); us.MaximumLength = (ushort)(us.Length + 2);
        IntPtr pUs = Marshal.AllocHGlobal(Marshal.SizeOf(us)); Marshal.StructureToPtr(us, pUs, false);
        var oa = new OBJECT_ATTRIBUTES(); oa.Length = Marshal.SizeOf(oa); oa.ObjectName = pUs; oa.Attributes = 0x40;
        try { return NtUnloadKey2(ref oa, 1); } // 1 = REG_FORCE_UNLOAD
        finally { Marshal.FreeHGlobal(pUs); Marshal.FreeHGlobal(us.Buffer); }
    }
}
"@
    foreach ($pass in 1..2) {
        $targets = Get-ClaudeSilos
        if (-not $targets) { 'no Claude silo hives mounted'; break }
        foreach ($hive in $targets) {
            'pass {0}  0x{1:X8}  {2}' -f $pass, [NtReg]::Unload($hive.Name), $hive.Name
        }
    }
    $left = Get-ClaudeSilos
    if ($left) { 'STILL MOUNTED:'; $left | Format-Table Name, Value -AutoSize -Wrap } else { 'done: no Claude silo hives remain' }
    exit 0
}

# Elevate, then re-run this same file as SYSTEM through a one-shot scheduled task.
$identity = [Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()
if (-not $identity.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
    $p = Start-Process powershell.exe -Verb RunAs -Wait -PassThru -ArgumentList @(
        '-NoProfile', '-ExecutionPolicy', 'Bypass', '-File', $PSCommandPath)
    exit $p.ExitCode
}

$taskName = 'ClaudeSilo-' + [Guid]::NewGuid().ToString('N')
$log = Join-Path $env:TEMP 'claude-silo-rescue.log'
Remove-Item $log -ErrorAction SilentlyContinue
$taskArgs = '-NoProfile -ExecutionPolicy Bypass -File "{0}" -AsSystem *> "{1}"' -f $PSCommandPath, $log
$action = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument $taskArgs
$trigger = New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(5)
try {
    Register-ScheduledTask -TaskName $taskName -Action $action -Trigger $trigger -User SYSTEM -RunLevel Highest -Force | Out-Null
    Start-ScheduledTask -TaskName $taskName
    do { Start-Sleep -Milliseconds 500 } while ((Get-ScheduledTask -TaskName $taskName).State -eq 'Running')
}
finally {
    Unregister-ScheduledTask -TaskName $taskName -Confirm:$false -ErrorAction SilentlyContinue
}

if (Test-Path $log) { Get-Content $log } else { 'no log written by SYSTEM task' }
explorer.exe "shell:AppsFolder\Claude_$family!Claude"

Log ends with done: no Claude silo hives remain on success. If it prints STILL MOUNTED, sign out and back in instead of re-running it.

Following up on the Start=4 test I said I would report on. It is not a fix. Four clean
update cycles, then a failure on the fifth, with the workaround correctly in place.

4 pass, 1 fail

08-28 23:25  1.37937.3 -> 1.40609.0    pass   0 x 215/208, event 201
09-02 04:03  1.40609.0 -> 1.40609.1    pass   0 x 215/208, event 201
09-02 23:23  1.40609.1 -> 1.44121.1    pass   0 x 215/208, event 201
09-03 08:33  1.44121.1 -> 1.44121.2    pass   0 x 215/208, event 201
09-04 15:56  1.44121.4 -> 1.46388.1    FAIL   15 x 215/208

Windows 11 Pro 26100. The two updates before this change (08-26, 08-27) both failed, so on this
machine the change did correlate with a run of passes - but it does not prevent the failure. I
would now describe it as a partial mitigation at best, and I would not want my earlier comment
read as a working workaround.

What was different about the run that failed

The failing cycle had an extra step the four passing ones did not: the deferred registration was
attempted and failed once before the forced one.

13:56:04  400   Add completed (staged), registration deferred - app running
15:51:07  638   still running {Claude_pzs8sxrjxfjjc!Claude}
15:51:07  419   error 0x80073D02: apps must be closed: Claude_1.44121.4.0
15:51:07  401   Register failed with 0x80073D02
15:55:29  603   RegisterByPackageFamilyName, ForceApplicationShutdownOption
15:56:03  9650  terminated service CoworkVMService of Claude_1.44121.4.0
15:56:03  7045  service reinstalled as auto start (Claude_1.46388.1.0)
15:56:05  211   process 447068 added to the new container   <- cowork-svc, 2s after 7045
15:56:04  215   0x80070020 (first failure)

In the four passing cycles the app's own process reached its container within 2-3 seconds and
produced its 201. Here it did not, and the service took it instead. I cannot tell from the
logs whether the failed 15:51 register is causal or incidental, but it is the one structural
difference I can see between the runs.

Negative result: an event-7045-triggered guard cannot win this race

I had automated the re-application with a scheduled task on System event 7045, 60-second delay.
It fired correctly, but 60 seconds is far too late - the service joins the container 2 seconds
after 7045. Shortening the delay does not fix it either; SCM starts the service essentially
immediately on reinstall. Anyone considering this approach should know it cannot be won from the
7045 side.

Negative result: stopping the service after the wedge does nothing (confirmed here too)

I ran the disable script at 15:56:50, verified Start=4, Stopped, no cowork-svc.exe. The
failures continued unchanged:

15:57:06  215/208     15:57:11  215/208
15:58:06  215/208     15:58:11  215/208

Add-AppxPackage -Register (Windows' own ACL-repair register at 15:57:06-09, "Register next time
should succeed") also changed nothing. This reproduces what @aonsi55 and @SpectraWorksVision
reported, on a machine where the pre-emptive version had appeared to help. So both halves are now
observed on the same box: pre-emptive disabling correlates with passes, post-hoc disabling is
inert.

Recovery: logoff worked, but calling it the "light" fix is misleading

15:59:24  Winlogon: logoff        (explorer PID 13384 -> 113876)
15:59:33  logon
16:00:09  210/211/201             app launches normally

No reboot, machine up since 08-31. But for a workstation user this is not a cheaper recovery than
a reboot in any way that matters: it closes every open application. In my case that meant two 3ds
Max sessions with unsaved scenes, a running screen capture, and a build. The only difference from
a reboot is about 90 seconds of POST time. The thread often presents logoff as the mild option; it
is the same loss.

The 7045 re-arm is now 5 for 5

Every one of the five updates above reinstalled the service as auto start, wiping Start=4.
Worth repeating for anyone testing mitigations: check the value before attributing an outcome.

@aonsi55: the registry path does work

Set-Service -StartupType Manual fails with Access is denied even from an elevated admin shell ... so users cannot apply that as a mitigation.

Confirmed on the SCM path, but the registry write succeeds from an elevated shell and survives
reboots:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService" /v Start /t REG_DWORD /d 4 /f

Given the 4-of-5 result above, I would call that worth applying and not worth trusting.

One detail on disableAutoUpdates that I have not seen mentioned

This gets suggested as the way to take control of when the risky moment happens. It works, but the
cost is larger than "you update manually". Reading the shipped app.asar, the policy also removes
the manual path:

t = ... && U().autoUpdate.disabled !== true
{ label: "Check for Updates…", visible: t, ... }

with a later filter dropping any item whose visible is false. The app's own description of the
key is *"Stop Claude Desktop from fetching updates entirely (no time limit). You'll need to push
new versions yourself."* So there is no update notification and no in-app check - you have to
watch the release feed yourself. On a build shipping this often (7 updates here in ten days) that
is a real burden for an individual user, as opposed to a fleet with an MDM behind it.

Where this leaves a single user

There is currently no user-side prevention. The mitigation helps sometimes, the recovery costs a
full session either way, and turning off updates costs visibility into updates. I have gone back
to leaving it alone and rebooting when it happens, which is not a good place for a paid product to
leave people. Still no maintainer response on the canonical issue.

Additional data point, with a measurement that I think narrows this down further than what is in the thread so far. Two things I could not find posted yet:

1. A negative control proving the session's AppX layer is healthy — it is not "AppX is broken in session 1", it is specific to this one package.
2. A PID/container correlation showing that cowork-svc.exe is the only process of the package that ever successfully gets a container, while the app process never does.

Environment

• Windows 11 Home 10.0.26200
• Claude_1.46388.2.0_x64__pzs8sxrjxfjjc, Status: Ok, InstallLocation: C:\Program Files\WindowsApps\...
• Cowork enabled, CoworkVMService running (WIN32_PACKAGED_PROCESS, START_TYPE: 2 AUTO_START, LocalSystem, binary inside the versioned package dir)
• Uptime at time of failure: 8 days 19 hours

Recurrence

I have a local watchdog that logs every AppXDeployment event 208/404 for this package. Since 2026-07-12 it has recorded 30 events across 13 distinct days and 12 distinct package versions:

1.20186.1.0   1.22209.0.0   1.24012.9.0   1.24012.11.0
1.25927.0.0   1.26832.0.0   1.30096.5.0   1.32885.1.0
1.34493.1.0   1.44121.2.0   1.46388.1.0   1.46388.2.0

Every single occurrence was triggered by an in-place self-update. Different versions, different boots — so this is not a one-off corrupted state.

The failure, end to end

The app quits itself for a stealth update and never comes back. From main.log:

16:14:25 [info] [stealth-update] Triggering stealth update after idle timeout
16:14:25 [info] [stealth-relaunch] Saved z-order anchor: 0x210966 (above our 0x7b0e90)
16:14:25 [info] [stealth-relaunch] Saved navigation history (50 entries, active=49)
16:14:25 [info] [CCD] Killing 5 PTY process tree(s) on quit
16:14:28 [info] beforeQuitForUpdate handler fired, going down for update
16:14:28 [info] Windows session ending (close-app) - quitting the app

That is the last line the app ever wrote. Every launch attempt afterwards produces no log line at all — the main process never reaches logger init.

Microsoft-Windows-AppModel-Runtime/Admin, one launch attempt (18:44), millisecond resolution:

18:44:14.921  215  0x80070020  container ... error converting the job
18:44:14.921  217       container {6FB5F188-...} destroyed
18:44:15.057  215  0x80070020  container ... error converting the job
18:44:15.057  217       container {6FB5F189-...} destroyed
18:44:15.058  208  0x80070020  LaunchProcess failed
18:44:15.841   68       runtime state -> 0x80000
18:44:15.841  217       container {6FB5EF2E-...} destroyed   <- leftover from the 18:41 attempt
18:44:15.980   68       runtime state -> 0x0
18:44:16.011  210       container {6FB5F18D-...} CREATED
18:44:16.011  211       process 581628 added to container 6fb5f18d
18:44:16.393  215  0x80070020  container ... error converting the job
18:44:16.405  215  0x80070020  container ... error converting the job
18:44:16.405  208  0x80070020  LaunchProcess failed
18:44:22.232  217       container {6FB5F18D-...} destroyed
18:44:26.163  215  0x80070020
18:44:26.369  215  0x80070020
18:44:26.369  208  0x80070020  LaunchProcess failed
18:44:26.930  210       container {6FB5F1A9-...} CREATED
18:44:26.930  211       process 581652 added to container 6fb5f1a9
18:44:27.258  215  0x80070020
18:44:27.271  215  0x80070020
18:44:27.271  208  0x80070020  LaunchProcess failed

The correlation: who wins the container

I polled Win32_Process for newly created processes during that same launch attempt:

18:44:16  NEW PID=581628  cowork-svc.exe
18:44:26  NEW PID=581652  cowork-svc.exe

Both PIDs match exactly the two Id=211 events above. On an earlier attempt the same holds: Id=211 reports process 578248 added to container {6FB5ED5C} at 18:37:43, and Win32_Process shows cowork-svc.exe PID 578248 created at 18:37:43.

In every single attempt, the only process of this package that is ever successfully placed into a Desktop AppX container is cowork-svc.exe (session 0, LocalSystem). The app's own process in the user session never gets one.

cowork-service.log shows the service crash-looping while this happens — it starts, waits for a handoff that never comes, dies, restarts:

Service ready. Listening on \\.\pipe\cowork-vm-service
Warning: failed to configure recovery actions ...: open service: Access is denied.
Service stop requested
Warning: failed to disarm recovery actions for this stop: open service: Access is denied.

This matches #28231 — the app has no chat-only fallback when the CoworkVMService handoff fails, so it takes the whole process down, and that is the crash that leaks the silo.

Negative control: the session and the AppX layer are fine

This is the part I have not seen posted. Two other MSIX packages were activated from the same user session (session 1), minutes and seconds apart from Claude failures:

18:41:07  210  container {6FB5EF34-...} created for Microsoft.DesktopAppInstaller_1.29.289.0_x64__8wekyb3d8bbwe
18:41:07  211  process 582292 added
18:41:08  217  container destroyed cleanly

— created in the same second as a Claude 0x80070020 failure.

18:45:03.401  211  process 578568 added to container b483fbb7-... for Microsoft.WindowsNotepad
18:45:03.402  201  process 578568 for Microsoft.WindowsNotepad_...!App started successfully

So Desktop AppX container creation, job→silo conversion and activation all work correctly in this session at the exact time Claude cannot be launched. The orphan is package-scoped, not session-scoped. Anything suggesting "reset your Windows AppX stack" is chasing the wrong layer.

Remedies attempted, all ineffective

Confirming the list already in this issue — each of these reported success and changed nothing:

| Attempt | Result |
|---|---|
| Add-AppxPackage -Register "...\AppxManifest.xml" -DisableDevelopmentMode | returns OK, app still will not launch |
| Stop-Service CoworkVMService -Force | service is restarted on the next activation attempt |
| Stop-Service + Stop-Process cowork-svc + re-register, in one sequence | no change |
| Killing every Claude/cowork process | no change |
| Checked PendingFileRenameOperations | no Claude entries (only Chrome/OneDrive) |
| Checked Crashpad | no dumps written |
| Checked for stale package versions in WindowsApps | none |

Two side observations

1. The packaged service cannot manage its own recovery actions. sc sdshow CoworkVMService:

D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-...)

The second ACE is NT SERVICE\AppXSvc. The AU ACE has no DC (SERVICE_CHANGE_CONFIG), and there is no ACE for SY or BA — so the service, running as LocalSystem, cannot call ChangeServiceConfig2 on itself. That is why both "failed to configure recovery actions" and "failed to disarm recovery actions for this stop" appear on every start/stop. sc qfailure confirms no recovery actions are armed at all. If the intent of the disarm-on-stop logic is to keep SCM from auto-restarting the service during package servicing, that logic is inert as shipped.

2. C:\ProgramData\Claude\Logs\cowork-service.log has grown to 526 MB with no rotation. The crash-loop above appends to it continuously while the app is unlaunchable.

Request

Nothing here changes the ask already in this issue, but it does sharpen it:

• The leaked silo is scoped to the package, not the session — a targeted teardown should be possible without forcing logoff/reboot.
• A chat-only fallback when the CoworkVMService handoff fails (#28231) would prevent the crash that leaks the silo in the first place.
• Until then, the self-update relaunch is the trigger in 100% of the 30 occurrences I logged. Deferring the relaunch, or verifying the previous silo is gone before relaunching, would cut the failure rate sharply for anyone running Cowork.

Happy to provide the full event traces or the watchdog log if useful.

Post-update relaunch fails with 0x80070020 (leaked AppX job); no file lock and no crash involved

[🤖] Adding a data point here, since #76357 was closed as a duplicate of this issue. My log supports this thread's central claim — that the "file in use" message is misleading and there is no lock in the install directory — and I can now show it directly: the Cowork service was explicitly stopped and no package process was alive, and the launch still failed with the same dialog. It also contradicts the file-lock mechanism proposed in #76357 and the AppInfo-service mechanism proposed in #61635.

Environment

• Claude Desktop for Windows, MSIX (x64)
• Package family: Claude_pzs8sxrjxfjjc
• Version at failure: 1.46388.3.0
• Two updates applied the same day: 1.44121.4.0 → 1.46388.2.0 → 1.46388.3.0
• Windows 11 Pro, 10.0.26100 (build 26100), x64-based PC (not ARM64 — distinguishing this from #61635)
• Virtual Machine Platform and Hyper-V both Disabled (see "Secondary finding")

Symptom

Windows dialog: "Another program is currently using this file", pointing at C:\Program Files\WindowsApps\Claude_1.46388.3.0_x64__pzs8sxrjxfjjc\...

Every relaunch fails identically. Signing out of Windows and back in resolves it; a full reboot is not required.

Timeline

Reconstructed from C:\ProgramData\Claude\Logs\cowork-service.log and Microsoft-Windows-AppModel-Runtime/Admin. Username, home paths and SID redacted.

| Time | Event |
|---|---|
| 12:28:10 | App exits (RPC EOF); service stop requested; Service stopped |
| 12:28:12 | Service restarts on 1.46388.2.0 |
| 12:28:19 | App reconnects, signature verified — update succeeded |
| 13:47:15 | App exits (RPC EOF); service stop requested; Service stopped |
| 13:47:17 | Service restarts on 1.46388.3.0 |
| — | App never reconnects. No client connection until 15:03:35 |
| 13:49:51 / 13:49:52 | Stop + restart (failed launch attempt) |
| 13:54:34 | Stop + restart (failed launch attempt) |
| 14:45:39 | Service start with no preceding stop — prior instance died without shutdown |
| 14:46:00 | Service start with no preceding stop — same again |
| 14:49:53 | Stop-Service CoworkVMService by hand; clean stop, service confirmed Stopped |
| — | Launch attempted with service stopped and no package process alive → same error. No service start logged; claude.exe failed before SCM was asked to start it |
| 14:51:04 | Sign out / sign in; service starts |
| 15:03:35 | App connects, signature verified — working, still on 1.46388.3.0 |

Get-AppxPackage *Claude* afterwards: 1.46388.3.0, Status: Ok. The package registration was never damaged.

AppModel-Runtime events at 14:46:00

68  AppModel Runtime status ... updated to 0x80000 (previous status = 0x0)
68  AppModel Runtime status ... successfully updated to 0x0 (previous status = 0x80000)
210 Created Desktop AppX container {196319F5-...} for package Claude_1.46388.3.0_x64__pzs8sxrjxfjjc
211 Added process 7540 to Desktop AppX container 196319f5-...
219 PSMFlags for Desktop AppX process %1 with applicationID %2 is %3
217 Destroyed Desktop AppX container {196319F8-...}
215 0x80070020: Cannot create the Desktop AppX container ... because an error was encountered converting the job.
217 Destroyed Desktop AppX container {196319F9-...}
215 0x80070020: Cannot create the Desktop AppX container ... (same)
208 0x80070020: Cannot create the process for package ... because an error was encountered while configuring runtime. [LaunchProcess]

PID 7540 was cowork-svc.exe — confirmed live at the time via Get-Process, running from the package path and owned by service CoworkVMService (StartMode: Auto).

What this establishes

1. No crash. Nothing from Application Error (1000) or hang (1002); no claude.exe entries in the Application log at all. The app exited cleanly (RPC EOF, orderly Service stop requested → Service stopped) as part of the normal update relaunch. The failure is in the post-update relaunch, not in applying the update — the package flipped to 1.46388.3.0 correctly and the service restarted on it.

1. No file lock. The decisive test: with CoworkVMService stopped and verified Stopped, and no process running from the package path, the launch still produced the same "file in use" dialog. Nothing in user space was holding anything. The blocker is the leaked job object, and the dialog text is misleading (as #53247 argues).

1. The service was enrolled in the app's per-launch container. Event 211 added the cowork-svc.exe PID to container ...F5. Correspondingly, the service instances started at 13:54:34 and 14:45:39 both vanish from the log with no Service stopped line — container teardown takes the process with it. A machine-wide Windows service being scoped into a per-launch AppX container looks wrong on its own, and it explains both the unclean exits and the leaked job.

1. The service survived the recovery. The instance started at 14:51:04 is the same one that served the successful 15:03:35 launch — no stop, no restart in between. Same service process across the broken and working state. What the sign-out cleared was the session-scoped job, nothing else.

Secondary finding: the service cannot configure its own recovery actions

Every start logs:

Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.

and every stop logs:

Warning: failed to disarm recovery actions for this stop: open service: Access is denied.

The service lacks SERVICE_CHANGE_CONFIG on itself. Its own message describes the consequence: it "may be auto-restarted during package servicing" — the mechanism #76357 blamed for update-time locking. Worth fixing regardless of this bug.

The same ACL blocks administrators: Set-Service -Name CoworkVMService -StartupType Manual returns "Access is denied" even from an elevated PowerShell, so users cannot opt out of the service as a workaround. Stop-Service is permitted.

Secondary finding: Cowork's VM backend is non-functional on this machine

Every service start logs:

[HCS] Warning: Failed to load vmcompute.dll: The specified module could not be found.
[HCN] Initialized HCN API from computenetwork.dll
[Cleanup] Warning: failed to enumerate HCN networks: HcnEnumerateNetworks failed with HRESULT 0x800706d9
[VM] Stale VM scan failed, continuing without cleanup: HCS not initialized

Virtual Machine Platform / Hyper-V is not installed — confirmed directly:

FeatureName               State
-----------               -----
VirtualMachinePlatform Disabled
Microsoft-Hyper-V-All  Disabled

So HCS never initializes and the stale-VM cleanup pass has never run. The service still starts, still joins the app's container, and still participates in the launch lifecycle while being unable to do its actual work. If Cowork is unavailable, the service arguably should not be started at all — or at minimum should not be enrolled in the app container.

Expected behaviour

• Launch should not fail because a job object from a previous session was not torn down; if a stale container is detected, it should be reclaimed rather than surfaced as an error.
• The error dialog should not claim a file is in use when the failure is at the container layer (0x80070020 on job conversion).
• CoworkVMService should not be scoped into the app's per-launch AppX container.
• The service should have the rights over itself that it expects, or stop attempting the calls that fail.

Workaround

Sign out of Windows and sign back in. A reboot works but is unnecessary — the job is session-scoped. Killing processes and stopping the service do not help.

This error is driving me nuts. For me Claude launches fine on boot, but the error happens when it auto-updates and tries to close-reopen itself. The reason it's annoying is because restarting my computer is the only thing that allows me to reopen Claude. So when i'm running long-horizon tasks with other AI's, restarting my computer at that time is a problem.

Here's what Fable 5.1 told me to comment about it:

Deterministic trigger for this: the auto-updater's self-restart.

Same dialog ("Another program is currently using this file", pointing at C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc\...), same outcome: app will not launch until reboot. x64, Windows 11 Pro. MSIX from claude.com/download.

The reporter lists reproduction as not deterministic. For me it fires every time the updater closes the app to apply a downloaded update on its own. It has happened 6–7 times in a few weeks.

Reproduce

1. Leave Claude Desktop open with an update downloaded. Take no in-app action.
2. Step away from the machine for 10+ minutes.
3. The app closes itself to apply the update. The "another program is using this file" dialog appears.
4. Every launch attempt shows the same dialog. No Claude app process exists. Task Manager shows only a "Claude" entry whose single child is cowork-svc.exe — the CoworkVMService host, not the app. End Task on it changes nothing: the service is back within seconds. Stop-Service CoworkVMService -Force likewise: it returns within ~30 s, and launch still fails in the window while it is stopped.
5. Reboot. App opens on the new version.

Recurred across versions. First failure on 1.37937.1.0. A reboot successfully applied the update. The next day the same failure happened again applying the following update, with 1.46388.3.0 now the registered package. So fix-on-reboot does not survive the next update cycle.

Also tried without success: Settings → Apps → Claude → Terminate, then Repair. Repair reports the app is "currently running" with no app process present — consistent with the orphaned Silo/Job diagnosis above.

Service state at time of failure

Name      : CoworkVMService
State     : Running
StartMode : Auto
PathName  : "C:\Program Files\WindowsApps\Claude_1.46388.3.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"

Impact: Each occurrence blocks all desktop use until a reboot. Because the restart fires on user inactivity with no defer option, it lands mid-workload by design — which is the worst possible time to demand a reboot.

Asks

• The updater should stop CoworkVMService, wait for it to reach Stopped, confirm no package-owned processes remain, then swap the package and restart the service (as in #57221 and #49655).
• Until then, expose a user-facing defer or notify-only option. Individual users should not have to set disableAutoUpdates in HKLM to avoid a forced restart that reliably breaks the app.
• Replace the misleading dialog text with the package full name and HRESULT.

Still reproducing on 1.46388.3.0 (Windows 11 Pro 26100, x64) as of 2026-09-05 — newer than the 1.32352.1.0 last reported here, so this is not fixed.

Same clean-quit trigger described by @Sabin-He and @HarvestEdge, not a crash. %LOCALAPPDATA%\Claude\Logs\main.log:

2026-09-05 05:07:03 [info] [stealth-update] Triggering stealth update after idle timeout
2026-09-05 05:07:04 [info] beforeQuitForUpdate handler fired, going down for update
2026-09-05 05:07:04 [info] Windows session ending (close-app) - quitting the app

Identical sequence on 2026-08-23 23:53:30. Every activation since fails, reproducible on demand via shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude:

EventID 215  0x80070020  cannot create Desktop AppX container (job conversion error)
EventID 208  0x80070020  cannot create process for package [LaunchProcess]

Confirming @DevHoracioRodriguez's hive finding on this build: SystemAppData\Helium\User.dat and UserClasses.dat cannot be opened with FileShare.None even after stopping CoworkVMService and waiting 45s with zero processes running from the package install location. settings.dat and roaming.lock in the same tree open fine.

Two details I did not see mentioned yet:

• config.json still reports updaterLastSeenVersion: "1.46388.2" while the registered package is 1.46388.3.0 — from the app's side the update never completed.
• Windows re-Registers the package on its own roughly every 30 minutes (AppXDeploymentServer 400/613, result 0x0) and this never recovers the launch.

Package Status = Ok, signature valid to 2026-10-21. Reboot recovers.

A within-machine control: the leaked silo is not just the mechanism, it is the predictor

[🤖] Analysis run with Claude Code against my own machine's event logs. The mechanism in the OP matches what I found independently, so I won't restate it. What I think the thread is missing is a control: five consecutive updates on one machine, four failures and one success, with a single discriminating variable.

Windows 11 Pro 26100 x64, package Claude_*_x64__pzs8sxrjxfjjc, Developer-signed sideload. Container GUIDs truncated to their first segment below (the full v1 UUID embeds the host MAC).

The five transitions

| Update | Outgoing version's container | Result |
|---|---|---|
| 09-03 10:22 → 1.44121.4.0 | still alive | 6× 215/208, reboot 10:25:01 |
| 09-04 07:49 → 1.46388.1.0 | {A57A732E} still alive | 215/208 at 07:49:08 and 07:49:17 |
| 09-04 18:49 → 1.46388.2.0 | {85A6670E} + {85A66673} both destroyed 18:49:08 | relaunched by itself, 201 at 18:49:14. Zero errors. No reboot. |
| 09-05 00:08 → 1.46388.3.0 | {84E76263} alive until 00:42:34 | failures at 00:08:56, 00:42:02/03/25/26, reboot 00:42:33 |
| 09-05 06:54 → 1.46388.4.0 | {9962D43A} alive until 08:56:54 | failures at 06:54:26, 08:56:40, 08:56:41, reboot 08:56:53 |

Every failure had a container belonging to a superseded version still alive. The one success did not. In both failures where I could bound it, the stale container was destroyed at session teardown (00:42:34 and 08:56:54), seconds before the shutdown, never spontaneously.

Method, if you want to reproduce it on your own machine: reconstruct container lifetimes from Microsoft-Windows-AppModel-Runtime/Admin ids 210 (created) / 211 (process added) / 217 (destroyed), keying on package full name, and clip unterminated spans at boot boundaries.

Two things that save time

1. Event 67 (Failed with 0x5 modifying AppModel Runtime status) is a red herring. It looks incriminating because it fires ~1 s before the first 215 in every failure. But it also fires in the successful 09-04 18:49:08 update. Not causal, don't chase it.

2. Repair cannot work here, structurally. Repair ran 3 times across 2 incidents; each time AppXDeploymentServer id 649 reported ACLs repaired successfully ... Register next time should succeed, and the launch failed one second later with the same 0x80070020:

08:56:40  603  RegisterByPackageFullName ... ForceTargetApplicationShutdownOption,RepairAppRegistrationOption
08:56:41  649  ACLs repaired successfully for ...\Claude_1.46388.4.0_x64__pzs8sxrjxfjjc
08:56:41  400  Register operation ... finished successfully
08:56:41  215  0x80070020: Cannot create the Desktop AppX container ... converting the job
08:56:41  208  0x80070020: Cannot create the process ... [LaunchProcess]

The reason is that Repair is addressed to the package full name. On 09-05 it force-terminated the current version's containers, but the straggler was {9962D43A}, belonging to 1.46388.3.0 — a version already moved to WindowsApps\Deleted and gone from the repository. No user-facing Windows tool addresses an object belonging to a deregistered package, which is exactly why only logoff or reboot clears it.

On the title's "after app crash"

Corroborating @spadieri and @Barncore: on this machine it is never a crash. The 09-05 06:54 sequence is a clean, intentional quit-for-update, and the deployment half succeeds completely:

06:43:35  603  Add ... Options NormalPriorityRequest and DeferRegistrationWhenPackagesAreInUse
06:43:48  638  Packages were not updated because affected apps are still running
06:43:48  658  Marking package {Claude_1.46388.4.0...} for deferred registration because {1.46388.3.0} is still running
06:54:19  ---  main.log: beforeQuitForUpdate handler fired, going down for update
06:54:21  400  Register ... finished successfully
06:54:21  472  Moving package folder ...1.46388.3.0 to ...\Deleted\... Result: 0x0
06:54:26  215/208  0x80070020   <-- the app's own post-update relaunch, 5 s later

The update is flawless. Only the activation that follows it fails. Suggest the title's "after app crash" is too narrow — the auto-updater's own self-restart is a deterministic trigger, and for me it has been 100% reproducible across every version bump.

The one open question

What process keeps the outgoing version's container alive? I could not name it. Ruled out on my machine: the MCP servers and CLI child processes carry no package identity (checked with GetPackageFamilyName over every process), so Windows does not count them at all. That leaves a package-tree process — a Chromium helper such as crashpad_handler, a utility or GPU process — surviving the quit. Anyone catching the failure live can settle it, since the state persists for hours:

Get-CimInstance Win32_Process | Where-Object { $_.ExecutablePath -like '*WindowsApps*Claude*' } |
  Select-Object ProcessId,ParentProcessId,Name,CreationDate,ExecutablePath | Format-List

Any row naming a Claude version other than the installed one, or a path under WindowsApps\Deleted\, is the survivor.

Also worth flagging: @jtrobles-cdd reports the launch still failing with CoworkVMService stopped and no package process alive, which would rule the packaged service out as the pin. That is consistent with what I see — the service's own container is torn down and recreated cleanly on every update, including the successful one.

Confirming on Windows 11 Enterprise 26200, packages Claude_1.46388.3.0 and Claude_1.46388.4.0 — same 215/208 + 0x80070020 signature, twice in one morning. That part is already well covered in this thread, so I'll only add three things I haven't seen mentioned here.

1. CoworkVMService is trigger-started on a named pipe, which is why "stop the service first" workarounds keep failing.

The package manifest declares it not just as auto-start but with a named-pipe trigger (\pipe\cowork-vm-service, subtype GUID 1f81d131-3e60-4c76-9860-37334e4ffce3 = NAMED_PIPE_EVENT_GUID):

<desktop6:Extension Category="windows.service" Executable="app\resources\cowork-svc.exe">
  <desktop6:Service Name="CoworkVMService" StartupType="auto" StartAccount="localSystem">
    <desktop6:TriggerEvents>
      <desktop6:TriggerCustom Action="ActionStart" Subtype="1f81d131-3e60-4c76-9860-37334e4ffce3">
        <desktop6:StringData><desktop6:DataItem Value="\pipe\cowork-vm-service" /></desktop6:StringData>

So stopping the service does not hold: the next launch attempt trigger-starts it again. In my logs every failed activation is accompanied by a fresh service start, e.g.

09:03:24  AppModel-Runtime/Admin  215  0x80070020 ... converting the job
09:03:26  AppModel-Runtime/Admin  215/208
09:03:27  CoworkVMService         Claude VM Service starting.
09:03:28  AppModel-Runtime/Admin  215/208

This may reconcile the conflicting results upthread about whether stopping the service helps — it can only ever help until the next launch attempt re-arms it.

2. The "SCM recovery restart loop" explanation does not hold on my machine, yet the failure still occurs.

sc qfailure CoworkVMService returns no failure actions at all:

RESET_PERIOD (in seconds) : 0
REBOOT_MESSAGE            :
COMMAND_LINE              :

There is nothing for the SCM to act on, so the restarts here are the pipe trigger, not service recovery policy. Worth separating the two mechanisms, since #91736 attributes the restarts to a recovery loop.

3. Decoded DACL — the ACE that looks like the service's own SID is actually AppXSvc's.

sc sdshow CoworkVMService:

D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)

| Principal | Rights |
|---|---|
| NT AUTHORITY\Authenticated Users | QueryConfig, QueryStatus, EnumDeps, Start, Stop, PauseContinue, Interrogate, ReadControl |
| NT SERVICE\AppXSvc | full, incl. ChangeConfig, DELETE, WRITE_DAC, WRITE_OWNER |

S-1-5-80-1949724575-... resolves to NT SERVICE\AppXSvc. The service's own SID is S-1-5-80-690231842-763816591-443537665-320658410-1005583601 (sc showsid CoworkVMService) and does not appear in the DACL at all — nor do LocalSystem or Administrators.

That is the concrete reason for the open service: Access is denied warnings the service logs on every start and stop: no principal in its own token holds SERVICE_CHANGE_CONFIG. It also explains why Set-Service -StartupType Disabled and sc config are refused even from an elevated prompt, leaving the HKLM Start value as the only route — as reported in #91736.

Note this is the standard DACL AppXSvc applies to MSIX-manifest-declared services, so a fix likely has to come from the app side (set recovery actions from the installer, or drop the self-management attempt) rather than from expecting the runtime ACL to change.

Happy to supply full event-log exports if useful.

Reproduced on demand, x64, 1.37937.x → 1.46388.4.0: the old container's live members are the non-elevated MCP-server / plugin processes that Claude Code spawned. Name-based kills miss them, which is why "no Claude processes remain" reports still wedge. Clearable without elevation and without sign-out.

Extending leifclaesson's live-member model from #73107 (pinner 1) and LucVanLuc's deferred-registration trace on #76357. Windows 11 Pro 10.0.26200 x64, Claude Desktop MSIX Claude_pzs8sxrjxfjjc, four bad updates 28 Aug → 5 Sep, one good update (3 Sep) as the control.

1. The discriminator, from Microsoft-Windows-AppModel-Runtime/Admin. On the one update that worked, event 217 (container destroyed) fired for the app's session container at the moment the app quit. On all four bad updates it did not: the old app container survived the quit, and its 217 came only 2–4 s before Winlogon 7002 (sign-out). Today:

08:41:07  211  1.46388.3.0  container 6A07CCFE  pid=18728 (Claude.exe)        <- app launched
09:02:48  main.log: [stealth-update] Triggering stealth update after idle timeout
09:02:49  main.log: [CCD] Killing 1 PTY process tree(s) on quit ; beforeQuitForUpdate
09:02:51  SCM 7040/7045  CoworkVMService reinstalled for 1.46388.4.0
09:02:52  210/211  1.46388.4.0  container A2207D78  pid=25608 (cowork-svc, session 0)   <- service container OK
09:02:52  215  1.46388.4.0  0x80070020  converting the job                              <- app container FAILS
09:02:52  215  1.46388.4.0  0x80070020
09:02:52  208  1.46388.4.0  0x80070020  [LaunchProcess]
          (no 217 for 6A07CCFE: the old app container is still alive)
10:04:42  217  1.46388.3.0  container 6A07CCFE                                        <- only at sign-out
10:04:46  Winlogon 7002 (sign-out)

The two-containers-per-version pattern LucVanLuc described is service (session 0) + app (user session). The service one is always fine; the app one is the one that fails.

2. Who the live members are. Not Claude.exe, not cowork-svc.exe, not chrome-native-host.exe alone. After the quit, the processes still running that had been spawned under Claude were the MCP servers and plugin helpers started by Claude Code sessions:

• bun.exe running a plugin's MCP server (...\.claude\plugins\cache\...)
• uvx.exe → uv.exe → chroma-mcp.exe → two python.exe
• chrome-native-host.exe (plus its cmd.exe wrapper)
• a litellm / python.exe process launched from a Claude Code terminal

None of them are elevated. main.log shows the teardown only kills PTY trees ([CCD] Killing N PTY process tree(s) on quit); MCP servers are not in that set, so they outlive the app and keep the old container Job alive. This is leifclaesson's pinner 1 without the elevation requirement, i.e. it is the default case for anyone running Claude Code with MCP servers configured, not the rare elevated-child case. It also explains the reports here and in #76357 where killing every claude* / cowork-svc* / chrome-native-host* by name "left no Claude processes" and still wedged: the members are named bun, uvx, python, node.

3. Proof, no update needed. With Claude Code sessions open, quit from the tray → no 217 for the app container within 60 s (leak), 69 and 56 leftover processes on two runs. Kill the non-elevated leftovers (plain Stop-Process, no admin) → 217 fires within seconds (01:46:39 on my run). Nothing else was touched: no service stop, no re-register, no sign-out. Relaunch then works. The broad kill is confirmed; killing only the MCP/helper set above (leaving VS Code, Chrome etc. alone) is what I am testing on the next occurrence.

4. During the fault (Sysinternals Handle, elevated): svchost.exe (Appinfo, PID 9036) holds Job \Container_Claude_1.46388.3.0_x64__pzs8sxrjxfjjc-<SID>, the old version, while 1.46388.4.0 is the installed one. Appinfo's service state stays RUNNING. That matches #61635; the handle is the symptom, the members are the cause. Restart Manager shows no file lockers because the hold is a Job/silo, not a file handle. Package is Status: Ok, and AppXDeploymentServer shows nothing for this because it is an activation failure (afram123's correction in #80286 holds).

5. What would fix it, app side. Before the stealth relaunch (beforeQuitForUpdate), terminate every member of the app's container Job, MCP servers and plugin processes included, not just PTY trees; or wait for the old container's 217 before launching the new package. Self-heal on launch (find the stale Container_Claude_<old> job, terminate its members, retry), as already asked for in #73107, covers it too. Both are doable from the packaged SYSTEM service.

User-side workaround until then, no sign-out: when the dialog appears, kill the leftover non-elevated processes started under Claude (the MCP servers / helpers above), wait for 217, relaunch. Because they are the user's own non-elevated processes this needs no elevation prompt, which matters, since the prompt is often unusable during the fault.

Scripts (PowerShell 7: a 60 s watcher that tracks the live container GUID and reports a leak, an on-demand quit test with optional reap, and the clear tool) available on request.

Root cause found (nested job objects), with a repro and a workaround

Symptom: after the idle-triggered stealth update the app won't start with "Another program is currently using this file". Event log Microsoft-Windows-AppModel-Runtime/Admin shows events 215/208 with 0x80070020 "error converting the job".

What is going on:

• The MSIX runtime puts every process of the app into one job object (the package container). Child processes inherit it. Breakaway is disabled on that job (LimitFlags = 0), so nothing spawned from inside can leave it.
• Claude Code CLI sessions started from the desktop app run inside that container, but they have no package identity. Same for their MCP servers (node, python, uvx) and anything a tool call starts.
• The updater registers the new package with ForceApplicationShutdown. That kills only processes with package identity (Claude.exe, cowork-svc.exe). The CLI, MCP servers and any long-lived process a session started survive. The old container job stays alive, the new version cannot create its own, and you get the sharing violation. A reboot "fixes" it only because it kills those survivors.

How to see it (Windows 11, PowerShell inside a Claude Code session):

1. IsProcessInJob on the shell returns true, but QueryInformationJobObject(NULL, JobObjectBasicProcessIdList) lists only 3 processes: the CLI, one MCP server and the shell. That is an inner job the CLI creates for its children.
2. Spawn a child with CREATE_BREAKAWAY_FROM_JOB and run the same query from it. It escapes the inner job only and now lists ~50 processes: Claude.exe, every CLI instance, all MCP servers, python/node/uvx. No unrelated processes. That is the container.
3. Processes started via explorer.exe are in no job at all.

Workarounds:

• Close Claude Code sessions before "Restart to update", or before leaving the app idle long enough for the stealth update.
• If already stuck: kill the surviving processes that are in a job but have no package identity (GetPackageFullName returns APPMODEL_ERROR_NO_PACKAGE), then launch the app from the Start menu. No reboot needed.
• Anything meant to outlive the session (servers, tray apps) should be launched via explorer.exe or Task Scheduler, not from a tool call.

Possible fixes on the app side: before quitting for the update, terminate the CLI process trees the app spawned (it owns those jobs), or spawn the CLI with PROC_THREAD_ATTRIBUTE_DESKTOP_APP_POLICY = BREAKAWAY_ENABLE_PROCESS_TREE so sessions live outside the container.

Hitting this on Windows 11 Pro 26100 with the MSIX/Store build. Two occurrences in under
14 hours, both after an idle-timer auto-update, both leaving the app unlaunchable with no
notification. Adding timings and log excerpts since I have a clean pair.

Package: Claude_1.46388.4.0_x64__pzs8sxrjxfjjc (Store/MSIX)

Occurrences

| | update fired | app returned | downtime |
|---|---|---|---|
| 2026-09-04 | 14:55:13 | 16:10:21 | 1h 15m |
| 2026-09-05 | 04:23:20 | 09:31:55 | 5h 08m |

Both preceded by [stealth-update] Triggering stealth update after idle timeout and, one
second later, beforeQuitForUpdate handler fired, going down for update.

The update succeeds; the relaunch is what fails

Worth stating explicitly because the symptom reads like a failed update. In
Microsoft-Windows-AppXDeploymentServer/Operational the servicing completes cleanly:

Finished resolving action lists. DeploymentRequest action lists:
  updateList: Claude_1.46388.3.0_x64__pzs8sxrjxfjjc is updating to Claude_1.46388.4.0_x64__pzs8sxrjxfjjc
...
Finished servicing singleton package Claude_1.46388.4.0_x64__pzs8sxrjxfjjc.
  Setting the singleton package state to enabled returned with 0x0.

Then in Microsoft-Windows-AppModel-Runtime/Admin, immediately after:

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

So the new package is installed and enabled, and the app simply cannot be launched. Nothing
is half-installed and there is nothing to roll back.

Frequency

60 0x80070020 events naming the Claude package, all within these two days:

2026-09-04 14:55  x3      <- update-triggered relaunch
2026-09-04 15:50  x3
2026-09-04 15:51  x9
2026-09-04 15:52  x6
2026-09-04 15:53  x6
2026-09-04 15:57  x6
2026-09-05 04:23  x3      <- update-triggered relaunch
2026-09-05 09:22  x12
2026-09-05 09:23  x6
2026-09-05 09:24  x1
2026-09-05 09:25  x5

The 15:50–15:57 and 09:22–09:25 clusters are me repeatedly clicking the icon and getting
nothing. Each click is a fresh failed container creation.

CoworkVMService state

Consistent with #57221. On this machine right now:

Name        : CoworkVMService
DisplayName : Claude
Status      : Running
StartType   : Automatic

Notably the deployment log shows Windows does terminate it during servicing:

0x0: TerminateSingleService for update successful for service
     Claude_1.46388.3.0_x64__pzs8sxrjxfjjc in package CoworkVMService, terminateService: true
0x0: Succesfully terminated service Claude_1.46388.3.0_x64__pzs8sxrjxfjjc in package CoworkVMService.

So termination is not being skipped — but with StartType: Automatic the service returns
on its own and can re-occupy the package job before the new container is built. Terminating
it once during servicing does not appear to be sufficient.

Also present at the time of writing: 19 Claude.exe processes from the package, 17 of
them resolving under WindowsApps\Claude*.

Two things that make this much worse than the error itself

1. Nothing retries and nothing tells you. After beforeQuitForUpdate, the app is gone.

There is no notification, no retry, no tray icon, no log entry indicating the relaunch
was even attempted from the app's side. The only signal is that the app you were using
has vanished. That is how a failed relaunch became a five-hour outage overnight — I was
asleep, and there was nothing to notice.

1. Terminal sessions are killed on the way out. The app logged

[CCD] Killing 5 PTY process tree(s) on quit before quitting. An idle-timer update
killed five terminal process trees. In my case the work had finished ten minutes earlier,
but an idle UI does not mean idle work — long-running jobs in those terminals would
have been destroyed with no warning and no way to resume.

Suggested asks

• After beforeQuitForUpdate, verify the new process actually started; if it did not,

surface a notification and retry rather than exiting silently.

• Treat running PTY sessions as a reason to defer an idle-timer update, or at minimum warn.
• If the packaged service must be stopped for servicing, keep it stopped until the new

container exists, rather than letting Automatic restart race the container creation.

Happy to supply the full event-log exports if useful.

Update: Incident did return after a few months of being clear - thankfully recovered without rebooting; Orphaned child processes confirmed

This recurred on 6 September 2026, and we recovered it without restarting Windows.

Environment

• Windows 11 Home, build 26200
• Claude Desktop update: 1.46388.3.0 → 1.46388.4.0

Failure sequence

The update initially failed with 0x80073D02, naming the previous Claude version as still in use. Registration subsequently succeeded, but every launch failed with 0x80070020:

• Event 215: error converting the job while creating the Desktop AppX container.
• Event 208: error configuring runtime while creating the process.

Repeated registration repairs and Cowork service recycling did not recover it.

What actually cleared it

We found several surviving command-line processes whose parents had exited:

| Process | Observation | Result |
| --- | --- | --- |
| git ... remote -v | Idle for over two hours, with an orphaned console | Stopping it did not resolve the failure |
| find and head | Orphaned Claude log-search commands, approximately two hours old | Stopping both released the old container |

The remaining commands were:

find / -maxdepth 6 -iname *.jsonl -newer /tmp -path *claude*
head -5

The event log recorded the recovery immediately afterward:

| Local time | Event | Result |
| --- | --- | --- |
| 13:55:51 | 217 | Old 1.46388.3.0 Desktop AppX container destroyed |
| 13:55:55 | 201 | New 1.46388.4.0 Claude process successfully created |

The desktop app opened normally. No reboot, sign-out, reinstall or data reset.

We stopped find and head together, so we cannot distinguish which one held the final container reference.

Implication

This supports the mechanism described in #91763, but with ordinary find/head children rather than a Git filesystem-monitor daemon.

Checking only for claude.exe, Cowork or Git processes can miss the actual survivors. The update lifecycle needs to account for child processes retaining the old app container after their parent exits.

The generic “Another program is currently using this file” dialog conceals the useful diagnosis: the previous version's container is still alive because child processes survived cleanup.

Another x64 (non-ARM), domain-managed repro, with a deterministic trigger: the *first
launch of the app each day* fails. Every time.

Environment

| | |
|---|---|
| OS | Windows 11 Enterprise 10.0.26100 (24H2), x64, domain-joined |
| App | Claude Desktop MSIX, Claude_*_x64__pzs8sxrjxfjjc |
| Versions seen failing | 1.40609.1.0, 1.44121.1.0, 1.46388.1.0, 1.46388.4.0 |
| Window observed | 2026-08-29 → 2026-09-07 |

Same signature as the OP — Microsoft-Windows-AppModel-Runtime/Admin, 0x80070020:

Event 215: cannot create the Desktop AppX container for package
           Claude_<ver>_x64__pzs8sxrjxfjjc due to an error converting the job
Event 208: cannot create the process for package Claude_<ver>_x64__pzs8sxrjxfjjc
           due to an error setting up the runtime. [LaunchProcess]

---

1. The trigger is the first launch of the day — 4 days out of 4

Cross-referencing the 215/208 clusters against the first successful app connection each day
(Client connected: ... exe=claude.exe in C:\ProgramData\Claude\Logs\cowork-service.log):

| Day | First launch attempt | First successful launch |
|---|---|---|
| 09-02 | 09-02 10:20:30 — FAILED | 10:34:07 (+14 min) |
| 09-03 | 09-03 09:08:41 — FAILED | 09:11:39 (+3 min) |
| 09-04 | 09-04 12:39:06 — FAILED | none that day |
| 09-07 | 09-07 09:13:09 — FAILED | 09:33:18 (+20 min) |

Every day the app was used, the day's first launch failed. (09-01, 09-05 and 09-06 have no
Claude activity at all — weekend plus one unused day — so there is no counter-example in the
window, not a single one.)

Retrying a few minutes later often succeeds; a logoff or reboot always works.

2. The failure comes before any deployment activity — the repair is a consequence, not the cause

This is the part I think matters most, and it corrects an assumption I initially made.

On the morning incidents the launch fails first, and Windows then kicks off a
same-version RegisterByPackageFullName self-repair about a second later:

09:13:09  AppModel-Runtime 215   0x80070020  (launch fails)
09:13:10  AppXDeploymentServer 603   Started deployment RegisterByPackageFullName operation
                                     on Claude_1.46388.1.0_x64__pzs8sxrjxfjjc
09:13:11  649   Trying to repair ACLs for \\?\C:\Program Files\WindowsApps\Claude_1.46388.1.0...
09:13:13  9648  TerminateSingleService for update successful for service
                Claude_1.46388.1.0_x64__pzs8sxrjxfjjc in package CoworkVMService
09:13:13  10000 About to service package Claude_1.46388.1.0... state to disabled -> 0x0
09:13:14  215   0x80070020  (still failing, during the repair)
09:13:16  208   0x80070020

Note the version does not change — 1.46388.1.0 → 1.46388.1.0. Identical shape on 09-03
with 1.44121.1.0. There is no Claude deployment activity between 00:00 and the first
failure on either day.

So the package is already in the bad state when the day begins. Windows notices at
activation, tries a same-version repair, and that repair also races the service (see §3),
which is why the next few attempts keep failing before it settles. Compare
https://github.com/anthropics/claude-code/issues/83932, which reports same-version
repair racing the service it is repairing.

The machine sleeps rather than shuts down, so the logon session survives overnight — which
fits an orphaned Silo/Job scoped to the user session persisting from the previous day's
update until the next morning's first activation walks into it.

3. CoworkVMService re-enters the package container ~1s into servicing

The service is stopped for servicing and restarts under a second later, mid-servicing,
and logs that it could not prevent exactly this:

2026/09/07 12:11:54.092563 Service stop requested
2026/09/07 12:11:54.112200 Warning: failed to disarm recovery actions for this stop: open service: Access is denied.
2026/09/07 12:11:54.112728 Service stopped.
2026/09/07 12:11:55.788164 Starting CoworkVMService as Windows service     <-- 1.7s later
2026/09/07 12:11:55.965589 [Server] Named pipe server listening
2026/09/07 12:11:55.966810 Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.

Same shape at 09:13:13 (restart 1.5s later) and 13:01:22 (0.76s later). The two warnings
in the Application log name the failure mode outright:

failed to disarm SCM recovery actions for this stop; if the stop overruns, the service may be auto-restarted during package servicing: open service: Access is denied.

failed to configure SCM recovery actions; if the service crashes it will not restart until the machine reboots: open service: Access is denied.

sc.exe qfailure CoworkVMService confirms recovery actions were never armed
(RESET_PERIOD : 0, no actions) — it is losing this call on both ends. On a domain-managed
machine the packaged service apparently cannot open itself in SCM with the rights it needs.

4. No crash precedes it

The issue title attributes the orphaned Silo to a crash during startup. There is no crash
here. Over 10 days: 50 Windows Error Reporting / Application Error / Application
Hang events in the Application log and 386 directories in
C:\ProgramData\Microsoft\Windows\WER\ReportArchive — zero for Claude or cowork. WER
demonstrably works on this box and never sees Claude fault.

5. Manifest

<desktop6:Service Name="CoworkVMService" StartupType="auto" StartAccount="localSystem">
  <desktop6:TriggerEvents>
    <desktop6:TriggerCustom Action="ActionStart" Subtype="1f81d131-3e60-4c76-9860-37334e4ffce3">
      <desktop6:StringData><desktop6:DataItem Value="\pipe\cowork-vm-service" /></desktop6:StringData>

StartupType="auto" and a named-pipe trigger, so setting the service to Manual will not
keep it down — which likely explains why
https://github.com/anthropics/claude-code/issues/61635 saw it return ~30s after
Stop-Service.

6. Suggested direction

1. Don't restart the service while a servicing or register operation on its own package is
2. in flight — gate on package state instead of racing it by ~1s.
3. 2. If the SCM recovery-action calls fail, the service should decline to auto-restart during
4. servicing rather than proceeding regardless.
5. 3. StartupType="auto" for a service living inside the package it must not hold looks like
6. the structural problem — see https://github.com/anthropics/claude-code/issues/57221.

Repro tip for anyone trying to reproduce this: don't try to reproduce it by sleeping the
machine. Several reports here (mine included, initially) describe the trigger as sleep/wake.
On this machine that correlation does not survive checking — 9 away-blocks over 60 minutes
produced 1 incident, while 31 shorter ones produced 6, and overnight blocks of 6–10 hours
produced none. What is deterministic is *the first activation of the package in a logon
session that has already seen an update*. Leave the session logged in across an app update
and launch the next morning.

Happy to pull further traces — this reproduces daily.

Adding a culprit family to the list here, with the evidence on #91763 since the
mechanism there is identical.

Git for Windows' GnuPG daemons: gpg-agent, keyboxd and scdaemon,
spawned by GPG-signed commits made from the Code tab. They survive the update's
forced shutdown inside the container's job object, so the old container never
gets its 217 Destroyed event and every launch of the new version fails 215/208
with 0x80070020.

Recovered here without a reboot or a sign-out by ending those three, gpg-agent
first because while it lives it respawns the other two straight back into the
same job. This reaches anyone with commit.gpgsign=true.

Container GUID pairing, the orphan sweep that finds it, and why it does not
happen on every update:
https://github.com/anthropics/claude-code/issues/91763#issuecomment-5570389648

Same failure on 1.49585.0.0 x64, English Windows 11, PowerShell 7.6.5. A few things here that the original report doesn't cover.

The main one: no update was pending. Get-AppxPackage showed 1.49585.0.0 before the failure and the same version after I recovered. Nothing staged, no MSIX operation running. So this isn't the deployment path from #76357, #83932 or #49655. It's the crash path the OP describes.

The build is also a lot newer than what's in the other reports. 1.49585.0.0 against the 1.1.x and 1.2x.x builds already filed. Nothing has fixed it.

Event log, Microsoft-Windows-AppModel-Runtime/Admin. Eleven events between 13:46:26 and 13:46:47, one 215/208 pair per launch attempt:

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

Same as the OP's, but on en-US, so the dialog isn't a locale artifact.

State while it was failing:

Service CoworkVMService    Stopped
Package processes          0
Package status             Ok

Stop-Service worked and nothing was left running under C:\Program Files\WindowsApps\Claude_*. No usermode handle on the package, and activation still failed. That matches the OP's handle.exe check.

Signing out and back in fixed it. I didn't need a full reboot.

Two things I hit that aren't in the report:

1. Restart-Service Appinfo doesn't work. #61635 pins the leaked handle on Appinfo, the UAC elevation broker, so restarting it is the obvious thing to try. It won't stop on a live desktop:

Restart-Service: Service 'Application Information (Appinfo)' stop failed.

If #61635 has the mechanism right, there's no way for a user to make the holder release, which leaves ask #2 as the only route.

2. Administrators can't reconfigure CoworkVMService, and it doesn't come back after you stop it. Stop-Service works. Set-Service doesn't, elevated:

Set-Service: Service 'Claude (CoworkVMService)' cannot be configured due to the following error: Access is denied.

Stop is allowed and config isn't, so it's the service DACL rather than my token. Looks like SERVICE_CHANGE_CONFIG isn't granted to Administrators. Same gap as the "failed to open service for recovery config: Access is denied" line in cowork-service.log in #40067.

StartType Automatic only covers boot, so once you stop the service mid-session the SCM leaves it stopped. The workaround going around from #76357 is "stop CoworkVMService, then relaunch," which means Cowork is down for the rest of your session, and per #28231 the app crashes instead of falling back to chat-only when it can't reach the service. That crash is what leaves the orphaned container behind. So the workaround sets up the bug it's working around. You need an explicit Start-Service afterward and you can't make that stick with Set-Service because of the ACL.

On ask #3: yes, please. The dialog names the install directory, so that's where you go looking, and I spent a while chasing file locks that don't exist. Nothing in the app or the message points at the container layer, and AppModel-Runtime/Admin is the only place the real error shows up.

Answering my own open question: there is no surviving process. The silo is empty.

[🤖] Follow-up to my earlier comment, where I asked which process keeps the outgoing version's container alive. I caught the failure live on 2026-09-09 (1.46388.4.0 -> 1.49585.0.0) and snapshotted the machine before recovering. The answer is that nothing is in it.

Container GUIDs truncated to their first segment; the full v1 UUID embeds the host MAC.

The snapshot

Get-CimInstance Win32_Process | Where-Object { $_.ExecutablePath -like '*WindowsApps*Claude*' } |
  Select-Object ProcessId,ParentProcessId,Name,CreationDate,ExecutablePath | Format-List

Zero rows. Taken 2h11m after the update, while the app was still refusing to launch. Meanwhile the orphaned silo was very much alive:

02:37:27  210  Created container {BC46CB77} for Claude_1.46388.4.0
02:37:27  211  Added process 9948 to container {BC46CB77}
02:37:27  201  Created process 9948 for application Claude_pzs8sxrjxfjjc!Claude   <-- the UI
--- update to 1.49585.0.0 lands ---
04:34:32  217  Destroyed container {BC46C97C} for Claude_1.46388.4.0              <-- sibling goes
          ---  {BC46CB77} is NOT destroyed
04:34:32  215  0x80070020 ... converting the job
04:34:38  215/208  0x80070020 ... [LaunchProcess]
--- 06:45 snapshot: zero package processes, app still broken ---
06:52:35  1074 restart initiated
06:52:36  217  Destroyed container {BC46CB77} for Claude_1.46388.4.0
06:53:02  boot

A job object dies when its last member process exits. This one persisted 2h18m with no members, then died 1 second into session teardown.

What that settles

1. taskkill and Stop-Service CoworkVMService cannot work, by construction. There is nothing to kill. This directly corroborates @jtrobles-cdd, who reported the launch still failing with the Cowork service stopped and no package process alive — that result is not anomalous, it is the expected one.

2. handle.exe finding no handles into the install directory is correct and irrelevant. It is the wrong object. The leak is a handle on the job, not on any file. Every "find what's locking the file" approach in this thread is searching the wrong namespace, which is also why the dialog's wording has misled so many of us.

3. Logoff is sufficient; the boot does no work. The silo died 26 seconds before the kernel came back. Anyone rebooting for this is paying for something session teardown already did.

Discriminator holds, 5th consecutive time

Same pattern as the five transitions in my earlier comment: the container that survives is always the one holding the app's own UI process, while its sibling is torn down normally in the same second.

Caveat, stated honestly

The snapshot ran non-elevated, so a LocalSystem process (e.g. cowork-svc.exe, session 0) would have a blank ExecutablePath and would not match the filter. But {BC46CB77} is a user-session container whose logged member was the app's own UI process, which runs as the user and would have appeared. So "no surviving process" is established for the container that actually blocks the launch, not for session 0.

The next step for whoever can catch it

The remaining question is no longer which process but which handle. Elevated, during the failure:

handle64.exe -a -t Job

and look for a job whose name references the stale Claude_<oldversion>_x64__pzs8sxrjxfjjc, then check which process holds it. That names the leaker outright. I did not have this captured in time; posting the method so the next person does.

Confirming this on x64 Windows 11 Pro (10.0.22631), Claude Desktop 1.49585.0.0. Same fingerprint — 0x80070020, AppModel-Runtime EventID 215/208, only logoff/reboot recovers, service restarts and package re-registration do not.

Three things I have not seen in this thread yet.

1. The trigger is the unattended forced MSIX update — and I have a control case

Deployment log, 2026-09-09:

01:53:30  638  update not applied, app still running
01:53:31  400  Add completed (1.49585.0.0)
02:04:02  603  RegisterByPackageFamilyName ... ForceApplicationShutdownOption

The updater force-terminated the app at 02:04 while I was away (the default enforcement path waits for 10+ minutes of idle). From then the app was unlaunchable. I rebooted at 13:49 — 11h45m of downtime.

Control case, 2026-09-07 11:44. Same app, same MSIX pipeline, same ForceApplicationShutdownOption — except I clicked "Restart to update" in the Help menu:

11:44:31  603  RegisterByPackageFamilyName ... ForceApplicationShutdownOption
11:44:33  400  Register completed
11:44:36       app back up — no leftover processes, no lock, no 0x80070020

Clean when the restart is user-initiated. Broken when the updater kills the app on idle. Three occurrences in six days (09-03, 09-07, 09-09), each preceded by an unattended forced shutdown; every user-initiated update in the same period succeeded.

2. The app's own self-repair fails — 15 re-registrations including a full Remove/Add

The issue body notes that Reset-AppxPackage and re-registration do not recover. Here the app itself attempted exactly that, repeatedly, and failed:

10:27:11  603  Register ... ForceTargetApplicationShutdownOption,RepairAppRegistrationOption
10:36:03  603  (same)
10:40:59  603  (same)
10:41:35  603  (same)
10:44:12  603  (same)
10:49:31  603  RepairPackageOperation
10:49:31  603  RegisterByPackageFullName ... RepairAppRegistrationOption
10:49:37  603  (same)
10:49:55  603  (same)
10:57:55  603  (same)
11:13:09  603  Remove ... PreserveApplicationData,RemoveForAllUsers
11:13:10  400  Add completed                    <- package removed and reinstalled
11:13:10  603  Register ... RepairAppRegistrationOption
11:14:05  603  (same)
11:26:56  603  (same)
11:37:28  603  (same)
13:49:07  603  (same)

15 repair re-registrations plus a full package Remove → Add over 3.5 hours. None recovered. Only the reboot did. Further confirmation that the orphaned handle sits above the package layer, so nothing at the deployment layer can clear it.

Matching AppModel-Runtime entries during the same window:

11:37:28  215  0x80070020 — cannot create desktop AppX container (job conversion)
11:37:28  208  0x80070020 — cannot create process [LaunchProcess]
13:49:07  215  (same)
13:49:08  208  (same)

3. This failure mode is invisible to telemetry

Across the whole 11h45m window:

• no Application Hang and no Application Error events
• zero Crashpad reports (the directory holds only settings.dat)
• no client telemetry, because the client could not start

All three of my occurrences look identical from the server side: nothing happened. Absence of crash reports for this bug should not be read as absence of impact.

Suggested mitigation while the Silo/Job cleanup is being fixed

Stop force-terminating the app to apply a staged MSIX update. Apply it on the next user-initiated restart instead. In my data that path has a 100% success rate and the forced path has a 0% one.

One angle that has not come up in this thread: affected users cannot opt out of the packaging layer the bug lives in.

The official Windows download is an .exe that installs an MSIX package. The winget manifest points at the same artifact:

winget show Anthropic.Claude
  Installer Type : exe
  Installer URL  : https://downloads.claude.ai/releases/win32/x64/<version>/Claude-<sha>.exe

Result on my machine — the Microsoft Store was never involved:

SignatureKind   : Developer          <- sideloaded MSIX
InstallLocation : C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc

Nothing under %LOCALAPPDATA%\Programs, no entry in Apps & features, and updates arrive as .msix from the same host. There is no non-MSIX build to switch to. (Earlier advice in #46179 to move to a standalone install via winget no longer applies — the manifest now resolves to the MSIX installer.)

Consequence for this issue: for everyone hitting 215/208 here, the only mitigation anyone can offer is "log off" or "reboot". There is no packaging fallback, so until the Silo/Job cleanup is fixed the failure has no user-side workaround at all.

Filed separately as #93008, which github-actions auto-labelled invalid 11 minutes later; reposting the substance here since this is where the mechanism is actually being worked out.

aFollow-up to my comment above — this reproduced again on 1.49585.0.0, and the sequence
matched the prediction end to end. Two new findings: retrying is not just useless, it makes
Windows re-register the package on every attempt, and logoff clears it in 14 seconds.

The predicted sequence, observed

The machine had not rebooted since 2026-09-07 13:03. The update landed the previous evening
and broke the session on the spot; the session then carried the damage overnight.

09-08 21:14:09  603    Add operation, Claude_1.49585.0.0_x64__pzs8sxrjxfjjc staged
09-08 21:25:07  603    RegisterByPackageFamilyName
09-08 21:25:40  472    Moving Claude_1.46388.4.0 -> WindowsApps\Deleted\...
09-08 21:25:39  215    0x80070020   <-- session breaks immediately, same evening
09-08 21:25:46  215/208

        (logon session stays alive overnight — no logoff, no reboot)

09-09 08:47:50  215    first launch of the day -> FAILED

That is exactly the repro recipe from my previous comment: leave the session logged in
across an app update, then launch. No sleep/wake needed.

Retrying does not converge — and re-registers the package every time

I retried for roughly half an hour. Every attempt failed, and each one triggered a fresh
package registration. One paired 7040 + 7045 in the System log per attempt:

08:47:52  7040  Service "Claude" start type changed from auto start to disabled.
08:47:52  7045  A service was installed: "...\Claude_1.49585.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
09:02:29  7040 / 7045   (again)
09:07:48  7040 / 7045   (again)
09:08:47, 09:09:15, 09:09:39, 09:09:41, 09:10:16, 09:11:05, 09:11:14,
09:12:45, 09:14:43, 09:15:52, 09:17:36, 09:18:06   ... 14 times in 31 minutes

215/208 fired on every single one. It never settled.

I think this explains the reports here that CoworkVMService "cannot be stopped". I could
not stop it either. It is not that the stop is denied as such — SCM is tearing down and
re-creating the service entry underneath you on every launch attempt, so a Stop-Service
races a re-registration that is already in flight. The more you retry, the more reliably the
stop fails.

Worth noting for the maintainers: a failed activation triggering a full
re-register + packaged-service reinstall is a fairly heavy self-repair to run on every click,
especially when it demonstrably cannot fix this state.

Logoff fixed it in 14 seconds

09:19:02  User Profile Service  4  user logoff processing finished
09:19:16  User Profile Service  1  user logon received (session 2)

App launched normally straight after. Consistent with the OP's session-scoped Silo/Job
diagnosis — and a full reboot was never needed.

Practical note for others hitting this

Don't wait it out and don't bother retrying; both cost time and neither works. Sign out and
back in — it is seconds, not a reboot. In my case the failure is now costing a logoff every
morning, because the app updates most days and the session always outlives the update.

Environment unchanged from my comment above: Windows 11 Enterprise 10.0.26100, x64,
domain-joined, MSIX Claude_*_x64__pzs8sxrjxfjjc, now on 1.49585.0.0.

Still reproduces on Claude Desktop 1.52386.0.0 (x64, MSIX) / Windows 11 Home 26200 — same 215 + 208 / 0x80070020 signature described here.

Trigger in my case: an MSIX update applied while the app was running (1.49585.0.0 → 1.52386.0.0). Sequence captured from Microsoft-Windows-AppModel-Runtime/Admin and Microsoft-Windows-AppXDeploymentServer/Operational (local time; username and SID redacted):

23:06:53  215 Error  0x80070020: Cannot create the Desktop AppX container for package
                     Claude_1.52386.0.0_x64__pzs8sxrjxfjjc because an error was
                     encountered converting the job.
23:06:53  208 Error  0x80070020: Cannot create the process for package
                     Claude_1.52386.0.0_x64__pzs8sxrjxfjjc because an error was
                     encountered while configuring runtime. [LaunchProcess]
23:25:06  215 + 208  (same pair, next launch attempt)
23:25:07  AppXDeploymentServer 400: Register of Claude_1.52386.0.0_x64__pzs8sxrjxfjjc
                     "finished successfully"
23:25:08  215 + 208  (same pair again, ~1s after the successful re-register)
   ...
00:28:49  217        Destroyed Desktop AppX container for Claude_1.49585.0.0   <-- OLD version
00:29:11  Windows reboot
00:29:40  210 + 211  container created, app launches normally

21 × 215/208 errors total in that window. Only the reboot recovered it.

Three details from this capture that might help narrow the root cause:

1. Not ARM64-specific. cf. #61635 — this machine is x64.

1. A successful package Register does not clear the stale Job. At 23:25:07 AppXDeploymentServer logs Register ... finished successfully for the new package, and the very next launch attempt ~1 second later still fails with 215/208. So the orphaned Job survives re-registration of the package — consistent with the reports here that Add-AppxPackage -Register and Reset-AppxPackage do not recover.

1. **The orphaned container belonged to the previous version.** Event 217 Destroyed Desktop AppX container ... Claude_1.49585.0.0 only fires at shutdown, roughly an hour after the update. That looks consistent with the old version's Job never being released when the updater swapped packages underneath a live app — which would also explain why this correlates so strongly with the update path rather than with plain crashes.

CoworkVMService was Running / Automatic throughout, and no Application Error / Application Hang events or Crashpad dumps were produced — the app does not crash here, it is blocked at container creation.

I have not personally confirmed that a logoff alone is sufficient (I rebooted); noting it only because this thread reports logoff as equivalent, and it would be a meaningfully cheaper recovery to document if confirmed.

Filing this as a comment rather than a new issue since #76357 was already closed as a duplicate of this one — just confirming the bug is still live on the current build, in case the version and timing data is useful.

Confirmation on Claude_1.52386.0.0 — stopping CoworkVMService does not recover

Reproduced after an in-place MSIX update. Adding diagnostics from a still-broken live state (no reboot yet).

Environment

• Windows 11, build 26200, x64
• Package Claude_1.52386.0.0_x64__pzs8sxrjxfjjc (Get-AppxPackage Status = Ok)

User-visible symptom
Bare Windows dialog titled with C:\Program Files\WindowsApps\Claude_1.52386..., text equivalent to "This file is being used by another program." Claude.exe never appears.

AppModel-Runtime/Admin on a failed launch

Id 211  Added process (cowork-svc.exe) to a Desktop AppX container
Id 217  Destroyed that Desktop AppX container
Id 215  0x80070020: Cannot create the Desktop AppX container for package
        Claude_1.52386.0.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.
Id 208  0x80070020: Cannot create the process ... [LaunchProcess]
        (also observed with [FinishPackageActivation])

Ruled out

• Restart Manager (RmGetList) on app\Claude.exe and app\resources\cowork-svc.exe: 0 lockers while launch still fails
• No userspace process has WindowsApps\Claude modules loaded
• Stop-Service CoworkVMService succeeds; service stays Stopped; launch still fails
• Start-Process of the claude: protocol and of app\Claude.exe fail with the same sharing-violation message
• Add-AppxPackage -DisableDevelopmentMode -Register <AppxManifest.xml>: no recovery
• Set-Service / sc config to Manual/Disabled: Access denied (packaged service ACL). StartupType remains Automatic

Manifest on 1.52386 still declares auto-start
AppxManifest.xml desktop6:Service:

• Name=CoworkVMService
• StartupType="auto"
• StartAccount="localSystem"
• Executable=app\resources\cowork-svc.exe (inside WindowsApps)

The Manual/Demand-start change proposed in related issues has not shipped in this build. The service is still WIN32_PACKAGED_PROCESS + AUTO_START.

Takeaway
This matches the leaked Job/Silo path rather than a live userspace file lock. The dialog is misleading. Stopping the service is not sufficient. Only logoff or reboot has been reported to clear it.

@Originalutter's finding that retrying makes Windows re-register the package on every attempt matches what I captured on 2026-09-09, and I can put a number on it.

The forced update landed at 02:04 while I was away:

01:53:30  638  update not applied, app still running
02:04:02  603  RegisterByPackageFamilyName ... ForceApplicationShutdownOption

From 10:27, while I kept trying to launch the app, the deployment log records this:

10:27:11  603  Register ... ForceTargetApplicationShutdownOption,RepairAppRegistrationOption
10:36:03  603  (same)
10:40:59  603  (same)
10:41:35  603  (same)
10:44:12  603  (same)
10:49:31  603  RepairPackageOperation
10:49:31  603  RegisterByPackageFullName ... RepairAppRegistrationOption
10:49:37  603  (same)
10:49:55  603  (same)
10:57:55  603  (same)
11:13:09  603  Remove ... PreserveApplicationData,RemoveForAllUsers
11:13:10  400  Add completed                    <- package removed and reinstalled
11:13:10  603  Register ... RepairAppRegistrationOption
11:14:05  603  (same)
11:26:56  603  (same)
11:37:28  603  (same)
13:49:07  603  (same)

15 repair re-registrations plus a full Remove → Add over 3.5 hours, none of which recovered it. Note the package was completely reinstalled at 11:13 and the container still would not activate afterwards — consistent with the orphaned handle living above the package layer, and with retrying being actively counterproductive rather than merely useless.

Two practical notes:

• I did not try logoff on that occasion. I rebooted at 13:49, 11h45m after the break. Against @Originalutter's measured 14 seconds, essentially all of that downtime was avoidable — worth putting in the issue body as the recommended first step, since "reboot" is what most people here reach for.
• I am now on 1.52386.0.0 (registered 2026-09-11 10:11) and have not hit the failure on this build yet, so I cannot confirm or deny it from my side — but given @luifer993 and @jmylot both reproduced on it, it does not look fixed.

Still reproducing on Claude Desktop 1.52386.3.0 (MSIX), Windows 11 Pro 26200. Adding a newer data point than the reports above (1.20186.0.0, 1.6608.0.0), plus two details I did not see in the thread.

Sequence, from Windows and app logs:

1. 13:21, update 1.52386.0.0 to 1.52386.3.0 applied with DeferRegistrationWhenPackagesAreInUse.
2. 15:34, [stealth-update] Triggering stealth update after idle timeout, then beforeQuitForUpdate. The relaunch never completed. updaterLastSeenVersion stayed on the old build and a stealth-relaunch marker was left behind.
3. From 18:03, every launch failed at Desktop AppX container creation with 0x80070020 while converting the job.

CoworkVMService (DisplayName "Claude", cowork-svc.exe) is AUTO_START with its binary at ...\Claude_1.52386.3.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe, so it runs whenever the machine is on, app open or not.

Nothing short of ending the logon session recovers it. I tried, in order: Stop-Service CoworkVMService -Force (it comes back), re-register, Reset-AppxPackage, then a full Remove-AppxPackage and clean reinstall. The reinstall failed with 0x80073CF6 / 0x80073D05 because ...\Local\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat was still a loaded hive, with 5 silos mounted. Only ending the session cleared it. Every step before that was wasted, and the uninstall left the machine with no working app in the meantime.

The forced restart is what makes this risky rather than annoying. autoUpdaterEnforcementHours defaults to 72, and my logs show Auto-restarting app after update pending for 73 hours. On a machine with long uptime, the app picks its own moment to relaunch into a package it cannot activate, with nobody present.

The fix already proposed in #76357 looks right: stop CoworkVMService, wait for cowork-svc.exe to exit, and terminate leftover package-owned Claude.exe processes before applying the update. Two smaller asks alongside it: make the service demand-start so it is not holding the package at idle, and fix the error text, since "Another program is currently using this file" sends people hunting for a file lock when the stuck object is a kernel silo.

Still reproducing on 1.52386.6.0 (x64 MSIX, Windows 11 Pro 26200), the latest build as of 2026-09-13. Adding one machine's frequency data, because it shows what separated the failed updates from the clean ones.

6 updates in 24 days: 4 left the app unlaunchable until reboot, 2 were clean

| Date | Update | Trigger | Result |
|---|---|---|---|
| 08-21 | 1.32885.1 → 1.34493.1 | update | 5 × event 208 0x80070020, reboot |
| 08-26 | 1.34493.1 → 1.37937.1 | stealth update | relaunch failed, reboot |
| 08-29 | 1.37937.1 → 1.40609.0 | normal quit, deferred register | old container survived ~19 h, next-day launch failed, reboot |
| 09-07 | 1.40609.0 → 1.46388.4 | stealth update | clean, relaunched in 2 s |
| 09-09 | 1.46388.4 → 1.49585.0 | stealth update | clean, relaunched in 37 s |
| 09-13 | 1.52386.3 → 1.52386.6 | stealth update | automatic relaunch + 4 manual attempts failed over 67 min, reboot |

The difference: in 3 of the 4 failures a console process hung during the forced shutdown and WER logged AppHangB1 (bash.exe 08-26, conhost.exe 08-29 and 09-13). Neither clean update logged a hang. That fits the nested-job analysis above: ForceApplicationShutdown only reaches processes with package identity, so a stuck identity-less child keeps the old container alive.

09-13 sequence (local time)

22:31:05  [updater] Update downloaded and ready to install { releaseName: 'Claude 1.52386.6' }
22:38:29  last active Claude Code session finished
22:48:29  [stealth-update] Triggering stealth update after idle timeout   (exactly 10 min later)
22:48:29  [CCD] Killing 5 PTY process tree(s) on quit
22:48:30  AppXDeploymentServer 603: RegisterByPackageFamilyName, ForceApplicationShutdownOption
22:49:08  WER 1001/1002: AppHangB1 conhost.exe
22:49:09  AppXDeploymentServer 400: register finished successfully
22:49:10  AppModel-Runtime 215/208: 0x80070020 (in-place relaunch fails)
23:47-48  4 manual launches, each followed by RegisterByPackageFullName + RepairAppRegistrationOption
          ("ACLs repaired successfully"); every launch still 215/208
23:56:46  reboot: AppModel-Runtime 217 destroys the OLD 1.52386.3.0 container, alive since that
          session's launch on 09-12 14:30:48
23:59:05  app launches normally

Container membership on a healthy session (QueryInformationJobObject from a Claude Code tool shell): 47 processes. 17 claude.exe (desktop app + CLI) carry package identity; the other 30 do not: 9 cmd.exe, 9 conhost.exe, 8 node.exe (stdio MCP servers), 3 rbx-studio-mcp.exe, 1 powershell.exe.

Correction to my earlier comment, plus a data point against the AppHangB1 split @NullF4iTH proposed.

On 09-09 I wrote that in my data "the forced path has a 0% success rate". That no longer holds. Since then the updater force-applied four more updates on this machine and all four were clean. Full history for this machine, every update I have logs for:

| Register | To | Initiated by | AppHangB1 in window | Outcome |
|---|---|---|---|---|
| 09-03 12:37 | 1.44121.4 | updater, idle | none | failed — confounded: vmcompute.dll also failed to load until reboot |
| 09-04 23:48 | 1.46388.2 | updater, idle | none | failed — unlaunchable next working morning, reboot |
| 09-07 11:44 | 1.46388.4 | me (Help → Restart to update) | none | clean, ~5 s |
| 09-09 02:04 | 1.49585.0 | updater, idle | none | failed — 215/208, 11h45m, reboot |
| 09-11 10:10 | 1.52386.0 | updater, idle | git.exe at 10:11:02 | clean — but Register took 42 s |
| 09-12 00:21 | 1.52386.1 | updater, idle | none | clean, ~4 s |
| 09-12 05:32 | 1.52386.3 | updater, idle | none | clean, ~4 s |
| 09-14 01:43 | 1.52386.6 | updater, idle | none | clean, ~4 s |

So: 3 of 7 updater-initiated forced updates failed, 4 were clean. The forced path breaks sometimes, not always, and something else decides which.

Against the AppHangB1 split

On this machine the WER hang record does not separate the outcomes, in either direction:

• None of the 3 failures has an AppHangB1 (or any Application Hang) anywhere near the forced register.
• One clean update did have one. On 09-11, an identity-less console process hung in the middle of the forced shutdown, and the update still completed:

09-11 09:59:47  658  registration deferred, app running
09-11 10:10:19  603  RegisterByPackageFamilyName ... ForceApplicationShutdownOption
09-11 10:11:01  400  Register completed          <- 42 s; every other clean one took ~4 s
09-11 10:11:02  WER  AppHangB1  git.exe
09-11 10:11:04       CoworkVMService client connected, app back up

git.exe here is almost certainly a child of a Claude Code session running in the desktop app's Code tab, so it is exactly the "stuck child without package identity" case — and the old container was released anyway.

Two readings I can't distinguish from logs alone:

1. The mechanism is right but AppHangB1 is a poor proxy for it. A child can hold the container without ever being reported as hung (my failures), and a reported hang may get torn down by WER in time for the container to be destroyed (my 09-11 case — note the 42 s stall, consistent with the register waiting on it).
2. The stuck-child mechanism is one cause among several, and my failures come from a different one.

Either way, absence of an AppHangB1 should not be used to rule this bug out. If anyone catches a failure live, the child-process tree of the old container before recovering is the thing to capture.

Follow-up: it happened again on the next update, 1.52386.3.0 to 1.52386.6.0, same machine. The logs show the trigger needs no user action.

From %LOCALAPPDATA%\Claude\Logs\main.log:

16:33:00 [updater] Found an update, downloading
16:33:06 [updater] Update downloaded and ready to install { releaseName: 'Claude 1.52386.6' }
16:43:36 [stealth-update] Triggering stealth update after idle timeout
16:43:37 [CCD] Killing 11 PTY process tree(s) on quit
16:43:37 beforeQuitForUpdate handler fired, going down for update

Then AppModel-Runtime event 215: 0x80070020: Cannot create the Desktop AppX container for package Claude_1.52386.6.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job. Unlaunchable until reboot.

1. The stealth update fired 10 minutes after download, while the machine was idle. No banner, no Relaunch click, no chance to step in. So "quit and sign out instead of clicking Relaunch" doesn't help, and the 72h autoUpdaterEnforcementHours isn't the only trigger. The quit also killed 11 running Claude Code sessions.
2. The service's own pre-update stop fails. Logged at 16:43:38 and again at 19:27:35:

``
Claude VM Service: failed to disarm SCM recovery actions for this stop; if the stop overruns, the service may be auto-restarted during package servicing: open service: Access is denied.
``
It looks like a fix is partly in place, but the service can't change its own recovery settings, so it can restart during servicing and lock the package again.

Data point that contradicts the CoworkVMService workaround being circulated in #76357 / #51954: on this machine stopping the service does not recover the launch, because the launch attempt itself re-installs and restarts the service.

Environment

• Windows 11 Pro, build 10.0.26200, x64
• Package: Claude_1.52386.6.0_x64__pzs8sxrjxfjjc (updated from 1.52386.0.0)
• Date of capture: 2026-09-14
• Symptom: after every update the app is unlaunchable until a reboot

1. Stopping the service does not help

Microsoft-Windows-AppModel-Runtime/Admin:

08:18:45 [210] Desktop AppX container {9474F756-...} created for Claude_1.52386.6.0
08:18:45 [211] process 19224 added to container 9474f756-...      <- 19224 = CoworkVMService
...
08:23:17 [217] container {9474F756-...} removed                   <- service stopped, container gone
08:23:21 [215] 0x80070020: cannot create Desktop AppX container (job conversion failed)
08:23:21 [215] 0x80070020: cannot create Desktop AppX container (job conversion failed)
08:23:21 [208] 0x80070020: cannot create process, runtime setup failed. [LaunchProcess]

The container holding the service was torn down four seconds earlier, and LaunchProcess still fails with ERROR_SHARING_VIOLATION. So whatever holds the silo is not the service's container membership.

2. Why the "disable the service, then Relaunch" workaround cannot work

System / Service Control Manager, at the exact moment of each launch attempt:

08:23:21 [7040] Service "Claude" start type changed from Auto to disabled
08:23:21 [7045] Service "Claude" installed.
               File: "C:\Program Files\WindowsApps\Claude_1.52386.6.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
               Start type: Automatic   Account: LocalSystem

The launcher re-registers the service with StartType=Automatic and starts it again (new PID 13460, new container {9474F7A9-...}) — before the main process gets to start. Any manual Set-Service -StartupType Disabled is undone by the next Relaunch.

This is not a one-off. The same 7040 → 7045 pair fires on every launch attempt, across updates:

14.09 08:23:21   7040 + 7045   (1.52386.6.0)
14.09 08:18:45   7040 + 7045   (1.52386.6.0)
14.09 08:16:45   7040 + 7045   (1.52386.6.0)
11.09 04:49:44   7040 + 7045   (1.52386.0.0)
09.09 03:47:01   7040 + 7045   (1.49585.0.0)
09.09 03:42:xx   7040 + 7045   (1.49585.0.0)  x4
09.09 03:23:05   7040 + 7045   (1.49585.0.0)

3. Old package does not deregister cleanly

During the update itself:

08:16:45 [68] runtime state 1.52386.0.0: 0x200000 -> 0x280000
08:16:45 [67] ERROR 0x5 changing AppModel runtime state for 1.52386.0.0
              (current = 0x280000, required = 0x480000)

0x5 = access denied while moving the previous package out of its state. Possibly related, possibly separate — flagging it in case it helps narrow this down.

(Event messages on this machine are localized; event IDs, HRESULTs and package names are verbatim.)

Summary

• Confirms the finding in this issue that no userspace file handle is involved — no Claude.exe processes remain, and the only package process alive is the service.
• The service-stop workaround does not apply here: it is silently reverted by the launcher.
• A reboot is the only recovery verified on this machine (logoff not tested here).

Happy to collect anything more specific (ETW trace, hcsdiag, handle dumps) if that would help.

@gammaraay fair, and your sample is bigger than mine. Two corrections to my comment:

1. "The difference" overstated a six-update correlation. Your data breaks it in both directions, and mine doesn't hold it up either: my clean 09-09 forced update also stalled 36 s in Register (603 at 03:36:59, 400 at 03:37:35) with no AppHangB1. So neither the hang record nor the Register stall separates the outcomes here. Your reading (1) fits the mechanism better: a windowless child (MCP server, find, head) never gets reported as hung, so a hang record is at best a side effect, not the thing holding the container.
2. I undercounted. There were 8 updates in that window, not 6. 09-11 (→ 1.52386.0) and 09-12 (→ 1.52386.3) were registered during logon after a restart (AppX 821) instead of through the forced in-session path, and both were clean. My table only covers the forced/quit path.

On capturing the tree live: agreed, that's the missing piece. I now have a scheduled task on AppModel-Runtime event 208 for Claude_pzs8sxrjxfjjc!Claude that records, before anything recovers, every process with its package identity, IsProcessInJob, parent liveness and command line, plus the 201/208/215/217 and AppX events. It doesn't kill anything. If it catches the next failure I'll post which in-job, identity-less processes were alive.

The leak is dormant, not immediate: it can survive a whole successful update cycle and detonate on an unrelated relaunch days later

[🤖] Third data point, following my first and second comments on this issue. I caught this one live with a script that reconstructs container lifetimes from the event log, run before recovering. It changes the timing model, not the mechanism.

Container GUIDs truncated to their first segment.

The sequence

09-11 04:09:57  quit-for-update, 1.49585.0 -> 1.52386.0. Container {F58892C1} for the
                OLD version leaks (empty, no member process survives). But the UPDATE
                ITSELF completes cleanly - AppXDeploymentServer 400 "finished successfully",
                one harmless transient 215 that self-heals on retry. No visible failure.
                A fresh container {1008CE0F} is created for the new version and the app
                launches into it fine.

09-11 -> 09-14  {1008CE0F} runs continuously for THREE DAYS. Meanwhile {F58892C1} - the
                orphan from three days earlier - sits alive and completely empty the
                whole time. Nothing points at it. Nothing is wrong, as far as anyone
                using the app can tell.

09-14 17:21:28  {1008CE0F} is finally torn down - an ORDINARY relaunch, no update
                involved (AppXDeploymentServer shows only a RegisterByPackageFullName
                with RepairAppRegistrationOption at this timestamp, not an Add/Register
                for a new version; the package was 1.52386.0.0 both before and after).
                Windows appears to auto-trigger this repair-style register on the failed
                launch attempt itself - no Settings > Repair click from the user. It
                successfully gives CoworkVMService a fresh container (I can see its PID
                land in a new container at the same timestamp). But the main UI's
                container creation fails repeatedly: 215/208, same signature as always.
                {F58892C1} - the THREE-DAY-OLD orphan from an unrelated update cycle -
                is what's blocking it.

09-14 17:24:17  {F58892C1} finally destroyed, 3s before Winlogon 7002 (session logoff).
                Sign out, not reboot - consistent with my second comment.
09-14 17:24:33  App launches clean.

What this changes

My first comment's control table implicitly assumed the leak and the failure it causes are close together in time - the orphan from update N blocks the relaunch that follows update N. That's not required. The leak from update N can survive update N+1 completing perfectly cleanly (N+1's own quit created a fresh, healthy container and nobody noticed anything), and then block some completely unrelated relaunch of N+1 days later, with no update in the picture at that moment at all.

Practical fallout for anyone trying to self-mitigate with "sign out right after every update": that is not provably sufficient on its own. You have to confirm no orphan is actually left behind, not just assume one sign-out cleared the slate - because the thing that finally bites you might be a leak from an update cycle you already thought you'd handled safely.

One more confirmation on Repair

@Sabin-He and others in this thread have noted Repair doesn't help. This adds a wrinkle: it's not only that manually clicking Repair in Settings doesn't help - Windows appears to auto-invoke an equivalent repair-style registration the moment a launch fails (RegisterByPackageFullName ... RepairAppRegistrationOption, no user action), and it still can't reach the problem, for the same structural reason: it only touches the current package's containers, and the orphan belongs to a version that's already deregistered. It's not that Repair is broken - it's addressed to the wrong package version by construction, automatically or manually.

Detection script, if useful to others

I built a small read-only PowerShell script that reconstructs container lifetimes from Microsoft-Windows-AppModel-Runtime/Admin (ids 210/211/217, keyed by package full name) and flags any live container whose version differs from what's currently installed - which is exactly how I caught this one. Happy to paste it here if it'd help others self-diagnose without waiting for a failure to also catch a live snapshot.

Addendum to my dormant-leak comment: it survives sleep, which is why it can be dormant so long

[🤖] Short follow-up to my previous comment on this thread. Someone reasonably asked (well, I did, of myself) whether the app might have silently crashed and sat broken for days without anyone noticing. Checked, and no - and the reason why is worth recording here since it explains the mechanism, not just the timing.

Microsoft-Windows-Kernel-Power 506/507 (Modern Standby entry/exit) show the machine asleep continuously across the whole gap:

09-12 02:37   entering Modern Standby
09-14 17:10   exiting Modern Standby -- Reason: "Input Keyboard"
09-14 17:21   the incident's one failure, 11 minutes after that wake

Zero 215/208 events anywhere in the 3-day span itself. The leaked Desktop AppX container isn't repeatedly failing while nobody's watching - it's suspended along with the rest of the machine's state, same as any other job object. It only collides with the OS's next attempt to build a new container, whenever a real launch next happens to occur - which in this case was the literal moment of waking the machine, not some earlier silent failure.

Practical takeaway for anyone else chasing this down from their own logs: if you're trying to correlate a failure with "what must have happened while I was away," check Kernel-Power 506/507 for Modern Standby spans and cross-reference against AppModel-Runtime/Admin 215/208 in the same window. A leak from days ago plus a machine that's been mostly asleep will look, from a wall-clock distance, like it "must have crashed at some point" - but the event log settles it precisely, and in this case the answer was "nothing failed until the exact second the machine woke up."

Same 215/208 0x80070020 signature, now on the 2.x line (1.52386.6.0 → 2.110.0.0, 2026-09-15). Adding three things I don't see in the thread yet: a failed restart that never rebooted still cleared it, a hung console child at register time on every failed update here, and the exact container pair behaviour. Everything under "Observed" is from logs; inferences are labelled.

Environment: Windows 11 Home 10.0.26200 x64 · MSIX Claude_pzs8sxrjxfjjc, SignatureKind: Developer, Status: Ok · CoworkVMService present, Auto · ClaudeStartup StartupTask enabled (State=2) · C:\ProgramData\Microsoft\Windows\AppRepository\Families\ApplicationData\Claude_pzs8sxrjxfjjc absent (same as @ennsta / @mySebbe) · logs at %LOCALAPPDATA%\Claude\logs\main.log. Earlier write-up from this machine on the 0x80073D02 variant: #76357 (2026-08-09).

Observed: 2026-09-15 timeline (local)

16:48:36  main.log   [updater] Update downloaded and ready to install { releaseName: 'Claude 2.110.0' }
16:48:36  AppX 658   Marking package {Claude_2.110.0.0} for deferred registration because {Claude_1.52386.6.0} is still running
20:15:32  main.log   [stealth-update] Triggering stealth update after idle timeout
20:15:33  main.log   [CCD] Killing 15 PTY process tree(s) on quit
20:15:34  main.log   beforeQuitForUpdate handler fired, going down for update   <-- last line for 16 min
20:15:34  AppX 603   RegisterByPackageFamilyName ... ForceApplicationShutdownOption
20:16:07  WER 1002   Application Hang: conhost.exe 10.0.26100.9444 stopped interacting with Windows and was closed
20:16:07  WER 1001   AppHangB1  conhost.exe
20:16:07  AppX 9648/9650/9643   CoworkVMService terminated, TerminateApplications successful (x2)
20:16:07  AMR 217    Destroyed container {60E4B8CB-...} for Claude_1.52386.6.0            <-- one of the pair
20:16:07  AMR 67     Failed with 0x5 modifying AppModel Runtime status for Claude_1.52386.6.0 (0x280000 -> 0x480000)
20:16:08  AppX 400   Register of Claude_2.110.0.0 finished successfully (Overall time: 34156 ms)
20:16:08  AMR 215 x2, 208   0x80070020 converting the job / [LaunchProcess]                <-- updater's own relaunch fails
20:18:27  AMR 215 x2, 208   (manual launch)  + AppX 603 RegisterByPackageFullName ... RepairAppRegistrationOption
20:18:28  AppX 400   Register finished successfully (1188 ms); SCM 7040/7045 service reinstalled; 215 x2, 208 again
20:19:22  System 1074   StartMenuExperienceHost initiated restart of computer, reason Other (Unplanned)
20:19:22  AMR 217    Destroyed container {60E4BA7A-...} for Claude_1.52386.6.0            <-- the orphan, same second
20:20:28  Winlogon 4004   The Windows logon process has failed to terminate the currently logged on user's processes
          (no 6006/6005, no 7002/7001; LastBootUpTime unchanged: 2026-09-13 19:46:42 -- the machine did NOT restart)
20:32:05  AMR 210/211/201   Created process for Claude_pzs8sxrjxfjjc!Claude in Claude_2.110.0.0   <-- normal launch
20:32:05  main.log   [updater] Version changed since last launch: 1.52386.6 -> 2.110.0
                     [event-loop-stall] update relaunch (stale marker) stands in for an unheard suspend

1. A restart that failed still cured it

The 20:19:22 restart never completed: Winlogon logged 4004 a minute later and the boot time is unchanged. But the orphaned 1.52386.6.0 container was destroyed in the same second the restart was requested, and the next launch at 20:32 was clean. So the cure is the session-teardown process sweep, not the boot and not a completed logoff. That narrows @TomerReuven's "logoff is sufficient" one step further: whatever Winlogon kills in the first second of teardown is enough.

Inference, not measured: the process Winlogon then failed to terminate is plausibly the hung console child from the next section, i.e. the sweep killed the pinning member and then got stuck on something else.

2. A hung identity-less console child at register time, on every failed update here

Four stealth updates this month, WER Application Hang records within the register window:

| Stealth update | Transition | PTY trees killed | Hang at register | Outcome |
|---|---|---|---|---|
| 09-11 01:55 | 1.49585.0 → 1.52386.0 | 8 | cmd.exe AppHangXProcB1 (waiting on python.exe) 01:55:42 | dark 5h26m, reboot |
| 09-11 22:44 | 1.52386.0 → 1.52386.3 | 6 | none | relaunched in 2 s |
| 09-13 19:07 | 1.52386.3 → 1.52386.6 | 8 | conhost.exe AppHangB1 19:07:37 | dark 41 min, reboot |
| 09-15 20:15 | 1.52386.6 → 2.110.0 | 15 | conhost.exe AppHangB1 20:16:07 | dark 16 min, see §1 |

3/3 failures had a hung console child in the forced-shutdown window; the 1/1 success did not. n=4, one machine, so I'm reading this as consistent with @NullF4iTH's mechanism rather than proof of it, and @gammaraay's counter-examples still stand. Note the [CCD] Killing N PTY process tree(s) on quit line is a usable proxy for how much identity-less tree the forced shutdown has to reap.

3. The container pair

Both 1.52386.6.0 containers were created at the 09-13 19:48 launch. TerminateApplications at 20:16:07 destroyed one; its sibling {60E4BA7A} survived empty for 3 min 15 s until the teardown in §1 and was what blocked every 2.110.0.0 activation. Matches @TomerReuven's observation that the survivor is always the one holding the UI process. Event 67 0x5 (0x280000 → 0x480000) fires at the same instant, as @ZardoZAntony noted.

Mitigation applied, will report back

Set the documented machine policy so the stealth path cannot fire, and will update manually with the app closed:

# elevated
New-Item -Path 'HKLM:\SOFTWARE\Policies\Claude' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Claude' -Name 'disableAutoUpdates' -Value 1 -Type DWord

Per the MDM reference this is one of the "app-behavior keys" that leaves the rest of the configuration local. If the [stealth-update] line stops appearing and the next update (done by hand, app closed) registers cleanly, that's a usable off-switch for anyone who'd rather own their update timing than lose 15 sessions to it.

Caveat on scope: single machine, timestamps verbatim from the logs, §1's "which process" is inferred.

Follow-up to my rescue-script comment: the same launch failure recurred today, 2026-09-17, on Claude Desktop 2.110.1.0 (Claude_2.110.1.0_x64__pzs8sxrjxfjjc).

Observed in Microsoft-Windows-AppModel-Runtime/Admin (local time, UTC+02:00):

• 09:47:00–09:47:02: Event 215 with 0x80070020 while converting the job, plus Event 208 while configuring runtime / LaunchProcess.
• Before recovery, no Claude Desktop package processes were running. A standalone Claude Code CLI process was running; its executable path distinguished it from Desktop.
• Ran the same self-contained rescue script linked above, which runs the package-scoped NtUnloadKey2(REG_FORCE_UNLOAD) recovery as SYSTEM through a temporary scheduled task.
• 09:47:16: Event 201 recorded successful creation of Claude Desktop for this package. The rescue process exited with code 0, the Claude window was responding, and I confirmed the app was working again.

Recovery succeeded without signing out, rebooting, reinstalling, or resetting the app. The standalone CLI process remained running.

This confirms that the failure still occurs on 2.110.1.0 and that the previously posted recovery script restored launch on this occurrence. I did not capture the per-hive unload output in this run, so I cannot report a hive count or individual unload statuses. A supported recovery path and a fix preventing recurrence are still needed.

Corroborating from an independent set of logs, plus one thing I cannot find in this thread.

Briefly, so as not to restate what's here: I independently hit the same 0x80070020 on AppModel-Runtime 208/215, with the Helium User.dat/UserClasses.dat pinned, event 649 reporting "ACLs repaired successfully ... Register next time should succeed" and register then failing, and the 7040/7045 re-arm on every servicing. All already established here, most of it in more depth than I had. 2.110.0.0 and 2.110.1.0 are already covered by @berad217 and @kamkie.

The new part: both HRESULTs occurred inside a single incident on my machine, same package, two minutes apart. All times UTC:

2026-09-15T22:29:10.517Z .. 22:30:38.680Z   36 events (208 and 215)   0x80070020
2026-09-15T22:32:30.747Z                    215 + 208                 0x80070002
2026-09-15T22:32:32.611Z                    215 + 208                 0x80070002

In fairness, Settings-initiated repair was already in flight by then (603 from SystemSettings.exe at 22:29:38.167Z, 22:30:03.279Z, 22:30:14.003Z) and fresh package data appeared from 22:33:27.664Z, so the 0x80070002 may be downstream of that remediation rather than an independent fault. Flagging it because #76357 (closed as a duplicate of this) and #94241 both treat the two codes as separate failures, and on this machine they were not cleanly separable.

Minor addition: Settings Reset did not recover it here on 17 September, and it is destructive, wiping local app config, the MCP server list, scheduled tasks and the sidebar session list. Worth steering people away from it for this signature, given the silo unload in this thread costs nothing.

Safety note on the SYSTEM unload script: check for running Desktop processes first.

While building a local wrapper around @kamkie's script I tested it against a healthy, working Claude Desktop, and found something worth flagging for anyone running it.

A normally running install has these hives mounted too. Right now, with Claude working fine and 13 Desktop processes alive, hivelist shows 8 Claude silo entries, including the two this thread is concerned with:

\REGISTRY\WC\Silo<guid>user_sid      <-  ...\Packages\Claude_<pfn>\SystemAppData\Helium\User.dat
\REGISTRY\WC\Silo<guid>user_classes  <-  ...\Packages\Claude_<pfn>\SystemAppData\Helium\UserClasses.dat

So a mounted silo is not itself the fault. The fault is a mounted silo with no Desktop process alive. The script's own filter, package family plus silo prefix, matches both states identically, and its guard against this is a line of prose in the comment ("do not run it while Claude is actually working").

Suggested addition: refuse unless there are zero Claude Desktop processes, with an override switch. Worth filtering on executable path rather than process name, since the Claude Code CLI also runs as claude.exe from %APPDATA% and is unrelated to the package container, so it should not block the repair.

I have not tested what force-unloading live hives does to a running install, and did not want to find out on a working one. But given people are running this mid-incident, when it is easy to misjudge whether the app is truly dead or just slow to show a window, a process check seems cheap insurance.

Adding a root-caused instance of this on Windows, with the trigger timestamped and the container error identified. Hopefully useful to whoever picks this up.

Environment: Claude Desktop MSIX 1.52386.6.0 → 2.110.0.0 → 2.110.1.0, Windows 11, enterprise-managed (Defender for Endpoint, Dell Trusted Device, Absolute). Package Status: Ok, standard WindowsApps location.

Trigger — confirmed via Get-AppxLog: the auto-updater applied 2.110.0.0 → 2.110.1.0 at 00:43 and again 00:54 local time with ForceApplicationShutdownOption while the app was open and idle overnight. The app never relaunched. Same pattern on the previous update. It only happens when the app is left running unattended.

The launch failure is not a file lock. The dialog says "Another program is currently using this file," but Microsoft-Windows-AppModel-Runtime/Admin shows the real error:

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

Container job creation fails. Verified no user-mode process holds any package file: Get-Process by path, Win32_Process enumeration, and Resource Monitor → Associated Handles searched while the error dialog was on screen — all empty. Killing orphaned MCP/bun/node/python processes does not help because there are none. Windows auto-runs RegisterByPackageFullName with RepairAppRegistrationOption, which completes 0x0, and launch still fails. Sign-out/in does not clear it; only a full reboot does.

Application logging is dead. main.log, claude.ai-web.log, cowork_vm_node.log last written 2026-08-20; main-window.log and mcp.log 0 bytes since 2026-08-11. Persists across two major version upgrades and a clean reboot. The logs\ directory is writable (ACL verified, write probe succeeded) and IndexedDB/Local Storage in the same container are written normally. So none of the four abnormal exits since 2026-09-05 have any application-level record.

Related — service cannot arm its own recovery. cowork-service.log on every stop: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied. The service DACL is:

D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-<CoworkVMService SID>)

No ACE for BA or SY, so SERVICE_CHANGE_CONFIG is denied to LocalSystem and to elevated administrators. sc.exe qfailure shows RESET_PERIOD 0 with no actions.

Asks:

1. Don't force-restart a running app to apply an update. Apply on next launch, or at minimum give the user a visible choice of timing. autoUpdaterEnforcementHours caps at 72 with no "never" option.
2. Make container creation recoverable after an abnormal exit without a reboot.
3. Fix Windows logging so these crashes can actually be diagnosed.

Happy to supply full Get-AppxLog, AppModel-Runtime, and cowork-service.log output on request.

Hitting this again today (2026-09-17), same signature. Claude Desktop 2.110.1.0, CoworkVMService / cowork-svc.exe.

cowork-service.log shows the service repeatedly failing to reset its own crash-recovery config after each crash, which appears to be what leaves the AppX job/silo handle orphaned:

Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.
Warning: failed to disarm recovery actions for this stop: open service: Access is denied.

Recurred 6 times in a single day (12:26, 12:28, 12:29, 12:31, 13:00, 16:06-16:08). Stopping CoworkVMService and killing cowork-svc.exe manually does not clear the lock -- app still fails to launch with 0x80070020 afterward. Only a full reboot recovers it. Would be good to get a fix prioritized since this is happening multiple times per day now, not as a one-off.

Adding data from another affected machine. Same symptom, but my error code is 0x80073D02 rather than the 0x80070020 in the original report — posting here since #76357 was consolidated into this issue. If maintainers judge this a sibling defect rather than the same one, happy to split it out. Environment Windows 11 Pro 26200 (x64) Claude Desktop 1.40609.0.0, MSIX, package family Claude_pzs8sxrjxfjjc * Updates are self-downloaded .msix files, not via Microsoft Store (SignatureKind: Developer) The event that names the blocker Get-AppPackageLog on a failed register writes AppXDeploymentServer event 638, which states the blocking app explicitly. This seems underused in the existing reports and is the fastest way to confirm the cause: `` Packages were not updated because affected apps are still running. Running apps: {Claude_pzs8sxrjxfjjc!Claude} Directly serviced packages: {Claude_1.40609.0.0_x64__pzs8sxrjxfjjc} Number of previous attempts: 0, Is user session locked: false ` Every failure fails at the same state handler: ` Error 0x80073D02: Failure in the ResolvedDeferredRegistrations state handler. ` **This is specific to the Claude package, not a broken deployment queue** Control test, same minute, same elevated shell: Package Result Microsoft.WindowsCalculator registered successfully, **656 ms** Claude_1.40609.0.0 failed at ResolvedDeferredRegistrations, **78 ms** So the machine's MSIX subsystem is healthy; only the Claude package is blocked, because only the Claude package has something of its own still running. **Timing: how long between the download and the forced shutdown** The updater downloads, then ~10 minutes later force-closes the app to apply. Four consecutive update cycles: ` download 08-25 13:48 -> force shutdown 08-25 13:59 +00:10 download 08-25 19:38 -> force shutdown 08-25 21:34 +01:55 download 08-26 15:54 -> force shutdown 08-26 16:05 +00:10 download 08-28 11:36 -> force shutdown 08-28 11:48 +00:12 ` Practical consequence: the whole cycle completes inside one working session, so "shut down at the end of the day" does not avoid it. The app is killed mid-session, and clicking the icon during the swap window produces the dialog. **A full uninstall + reinstall does NOT fix it** Worth recording so others do not spend the time. I uninstalled Claude Desktop completely, confirmed no package remained registered, reinstalled from the official download, signed in — and the very next register attempt failed identically at ResolvedDeferredRegistrations with 0x80073D02. **An orphaned package folder also survives the uninstall** ` C:\Program Files\WindowsApps\Claude_<older-version>_x64__pzs8sxrjxfjjc 2667 files, 591.6 MB ` No package record in the repository — AppXDeploymentServer logs **event 1230** ("these hardlinks did not have packages in repository", ~100 entries) on every deployment operation. It persisted through the uninstall/reinstall and had to be removed manually after taking ownership. Its large files all report hardlink count = 1, so it is genuinely dead space, not shared with the live package. **CoworkVMService ships with the app and is not opt-in** Confirming a detail from [#76357](https://github.com/anthropics/claude-code/issues/76357): CoworkVMService (cowork-svc.exe, display name "Claude") is declared in AppxManifest.xml, starts automatically at boot, and runs from inside the package directory. It is **not** a consequence of enabling Cowork: * After the reinstall, with vm_bundles and claude-code-vm both absent (zero Cowork data provisioned), the service was still State=Running, StartMode=Auto * Its first installation predates the first Cowork session on this machine by several days So every Claude Desktop install carries a service that holds the package folder open regardless of whether the user closes the window. **A debugging trap worth flagging** Do not count package processes with Get-CimInstance Win32_Process | Where-Object { $_.ExecutablePath -like '*WindowsApps*Claude*' } cowork-svc.exe reports an **empty** ExecutablePath via WMI, so that filter silently misses it and reports zero processes while the package is still in use. That false reading cost me several hours and one unnecessary reinstall. Match on process **name**, or better, just read event 638 and let Windows tell you. **Suggested fix** (same as [#76357](https://github.com/anthropics/claude-code/issues/76357), restating with the extra evidence) The updater should, before applying the package: 1. Stop-Service CoworkVMService 2. terminate all package-owned Claude.exe` processes 3. apply the MSIX update 4. restart the service and relaunch the app A reboot should never be required.

Two more occurrences today on the same machine, and the logs this time rule out
the explanation most of these reports assume. Adding them because the sequence
is unusually clean.

Environment

• Windows 11 Pro 26200 (x64)
• Claude Desktop, MSIX, package family Claude_pzs8sxrjxfjjc
• Versions today: 2.110.0 → 2.110.1 → 2.2553.0 (two updates in ~3.5 hours)

The failure is not caused by anything holding the package

Previous reports (and my own earlier one) assume the leak follows a forced
shutdown of a still-running app. Today shows it happens when the app shuts
itself down cleanly and Windows has already stopped the packaged service.

Occurrence 1, from main.log plus the AppX logs:

09:12:27  [updater] Host busy; deferring background update checks
09:15:27  [updater] Host quiet after 3 busy min; checking for updates
09:15:27  [updater] Found an update, downloading
09:15:39  [updater] Update downloaded and ready to install (2.110.1)
09:15:39  AppXDeployment 638  Running apps: {Claude_pzs8sxrjxfjjc!Claude}   <- staging, expected
09:15:39  AppXDeployment 658  deferred registration
09:25:39  [updater] Staged version 2.110.1 is still current
09:26:09  [stealth-update] Triggering stealth update after idle timeout
09:26:09  [stealth-relaunch] Saved z-order anchor / navigation history
09:26:10  beforeQuitForUpdate handler fired, going down for update   <- app quits ITSELF
09:26:10  AppXDeployment 603  RegisterByPackageFamilyName [ForceApplicationShutdownOption]
09:26:46  AppXDeployment 9648/9650  TerminateSingleService successful, service CoworkVMService terminated
09:26:49  AppXDeployment 400  Register operation finished
09:26:49  AppModel-Runtime 215  0x80070020 Cannot create the Desktop AppX container
09:26:56  AppModel-Runtime 215 + 208  0x80070020
09:37:54  [updater] Version changed since last launch: 2.110.0 -> 2.110.1   <- back after 11 min

Occurrence 2, same day, identical shape:

12:40:55  Found an update, downloading (2.2553.0)
12:41:24  Update downloaded and ready to install
12:51:54  [stealth-update] Triggering stealth update after idle timeout
12:51:55  beforeQuitForUpdate handler fired, going down for update
12:52:35  AppModel-Runtime 215  0x80070020
12:52:42  AppModel-Runtime 215 + 208  0x80070020
~12:59    app back on 2.2553.0

So at the moment of the failing container creation:

• the app had quit itself via beforeQuitForUpdate, not been force-killed
• CoworkVMService had already been terminated by the deployment engine

(events 9648/9650 at 09:26:46, three seconds before the first 215)

• the register itself succeeded (event 400)

The register is fine. What fails is rebuilding the container afterwards. Every
subsequent launch attempt produces a fresh 215/208 rather than recovering, so
each attempt to reopen the app makes the situation worse rather than better.

Every register leaks, without exception

Correlating every Claude register operation against AppModel-Runtime 215/208
within 3 minutes, since 08-31:

| Register | Forced | 215/208 |
|---|---|---|
| 09-01 21:28 | yes | 3 |
| 09-02 02:30 | yes | 15 |
| 09-02 02:31 | yes | 9 |
| 09-02 02:31 | yes | 3 |
| 09-03 12:29 | yes | 3 |
| 09-07 15:48 | yes | 3 |
| 09-07 16:12 | yes | 3 |
| 09-08 13:14 | yes | 12 |
| 09-17 09:26 | self-quit | 3 |
| 09-17 12:51 | self-quit | 3 |

10 of 10. The two self-quit cases matter most: they remove "something was still
running" as an explanation.

Outcome varies even though the leak does not. Sometimes the app recovers on its
own after ~10 minutes (both of today's cases). Sometimes it stays unlaunchable
until sign-out or reboot (09-03, 09-07, 09-08). A user-session script cannot
clear it either way - I tried stopping the service and terminating every
package process, and it changes nothing, which is consistent with the object
being bound to the logon session.

Frequency makes this expensive

Update cadence on this machine: 08-25 (x2), 08-26, 08-28, 09-02, 09-03, 09-07,
09-08, 09-10, 09-11, 09-13, 09-15, 09-17 (x2). Roughly daily, twice on some
days. Each one costs ~10 minutes of the app being gone, and anything unsaved in
a Design canvas at that moment is lost, because the canvas is not persisted
locally.

The client log also shows [updater] Using GrowthBook check_interval_ticks=1
(default 4) - this account appears to be in a cohort checking four times as
often as default. Even without a code fix, moving affected users out of that
cohort would cut the exposure by ~4x. That seems worth considering as an
interim mitigation, since it needs no release.

What would help users today

The app already knows when it is about to do this - beforeQuitForUpdate fires
first. Two things that need no fix to the underlying container bug:

1. After relaunch, detect that the container failed (215/208 in

AppModel-Runtime) and tell the user plainly that a Windows sign-out is
required, rather than leaving them with Explorer's generic "Another program
is currently using this file" dialog.

1. Do not retry the launch automatically on that error - each retry emits

another 215/208 and does not recover.

Second machine on check_interval_ticks=1, with measured check rates. Corroborating @rachellliao's cohort observation.

@rachellliao noted her client log shows [updater] Using GrowthBook check_interval_ticks=1 (default 4) and suggested moving affected users off that cohort as an interim mitigation. My machine is in the same cohort, and I can put numbers to what it costs.

That line appears 252 times across my retained logs, always with the same values:

[updater] Using GrowthBook check_interval_ticks=1 (default 4)

Measured update checks per day from main.log:

09-13  24 checks
09-14  22 checks
09-15  24 checks
09-16  18 checks
09-17  14 checks

That is roughly hourly, which is what ticks=1 implies, against roughly six a day at the default of 4. Six failures here in eight days, against reports in this thread of hitting it occasionally.

The hypothesis worth testing: hit rate scales with update-check frequency, because each applied update is another chance to leak the silo. @rachellliao's data supports the mechanism directly, with 10 of 10 registers leaking regardless of whether the shutdown was forced or clean. If leak-per-update is near constant, then updates-per-day is the whole story, and the cohort assignment would explain most of the variance in how often people hit this.

Ask for anyone hitting this often: please check which cohort you are in and post the value. It is one line:

Select-String -Path "$env:LOCALAPPDATA\Claude\Logs\main*.log" -Pattern 'check_interval_ticks' | Select-Object -Last 1

If the frequent reporters are all ticks=1 and the occasional ones are ticks=4, that narrows the repro considerably and makes the cohort change @rachellliao proposed a defensible interim mitigation with no release required.

I'm getting it every night :/ some support for the ticks hypothesis:
PS C:\Users\Driver> Select-String -Path "$env:LOCALAPPDATA\Claude\Logs\main*.log" -Pattern 'check_interval_ticks' | Select-Object -Last 1

AppData\Local\Claude\Logs\main3.log:40943:2026-08-25 19:51:14 [info] [updater] Using GrowthBook check_interval_ticks=1
(default 4)

Just got it on my windows PC, it does not boot the claude desktop "dit bestand wordt door een ander programma gebruikt" . Account develuse@gmail.com

Following up on my earlier comment with a live capture on 2.110.1.0: a snapshot taken automatically at the failure, before any recovery. The process holding the old container was not a Claude Code child, contrary to what I expected. It was RuntimeBroker.exe carrying the old package's identity.

Sequence (local time, Windows 11 Pro 26200 x64, MSIX Claude_pzs8sxrjxfjjc)

09-15 23:06:46  stealth update 1.52386.6 -> 2.110.0, relaunched 7 s later, clean
09-16 13:00:17  app launched; container {DB60FB19} created for 2.110.0.0 (main pid 17736)
09-16 13:00:18  RuntimeBroker.exe pid 4296 starts, parent DcomLaunch svchost, "-Embedding"
09-17 09:00:34  2.110.1.0 staged; 658 deferred registration
09-17 09:11:05  [stealth-update] Triggering stealth update after idle timeout
                [CCD] Killing 3 PTY process tree(s) on quit
09-17 09:11:05  AppX 603 RegisterByPackageFamilyName ... ForceApplicationShutdownOption
09-17 09:11:06  217 destroys the OTHER 2.110.0.0 container {DB60EC6A}
09-17 09:11:07  AppX 400 register finished successfully; 215/208 0x80070020, in-place relaunch fails
09-17 12:42:41  next launch attempt: 215/208 again
09-17 12:42:47  reboot; 217 finally destroys {DB60FB19}
09-17 12:43:51  app launches normally

Snapshot at 09:11:08 (GetPackageFullName + IsProcessInJob + parent liveness over every PID, taken by a scheduled task triggered on event 208):

• Processes carrying the old package identity: exactly one, RuntimeBroker.exe pid 4296, parent DcomLaunch, -Embedding, in a job, started 09-16 13:00:18, one second after that session's main process.
• Surviving Claude Code children (node / cmd / conhost / MCP servers / shells): none.
• Live containers: {DB60FB19} 2.110.0.0 (created 09-16 13:00:17, the blocker) and {F6410FF6} 2.110.1.0 (the service).

Second snapshot at 12:42:41, same incident: RuntimeBroker 4296 was gone, no process carried the old identity at all, and {DB60FB19} was still alive and still blocking. So both states discussed in this thread occurred in sequence within one incident on one machine: first a live member process with the old identity, then an empty leaked container after it exited.

Two practical notes:

• A check by file handles or by Get-Process image path will not surface this one. RuntimeBroker.exe holds no package file and its path is C:\Windows\System32; it is only visible by calling GetPackageFullName on every PID (or from the 211 events). It is also a Windows broker, not something the app spawned, which may be why ForceApplicationShutdown left it behind.
• For no-reboot recovery attempts: killing the old-identity broker while it is still alive looks worth trying in the early window, but it is clearly not sufficient later, since the container here outlived it by three and a half hours.

It's unbelievable that this issue is still open. PLEASE FIX!

Same failure on Windows 11 Pro (build 26200), Claude Desktop MSIX 1.52386.0.0 -> 1.52386.3.0, 2026-09-12

Adding timestamped evidence that may narrow this down. The container failure happens 2 seconds after the app quits for update, before any user or tooling can intervene:

08:51:28  main.log: beforeQuitForUpdate handler fired
08:51:30  AppModel-Runtime/Admin 215: 0x80070020: Cannot create the Desktop AppX
          container for package Claude_1.52386.3.0_x64__pzs8sxrjxfjjc because an
          error was encountered converting the job.
08:51:31  (same error repeats)

Key observations

1. 215 is logged only at the update moment. Six later activation attempts (08:52:00 ... 08:56:33) produced zero additional 215 events, while TWinUI 1621 reported each activation as "completed successfully" with no process ever starting.
2. Every relaunch attempt re-triggers package registration (AppXDeploymentServer 400), which reinstalls the packaged service (System 7045/7040) - so retrying actively prolongs the broken state.
3. Stopping CoworkVMService and killing all package processes does not help. I automated exactly that (elevated, verified Stopped each time); 3 automatic + 3 manual attempts all failed. Only a reboot recovered it.
4. The app itself logs that it cannot prevent the service from being revived:

``
CoworkVMService: failed to disarm SCM recovery actions for this stop; if the stop
overruns, the service may be auto-restarted during package servicing:
open service: Access is denied
CoworkVMService: failed to configure SCM recovery actions ... Access is denied
`
The service is AUTO_START + WIN32_PACKAGED_PROCESS + LocalSystem, with no SCM recovery actions configured (sc qfailure -> RESET_PERIOD 0`).

1. This reproduces on every update (2026-09-09, 09-11, 09-12).

Note for anyone collecting logs: the Microsoft-Windows-AppModel-Runtime/Admin channel wrapped in 7-20 minutes on my machine, so the 215 events are gone if you look later. Capture right after the failure.

Follow-up to my 2026-09-17 report — recurred again today, fourth consecutive occurrence, and this one was mid-workday.

Get-AppxLog shows the forced update 2.2553.1.0 -> 2.2553.13.0 at 10:45 and 12:05 local time on 2026-09-22, while I was actively using the machine. Same "Another program is currently using this file" on relaunch, same AppModel-Runtime 215 / 0x80070020 pattern, only a reboot recovers. So this is not an idle/overnight edge case: whatever timer drives ForceApplicationShutdownOption fires during active use too. The two attempts ~80 minutes apart match the pair I logged on 09-17 (00:43 / 00:54 for 2.110.0.0 -> 2.110.1.0).

Two data points that may help whoever picks this up:

1. The machine-side theories are exhausted on this box. Over the past week I checked Defender for Endpoint ASR (audit-only, no Claude events), Dell Trusted Device and Absolute filter drivers, WindowsApps\Deleted delete-pending leftovers (cleared — no effect), package Status/SignatureKind, package-folder ACLs (repaired by Windows on every launch attempt, still fails), and every user-mode handle via Resource Monitor while the error dialog was displayed (empty). Nothing on the endpoint explains it. @NullF4iTH's RuntimeBroker.exe-with-old-package-identity capture is consistent with that: a broker holding the silo, not a file, is exactly what a file-handle search would miss.
2. Application logging has been dead on this machine since 2026-08-20 across 1.52386 -> 2.110.x -> 2.2553.x, with a verified-writable logs\ directory. I can't contribute check_interval_ticks or beforeQuitForUpdate timings because the app writes nothing. If that's a separate regression it's blocking diagnosis for at least some of the people in this thread.

Ninety-eight comments, five months, no maintainer response. A forced restart that leaves the app unlaunchable until reboot is a P1 for anyone using Desktop as their primary surface.

Follow-up to my 2026-09-17 report — recurred again today, fourth consecutive occurrence, and this one was mid-workday. Get-AppxLog shows the forced update 2.2553.1.0 -> 2.2553.13.0 at 10:45 and 12:05 local time on 2026-09-22, while I was actively using the machine. Same "Another program is currently using this file" on relaunch, same AppModel-Runtime 215 / 0x80070020 pattern, only a reboot recovers. So this is not an idle/overnight edge case: whatever timer drives ForceApplicationShutdownOption fires during active use too. The two attempts ~80 minutes apart match the pair I logged on 09-17 (00:43 / 00:54 for 2.110.0.0 -> 2.110.1.0). Two data points that may help whoever picks this up: 1. The machine-side theories are exhausted on this box. Over the past week I checked Defender for Endpoint ASR (audit-only, no Claude events), Dell Trusted Device and Absolute filter drivers, WindowsApps\Deleted delete-pending leftovers (cleared — no effect), package Status/SignatureKind, package-folder ACLs (repaired by Windows on every launch attempt, still fails), and every user-mode handle via Resource Monitor while the error dialog was displayed (empty). Nothing on the endpoint explains it. @NullF4iTH's RuntimeBroker.exe-with-old-package-identity capture is consistent with that: a broker holding the _silo_, not a file, is exactly what a file-handle search would miss. 2. Application logging has been dead on this machine since 2026-08-20 across 1.52386 -> 2.110.x -> 2.2553.x, with a verified-writable logs\ directory. I can't contribute check_interval_ticks or beforeQuitForUpdate timings because the app writes nothing. If that's a separate regression it's blocking diagnosis for at least some of the people in this thread. Ninety-eight comments, five months, no maintainer response. A forced restart that leaves the app unlaunchable until reboot is a P1 for anyone using Desktop as their primary surface.

DITTO FOR ME TODAY ALSO

Hi, I’m experiencing the same recurring issue, and it has been happening for about a month and a half.
Today, September 22, Claude updated from 2.2553.1.0 to 2.2553.13.0 and closed while I was using it. It now refuses to reopen, displaying “Another program is currently using this file.”
Windows logs show ForceApplicationShutdownOption at 21:26 local time, followed by AppModel-Runtime events 215/208 with 0x80070020 (“error converting the job”). No claude.exe process remains.
Have you found a reliable recovery without signing out or rebooting, or received any response from Anthropic? I can provide targeted logs if useful.

A fresh recurrence on a newer build, on the same machine that previously experienced this failure.

Environment

• Windows 11 Pro 25H2, build 26200.9457
• Claude Desktop MSIX: Claude_2.2553.13.0_x64__pzs8sxrjxfjjc
• Package status: Ok
• Package installed/updated on 2026-09-22 at approximately 21:14 local time

Reproduction and current evidence

On 2026-09-23 at 08:05 local time, launching Claude produced no targetable window. Microsoft-Windows-AppModel-Runtime/Admin recorded:

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

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

Additional observations:

• No Claude/Anthropic processes were running after the failed activation.
• CoworkVMService was stopped; Appinfo was running.
• Both package registry hives were still locked:
• %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat
• %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\UserClasses.dat
• HKLM\SYSTEM\CurrentControlSet\Control\hivelist still contained the Claude user-container mappings under Silo934eac67-a570-82a8-6db9-fe7c1c4ab787.
• An elevated scan using a signature-verified Microsoft Sysinternals Handle executable found no matching user-mode file or job handle. This is consistent with the already reported orphaned container state rather than an ordinary lock on Claude.exe.

This is a recurrence across releases on the same machine: the same 0x80070020 / Event 215+208 failure was previously observed with Claude_2.110.1.0 on 2026-09-17, and rebooting only provided temporary recovery. It returned after the next update cycle on 2.2553.13.0.

Please provide either:

1. a supported way to tear down the orphaned Desktop AppX container without logging off or rebooting, or
2. an updater change that verifies complete container teardown before registering and relaunching the new package.

A supported update-deferral option would also reduce disruption until the underlying issue is fixed.

Summary

This is another reproduction of this issue, from a stealth auto-update, with a full process-level trace. After the update, the new version couldn't start. The shell shows "Another program is currently using this file" on C:\Program Files\WindowsApps\Claude_2.7032.0.0_x64__…\app\Claude.exe, and AppModel-Runtime logs 215/208 0x80070020. On this machine it only ever cleared at sign-out/reboot.

The trigger here was long-running processes that a Claude Code session had started through the Bash tool (nohup … &). ForceApplicationShutdown didn't terminate them, and they ran on past the update. The old per-user container \Container_Claude_<oldver>_x64__pzs8sxrjxfjjc-<SID> stayed alive until they exited, and Windows couldn't create the container for the new version. Related: #89680, #93220, #73107, #91763, #92167, #95266.

Environment

• Windows 11 Enterprise 10.0.26200, x64
• Claude Desktop MSIX Claude_pzs8sxrjxfjjc 2.2553.13.0 → 2.7032.0.0; Claude Code CLI 2.1.280; Bash tool = Git for Windows bash
• Rancher Desktop (WSL2, moby)

Steps to reproduce

1. In a Code-tab session, have the Bash tool start long-lived servers, e.g. rdctl start … (returns, but the Rancher Desktop.exe it spawns keeps running), nohup dotnet run --project <api> > api.log 2>&1 &, nohup npm run dev > web.log 2>&1 &
2. Leave the app idle and unfocused with an update staged, so [stealth-update] Triggering stealth update after idle timeout fires.
3. The app quits for the update, and the update registers successfully. The relaunch fails.

Expected: the new version relaunches, and spawned tools are either terminated or don't block the relaunch.
Actual: every launch fails the same way until sign-out or reboot. Ending the orphaned processes is reported to fix it in #73107, #91763 and #93220; that wasn't tested here.

Timeline (2026-09-23, local time)

| Time | Event |
|---|---|
| 08:42:39 | App 2.2553.13 main process starts in container {C36B4903} (AppModel 210/211) |
| 08:44–08:52 | Bash tool: rdctl start, nohup bash db/apply.sh &, nohup dotnet run … &, 2× nohup npm run dev & |
| 09:15:25 | [stealth-update] Triggering stealth update after idle timeout; CLIs stopped; Killing 2 PTY process tree(s) on quit |
| 09:15:27.842 | AppXDeploymentServer 603 RegisterByPackageFamilyName with ForceApplicationShutdownOption; main process exits on its own at 09:15:27.956 |
| 09:16:03.109 | Only 5 of the old app's descendants terminated (crashpad-handler + 4 console conhosts, via WerFault /hc). Application 1002/MoAppHang is for the crashpad-handler. The old cowork-svc, in its separate PackagedService container, was also ended. |
| 09:16:04–05 | Automatic relaunch: AppModel-Runtime 215 0x80070020 Cannot create the Desktop AppX container … converting the job (twice) + 208 [LaunchProcess]. The first 215 fires just before AppX 400 "Register finished successfully"; the second comes after it. The new version's PackagedService container (cowork-svc) is created fine. |
| 09:16–09:45 | Old container {C36B4903} stays alive; 42 Bash-tool descendants still running (Rancher Desktop + wsl helpers, dotnet → API → PuppeteerSharp chrome ×7, 2× npm → vite → esbuild, a hung docker.exe) |
| 09:45:32.240 | Reboot/logoff ends them → AppModel 217 destroys {C36B4903} (the per-family Helium User.dat/UserClasses.dat show the same LastWriteTime). After boot, 2.7032 launches normally. |

Survivor list reconstructed from EDR process journals (exact start/exit times + command lines). Process-creation auditing (4688) wasn't enabled.

Frequency

Of 33 in-app update quits between 2026-06-17 and 2026-09-23, 7 never relaunched. 4 of those (09-17, 09-18, 09-22, 09-23) have the identical AppModel 215/208 0x80070020 signature in AppModel-Runtime logs captured during the investigation; the older ones are inferred from log gaps. Every failure where the launcher is known (6 of 7; 09-11 is unclear) followed a dev stack started from a Code session in the same boot. The failure was also seen to persist:

• 09-17: six launches about 1.5 h after the update (07:41–07:45) failed the same way.
• 09-22: launches 8 minutes later failed the same way, even after a Repair re-registration (RepairAppRegistrationOption).

Which launch paths join the Claude container (tested live on 2.7032)

| Started from inside a Code session via… | Lands in \Container_Claude_…? |
|---|---|
| Bash tool: nohup cmd & | yes |
| Bash tool → powershell.exe 5.1 Start-Process | yes |
| Bash tool → nohup pwsh … | the nohup.exe wrapper yes, and it stays alive as long as pwsh does, so a long-running pwsh still pins the container. pwsh and its children: no. |
| Bash tool → Store-pwsh alias (%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe) Start-Process … | no |
| PowerShell tool (Store pwsh) → Start-Process … | no |
| WMI Win32_Process.Create | no |

CREATE_BREAKAWAY_FROM_JOB from a Bash-tool process succeeds, but the child is still in the Claude container. Packaged parents (Store pwsh, Windows Terminal) do get their children out, so spawning outside the container from the app side looks feasible.

App-side observations

• main.log logs [windows-app-job] skipped: flag off on every start.
• The update path stops tracked sessions and runs taskkill /T on PTY/MCP trees. That's a parent-PID walk, so it can't reach orphans whose parent has already exited. It then calls Electron's MSIX quitAndInstall (RegisterApplicationRestart + RegisterPackageByFamilyNameAsync(ForceApplicationShutdown)), which never enumerates or waits on the container job.
• Tracked background tasks appear to block the stealth update; untracked detached processes don't. (This is from reading the app bundle, not verified at runtime.)

Workarounds

• Recover without a reboot (reported upstream, untested here): end the processes still in the old \Container_Claude_<oldver>_…-<SID> job, or sign out and back in. Listing the job's members (NtOpenJobObject + JobObjectBasicProcessIdList) needs an elevated process, because the job DACL grants only SYSTEM and Administrators. Ending your own processes doesn't.
• Prevent: don't start long-lived processes from the Bash tool. Launch them from Windows Terminal, or via the Store-pwsh alias + Start-Process (table above).
• Settings → Repair doesn't help. Reset/reinstall wipes all local sessions and config.

Suggested fixes (any one)

1. Before RegisterPackageByFamilyNameAsync, enumerate the app's container job and terminate its members (or wait for it to empty).
2. Put spawned tool processes in a kill-on-close job, or finish the [windows-app-job] work.
3. Don't trigger the stealth update while untracked non-Electron members exist in the container.
4. Detect the failed relaunch (215/208 0x80070020) and tell the user which PIDs to end, instead of silently staying closed.

What is inferred rather than proven

• The causal link, on this machine: it rests on co-occurrence. Every 0x80070020 in the retained logs happened while an old user container was alive, and there's no counterexample, but no intervention was done here. Intervention evidence comes from #73107, #91763 and #93220.
• Job membership of the old instance's survivors wasn't read at the time. It's inferred from npm logs being redirected into the package's LocalCache, from the same launch paths being in the job on 2.7032 (table above), and from the timing.
• The last holder: by timing it's most likely Rancher Desktop, since the container was destroyed 81 ms after Rancher Desktop.exe exited. However, Rancher's new Windows-side files weren't redirected into the package LocalCache (the npm logs were), so its membership is unresolved. If Rancher was outside the job, the last holder is unidentified.
• The "file in use": it's probably the version-independent Helium User.dat/UserClasses.dat hive held by the old silo. Evidence: the hivelist, the matching timestamp, and opening User.dat fails with 0x80070020 while a silo holds it. There's no handle trace at the moment of failure.
• Which processes ForceApplicationShutdown terminates: unknown. It ended exactly those 5 processes and no others.

Stealth auto-update relaunch races the old process tree → 0x80070020 "converting the job"; 5 of 14 auto-updates left the app dead until reboot

Adding a timed reproduction from one machine that points at the update relaunch path specifically, not a startup crash. Data is from %LOCALAPPDATA%\Claude\logs\main*.log and the Microsoft-Windows-AppModel-Runtime/Admin + AppXDeploymentServer/Operational event logs.

Environment

• Windows 11 Pro 10.0.26200, x64
• Claude Desktop MSIX (Claude_pzs8sxrjxfjjc), versions 1.40609 → 2.7032 over the period below; Electron 44.2.0 at the last failure
• Claude Code CLI 2.1.275 / 2.1.280 inside the app; 10-20 Code sessions typically open
• CoworkVMService left at its default (Start=2, trigger-start)

Sequence on 2026-09-22 (local time)

12:14:16 [updater] Found an update, downloading
12:14:45 [updater] Update downloaded and ready to install { releaseName: 'Claude 2.2553.13' }
  (AppX log: package Add deferred because the app is running)
13:31:21 [stealth-update] Triggering stealth update after idle timeout
13:31:21 [CCD] Stopping 20 active session(s) on quit
13:31:28 [CCD] CLI exit before update: 20 of 20 exited within 6640ms
13:31:28 [CCD] Killing 16 PTY process tree(s) on quit
13:31:29 [pty-host] worker exited (0) with 16 live PTY(s); refork on demand
13:31:29 beforeQuitForUpdate handler fired, going down for update
13:31:30 Windows session ending (close-app) - quitting the app

AppX/AppModel event log, same second range:

13:31:29  AppXDeployment 603   RegisterByPackageFamilyName Claude_pzs8sxrjxfjjc, ForceApplicationShutdownOption
13:31:30  AppXDeployment 9648  TerminateSingleService ... CoworkVMService ... successful
13:31:31  AppModel-Runtime 67  Failed with 0x5 modifying AppModel Runtime status for package Claude_2.2553.1.0 (current 0x280000, desired 0x480000)
13:31:34  AppModel-Runtime 210 Created Desktop AppX container {A2DEC4F3-...} for Claude_2.2553.13.0
13:31:34  AppModel-Runtime 211 Added process 25120 to container a2dec4f3 (this is cowork-svc.exe; "Claude VM Service starting" logs the same second)
13:31:34  AppModel-Runtime 215 0x80070020: Cannot create the Desktop AppX container for package Claude_2.2553.13.0 because an error was encountered converting the job.
13:31:34  AppModel-Runtime 215 (same, second container)
13:31:34  AppModel-Runtime 208 0x80070020: Cannot create the process for package Claude_2.2553.13.0 because an error was encountered while configuring runtime. [LaunchProcess]
13:31:34  AppXDeployment 472   Moving package folder ...\Claude_2.2553.1.0_... to ...\WindowsApps\Deleted\...
13:31:35  AppXDeployment 613   Deployment Register operation ... Overall time: 5953 ms

After that the app never tried again; main.log has nothing between 13:31:30 and the next boot. A manual Repair at 15:47 (RegisterByPackageFullName with RepairAppRegistrationOption, done twice) re-registered the package and restarted cowork-svc successfully, but the app launch failed with the identical 215/208 pair both times. A reboot the next morning fixed it; the app then launched normally (Version changed since last launch: 2.2553.1 → 2.2553.13).

It is a race, and it is frequent. Relaunch attempted 4 s after the quit → failure. Successful stealth updates on this machine relaunched 15-20 s after the quit line:

| stealth update (quit) | relaunch | outcome |
|---|---|---|
| 08-30 14:57:29 | 14:59:52 | ok |
| 09-02 23:26:04 | 23:26:19 | ok |
| 09-03 09:51:56 | 09:52:13 | ok |
| 09-04 00:03:40 | 00:03:52 | ok |
| 09-04 08:25:28 | 08:27:30 | ok |
| 09-05 07:27:45 | next start 09-06 08:54 | dead until relaunched next day (10 PTY trees killed) |
| 09-11 13:32:24 | 13:32:37 | ok |
| 09-11 15:43:59 | 15:44:04 | ok |
| 09-13 15:55:09 | 17:17 after user reboot | dead (8 PTY trees) |
| 09-15 20:02:23 | 20:02:44 | ok |
| 09-17 02:16:09 | 09:58 after reboot | dead (7 PTY trees) |
| 09-17 21:53:12 | 09-18 08:02 after reboot | dead; 8 manual launch attempts 07:50-07:54 all logged 208/0x80070020 |
| 09-18 11:01:19 | 11:01:30 | ok |
| 09-22 13:31:30 | 09-23 08:27 after reboot | dead; detail above |

5 of 14 stealth updates since 2026-08-30 left the app unlaunchable until a reboot. The failures cluster on updates with more live sessions / PTY trees (7-16 killed) and a relaunch inside ~5 s of the quit. No WER/Application Error events for Claude.exe in the same period, so this is not a crash of the new process; the launch is refused before the process exists.

Why it hurts. The update is silent and idle-triggered, so the user comes back to no app and every Claude Code session gone, with no error shown. The Windows dialog on manual launch says "another program is using this file", which sends people hunting for file locks that do not exist. Repair does not help. Nothing in the app retries.

Suggestions

1. In the stealth-update path, wait for the old process tree / container job to fully drain before calling the relaunch (or relaunch from a helper that is not inside the old package's container job), instead of firing ~4 s after beforeQuitForUpdate.
2. If the relaunch fails with 0x80070020, retry with backoff for a few minutes rather than giving up silently.
3. If it still fails, leave a visible notification / toast on next logon rather than nothing.
4. Consider not killing live Claude Code sessions and their PTY trees for a background update; a "restart to update" prompt while the app is idle would avoid both the data loss and the race.

Workaround I am using: a user-level scheduled task that watches for the main Claude.exe to disappear, waits 60 s, ends stray Claude.exe children, and launches shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude with backoff. It cannot fix the 0x80070020 state itself; reboot still does that.

Happy to attach the full main.log window and an .evtx export of the two event logs if useful.

I got Claude Desktop to launch without restarting Windows or signing out by copying its application files outside the WindowsApps package directory and launching that copy.

In my case, stopping CoworkVMService, repairing the app, and re-registering the package did not resolve the launch error. Event Viewer continued reporting 0x80070020 with "an error was encountered converting the job."

What worked:

1. Find the installation folder:

``powershell
(Get-AppxPackage -Name Claude).InstallLocation
``

1. Copy the entire app subfolder, including its contents, to a separate folder for example:

%LOCALAPPDATA%\Claude-Launch-Workaround\<version>

1. Launch claude.exe from the copied folder.

The copied app opened and its window was responding. No reboot or Windows sign-out was required, and the original installation was left intact.

This is an unofficial temporary workaround. It does not repair the original package's launch problem. Cowork, automatic updates, and other integrations have not been verified in the copied version. Do not delete or reset your existing Claude data.

This kept happening to me too. Killing these python services fixed it and let Claude launch. Here's the diagnosing powershell:

(Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\hivelist').PSObject.Properties |
  Where-Object { $_.Name -like '*Silo*' -and $_.Value -match 'pzs8sxrjxfjjc' } |
  Select-Object Name, Value

This was the output:

ProcessId    : 26384
Name         : python.exe
CreationDate : 2026-09-20 3:34:00 PM
CommandLine  : C:\Python311\python.exe -m http.server 8731

ProcessId    : 23012
Name         : python.exe
CreationDate : 2026-09-20 9:25:56 PM
CommandLine  : C:\Python311\python.exe -m http.server 8731

Attaching a ps1 script that claude thinks will fix this problem for you if you run it:

Fix-ClaudeDesktopLaunch.txt

But it's just a one-time fix. Claude needs to avoid orphaning these jobs it seems.

Adding another affected machine with current diagnostics, as of 2026-09-24.

Environment and symptom

• Windows 11 Home 25H2, build 26200.9457, x64.
• Claude Desktop MSIX: Claude_2.9939.2.0_x64__pzs8sxrjxfjjc; Get-AppxPackage reports Status: Ok.
• The same launch failure was also observed on this machine on 2026-09-22 with 2.7032.0.0.
• Launching the registered app produces “Another program is currently using this file.”
• Microsoft-Windows-AppModel-Runtime/Admin records 215 (0x80070020, cannot create the Desktop AppX container, “an error was encountered converting the job”) and 208 (0x80070020, failure while configuring runtime, [LaunchProcess]).

Current observations, 2026-09-24

• No Claude.exe was running during the diagnostic snapshot.
• An elevated scan using GetPackageFullName and GetPackageFullNameFromToken found only cowork-svc.exe exposing Claude package identity among the readable processes. One process could not be queried.
• Claude's User.dat and UserClasses.dat under %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium remained mounted in HKLM\SYSTEM\CurrentControlSet\Control\hivelist, under the \REGISTRY\WC\Silo... namespace.
• Exclusive read attempts (FileShare.None) on both files failed with sharing violations.
• Windows Restart Manager (RmRegisterResources / RmGetList, read-only; no shutdown requested) identified the same holders for both files:

PID   Application   ApplicationType   Restartable
4     System        1000 (critical)   False
376   Registry      1000 (critical)   False

• An elevated Sysinternals Handle search for that package's Helium path returned no matching handles.

These findings identify the reported file holders, not the upstream cause. Mounted hives alone do not prove an orphaned container, and the package-identity scan does not rule out every possible surviving descendant or reference.

Recovery attempts during the earlier 2026-09-22 occurrence

• Stopping CoworkVMService did not release the hive locks.
• Re-registering the official package, including with -ForceApplicationShutdown, succeeded but did not restore launch.
• IPackageDebugSettings::TerminateAllProcesses returned S_OK for the then-current package and the previously observed package versions; both hive files remained locked afterward.
• Launching an unpackaged copy was not a usable full-featured recovery: it requested sign-in, but the email verification did not complete sign-in in that copy. It was abandoned and normal protocol routing was restored.

Please provide a supported per-package recovery procedure that preserves the current Windows session and full desktop/Cowork functionality, or guidance on a targeted trace that would distinguish an orphaned container from a remaining process/reference. Windows sign-out or reboot disrupts unrelated running work, so a session-preserving recovery is important.

Still happening on 2.16120.0.0: now on two machines, survives uninstall/reinstall, and the reinstall wipes Code session history

Environment

• Claude Desktop (MSIX) 2.16120.0.0
• Windows 11 25H2, build 26200.9550
• Reproduced on two separate machines

Symptom
On launch, Windows shows: "Another program is currently using this file." with the path C:\Program Files\WindowsApps\Claude_2.16120.0.0_.... The app does not start. This is a recurrence; it has happened before after an update.

What I tried (none fixed it without ending the session)

1. Stop-Service CoworkVMService and force-killing claude, cowork-svc, node
2. Settings > Apps > Claude > Repair, then Reset (Reset-AppxPackage)
3. Re-registering the package via Add-AppxPackage -Register ...AppxManifest.xml -ForceApplicationShutdown
4. Full uninstall and reinstall from claude.ai/download: the reinstalled app fails the same way

The only known fix is logging off or rebooting. That isn't acceptable here: the machine is running a 24h+ job in my user session that would be killed.

Second problem: reinstalling loses Code session history
After uninstalling/reinstalling, the desktop app's Code tab shows no previous sessions. The transcripts are intact in %USERPROFILE%\.claude\projects\ and claude --resume in the CLI lists them all. The desktop app keeps its session index in the package data, which is deleted on uninstall, and it does not rebuild the list from existing transcripts. Since this bug pushes users toward reinstalling, the result is effectively lost history in the app.

Requests

1. Fix the leaked container / update path so the app can relaunch without ending the Windows session.
2. Have the desktop app rebuild or import its Code session list from ~/.claude/projects (or store the index outside the MSIX package data) so an uninstall doesn't orphan history.
3. Until then, document the no-reboot limitation and warn that uninstalling drops the desktop session list.