[BUG] Claude Desktop (Windows): every MSIX auto-update leaks a container silo, app won't launch until reboot

Summary

On Windows, every Claude Desktop auto-update leaves the app unable to launch. The updater rewrites the MSIX package in place while the previous instance's Windows container ("Helium" DesktopAppX) silo is still mounted. The old silo is leaked and keeps the package's virtualized registry hives locked, so the freshly updated build cannot create its container and dies before showing a window. The only user-facing fix is a full Windows reboot.

Environment

• Desktop app version: updated 1.11847.5 → 1.12603.1.0 (package Claude_1.12603.1.0_x64__pzs8sxrjxfjjc, sideloaded MSIX, publisher "Anthropic, PBC")
• OS: Windows 11 Pro 26200.8655 (x64)
• Reproduces: on every auto-update, consistently

Steps to reproduce

1. Have Claude Desktop running.
2. Let it auto-update (or use its "Restart to update").
3. After the update, launch Claude Desktop.

Expected

App launches normally after the update.

Actual

App fails to launch. Depending on how far the broken launch gets, either:

1. A dialog: "This file is currently used by another program" pointing at C:\Program Files\WindowsApps\Claude_<ver>_..., or
2. The window flashes for a moment, a system sound plays, then nothing — no window appears.

Diagnostic signatures

Event Viewer → Applications and Services Logs → Microsoft → Windows → AppModel-Runtime/Admin:

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

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

(0x80070020 = ERROR_SHARING_VIOLATION)

HKLM\SYSTEM\CurrentControlSet\Control\hivelist shows orphaned container-silo hives that survive the update with no live member process:

\REGISTRY\WC\Silo<guid>user_sid      -> ...\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat
\REGISTRY\WC\Silo<guid>user_classes  -> ...\Helium\UserClasses.dat
\REGISTRY\WC\Silo<guid>software / com -> matching package hives

• User.dat / UserClasses.dat are locked (CreateFile → ERROR_SHARING_VIOLATION).
• Zero crash reports in ...\LocalCache\Roaming\Claude\Crashpad\reports — the process dies at the OS container layer, before any Electron/app code runs (so this is not a JS-side crash).

Root cause (hypothesis)

The in-place MSIX update is applied while the previous version's DesktopAppX container silo is still alive. That silo is leaked (it persists with no member process) and holds the package's virtualized registry hives open. Each subsequent launch attempt then fails at container job creation with a sharing violation, and each failed attempt orphans yet another silo.

What does / doesn't fix it

• Re-registering the package (Add-AppxPackage -DisableDevelopmentMode -Register ...\AppxManifest.xml) repairs the registration but does not release the leaked silo hives → still won't launch.
• A full Windows reboot clears the kernel silos → launches cleanly.
• Force-unloading just the leaked silo hives from a SYSTEM context (NtUnloadKey2 + REG_FORCE_UNLOAD; elevated admin gets 0xC0000022 ACCESS_DENIED, SYSTEM succeeds) releases the locks and the app launches without a reboot — confirming the leaked silo + locked hives are the cause.

Impact

Every update bricks the app until the user reboots. Especially painful for users with long uptime / many open apps. The reboot requirement is non-obvious — the failure surfaces only in the event log.

Suggested fix

During the update, fully tear down the running instance's container (terminate all package processes and ensure the DesktopAppX silo is unmounted) before re-registering the new package, so no silo is leaked and the package registry hives are released.