Claude Desktop (Windows MSIX): app fails to launch after every in-app update until the machine is rebooted (0x80070020)

Claude Desktop (Windows MSIX) fails to launch after every in-app auto-update — 0x80070020 at AppX container creation — only a full reboot recovers

Environment

| | |
|---|---|
| Claude Desktop | MSIX package family Claude_pzs8sxrjxfjjc, versions observed: 2.110.1.0, 2.2553.1.0, 2.7032.0.0, 2.9939.2.0, 2.9939.4.0, 2.16120.0.0 |
| Delivery | SignatureKind: Developer (sideloaded MSIX from Claude Setup, not Store) |
| OS | Windows 11 Enterprise, build 26200 (10.0.26200), x64 |
| App data | %LOCALAPPDATA%\Claude-3p (3p / gateway deployment mode) |
| AV | Tencent PC Manager (active). A previously installed 360 security suite left filter drivers behind; these were fully removed on 2026-09-25. The bug reproduces both before and after that removal. |

Summary

After an in-app auto-update, Claude Desktop cannot be started again. Every launch attempt fails at AppX activation. The only recovery is a full OS reboot. This has now happened five times, spanning five different package versions.

Steps to reproduce

1. Install Claude Desktop (MSIX) and launch it. It works normally.
2. Leave it running. An in-app auto-update downloads (log: [updater] Update downloaded and ready to install { releaseName: '...' }).
3. The app exits for the update (beforeQuitForUpdate handler fired, going down for update → Windows session ending (close-app) - quitting the app).
4. The package update registers successfully.
5. Launch Claude Desktop (desktop shortcut, Start menu, or shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude).

Observed: the app never starts. No window, no process.

Observed behaviour (Event log)

Microsoft-Windows-AppModel-Runtime/Admin, every launch attempt:

Id 208 (Error): 0x80070020: Cannot create the process for package
  Claude_<version>_x64__pzs8sxrjxfjjc because an error was encountered
  while configuring runtime. [LaunchProcess]

Id 215 (Error): 0x80070020: Cannot create the Desktop AppX container for
  package Claude_<version>_x64__pzs8sxrjxfjjc because an error was
  encountered converting the job.

0x80070020 = ERROR_SHARING_VIOLATION. The failure is in Desktop AppX container / job-object conversion, not in the app's own startup code — the app's main process is never created.

The deployment itself succeeds. For the 2026-09-30 attempt:

01:49:50  Id 603  Started deployment Add operation ... Options NormalPriorityRequest
                  and DeferRegistrationWhenPackagesAreInUse
01:52:48  Id 638  Packages were not updated because affected apps are still running.
                  Running apps: {Claude_pzs8sxrjxfjjc!Claude}
01:52:48  Id 658  Marking package {Claude_2.16120.0.0} for deferred registration because
                  {Claude_2.9939.4.0} is still running
01:52:49  Id 400  Deployment Add operation ... finished successfully
09:14:35  Id 603  Started deployment RegisterByPackageFamilyName ... ForceApplicationShutdownOption
09:14:38  Id 400  Deployment Register operation ... finished successfully
09:14:43  Id 208  0x80070020 ... [LaunchProcess]      <-- first launch after update fails

Occurrence log

| # | Date/time (local, UTC+8) | Package | Failures | Recovery |
|---|---|---|---|---|
| 1 | 2026-09-18 06:20:22 – 06:22:57 | 2.110.1.0 | 7 | User rebooted 06:23:19; launches worked immediately after (18 successful launches that day) |
| 2 | 2026-09-19 11:47:57, 12:07:25, 12:07:32, 12:09:19, 12:09:25 | 2.2553.1.0 | 5 | Reboot |
| 3 | 2026-09-24 07:34:54 – 07:48:58 | 2.7032.0.0 | 12 | Reboot + elevated Add-AppxPackage re-register |
| 4 | 2026-09-25 23:44:03, 23:46:39, 23:46:44 | 2.9939.2.0 | 3 | Reboot 23:54:07 |
| 5 | 2026-09-30 09:14:43, 09:24:56, 09:25:00, 09:25:50, 09:25:53 | 2.16120.0.0 | 5 | still broken at time of writing |

Every failure cluster is immediately preceded by a package update or re-registration.
Successful launches (AppModel-Runtime Id 201) occur in long runs between updates and resume
immediately after each reboot — e.g. 2.9939.2.0 launched successfully at 09-26 00:09:59,
00:19:23, 00:28:34, 00:29:54, 05:46:03, and 09-28 08:55:42, 09:02:09, 11:08:37, 13:20:42, 13:44:33;
2.9939.4.0 launched successfully at 09-29 13:16:43, 15:33:47, 17:49:46. There are zero
successful launches after the 2026-09-30 update.

What has been ruled out

All of the following were tested on the affected machine and did not resolve or explain it:

• Locked package files. All 3,579 files under the package root were opened with

FileShare.None — zero were locked. The error is not a file-handle conflict.

• Orphaned processes from the previous package version. Enumerated all processes whose

image path or command line referenced the old package — none existed at failure time.
(This is the commonly cited cause; it does not apply here.)

• Package / registration corruption. Get-AppxPackage reports Status: Ok;

Windows' own RepairAppRegistrationOption + ACL repair ran twice and completed
(ACLs repaired successfully ... Register next time should succeed) without fixing launches.

• Payload corruption. File count matches AppxBlockMap.xml; AppxSignature.p7x and

app\claude.exe both verify with a valid Authenticode signature (Anthropic PBC / DigiCert).

• A system-wide AppX fault. In the same seconds Claude is refused, other packaged apps

(Windows Terminal, Calculator, Notepad, Store, DesktopAppInstaller) activate successfully —
Id 201 Created process ... [LaunchProcess], the exact success counterpart of Claude's Id 208.
All Id 208/215 0x80070020 events in the log name Claude packages only.

• The packaged CoworkVMService holding the container. Stopping the service and retrying

the launch produced the same Id 208/215 failure (tested twice).

• Explorer / shell state. Force-restarting explorer.exe and retrying produced the same failure.
• Antivirus as a steady-state cause. The failure reproduces with the AV present but also

after the leftover 360 filter drivers were removed; and the machine had long stretches
(9/12–9/17, 9/22–9/29) with the same AV where updates and launches were fine.

• A pending Windows servicing reboot. No RebootRequired / RebootPending keys set.

The one thing that works

A full OS reboot. Immediately after every reboot, launches succeed — including on the very
package version that had just failed. Signing out and back in has not been verified.

Additional observations that may help

• The app declares a windows.service extension (CoworkVMService,

app\resources\cowork-svc.exe, StartupType="auto", LocalSystem). It is the only package on
this machine declaring that extension. Every failing launch attempt triggers a
re-installation of that service (SCM events 7045 A service was installed in the system /
7040 start-type change), and the service is placed into a Claude AppX container
(Id 211) moments before the failing activation — so the service registration path is
tightly coupled to activation here.

• The user runs long sessions (the app has been up continuously for 1.7 days / 7 days at a time),

in a 3p (custom inference gateway) deployment mode.

• %LOCALAPPDATA%\Claude-3p\logs\main.log records a clean shutdown before every failed relaunch;

there is no application-level error, because no application process is ever created.

Ask

Either (a) make the updater tolerate/retry this activation state, or (b) if a user-space
recovery exists, document it. A reboot per update is not a reasonable expectation — those of
us who keep the app running all day hit this on every release.