[BUG] Windows MSIX: package servicing disables the package while running, silently killing Claude Code background agents (no crash record, no recovery)

Status Open

Maintainer reply None cached

Activity 5 comments · opened Jul 29, 2026

Environment

| | |
|---|---|
| Claude Desktop | 1.24012.9.0 (MSIX, sideloaded from downloads.claude.ai) |
| Package family | Claude_pzs8sxrjxfjjc |
| Install location | C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\ |
| SignatureKind | Developer (signed "Anthropic, PBC", valid to 2026-10-21) |
| OS | Windows 10 Home 22H2 (10.0.19045), it-IT |
| RAM | 16 GB (not a resource-exhaustion issue — see below) |

Summary

On this machine the MSIX package is repeatedly re-deployed with the same version number. Each deployment sets the package state to disabled before servicing it. Disabling an MSIX package terminates every process running from that package — which includes Claude Desktop and every child process it spawned, i.e. Claude Code and all its background subagents.

The result: long-running background work is destroyed mid-flight, with no crash record and nothing recoverable. Three separate multi-agent Claude Code workflows were killed this way in under three hours. In each case the agents had produced work that was never written out, because the kill is instantaneous and unsignalled.

This is not a resource problem (9.5 GB RAM free at the time) and not a certificate problem (83 days of validity remaining).

Why it produces no diagnostics

No Application Error / App Hang events (ID 1000/1001/1002) naming Claude
No Windows Error Reporting archive entries
No Resource-Exhaustion-Detector events
The app's own main.log shows a clean beforeQuit: handler fired, going down

From every diagnostic surface it looks like a normal user-initiated quit. It is not — the user did nothing.

Evidence

From Microsoft-Windows-AppXDeploymentServer/Operational, all on 2026-07-29:

11:31:20  ID 607  Register operation dequeued, package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc
11:31:20  ID 573  package family Claude_pzs8sxrjxfjjc, enabled false
11:39:37  ID 10000 package servicing starting; setting package state to disabled -> 0x0
11:42:55  ID 854  URI added: file:///C:/Users/<u>/AppData/Local/Temp/Claude-13094932.msix
12:01:49  ID 573  package family Claude_pzs8sxrjxfjjc, enabled false
12:02:53  ID 854  URI added: file:///C:/Users/<u>/AppData/Local/Temp/Claude-587357855.msix
12:09:03  ID 607  Remove operation (full uninstall)
12:19:02  ID 854  URI added: file:///C:/Users/<u>/AppData/Local/Temp/Claude-2765775605.msix
13:54:47  ID 573  package family Claude_pzs8sxrjxfjjc, enabled false
13:54:58  ID 573  package family Claude_pzs8sxrjxfjjc, enabled false
13:56:42  ID 854  URI added: file:///C:/Users/<u>/AppData/Local/Temp/Claude-360131957.msix

Correlation with the three destroyed Claude Code workflows:

| Workflow run | Last agent activity | Nearest deployment event |
|---|---|---|
| wf_e23f2c7d-b5e | 11:30:16 | 11:31:20 — Register, package disabled |
| wf_4c12faca-0cf | 11:56:44 | 12:01:49 — Register, package disabled |
| wf_addcac35-514 | ~13:54 | 13:54:47 + 13:54:58 — Register, package disabled ×2 |

In every case the workflow journal contains only started records and never a single result, so the built-in resume-from-cache mechanism recovers nothing. The work has to be redone from zero.

Lock holders (matches #76357)

CoworkVMService   DisplayName "Claude"   StartMode Auto   State Running
                  C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe
cowork-svc.exe    running
claude.exe        11 processes running from the WindowsApps package directory

These hold file locks inside the package directory. Unlike #76357, where the deployment fails with "Another program is currently using this file", here the deployment succeeds by forcing the package into the disabled state first — which is what kills the running processes.

Evidence of a re-install loop

The app re-deploys the same version (1.24012.9.0) over and over, each time from a freshly downloaded .msix in %TEMP%. config.json records "updaterLastSeenVersion": "1.24012.9" — i.e. the updater already considers itself current, yet keeps re-adding.

Leftover installers in %TEMP%:

Claude-2963852561.msix        0 bytes   11:32:07   <-- truncated download
Claude-587357855.msix     246.4 MB      12:02:50

The 0-byte file is a failed download. When that happens the deployment leaves the package disabled and the app does not come back — the user must reinstall by hand to recover. This has happened repeatedly.

Collateral damage

A full uninstall/reinstall cycle (12:09 Remove → 12:19 Add) wipes config.json, including user customisations and any .bak the user had made. Settings silently revert to defaults after every recovery reinstall.

Steps to reproduce

Install Claude Desktop on Windows via the MSIX package from claude.ai/download
Leave CoworkVMService at its default (auto-start)
Start a long-running Claude Code background task (a multi-agent workflow, 10+ minutes)
Wait for the updater's periodic check to trigger a package re-deployment
The app and every child process disappear instantly; all background work is lost

Expected behaviour

Package servicing must not run while the app has active background work. The updater should defer, or at minimum prompt.
If servicing is unavoidable, the app should receive a shutdown signal early enough to flush in-flight agent results to the workflow journal, so resumeFromRunId can actually recover them. Today the journal contains started with no matching result, which makes resume useless.
The updater should not re-deploy a version identical to the installed one.
A failed/truncated %TEMP% download must not leave the package disabled and unlaunchable.
Uninstall/reinstall should preserve config.json.

Related issues

#76357 — same lock holders (CoworkVMService + lingering Claude.exe), but there the update fails; here it succeeds by disabling the package
#63397 — MSIX auto-update failing while app running, closed as not planned
#58009, #59692, #62028 — same MSIX/AppContainer family

Diagnostic commands used

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-AppXDeploymentServer/Operational'; StartTime=(Get-Date).AddDays(-7)} |
  Where-Object { $_.Message -match 'laude' } | Sort-Object TimeCreated

Get-AppxPackage -Name "Claude*" | Select-Object Name,Version,Status,SignatureKind,InstallLocation

Get-CimInstance Win32_Service -Filter "Name='CoworkVMService'" | Select-Object Name,State,StartMode,PathName

Get-Process | Where-Object { $_.Path -like "*WindowsApps*Claude*" }

View original on GitHub ↗

5 Comments

molokoloco · 6 days ago

Adding a data point, since this issue has no comments yet and I hit the redundant-deployment part of it on 24/08.

Windows 10 Pro 19045, sideloaded MSIX, Claude 1.34493.1.0.

The deployment stack ran a RegisterByPackageFullName with RepairAppRegistrationOption against the version that was already installed - 1.34493.1.0 against 1.34493.1.0 - while the app was running. It failed with 0x80073D02 (ERROR_PACKAGES_IN_USE) and left the package Modified, NeedsRemediation.

So the servicing operation had no version to gain and a working install to lose, and it lost it. The app kept running, then refused to activate. Recovering it took a full reinstall of the same version number.

Timeline from Microsoft-Windows-AppXDeploymentServer/Operational:

18:03:48  404  deployment failed, 0x80073D02
18:04:22  603  RegisterByPackageFullName, options RepairAppRegistrationOption
18:04:22  638  packages not updated, apps still running: {Claude_pzs8sxrjxfjjc!Claude}
18:04:23  401  Register failed, 0x80073D02
          ->   package now Modified, NeedsRemediation
18:10:45  400  Add succeeded (manual reinstall, same version), 17.4s

This lines up with @tonydzi on #76357 (12/08), who saw RepairAppRegistrationOption failing repeatedly while the package still reported Status: Ok.

Two things that would have prevented the damage here, both already in your request list:

not servicing a package while its own processes are running, or at minimum not attempting a repair registration that cannot succeed under that condition
not redeploying a version identical to the installed one

I would add a third: when the repair fails, the package should not be left flagged NeedsRemediation. That flag is what turns a failed no-op into a broken install, and it survives every subsequent Register - only a full Add clears it.

No data loss on my side, for what it is worth: ~/.claude was untouched throughout.

afram123 · 6 days ago

No Application Error / App Hang events (ID 1000/1001/1002) naming Claude

I hit this same class of silent kill on 2026-08-24 and I think I found where the missing
crash record actually is: it exists, but it is filed under node.exe, not under
anything matching Claude. The diagnostic command in this issue —
Where-Object { $_.Message -match 'laude' } — filters it out.

Environment

Windows 11 Home 10.0.26200.9168, ARM64 (Snapdragon X Plus)
Claude Desktop Claude_1.34493.1.0_arm64__pzs8sxrjxfjjc

The record that does exist

22:58:18.123  Application  1001  Fault bucket 2152750059287222162, type 5
                                 Event Name: AppHangB1
                                 P1: node.exe
                                 P2: 24.11.1.0
                                 P3: 69130cb2   P4: 222a   P5: 2097152
22:58:18.133  Application  1002  The program node.exe version 24.11.1.0 stopped interacting
                                 with Windows and was closed.

Those node.exe processes are C:\Program Files\nodejs\node.exe (system Node v24.11.1)
spawned as children of the packaged Claude.exe to host MCP servers. They are inside the
package's process tree for containment purposes but carry their own image name, which is
why nothing in the crash record says "Claude".

10 ms later the mechanism this issue describes fires:

22:58:18.147  AppXDeploymentServer  9648  TerminateSingleService for update successful ... CoworkVMService
22:58:18.159  AppXDeploymentServer  9650  Succesfully terminated service ... CoworkVMService
22:58:18.164  AppXDeploymentServer 10000  About to service package. Setting the package state to disabled -> 0x0
22:58:18.169  AppModel-Runtime       217  Destroyed Desktop AppX container {D93179E5-...}

So the sequence is: forced shutdown request → the tree does not exit within the timeout →
Windows AppHang-terminates it (recorded against node.exe) → container destroyed → every
remaining process in the package dies. Event 217 "Destroyed Desktop AppX container" in
Microsoft-Windows-AppModel-Runtime/Admin is a much better tripwire than the
Application log, since it names the package directly.

The trigger is wider than the periodic updater

Worth flagging for the repro steps in this issue: on my machine the servicing operation was
not the updater's periodic check. The app had already exited at 22:57:23.5
(cowork-service.log: Persistent RPC: connection ended: failed to read length: EOF,
with no Application Error event for Claude.exe). When I clicked to reopen it, the failed
activation triggered Windows' auto-heal path:

22:57:45.740  TWinUI                1621  Activation of app Claude_pzs8sxrjxfjjc!Claude attempted
22:57:45.809  AppXDeploymentServer   603  Started RegisterByPackageFullName ...
                                          Options ForceTargetApplicationShutdown
22:57:58.070  AppXDeploymentServer   603  (same again, after a second click)
22:58:18.397  AppXDeploymentServer   400  Register operation finished successfully
22:58:18.414  AppXDeploymentServer   613  Performance summary: overall 32594 ms

ForceTargetApplicationShutdown is exactly the "disable the package while things are still
running" behaviour described here, and it took 32.6 seconds — the window in which the
process tree was asked to leave and failed to. So the kill window is not only "the updater
ran": any failed activation can force a package re-register that tears down a
still-running process tree, including background agents that outlived a UI crash.

That also means the mitigation requested in this issue (item 2 — signal the app early
enough to flush in-flight results) has a concrete hook: the shutdown request is being
delivered and there is a ~30 s budget before the force-kill. Nothing in the tree currently
uses it.

Cross-reference: #88962 documents the companion failure — after this teardown, Settings →
Repair cannot recover, because Repair's own step 1 auto-starts CoworkVMService, which
makes its step 2 abort with 0x80073D02 395 ms later.

jordanjamesmedia · 5 days ago

Filed #89660 for what looks like a sibling of this on the same package, with a different kill path worth separating out.

Same harm you describe, Claude Code sessions destroyed silently with no crash record, but no event 10000 package-disable anywhere on my machine. Reading the CallingProcess field out of the event XML instead of the rendered message settles what issues it: all 27 forced shutdowns since 24 Aug come from explorer.exe doing an activation-time repair-register, none from the servicing path. SystemSettings.exe shows up only after a failure, so it is Windows auto-remediating rather than driving.

@molokoloco your comment matches mine almost exactly, same build 1.34493.1.0, same date, RepairAppRegistrationOption against the already-installed version, left Modified/NeedsRemediation. The re-entry is what makes it permanent: NeedsRemediation causes the next activation to repair-register again, which fails the same way. Still reproducing on 1.37937.0.0.

molokoloco · 4 days ago

Fifth occurrence here (26/07, 27/07, 30/07, 24/08, 26/08), Windows 10 Pro 19045, sideloaded MSIX. This one has a variant I have not seen in this thread or the neighbouring ones, and it also corrects something I claimed in my own comment above.

The repair targeted a package version that was no longer installed

Every documented case in these threads — including mine on 24/08 and @jordanjamesmedia's confirmation — is a repair-register fired against the currently installed version. This one was fired against a stale one, ten hours after a newer version had been successfully installed and was running fine.

Timeline, Microsoft-Windows-AppXDeploymentServer/Operational (local time, translated from a French locale):

00:35:51  821  during logon, registration of Claude_1.37937.0.0_x64__pzs8sxrjxfjjc for user
               S-1-5-21-...-1001 completed with result 0x80073D02
00:35:51  638  packages not updated, apps still running: {Claude_pzs8sxrjxfjjc!Claude},
               directly managed: {Claude_1.34493.1.0_x64__pzs8sxrjxfjjc}
00:35:51  404  deployment failed for Claude_1.37937.0.0_x64__pzs8sxrjxfjjc, 0x80073D02
               ^^^ 18 claude processes running at this point. Stale registration entry created here.

10:46:51  613  Add performance summary, Claude_1.37937.1.0_x64__pzs8sxrjxfjjc, overall 34375 ms
               ^^^ newer version installed successfully. App works. Nothing cleans up 1.37937.0.0.

12:11:11  603  RegisterByPackageFullName, main parameter Claude_1.37937.0.0_x64__pzs8sxrjxfjjc,
               Options RepairAppRegistrationOption
12:11:11  854  URI added: C:\Program Files\WindowsApps\Claude_1.37937.0.0_x64__pzs8sxrjxfjjc\AppxManifest.xml
12:11:11  855  action list resolution finished, addPackageList: Claude_1.37937.0.0_x64__pzs8sxrjxfjjc
12:11:11  573  package family Claude_pzs8sxrjxfjjc, enabled false
12:11:12  9645 GetActiveAumidsInPackage succeeded for Claude_1.37937.0.0_x64__pzs8sxrjxfjjc
12:11:12  638  packages not updated, apps still running: {Claude_pzs8sxrjxfjjc!Claude}
12:11:12  419  0x80073D02: cannot install because the following apps need to be closed
               Claude_1.37937.0.0_x64__pzs8sxrjxfjjc
12:11:12  404  deployment failed for Claude_1.37937.0.0_x64__pzs8sxrjxfjjc, 0x80073D02

Package status right after: 1.37937.0.0 → Modified, NeedsRemediation. Only 2 claude processes were alive at 12:11. Nobody clicked anything, no update was pending, and the installed version was 1.37937.1.0.

What this looks like: the failed logon-time registration at 00:35 leaves an orphan entry for 1.37937.0.0. The successful Add of 1.37937.1.0 at 10:46 does not clear it. Ten hours later Windows' auto-heal goes after that orphan. Because the AUMID it checks (Claude_pzs8sxrjxfjjc!Claude) is family-scoped, the still-running 1.37937.1.0 reads as "the app is running", the repair aborts with 0x80073D02, and the 573 enabled false from a few hundred ms earlier has already been applied to the whole package family.

So the damage came from repairing a failure that no longer mattered, and it hit a version that was not the one being repaired. This is a second way to reach the harm described in this issue: not "servicing disables a running package", but "auto-healing a stale registration disables the running package's whole family".

Correction to my earlier comment, and to the prevailing reading of #76357

Above, and on #76357, I stated that Add-AppxPackage -Register succeeds without clearing NeedsRemediation, and that only a full Add recovers. That is not universally true, and the distinction matters.

Re-registering here cleared it in 13 seconds, no reboot, no reinstall, nothing re-downloaded:

12:11:58  service CoworkVMService stopped (start type Manual)
12:11:59  3 residual processes terminated (chrome-native-host, 2x claude)
12:12:05  re-register of Claude_1.37937.1.0_x64__pzs8sxrjxfjjc: SUCCESS
12:12:09  real activation test via AUMID Claude_pzs8sxrjxfjjc!Claude: app launched

The reason it worked is the same as the reason it broke: the NeedsRemediation flag was on 1.37937.0.0, and what I re-registered was 1.37937.1.0. In July, when re-registering did nothing for me, the flag and the target were the same package full name.

Practical consequence for anyone scripting a recovery: before concluding "register cannot fix this", compare the package full name carrying the flag with the one you are registering. If Get-AppxPackage shows several Claude entries, re-registering the newest one is worth trying first — it is 13 seconds against a 250 MB reinstall.

Question

Given 821 at logon and 603 … RepairAppRegistrationOption ten hours later, both against a version that was superseded in between: is anything on the app side triggering these, or is this purely Windows auto-heal reacting to the orphan left by the first failure? If it is the latter, a successful Add that also cleaned up the previously failed registration for the same family would remove the whole class.

Happy to pull the full event XML for any of the above.

harelbashiri · 2 days ago

Confirming this on Windows 11 Pro (10.0.26200), x64, Claude Desktop 1.37937.x — same package family Claude_pzs8sxrjxfjjc, but in my case triggered by regular version-to-version auto-updates, twice within 24 hours. Each time, the whole package (app window with open Claude Code sessions + the bundled CoworkVMService) was hard-killed with no graceful stop.

Incident 1 — Aug 26, 2026

22:05:54 — during-logon registration of 1.37937.2.0 replacing 1.37937.1.0; also logged error 0x80070015: Unable to notify pre-launch service for app Claude_pzs8sxrjxfjjc!Claude install/uninstall
23:06:51 — Kernel-General ID 16 hive servicing on ...\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat / UserClasses.dat
23:06:53 — SCM event 7034: The Claude service terminated unexpectedly (CoworkVMService). cowork-service.log shows no "Service stop requested" — the previous line is from 22:05:54 and the next line is the 23:07:49 restart banner. The app went down with it; one open Claude Code session had a just-submitted prompt that was never answered.

Incident 2 — Aug 27, 2026

09:46:27 — update 1.37937.2.0 → 1.37937.3.0 (clean stop/start pair in the service log during registration, ActivationStore.dat servicing)
09:54:18 — SCM 7034 again; again zero shutdown lines in the service log between the 09:46:28 startup banner and the 09:55:08 restart banner.

Same diagnostic silence as described here: no Crashpad minidumps, no WER AppCrash for claude.exe/cowork-svc.exe, nothing in Reliability Monitor, and no memory pressure (192 GB RAM, >140 GB free at the time).

The non-recovery half matches #85840: every service start logs Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied. — so after each kill the service stayed down (~1 minute in my case) until the app was relaunched and restarted it.

[BUG] Windows MSIX: package servicing disables the package while running, silently killing Claude Code background agents (no crash record, no recovery)

Environment

Summary

Why it produces no diagnostics

Evidence

Lock holders (matches #76357)

Evidence of a re-install loop

Collateral damage

Steps to reproduce

Expected behaviour

Related issues

Diagnostic commands used

5 Comments

Environment

The record that does exist

The trigger is wider than the periodic updater

The repair targeted a package version that was no longer installed

Correction to my earlier comment, and to the prevailing reading of #76357

Question

Related Claude Code issues

Browse by topic