[BUG] Windows MSIX: explorer.exe activation-time repair-register force-kills the app and every in-app Claude Code session, and the failure is self-sustaining

Preflight Checklist

• [x] I have searched existing issues. The closest are #82277, #73694, #80502, #88689 and #89599. This is a different kill path and adds the missing attribution: see "How this differs from the existing issues" at the bottom.
• [x] This is a single bug report
• [x] I am using the latest version

What's Wrong?

Summary

Since 2026-08-24 this machine has been in a servicing loop that force-terminates Claude Desktop several times a day, taking every Claude Code session running inside the app with it. Two full app exits in the last 12 hours destroyed 7 Claude Code sessions between them.

The new information in this report is who issues the kill. Every deployment event carries a CallingProcess field, and it settles the question:

| Caller | 603 register ops since 24 Aug | Carries ForceTargetApplicationShutdownOption |
|---|---|---|
| explorer.exe | 27 | 27 (all of them) |
| svchost.exe,AppXSvc,ClipSVC | 21 | 0 |
| SystemSettings.exe | 10 | 0 |
| claude.exe | 2 | 0 |

All 27 forced shutdowns come from explorer.exe. That is the shell doing an activation-time repair-register when the app is launched. It is not a background servicing sweep and it is not Windows Update.

The second finding is why it never converges. A failed register leaves the package Modified, NeedsRemediation. The next activation therefore triggers the same repair-register, which fails the same way, which leaves it needing remediation again. Nothing breaks the cycle, and every pass through it force-kills the running app.

Environment

| | |
|---|---|
| Claude Desktop | Claude_1.37937.0.0_x64__pzs8sxrjxfjjc (also reproduced on 1.34493.1.0) |
| Package family | Claude_pzs8sxrjxfjjc |
| SignatureKind | Developer, CN="Anthropic, PBC" |
| Install location | C:\Program Files\WindowsApps\Claude_1.37937.0.0_x64__pzs8sxrjxfjjc\ |
| OS | Windows 11 Pro 25H2, 10.0.26200.9168, x64 |
| RAM | 64 GB, 18 to 39 GB free at every kill. Not resource exhaustion. |

The cycle, one full pass

From Microsoft-Windows-AppXDeploymentServer/Operational on 2026-08-26. CallingProcess is read from the event XML, not the rendered message.

00:18:53  603   RegisterByPackageFullName   caller=explorer.exe
                Options ForceTargetApplicationShutdownOption,RepairAppRegistrationOption
00:18:53  649   ACLs repaired for \\?\C:\Program Files\WindowsApps\Claude_...
          ---- app tree dies here: 16 processes to 2, 6 Claude Code sessions lost ----
00:18:57  603   ResetPackageOperation       caller=SystemSettings.exe
00:18:59  603   RepairPackageOperation      caller=SystemSettings.exe
00:18:59  603   Add   Claude-255293a41a25d54c5177aa9614fb4cd620e70b78.msix
00:21:17  603   RegisterByPackageFullName   caller=svchost.exe,AppXSvc,ClipSVC
00:21:18  8100  Starting validation and setting the Trust Label
00:21:18  8107  Illegal non-AppStore or non-AppInstaller package integrity validation attempted
00:21:18  8104  Failed to set the Trust Label, Error: 0x80070057
00:21:18  419   error 0x80073D02: Unable to install because the following apps need to be closed
00:21:18  9641  0x80004004: Deployment aborts due to active service Claude_pzs8sxrjxfjjc!Claude
00:21:18  638   Packages were not updated because affected apps are still running
00:21:18  617   status updated (Set=0x400)
00:21:18  404   AppX Deployment operation failed, error 0x80073D02

The app has relaunched by 00:21, so the register that follows the kill fails on the app it just killed. SystemSettings.exe appears only ever after a failure, so it is Windows auto-remediating, not the driver.

The 8107 / 8104 pair is secondary, not structural

Counts since 24 Aug: 9 x 8107, 9 x 8104, 9 x 404. In every single occurrence they appear alongside 419 apps need to be closed. They have never once appeared on their own.

The converse also holds. On 2026-08-26 at 07:32:21 and 07:32:28, while the app was down for the update to 1.37937.0.0, two registers completed successfully with no 8107 and no 8104. Ten seconds later, with the app relaunched, the follow-up repair-register produced both again plus 0x80073D02.

So the trust-label rejection is not a permanent property of the Developer-signed package. It is what the register reports when it cannot get the package quiet. That matters because it means this is fixable, not a signing dead end.

Healthy baseline, for contrast

The same explorer.exe activation-time repair-register with the identical flags ran during the healthy period and succeeded every time:

08-18 10:55:17  603 caller=explorer.exe flags=1073741888  -> 400 finished successfully
08-18 10:55:45  603 caller=explorer.exe flags=1073741888  -> 400 finished successfully
08-20 07:06:22  603 caller=explorer.exe flags=1073741888  -> 400 finished successfully

SystemSettings.exe appears zero times in 17 to 21 Aug. So the shell call is normal, roughly every day or two. What changed on 24 Aug is that it began failing, and a failing one is self-sustaining.

Build 1.34493.1.0 was installed 21 Aug 13:39. The first failure is 24 Aug 19:32, which is simply the first activation-time register after that install. No Windows servicing-stack update landed between 21 and 24 Aug on this machine, only Defender definitions and Store app updates.

Why stopping the service is not a workaround

CoworkVMService blocks the deployment, as already documented in #73694 and #80502. Setting it to Manual and stopping it does not hold, because it has a named-pipe start trigger:

sc.exe qtriggerinfo CoworkVMService

START SERVICE
  CUSTOM  : 1f81d131-3e60-4c76-9860-37334e4ffce3 [ETW PROVIDER UUID]
    DATA  : \pipe\cowork-vm-service

Anything that touches that pipe restarts the service, including the app relaunching after the forced shutdown. A local repair that stops the service, registers, and restarts it therefore has a race it cannot reliably win.

Measured cost

| | |
|---|---|
| 603 register operations since 24 Aug | 60 |
| Forced shutdowns requested | 27 |
| Failed deployments (404) | 9 |
| Full app exits in the last 12 hours | 2 |
| Claude Code sessions destroyed by those 2 exits | 7 |
| Rate | 9 ops on 24 Aug, 19 on 25 Aug, 18 in the first 30 minutes of 26 Aug |

Every destroyed session is work in flight with no crash record and nothing to resume from.

Ruled out

• Not memory: 18 to 39 GB free at every kill on a 64 GB machine
• Not a crash: zero Crashpad reports, zero WER entries, zero Application Error 1000/1001/1002 naming the package
• Not a user quit: one graceful onQuitCleanup in 19 days of app logs
• Not Windows Update: no servicing-stack update between the last healthy day and the first failure
• Not certificate expiry: the package validates, and clean registers succeed when the app is down

Suggested fix

1. Do not declare an always-on, trigger-started service in a package that the shell will repair-register at activation time. CoworkVMService is AUTO_START plus a pipe trigger, so the package is never quiet, so activation-time servicing can never complete cleanly. Every other app hits the same "apps still running" deferral and clears it when the user closes the app. This one cannot.
2. Make the service releasable. Have it drop its handles on the package directory when AppX signals servicing, or move it out of the package payload.
3. Do not let a failed repair-register leave the package NeedsRemediation when the only cause was ERROR_PACKAGES_IN_USE. In-use is a retry-later condition, not damage, and treating it as damage is what turns one failure into a permanent loop.
4. Do not force-terminate to service a package whose version is unchanged. 27 forced shutdowns produced no version change. See also molokoloco's comment on #82277 making the same point.

How this differs from the existing issues

• #82277 is the same harm (Claude Code sessions destroyed silently) but a different mechanism: package-disable via event 10000 during servicing. There are no 10000 events on this machine. This report adds the CallingProcess attribution and the self-sustaining re-entry that explains why it never converges.
• #73694 and #80502 correctly identify CoworkVMService as the lock holder. This report adds that the shell, not the updater, is what escalates to a forced shutdown, and adds the pipe-trigger reason a local stop-and-register workaround cannot hold.
• #88689 covers repair registering from a deleted %TEMP% msix. Consistent with what is seen here: the repair Adds Claude-255293a41a25d54c5177aa9614fb4cd620e70b78.msix, and no file by that name exists anywhere on this machine.
• #89599 is the idle stealth-update variant. This one needs no update at all; it fires on ordinary app activation.

Still reproducing on 1.37937.0.0, released seven builds after #82277 was filed.