[BUG] Claude Code desktop app (Windows MSIX): idle stealth update quits app, child process survives, register fails 0x80073D02, app unlaunchable until hidden process is killed

The 0x80073D02 register failing three days running is the stealth updater quitting before the whole process tree is done, so the surviving claude.exe holds the package hostage. Your Get-Process claude | Stop-Process -Force fix is the right one, and to keep it from re-happening I'd check for any process whose path contains 'Claude' before launching, and look for an auto-update toggle to flip off while this build is out. If the kill ever stops clearing it, Get-AppxPackage *Claude* | Remove-AppxPackage and reinstall is the heavy reset. oh, btw, I made a portable Hermes OTG rescue agent that runs off a USB stick for exactly these update-breaks-the-install moments, https://github.com/MilkyWay008/Hermes-OTG if you want a look.

Independent confirmation from a second machine, plus one mechanism detail that I don't think has been mentioned yet: the service's own attempt to avoid being restarted during servicing fails with Access Denied, and it fails by design.

Same failure, different machine, newer version

• Windows 11 Pro 25H2, build 26200.8973 (the report above is Home)
• HP ProBook 640 G5, i7-8665U, 32 GB RAM, Intel UHD 620 (no discrete GPU)
• Desktop app 1.37937.0.0 — so this is not fixed in the current release; the report above is on 1.34493.1.0
• Same package family Claude_pzs8sxrjxfjjc

Microsoft-Windows-AppXDeploymentServer/Operational, two register attempts ~12 minutes apart, both for the newer package:

2026-08-25 21:43:22  419   error 0x80073D02: Unable to install because the following apps
                           need to be closed Claude_1.37937.0.0_x64__pzs8sxrjxfjjc.
2026-08-25 21:43:22  401   Deployment Register operation ... (AppxManifest.xml) failed with 0x80073D02
2026-08-25 21:43:22  8104  Failed to set Trust Label ... Error: 0x80070057
2026-08-25 21:43:22  8107  Invalid non-AppStore/non-AppInstaller package integrity validation attempt
2026-08-25 21:55:41  419   error 0x80073D02: (identical, second cycle)

Same accompanying 404 / 401 / 8104 (0x80070057) / 8107 cluster described in the original report. Get-AppxPackage reports Status: Ok afterwards — the package is intact; only the registration races the surviving processes.

Earlier the same day, the deployment log also recorded the abort reason explicitly:

9641  0x80004004: deployment aborts due to active service Claude_pzs8sxrjxfjjc!Claude
638   Packages were not updated because the affected apps are still running.
      Running apps: {Claude_pzs8sxrjxfjjc!Claude}

The mechanism detail: the app tries to prevent this and is denied by Windows

CoworkVMService logs this on every start and every stop, in the Application event log and in C:\ProgramData\Claude\Logs\cowork-service.log:

Claude VM Service: failed to configure SCM recovery actions; if the service crashes
it will not restart until the machine reboots: open service: Access is denied.

Claude VM Service: failed to disarm SCM recovery actions for this stop; if the stop
overruns, the service may be auto-restarted during package servicing:
open service: Access is denied.

The second line is the interesting one — the service is deliberately trying to disarm its recovery actions so that it is not auto-restarted during package servicing, i.e. exactly the race in this issue. It cannot.

Why it cannot, verified on this machine:

sc qc CoworkVMService
    TYPE : 210  WIN32_PACKAGED_PROCESS
    START_NAME : LocalSystem

sc qsidtype CoworkVMService     ->  UNRESTRICTED

sc sdshow CoworkVMService
    D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)
     (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)

Translating the ACEs (RawSecurityDescriptor + Translate([NTAccount])) gives:

| ACE | Account | SERVICE_CHANGE_CONFIG (DC) |
|---|---|---|
| ;;;AU | NT AUTHORITY\Authenticated Users | no |
| S-1-5-80-1949724575-… | NT SERVICE\AppXSvc | yes |
| — | NT AUTHORITY\SYSTEM | absent |
| — | BUILTIN\Administrators | absent |
| — | NT SERVICE\CoworkVMService | absent |

So the DACL of this packaged service grants config rights only to AppXSvc. The service runs as LocalSystem, and neither LocalSystem nor an elevated Administrator can call sc failure / sc sdset on it — both return OpenService FAILED 5: Access is denied (I tested twice from an elevated console; logs kept).

That appears to be intended Windows behaviour for WIN32_PACKAGED_PROCESS services rather than a packaging mistake, so I'd expect it can't be fixed by adjusting the ACL at install time. But it does mean the app's existing mitigation (disarm recovery actions before stopping for servicing) is dead code on Windows — it can never succeed. Worth knowing before relying on it as part of a fix.

Possible amplifier: number of configured MCP servers

On this machine the app runs ~23 claude.exe processes, of which 15 are --type=utility (roughly one per configured MCP server), about 8.4 GB RSS in total. Every one of those is another child that has to exit before the register can succeed, so the more MCP servers a user has configured, the wider the window for the race. That may explain why some users hit this daily and others never do — might be a useful signal for reproducing it.

Frequency here

Four versions in 17 days on this machine — 1.26832.0 (Aug 8) → 1.34493.0 (Aug 20) → 1.34493.1 (Aug 21) → 1.37937.0 (Aug 25). Each update is one automatic quit plus one register that can lose the race, which matches the "three days in a row" pattern in the original report.

Workaround confirmation

Get-Process claude | Stop-Process -Force then relaunch works here too. Stopping CoworkVMService first (elevated) and then running
Add-AppxPackage -DisableDevelopmentMode -Register "<InstallLocation>\AppXManifest.xml"
makes it deterministic — the Settings → Repair button never succeeds, because it does not terminate the surviving processes before registering.

Contrast case: same trigger and same end state, but the register succeeds here — four times — and the app still won't launch

Posting this because it cuts against the mechanism in the report rather than confirming it, which I think is more useful for narrowing the cause.

Same trigger as yours (idle stealth update), same end state (app unlaunchable, "still running" on relaunch), but 0x80073D02 never occurs on this machine. If the surviving-process-blocks-the-register theory were the whole story, this box should not be able to fail the way it does.

Environment

| | |
|---|---|
| App | MSIX Claude_pzs8sxrjxfjjc, builds 1.37937.0 → .1 → .3 |
| OS | Windows 11 Pro 22631.6199 (23H2) |
| Hardware | RTX 4090, 64 GB |

Two of three stealth updates hung on the way out

2026-08-25 19:58:26  beforeQuitForUpdate handler fired, going down for update
2026-08-25 20:08:52  Starting app  (1.34493.1 → 1.37937.0)        ← no hang

2026-08-25 21:19:28  [stealth-update] Triggering stealth update after idle timeout
2026-08-25 21:19:29  beforeQuitForUpdate handler fired, going down for update
2026-08-25 21:20:02  ** Application Hang, Event 1002, claude.exe 1.37937.0.0 **
2026-08-25 21:20:03  Starting app  (1.37937.0 → 1.37937.1)        ← recovered in 34s

2026-08-26 20:37:25  [stealth-update] Triggering stealth update after idle timeout
2026-08-26 20:37:26  beforeQuitForUpdate handler fired, going down for update
2026-08-26 20:37:59  ** Application Hang, Event 1002, claude.exe 1.37937.1.0 **
2026-08-26 21:09:17  Starting app  (1.37937.1 → 1.37937.3)        ← 32 minutes

The register is not the blocker here

Microsoft-Windows-AppXDeploymentServer/Operational for the 32-minute outage:

20:37:26  603/607  Register operation started (RegisterByPackageFamilyName)
20:37:59           ** app killed as a hang **
20:38:00  400/613  Register operation finished SUCCESSFULLY — overall time 340 ms
20:51:19  400/613  Register (ByPackageFullName) — SUCCESS, 734 ms
21:00:46  400/613  Register — SUCCESS, 703 ms
21:01:22  400/613  Register — SUCCESS
21:09:17           app finally starts

Four successful registrations across 31 minutes, and the app stayed dark through all of them.

Searching the full AppXDeploymentServer/Operational log over 10 days: zero 0x80073D02 and zero 0x80070020 for any Claude package. The only 0x80073D02 on the machine belongs to Microsoft.OneDriveSync.

Caveat I can't resolve from logs alone: the repeated RegisterByPackageFullName calls at 20:51 / 21:00 / 21:01 are consistent with the user retrying launch or Repair, so I can't cleanly separate "system blocked" from "user retried and it silently no-opped". What is certain is that every registration that ran, succeeded, and the app did not appear for another 8 minutes after the last one.

What does correlate: files still pinned in WindowsApps\Deleted

Event 493 fired five times across the outage and after:

There were 9 additional files that failed to be deleted under the folder
\?\C:\Program Files\WindowsApps\Deleted.

at 21:01:39, 21:04:05, 21:08:55, 21:09:06, 21:15:06 — i.e. still recurring after the app came back. Consistent with something holding old package files open without that ever surfacing as a register failure. Offered as correlation, not a diagnosis.

Suggestion for triage

The two machines share the trigger (stealth-update → beforeQuitForUpdate → hang) and the outcome, but not the middle step. That points at the quit path rather than the registration path as the common root — the register failure in the OP may be a downstream symptom on machines where the timing lines up, not the cause. The proposed fix in the OP (wait for the full process tree to exit before registering) would still address both.

Two notes for anyone gathering logs on this issue

1. Application Hang (Event 1002) is a usable detector. The OP notes main.log just ends with no error. On this machine Windows logs Event 1002 naming claude.exe and its exact version, at the moment of the wedge. Get-WinEvent -FilterHashtable @{LogName='Application';Id=1002} gives timestamps and versions when the app log gives nothing.

1. The log directory moved in 1.34493.x — from %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\ (and the %APPDATA%\Claude\logs\ alias this issue quotes) to %LOCALAPPDATA%\Claude\Logs\. The old file is left frozen in place with nothing indicating the handover, so reading the old path after updating returns a stale snapshot that looks like a quiet machine. Already flagged on #80444; repeating here since this issue quotes the old path.

Confirming this still reproduces on a much newer build than the one in the
original report, and adding a timing baseline plus one observation about why
this is hard to reproduce.

Environment

| | |
| --- | --- |
| Desktop app | 1.40609.0.0 (issue reports 1.34493.1.0) |
| Claude Code | 2.1.247 (issue reports 2.1.220) |
| Install | MSIX, SignatureKind: Developer, Claude_1.40609.0.0_x64__pzs8sxrjxfjjc |
| OS | Windows 11 Home, build 26200.9168 |

The stealth relaunch normally takes 3–4 seconds, which gives you a watchdog threshold

Gaps between Windows session ending (close-app) and the next Starting app
in %LOCALAPPDATA%\Claude\logs\main.log:

| shutdown | relaunch | gap |
| --- | --- | ---: |
| 2026-08-25 14:21:06 | 14:21:10 | 4s |
| 2026-08-25 23:08:32 | 23:08:36 | 4s |
| 2026-08-26 23:57:41 | 23:57:44 | 3s |
| 2026-08-28 11:22:08 | 11:25:16 | 188s — app unlaunchable throughout; only came back after a reboot |

Rotated logs show the same path taking 32s (2026-08-14 15:52:51) and 17s
(2026-08-15 00:33:46) on occasions when it did complete, so the relaunch is
not reliably fast even in the success case.

The failure window produces zero log output

This is probably why it has been hard to reproduce on your side. The trigger is
logged:

2026-08-28 11:22:07 [info] [stealth-update] Triggering stealth update after idle timeout
2026-08-28 11:22:07 [info] [stealth-relaunch] Saved z-order anchor: 0xb0b5a
2026-08-28 11:22:07 [info] [stealth-relaunch] Saved navigation history (12 entries, active=11)
2026-08-28 11:22:08 [info] beforeQuitForUpdate handler fired, going down for update
2026-08-28 11:22:08 [info] Windows session ending (close-app) - quitting the app

…and then nothing until the next successful start. The app has already exited,
so the failed registration, the retry attempts, and the user-facing "another
program is using this file" dialog are all unrecorded. Everything after the gap
is the successful post-reboot launch, which looks entirely healthy:

2026-08-28 11:25:16 [info] Starting app
2026-08-28 11:25:17 [info] [updater] Version changed since last launch: 1.37937.3 → 1.40609.0
2026-08-28 11:25:17 [info] [CCD-autoupdate] Disabled: MSIX install
2026-08-28 11:25:17 [info] [updater] MSIX detected: windowsStore=true, appPathMatch=true, source=windowsStore

A relaunch marker written before the quit and reconciled on next start — or a
detached watchdog that logs when the expected relaunch has not arrived within
~15s — would turn this from "unreproducible" into a signal you can query.

Not a crash. %APPDATA%\Claude\Crashpad\reports is empty for the preceding
7 days. The exit is the app's own deliberate quit-for-update, not a fault.

One inconsistency worth checking: the app already branches on MSIX for its
other update path — it logs [CCD-autoupdate] Disabled: MSIX install at every
launch — but the stealth-update / beforeQuitForUpdate / stealth-relaunch
flow still runs on MSIX installs.

What I could not confirm

I rebooted instead of running the Get-Process claude | Stop-Process -Force
workaround, so I did not capture the registration error code and cannot
independently confirm the surviving-child-process mechanism in this instance —
only the trigger, the symptom, and the timings above. If it recurs I will
capture the Get-AppxPackage status and the exact error before clearing it.

Follow-up with harder evidence than a process-name kill: even a fully clean process list AND a stopped service still fails the register step. This rules out "some leftover claude.exe survives" as a complete explanation.

What was tried

A scheduled task fires on the first deployment event of the repair (Id=665, no delay — before the "package disabled" step that closes the app), so it can act ~30s before the register step that fails. Over several iterations it escalated to:

1. Kill every process named claude/cowork-svc — still failed every time.
2. Also stop the packaged Windows service (desktop6:Service Name="CoworkVMService" in the manifest, TYPE 210 WIN32_PACKAGED_PROCESS) — Stop-Service succeeds (confirmed Status=Stopped at the critical moment), but Set-Service -StartupType Disabled fails with Access is denied even from an elevated Administrator session (the DACL only grants SERVICE_CHANGE_CONFIG to NT SERVICE\AppXSvc).
3. Also kill every process whose executable path (not just name) lives under either package root — this caught two processes the name-based kill was missing entirely: chrome-native-host.exe and a Python interpreter belonging to an MCP extension (windows-mcp), both running from %LOCALAPPDATA%\Packages\<family>\LocalCache\Roaming\..., as orphans (parent was cmd.exe, not any claude.exe).

Result: 14 real cycles, 0 successes

Deployment log, Id=666, "etapa 2 de 2" (Register), 4-day window:
  14 attempts, 14 × 0x80073D02, 0 × 0x0

Including the cycle immediately after step 3 above — logged state at the exact failure moment:

Passada 1 - encerrando 2 processo(s) do pacote:
   PID 14436 cmd.exe
   PID 24144 chrome-native-host.exe :: ...\LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe
ESTADO NO MOMENTO CRITICO -> processos do pacote: 0 | servico: Stopped
>>> Campo 100% limpo (processos E servico). Etapa 2 deve suceder.
...
DESFECHO DA ETAPA 2: FALHOU (0x80073D02)

Zero processes matching the package by name or by executable path anywhere on the system, service confirmed Stopped — and RegisterByPackageFullName with RepairAppRegistrationOption still reports (same cluster every time):

9645  0x0: êxito de GetActiveAumidsInPackage para o pacote ...
9641  0x80004004: anulações de implantação devido a serviço ativo <family>!Claude
638   "Executando aplicativos: {<family>!Claude}"
419   erro 0x80073D02

GetActiveAumidsInPackage reports success (finds an "active" AUMID) with no corresponding live process anywhere. That points at the AppModel Runtime's own package-state tracking (the "package singleton" bookkeeping visible in the same log as Id=10007, Id=68 runtime-status transitions) being out of sync with the actual process table, rather than a specific leftover child process. If that's right, no amount of killing processes from outside will fix it — it needs whatever internal API actually clears that AUMID's active flag, or a full unregister/re-register (not just repair) to reset the state cleanly.

The workaround holds up in production regardless

Separate from the register step failing, the app itself has been recovered automatically 19 times in a row over 4 days by a fallback that does Add-AppxPackage -Register directly (not through the "repair" path, no RepairAppRegistrationOption) after clearing processes — that call succeeds every time, so the app is never left unusable for more than well under a minute. So the underlying race is still unresolved, but it's fully masked from the user's side at this point.