[Bug] MSIX stealth update relaunch fails with 0x80070020, app becomes unlaunchable

Bug Description
Title: [Windows/MSIX] Stealth auto-update relaunch fails permanently with 0x80070020 — app becomes unlaunchable, shell reports "Claude is already in use"

Summary

The desktop app's idle-triggered "stealth update" quits the app to relaunch itself, but the
relaunch fails at the MSIX layer with 0x80070020 (ERROR_SHARING_VIOLATION). The failure is
permanent, not transient — every subsequent launch attempt fails identically. Windows
surfaces this to the user as "Claude is already in use", which is misleading: no Claude
process is running at all.

Environment

• Windows 11 Pro, build 26200.9168
• Claude desktop: package Claude_1.37937.1.0_x64__pzs8sxrjxfjjc (MSIX/Store), version 1.37937.1.0
• Claude Code CLI: 2.1.246 (installed separately at ~/.local/bin/claude.exe, unaffected)
• Machine uptime at time of failure: ~7 days
• Get-AppxPackage Claude* reports Status: Ok, version 1.37937.1.0 — i.e. the package is

intact and the staged update did apply. Only process launch is broken.

Timeline / evidence

%LOCALAPPDATA%\Claude\logs\main.log — the app decides to update and quits:

2026-08-26 17:23:29 [info] [stealth-update] Triggering stealth update after idle timeout
2026-08-26 17:23:29 [info] [stealth-relaunch] Saved z-order anchor: 0xb240fa0 (above our 0x508d0)
2026-08-26 17:23:29 [info] [stealth-relaunch] Saved navigation history (50 entries, active=49)
2026-08-26 17:23:29 [info] [popout-restore] Saving 0 session popout(s) for next launch
2026-08-26 17:23:29 [info] beforeQuitForUpdate handler fired, going down for update
2026-08-26 17:23:29 [info] Windows session ending (close-app) - quitting the app

main.log ends here. Nothing is ever appended again — the relaunched process never reaches
Electron main.

Event log Microsoft-Windows-AppModel-Runtime/Admin, two seconds later:

17:23:31 Id 215 0x80070020: Cannot create the Desktop AppX container for package
Claude_1.37937.1.0_x64__pzs8sxrjxfjjc because an error was encountered
converting the job.
17:23:31 Id 215 (same, repeated)
17:23:31 Id 208 0x80070020: Cannot create the process for package
Claude_1.37937.1.0_x64__pzs8sxrjxfjjc because an error was encountered
while configuring runtime. [LaunchProcess]

These 17:23:31 entries are the earliest Claude-related errors in the retained event log —
the app had been running normally all day until the stealth update. The identical triple then
repeats on every manual launch attempt afterward:

18:05:23, 18:05:48, 21:15:49, 21:15:50 — same Id 215 / 215 / 208, same 0x80070020

At 21:15:49 the container lifecycle partially succeeds before failing, suggesting a race
rather than a plain file lock:

Id 211 Added process 84768 to Desktop AppX container 33ccc0aa-... for package Claude_...
Id 219 PSMFlags for Desktop AppX process ...
Id 217 Destroyed Desktop AppX container {33CCC0AE-...} for package Claude_...
Id 215 0x80070020 ... converting the job
Id 208 0x80070020 ... [LaunchProcess]

Verification that nothing is actually in use

Get-Process | Where-Object { $_.Path -like 'WindowsAppsClaude' -or $_.Path -like 'Packages\Claude*' }
-> no results

No packaged Claude process, no leftover Electron renderer/gpu/utility children. The
"already in use" message is Windows misreporting ERROR_SHARING_VIOLATION from the failed
AppX container/job-silo creation, not a live instance.

Expected vs actual

• Expected: beforeQuitForUpdate → process exits → new version relaunches → window restores

(z-order anchor and 50-entry nav history were saved specifically for this).

• Actual: process exits, relaunch fails, app is unlaunchable indefinitely. The saved window

state is never restored. No error is shown to the user at quit time — the app just vanishes
and only fails visibly on the next manual launch, hours later.

Impact

Silent, self-inflicted, and permanent until the user reboots or re-registers the package.
Because the failure is invisible at quit time, the user's mental model is "the app crashed",
and the shell's "already in use" message actively points diagnosis in the wrong direction
(hunting for a phantom running instance). Diagnosing this required digging through the
Windows AppModel event log — not a reasonable ask.

Workarounds found

1. Re-register the package (no data loss, no reboot):

Get-AppxPackage Claude* | ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"
}

1. Reboot — clears the stale container/job state.

Suggested fixes

• Don't tear down the old process until the new one is confirmed launched; ve…

Note: Content was truncated.