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

WA (get-appxPackage) proposed doesn't work.

You're right — a reboot isn't a workaround, it's an admission that the app puts itself into a state nothing short of destroying the logon session can recover. That belongs in the report as a severity point, not a fix. Here's the follow-up:

Update — original report was wrong about the workaround, and the root cause is narrower than I described

Correction: re-registering the package does NOT fix this

Workaround #1 in my report (Add-AppxPackage -Register) is wrong. Please disregard it.
It completes successfully and the app still fails to launch ~200ms later:

21:26:12 Deployment Register operation on Package Claude_1.37937.1.0_x64__pzs8sxrjxfjjc
from: (AppxManifest.xml) finistime: 703 ms
21:26:12 Successfully updated the status for package Claude_1.37937.1.0_x64__pzs8sxrjxfjjc
21:26:12 0x80070020: Cannot create the process for package Claude_... [LaunchProcess]

The package was never corrupt. `Get-AppxPackore and after.

Sharper root cause: the FIRST container succeeds, subsequent ones fail

Full event sequence from a single launch attempt (Microsoft-Windows-AppModel-Runtime/Admin):

21:26:12 Id 210 Created Desktop AppX container {33CCC860-...} for package Claude_1.37937.1.0_x64__pzs8sxrjxfjjc
21:26:12 Id 211 Added process 16724 to Desktop AppX container 33ccc860-... for package Claude_...
21:26:12 Id 219 PSMFlags for Desktop AppX process ...
21:26:12 Id 217 Destroyed Desktop AppX container {33CCC864-...} for package Claude_...
21:26:12 Id 215 0x80070020: Cannot create the Desktop AppX container ... error encountered converting the job.
21:26:12 Id 217 Destroyed Desktop AppX container {33CCC865-...} for package Claude_...
21:26:12 Id 215 0x80070020: Cannot crer ... error encountered converting the job.
21:26:12 Id 208 0x80070020: Cannot create the process for package Claude_... [LaunchProcess]

The Electron main process gets into a container fine. The child processes
(renderer / GPU / utility) then fail to be pith
0x80070020 ... converting the job, and the app dies before reaching Electron main.

Confirming it never reaches main: %LOCALAPPDATA%\Claude\logs\main.log has a last-write
time of 17:23 and has not grown by a single byte across 9 subsequent failed launch
attempts (17:23:31, 18:05:23, 18:05:24, 18:05:48, 18:05:49, 21:15:49, 21:15:50,
21:26:12, 21:26:12). There is no app-side log of any of these failures — the only record
anywhere on the system is the Windows event log.

Ruled out by evidence

• Package corruption — fresh successful on unchanged (1.37937.1.0).
• Phantom running instance — no process under *WindowsApps*Claude* or *Packages\Claude* exists.
• System-wide MSIX breakage — other packthe same minute:

Microsoft.ScreenSketch at 21:26:14, Microsoft.DesktopAppInstaller at 21:26:13.
Both are single-process; Claude is the multi-process one. This is specific to spawning
children into the package container.

• Third-party job-object software (Process Lasso / Sandboxie / EDR) — none installed;

Windows Defender only. Docker Desktop and WSL are running but are not in this code path.

What remains is stale kernel-side container/silo state for this package, created when the
17:23 stealth-relaunch raced its own shutdown. Package-level operations can't touch it —
it's bound to the logon session.

"Reboot" is not a workaround — it's the severity

The only things that clear this are signinoting, because
Desktop AppX containers are per-logon-session. That is not a workaround; that is the app
having no recovery path short of destroying the user's entire session. On this machine that
means killing Docker containers, a Unity editor, and running CLI sessions — to recover a
chat client that broke itself while idle.

Restating the severity in those terms:

• The app takes an unprompted action (idle-triggered stealth update) that leaves itself

permanently unlaunchable.

• It logs nothing about the failure — `msion.
• The user-visible symptom is a Windows popup saying "Claude is already in use", which

is actively misleading: nothing is in use. 0x80070020 is ERROR_SHARING_VIOLATION and
the shell renders it as an in-use message. hunt for a
running instance that does not exist.

• Recovery requires reading Microsoft-Windows-AppModel-Runtime/Admin in Event Viewer to

discover that the answer is "log out." No ordinary user reaches that conclusion.

• The update was not even necessary: the log shows `Staged version 1.37937.1 is still

current (latest: 1.37937.1, lastTarget: 1.37937.1)` on a 20-minute loop for hours
beforehand. The version did not change. Itwhat it already had.

Requested fixes (revised)

1. Don't relaunch into a race. Confirm tfore tearing down

the old process; if LaunchProcess fails, abort the update and keep the window.

1. Don't self-update when the staged versi. The 17:23

teardown had no update to apply.

1. Retry 0x80070020 with backoff on container creation instead of exiting into a state

that survives every launch attempt afterw

1. Log the relaunch failure somewhere the app owns. main.log ending silently mid-line is the reason this took an event-log dig
2. Fix the user-facing message. If activation fails with 0x80070020, say what's

actually wrong and what clears it — not the OS's "already in use" text.

Fresh reproduction on 2.110.1 — still live three weeks and a major version later

Same failure as this report, on a different machine, on a much newer build. Posting because this
issue is currently labelled invalid and because my data refines two of the claims here rather
than just repeating them.

Environment

| | |
|---|---|
| OS | Windows 11 Pro 10.0.26200 |
| Package | Claude_2.110.1.0_x64__pzs8sxrjxfjjc → Claude_2.2553.0.0_x64__pzs8sxrjxfjjc |
| SignatureKind | Developer — sideloaded MSIX from the .exe download, not Store-delivered |
| Bundled Claude Code | 2.1.271 → 2.1.274 |
| Node | 24.20.0 |

Note the package origin: this reproduces on a sideloaded MSIX, so it is not specific to Store
delivery. (Original report lists MSIX/Store.)

Timeline — %LOCALAPPDATA%\Claude\Logs\main.log

2026-09-18 02:08:50 [info] [stealth-update] Triggering stealth update after idle timeout
2026-09-18 02:08:50 [info] [popout-restore] Saving 0 session + 0 pane + 0 project popout(s) for next launch
2026-09-18 02:08:50 [info] [stealth-relaunch] Saved z-order anchor: 0x271906 (above our 0x500ffe)
2026-09-18 02:08:50 [info] [stealth-relaunch] Saved navigation history (16 entries, active=15)
2026-09-18 02:08:51 [info] [CCD] Killing 1 PTY process tree(s) on quit
2026-09-18 02:08:52 [info] beforeQuitForUpdate handler fired, going down for update
2026-09-18 02:08:52 [info] Windows session ending (close-app) - quitting the app
        <<< 24 minutes: app gone, launches fail, machine rebooted >>>
2026-09-18 02:32:53 [info] Starting app { appVersion: '2.110.1', isPackaged: true, platform: 'win32', arch: 'x64', nodeVersion: '24.20.0' }

Microsoft-Windows-AppModel-Runtime/Admin — identical signature to this issue, on manual launch
attempts:

02:23:56  Id 215  ERROR  0x80070020: Cannot create the Desktop AppX container for package
                         Claude_2.110.1.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.
02:23:56  Id 208  ERROR  0x80070020: Cannot create the process for package
                         Claude_2.110.1.0_x64__pzs8sxrjxfjjc because an error was encountered while configuring runtime. [LaunchProcess]
02:23:59  Id 215  ERROR  0x80070020  (second launch attempt, same triple)
02:23:59  Id 208  ERROR  0x80070020
...
02:32:53  Id 201  INFO   Created process 27948 for application Claude_pzs8sxrjxfjjc!Claude   ← first success, post-reboot

Same Id 215 / Id 208, same 0x80070020, same "an error was encountered converting the job" —
i.e. the orphaned job object / silo described in #53247.

Refinement 1 — it is not necessarily permanent, and a reboot clears it

This report says *"The failure is permanent, not transient — every subsequent launch attempt
fails identically."* On this machine it was not permanent: two launch attempts failed, a reboot
cleared it, and the app started normally. Worth capturing because it changes the recovery advice and
suggests a process-lifetime-scoped resource rather than persistent on-disk state.

Refinement 2 — the same mechanism succeeded on the same machine 67 minutes later

2026-09-18 03:40:08 [info] beforeQuitForUpdate handler fired, going down for update
2026-09-18 03:40:08 [info] Windows session ending (close-app) - quitting the app
2026-09-18 03:40:10 [info] Starting app { appVersion: '2.2553.0', ... }

Two seconds, clean. Same box, same code path, ~720× the downtime of the failed one. This supports
the race-condition reading in this issue over a plain file lock.

New signal — recurring EBUSY on a file inside the app's own package directory

Present on this machine across multiple versions, including well before the failed update:

2026-09-18 00:39:59 [error] [Chrome Extension MCP] Failed to copy native host binary:
  Error: EBUSY: resource busy or locked, copyfile
  'C:\Program Files\WindowsApps\Claude_2.110.0.0_x64__pzs8sxrjxfjjc\...'
2026-09-18 02:32:54 [error] (same, Claude_2.110.1.0_...)
2026-09-18 02:33:20 [error] (same, Claude_2.110.1.0_...)

EBUSY and 0x80070020 are both sharing violations. Something in the app holds open handles into
its own WindowsApps package directory during normal operation. Offered as a lead: if a handle into
the outgoing package survives beforeQuitForUpdate, that is a plausible mechanism for the job/silo
conversion to fail on the way back up. Not a diagnosis — I cannot see which handle.

Impact not yet captured here — active sessions are killed, not just window state

2026-09-18 02:08:51 [info] [CCD] Killing 1 PTY process tree(s) on quit

The updater terminates live Claude Code PTY process trees. This issue notes the saved z-order and
navigation history never being restored; the sharper cost is that an in-progress Claude Code session
is killed by the updater, so a failed relaunch can mean lost work, not just a lost window.

In this instance it landed mid-working-hours and cost ~30 minutes to diagnose and reboot.

Request: make the auto-update opt-out reachable by users

A setting already exists — the app defines disableAutoUpdates ("Block auto-updates … Stop Claude
Desktop from fetching updates entirely"), alongside autoUpdaterEnforcementHours (1–72). Both are
scoped to admin/MDM managed settings, i.e. they require a machine-wide policy file or registry key.

For an individual user on their own machine, the workaround for an updater that can render the app
unlaunchable is currently "author a Windows policy." Please surface disableAutoUpdates in the
app's own Settings. Until the relaunch path is reliable, the people it breaks should be able to
turn it off without administering a fleet.

Two smaller asks in the same area:

1. Do not relaunch while a session has live child processes. The log above shows a PTY tree

being killed to make way for an update.

1. Add a relaunch watchdog. If the new process has not reported startup within N seconds,

surface something. A feature deliberately engineered to be invisible (stealth-update, saved
z-order, saved nav history) has no way to tell the user it failed — from the user's side the
application simply ceases to exist, with no dialog, no tray icon and no log line.

Related: #53247 (orphaned Silo / Job Object, same 0x80070020 and same Id 215/208 pair).

Happy to supply the full main.log or the raw event-log export if useful.