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