[BUG] MSIX in-place update leaks a container silo, making Claude Desktop unlaunchable until reboot (0x80070020)

Independent confirmation on a second machine, same package version — and with a different AV vendor, which I think closes the ESET question you flagged as incidental.

Environment

• Windows 11 Pro 25H2, build 26200.9168, x64
• Claude Desktop Claude_1.32885.1.0_x64__pzs8sxrjxfjjc (MSIX), Get-AppxPackage Status = Ok, SignatureKind: Developer
• Windows Defender only — no third-party AV. You had ESET active with Defender real-time off; I have the exact opposite and reproduce identically. AV is not a factor.

Leaked silo present here too

HKLM\SYSTEM\CurrentControlSet\Control\hivelist, with zero Claude processes running:

\REGISTRY\WC\Silo4c9b2412-a8cd-3b15-dd75-5a562ada0941software
  -> \Device\HarddiskVolume2\ProgramData\Microsoft\Windows\WindowsApps\Claude_1.32885.1.0_x64__pzs8sxrjxfjjc\Cache\3b2b1b5fc136b388.dat
\REGISTRY\WC\Silo934b7f82-d44a-d4e2-0880-e80cd550bafecom
  -> \Device\HarddiskVolume2\ProgramData\Microsoft\Windows\WindowsApps\Claude_1.32885.1.0_x64__pzs8sxrjxfjjc\Cache\3b2b1b5fc136b388_COM15.dat
\REGISTRY\WC\Silo4c9b2412-a8cd-3b15-dd75-5a562ada0941com
  -> \Device\HarddiskVolume2\ProgramData\Microsoft\Windows\WindowsApps\Claude_1.32885.1.0_x64__pzs8sxrjxfjjc\Cache\3b2b1b5fc136b388.dat

Minor variation from your capture: my entries point at ProgramData\Microsoft\Windows\WindowsApps\Claude_<version>\Cache\ rather than ProgramData\Packages\Claude_pzs8sxrjxfjjc\...\Helium\Cache\, and there are no user_sid / user_classes rows — only software and com. Same phenomenon, slightly different hive set.

Same events on every launch attempt (Microsoft-Windows-AppModel-Runtime/Admin), locale pt-BR:

19/08/2026 18:46:10  Id 215  Erro  0x80070020: nao e possivel criar o conteiner do Desktop AppX
                                   para o pacote Claude_1.32885.1.0_x64__pzs8sxrjxfjjc devido a
                                   um erro ao converter o trabalho.
19/08/2026 18:46:11  Id 215  Erro  (idem)
19/08/2026 18:46:11  Id 208  Erro  0x80070020: ... erro ao configurar o tempo de execucao. [LaunchProcess]

Positive evidence that the process tree outlives quit-for-update

#77421 notes that no further quit lines are written after beforeQuitForUpdate. My main.log gives the complementary positive signal — the tree is demonstrably still alive 16 seconds later, because the periodic process-memory sampler keeps reporting it:

2026-08-19 18:45:32 [info] beforeQuitForUpdate handler fired, going down for update
2026-08-19 18:45:32 [info] Windows session ending (close-app) - quitting the app
2026-08-19 18:45:48 [info] [process-memory] trigger=interval tree_rss_sum=2789MB
       tree_footprint_sum=1177MB electron(15)=2789MB children(0)=0MB
       top=[electron_renderer:25332:873MB electron_main:11740:432MB electron_gpu:35636:173MB
            electron_utility:21924:125MB electron_utility:14872:124MB]

15 Electron processes and 2.79 GB resident, 16 s after the app announced it was going down for the update. cowork-svc.exe for the new package started at 18:46:09, the Register completed 18:46:10, and the container errors landed 18:46:10–11.

Deferrals accumulate for days

Because the app is essentially never fully closed, AppXDeploymentServer/Operational event 658 fired on three consecutive updates, all blocked by the same old package:

17/08 20:39:20  1.32352.0 deferred - Claude_1.30096.5.0 still running
18/08 00:49:39  1.32352.1 deferred - Claude_1.30096.5.0 still running
18/08 20:40:22  1.32885.1 deferred - Claude_1.30096.5.0 still running
19/08 09:50:12  Id 404 Erro 0x80073D02 (ERROR_PACKAGES_IN_USE)
                "Failed to reach state ResolvedDeferredRegistration"

Ruled out independently (matches your table)

| Hypothesis | Test | Result |
|---|---|---|
| CoworkVMService holds the container | Stopped the service, verified zero processes from WindowsApps\Claude and zero orphans, then launched | Fails identically — 3 fresh 215/215/208 at 18:49:50 and 18:49:53 |
| Main binary locked | [IO.File]::Open(Claude.exe,'Open','Read','None') | Opens fine |
| Broken registration | Get-AppxPackage | Status = Ok; Register operations complete in ~1.5–2 s |
| Antivirus | Defender only, no third party | Reproduces anyway |

One extra data point on recovery: force-killing the orphaned trees (which needs admin — a medium-integrity token gets Access Denied even with taskkill /F /T) does not help and appears to be what strands the silo. Only a reboot clears it here as well.

Third occurrence on this machine: 2026-08-04, 08-13 and 08-19 — effectively every auto-update.

Third machine, and one detail that I think matters for triage: this reproduces on a newer package version. Your report and the confirmation above are both pinned at 1.32885.1.0, so nothing there rules out a version-specific defect. It survives the bump.

Environment

• Windows 11 Pro 26200 (25H2), x64, AzureAD-joined
• Claude Desktop MSIX Claude_pzs8sxrjxfjjc, updated 1.32885.1.0 -> 1.34493.0.0, Get-AppxPackage Status Ok
• Claude in Chrome extension in use; Cowork VM service present
• Claude Code CLI unaffected, as you found

Recurrence on 1.34493.0.0 (2026-08-20)

The Store updated the package and the app quit itself to install it. Every launch afterwards fails identically. Microsoft-Windows-AppModel-Runtime/Admin, at the launch attempt:

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

In the same second, the outgoing package flips runtime status:

68  AppModel Runtime status for package Claude_1.32885.1.0_x64__pzs8sxrjxfjjc
    successfully updated to 0x0 (previous status = 0x200000).

%APPDATA%\Claude\logs\main.log receives no writes after the attempt and no package process is ever created, which matches your "app never opens, nothing reaches it" description. That log going silent is the fastest way to distinguish this from the app starting and failing later.

The leaked silos, including the new package's own

HKLM\SYSTEM\CurrentControlSet\Control\hivelist with zero package processes running:

\REGISTRY\WC\Silo 6c080106-cd8b-e337-c02d-a5d6ba7b4200 software     -> ProgramData\Packages\Claude_pzs8sxrjxfjjc\<sid>\...\Helium\Cache\3b2b1b5fc136b388.dat
\REGISTRY\WC\Silo 6c080106-cd8b-e337-c02d-a5d6ba7b4200 user_sid     -> Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat
\REGISTRY\WC\Silo 6c080106-cd8b-e337-c02d-a5d6ba7b4200 user_classes -> Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\UserClasses.dat
\REGISTRY\WC\Silo 6c080106-cd8b-e337-c02d-a5d6ba7b4200 com          -> ...\Helium\Cache\3b2b1b5fc136b388.dat
\REGISTRY\WC\Silo c5e7b70d-34ad-77a5-ef90-9b8df1cc3b05 com          -> ...\Helium\Cache\3b2b1b5fc136b388_COM15.dat
\REGISTRY\WC\Silo 445dbdc3-205a-a7c5-edd8-45b94b6ec1cb software     -> ProgramData\Microsoft\Windows\WindowsApps\Claude_1.34493.0.0_x64__pzs8sxrjxfjjc\Cache\149fe60e9f080bfc.dat
\REGISTRY\WC\Silo 445dbdc3-205a-a7c5-edd8-45b94b6ec1cb com          -> ...\Claude_1.34493.0.0_x64__pzs8sxrjxfjjc\Cache\149fe60e9f080bfc.dat
\REGISTRY\WC\Silo d7920e68-2215-305b-816d-e30911d5fe12 com          -> ...\Claude_1.34493.0.0_x64__pzs8sxrjxfjjc\Cache\149fe60e9f080bfc_COM15.dat

Worth noting against your silo-teardown theory: the first group is the package-profile silo you documented, but 445dbdc3 and d7920e68 map to the new version's own cache directory. So the incoming package leaks a silo too, not just the outgoing one. If the fix is scoped to tearing down the old silo on beforeQuitForUpdate, that may leave this half in place.

Consistent with your ruled-out table

Independently reached the same dead ends on 2026-08-18, in case it saves anyone re-testing them: launching from Start menu, packaged shell, and non-packaged shell all fail identically; no leftover Electron processes; Restart Manager reports no handles on claude.exe or app.asar; the first container creation fails with CoworkVMService verified STOPPED, so it is not the live blocker; Windows re-registers the package on every attempt and it changes nothing. Reboot is the only recovery here as well.

Frequency

Twice in three days on this machine, across two different package versions, and on effectively every update before that. Because the Store schedules the update and the app quits itself to take it, the timing is not the user's to choose, so the reboot lands whenever it lands.

Separate minor thing, not a cause

After an update the app cannot refresh its Chrome native messaging host while Chrome holds the old one:

[error] [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked, copyfile
  '...\Claude_<version>\app\resources\chrome-native-host.exe'
  -> '...\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe'

The app logs "Native host sync complete" straight afterwards and continues, so the extension silently runs a stale host until Chrome exits. Agrees with your finding that the native host is never a container member, so it is unrelated to the wedge, but versioning the host filename would fix it independently.

Fourth machine, and the reason I am adding it rather than opening a new issue: this reproduces on
package 1.34493.1.0. The report is pinned at 1.32885.1.0 and the confirmation above at
1.34493.0.0, so the servicing revision does not fix it either.

Environment

• Windows 11 Pro 26200 (25H2), x64
• Claude Desktop MSIX, in-place update 1.32885.1.0 -> 1.34493.1.0 on 2026-08-21 at 09:49
• Get-AppxPackage Status Ok, SignatureKind: Developer
• Windows Defender only, real-time protection on, tamper protection on, zero detections in the

preceding 24 hours

• Single interactive console session (quser), Claude Code CLI unaffected

Leaked silos present, two groups

HKLM\SYSTEM\CurrentControlSet\Control\hivelist, with zero Claude processes running:

\REGISTRY\WC\Silo4dd010b8-22ed-320f-1a92-2bde372c2c08software
  -> ProgramData\Packages\Claude_pzs8sxrjxfjjc\<sid>\SystemAppData\Helium\Cache\3b2b1b5fc136b388.dat
\REGISTRY\WC\Silo4dd010b8-22ed-320f-1a92-2bde372c2c08user_sid
  -> AppData\Local\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat
\REGISTRY\WC\Silo4dd010b8-22ed-320f-1a92-2bde372c2c08user_classes
  -> AppData\Local\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\UserClasses.dat
\REGISTRY\WC\Silo04aeae3a-2276-f7aa-b6ba-c203d963af97com
  -> ProgramData\Packages\Claude_pzs8sxrjxfjjc\<sid>\SystemAppData\Helium\Cache\3b2b1b5fc136b388_COM15.dat

\REGISTRY\WC\Silod4b609ec-03de-812f-c0a1-238ad6af714asoftware
  -> ProgramData\Microsoft\Windows\WindowsApps\Claude_1.34493.1.0_x64__pzs8sxrjxfjjc\Cache\625425aef8ca07cd.dat
\REGISTRY\WC\Silo21b744fe-f77b-c0da-e8f0-bce22b1ebc04com
  -> ...\Claude_1.34493.1.0_x64__pzs8sxrjxfjjc\Cache\625425aef8ca07cd_COM15.dat

Both hive-set variants reported in this thread are present at once here: the package-family set
under ProgramData\Packages\Claude_pzs8sxrjxfjjc including user_sid and user_classes, and the
version-scoped set under WindowsApps\Claude_1.34493.1.0.

Events on every launch attempt are identical to the report (Microsoft-Windows-AppModel-Runtime/Admin,
Id 215 and Id 208, 0x80070020).

"No member processes" verified three independent ways

This is the part I would like to add to the thread, because it rules out the explanations that
usually get suggested first:

1. Restart Manager (RmStartSession / RmRegisterResources / RmGetList) on Claude.exe

reports 0 blocking processes. This is the same mechanism installers use, so "some process
holds the file" is not merely unproven, it is refuted.

1. GetPackageFullName called against every running process finds 56 packaged processes

system-wide and none belonging to Claude_pzs8sxrjxfjjc. No helper process survives the
update.

1. File.Open(..., FileShare.None) on Claude.exe succeeds, so the file is genuinely free.

The packaged service is not the blocker here

Worth separating from #84435 and #88101, which are about the update being blocked. For the
launch failure, CoworkVMService is not the cause on this machine:

• Sorted by RecordId rather than TimeCreated, the container failure consistently precedes

the service start within the same second. Time-sorting these events reverses their order and
makes the service look guilty; that cost me a full diagnostic branch.

• With the service stopped, the launch fails unchanged.
• Its StartupType cannot be changed (Set-Service silently leaves it at Automatic), matching

the ACL finding in #84435.

Things that do NOT clear the leaked silo

Each tried individually with a launch attempt in between, all ineffective:

• Add-AppxPackage -Register "<pkg>\AppxManifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown (succeeds, no effect)
• stopping CoworkVMService
• restarting AppReadiness, ClipSVC, StateRepository, AppXSvc
• killing all RuntimeBroker processes
• killing sihost.exe (Shell Infrastructure Host, restarts cleanly)
• restarting explorer.exe

Only a reboot is confirmed to clear it on this machine.

I want to explicitly flag what I have not tested, rather than let it be assumed: whether
signing out and back in is sufficient. It would be the cheaper remedy, but the hive set above
argues against taking it for granted. Only user_sid and user_classes come from
AppData\Local\Packages; software and com are mounted from ProgramData\Packages\... and
ProgramData\Microsoft\Windows\WindowsApps\..., which are machine-wide, so a logoff may well leave
those two mounted. If anyone has actually tested the logoff path, that result would be worth having
in this thread.

Reproduction without the shell

Start-Process "C:\Program Files\WindowsApps\Claude_<ver>_x64__pzs8sxrjxfjjc\app\Claude.exe"
# -> "The process cannot access the file because it is being used by another process"

Control: the same direct launch works for Notepad.exe and ms-teams.exe from their own package
folders, so the path itself is not blocked.

Impact

Every update costs the user their entire working session. On this machine it has occurred on every
update so far, without exception.

Follow-up to my comment above, on the one thing I explicitly marked as untested: signing out and
back in is sufficient. A full reboot is not required.

Measured on the same machine (Windows 11 Pro 26200, package 1.34493.1.0) while the launch failure
was present: signed out of the interactive session, signed back in, and Claude Desktop launched
normally on the first attempt.

Proof that no reboot was involved:

(Get-CimInstance Win32_OperatingSystem).LastBootUpTime
# 08/18/2026 08:20:55

Get-CimInstance Win32_LogonSession -Filter "LogonType=2" |
  Sort-Object StartTime -Descending | Select-Object -First 1 StartTime
# 08/21/2026 12:19:29

Boot time three days old, new interactive logon minutes before the successful launch.

This also settles the objection I raised myself. The software and com hives are mounted from
ProgramData\Packages\... and ProgramData\Microsoft\Windows\WindowsApps\..., so they look
machine-wide, but they belong to the session silo and are torn down with it. My reasoning that they
might survive a logoff was wrong.

Practical upshot for anyone landing here after an update: sign out, sign back in, done. Everything
that does not clear the silo is still listed in my previous comment, and I have found nothing that
clears it without tearing down the session.