[BUG] Windows: MSIX auto-update leaves Claude Desktop unlaunchable (Modified/NeedsRemediation) — surviving chrome-native-host.exe blocks package-data cleanup (0x80073D05 → 0x80073CF6); winget repair falsely reports success

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

While Claude Desktop was mid-workflow (active Cowork VM + Claude Code sessions), the automatic MSIX update from 1.37937.1 → 1.37937.3 was staged and deferred because the app was running. During the incident, the package's chrome-native-host.exe (Claude-in-Chrome native messaging host, running out of the package's LocalCache) survived app shutdown and held a lock on its own executable. Windows AppX deployment could not delete the package application data (17× access-denied on that one file), deployment operations failed with 0x80073CF6 wrapping 0x80073D05 (ERROR_DELETING_EXISTING_APPLICATIONDATA_STORE_FAILED), and the package sat in Modified, NeedsRemediation — Claude Desktop would not launch. winget repair reported success while the package remained broken.

Recovery ultimately required manually identifying and stopping the lock-holding chrome-native-host.exe process, moving the locked file aside, and re-registering the package. Three distinct defects and one UX gap are detailed below; each is independently actionable.

Environment

• Windows 11 Pro 10.0.26200, x64
• Claude Desktop MSIX: Claude_1.37937.1.0_x64__pzs8sxrjxfjjc → Claude_1.37937.3.0_x64__pzs8sxrjxfjjc (update source: https://downloads.claude.ai/releases/win32/x64/1.37937.3/…​.msix)
• Cowork enabled (CoworkVMService running, Hyper-V HCS VM active), Claude in Chrome installed, active Claude Code Remote Control session at the time
• Claude Code CLI 2.1.246 (separate install under %APPDATA%\Claude\claude-code, unaffected)

Verified timeline (2026-08-26, local time; source: Microsoft-Windows-AppXDeploymentServer/Operational)

| Time | Event | What happened |
|---|---|---|
| 17:12:00 | 603/854 | Auto-update of 1.37937.3 begins (download from downloads.claude.ai) |
| 17:12:24 | 638 ×2 | "Packages were not updated because affected apps are still running. Running apps: {Claude_pzs8sxrjxfjjc!Claude} …" |
| 17:12:24 | 658 | "Marking package {Claude_1.37937.3.0_x64__pzs8sxrjxfjjc} for deferred registration because {Claude_1.37937.1.0_x64__pzs8sxrjxfjjc} is still running." |
| 17:12:25 | 400 | Add of .3 "finished successfully" — staged, registration deferred |
| ~17:12–18:47 | — | App in broken state for the user; Get-AppxPackage showed Modified, NeedsRemediation; Claude Desktop would not launch |
| 18:47:29 | 400 | Deferred registration of .3 completed successfully |
| 18:53:08 | 717/404 | (recovery attempt) Remove of .3 with PreserveApplicationData failed — 0x80073CFA (flag only valid for dev-mode packages) |
| 18:56:24–29 | 5224 ×3 | "Error while deleting file \\?\C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe. Error Code : 0x5." (during plain Remove of .3, which otherwise succeeded) |
| 19:08:29–35 | 5224 ×14 | Same file, same 0x5 (ERROR_ACCESS_DENIED), during re-Add of 1.37937.1 |
| 19:08:35 | 300 | "error 0x80073CF6: Cannot register the Claude_pzs8sxrjxfjjc package due to the following error: Package could not be registered." |
| 19:08:36 | 401 | "Deployment Add operation … on Package Claude_1.37937.1.0_x64__pzs8sxrjxfjjc … failed with error 0x80073CF6." |
| 19:08:36 | 404 | "…failed … with error 0x80073CF6. The specific error text for this failure is: An internal error occurred with error 0x80073D05." |
| ~19:10 | — | Lock-holding chrome-native-host.exe identified and stopped; locked file moved aside manually |
| 19:12:11 | 503 | "The file system entries for package Claude_pzs8sxrjxfjjc could not be cleaned up after reboot. The package is removed from the purge list." |
| 19:12:23 | 400 | Re-Add of 1.37937.1 succeeds (only after the lock holder was dealt with) |
| 19:13:23 | 638/658 | .3 install deferred again because .1 is now running — the same race repeats within the recovery |
| 19:18:00 | 400 | RegisterByPackageFamilyName with ForceTargetApplicationShutdown → "Deployment Register operation … finished successfully." Package now Status: Ok. |

The same 638/658 deferral pattern also fired on 2026-08-25 at 15:30 and 20:53 — every recent update on this machine has gone through deferred registration because the updater stages while the app runs.

Defect 1 — updater/uninstaller race with the package's own surviving processes

chrome-native-host.exe runs from the package's application data (LocalCache\Roaming\Claude\ChromeNativeHost\), is spawned on behalf of Chrome, and does not exit when the Claude Desktop window is closed. Nothing in the update path quiesces it (or, per public reports, CoworkVMService lock handles) before AppX tries to replace/clean package data. Result: a file the package itself deployed blocks the package's own servicing, and the failure repeats deterministically until a human identifies the PID. Note event 5224's access-denied is logged as Win32 0x5; the AppX operation surfaces it as 0x80073D05/0x80073CF6.

Ask: the desktop app (or its updater) should enumerate and stop its own helper processes — native messaging host, tray, utility processes — before update/repair/uninstall, or the native host should be installed outside the AppX-managed application data it can deadlock.

Defect 2 — winget repair false positive

While the package was in Modified, NeedsRemediation, winget repair for Anthropic.Claude reported success without remediating; the package remained broken and the app still would not launch. Whatever remediation hook runs there does not verify resulting package status. This wastes significant diagnostic time because the obvious first-line fix "succeeds" while fixing nothing.

Defect 3 — CoworkVMService cannot configure its own recovery actions (pre-existing, every start since at least 2026-04-22)

C:\ProgramData\Claude\Logs\cowork-service.log shows, on essentially every service start (112 matching lines from 2026-04-22 through 2026-08-26 on this machine):

Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.

(older builds: Warning: failed to open service for recovery config: Access is denied.; there is also an on-stop variant failed to disarm recovery actions for this stop). sc.exe qfailure CoworkVMService confirms the result: no failure actions configured (RESET_PERIOD 0, no restart actions). The service's own log states the consequence: a crash leaves Cowork down until reboot or manual restart.

Why the runtime attempt can never succeed (verified on this machine): CoworkVMService is a WIN32_PACKAGED_PROCESS (MSIX-managed) service, and its security descriptor is:

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

The only principal holding DC (SERVICE_CHANGE_CONFIG), WD, and WO is S-1-5-80-1949724575-…, which resolves to NT SERVICE\AppXSvc — the AppX Deployment Service. Authenticated Users get start/stop/query only; there is no ACE at all for Administrators or SYSTEM, and although the service's SID type is UNRESTRICTED, its own virtual-account SID is absent from the DACL. Consequently the service's runtime ChangeServiceConfig2 self-call is architecturally unable to succeed, and even an elevated Administrator sc.exe failure CoworkVMService … returns Access denied (verified: exit 5 from an elevated console). Recovery actions for a packaged service can only be set through the AppX servicing pipeline — i.e., this must be fixed in the package/service registration, and end users cannot work around it.

UX gap — dead Remote Control host is invisible after recovery

After the desktop app was repaired, the previously-active Claude Code session showed only "computer unreachable." Its local Remote Control host process had died with the crash and nothing recreated it — which matches documented behavior (https://code.claude.com/docs/en/remote-control: "Local process must keep running"), but nothing anywhere surfaced which session died, that the fix is claude --resume <uuid> from the original working directory, or what the session's UUID/cwd were. Recovery required manually mining ~/.claude/projects transcripts. A "this machine has recently-live sessions with no host process — resume?" affordance in the desktop app would have turned an hour of forensics into one click.

Ongoing residual after recovery

WindowsApps\Deleted staging folders for the superseded versions (1.37937.0.0 and 1.37937.1.0) still contain files Windows cannot delete — Event ID 471, "error 0x12C: Deleting file …\WindowsApps\Deleted\Claude_1.37937.x.0_…\app\v8_context_snapshot.bin failed" — recurring every 5–60 minutes since recovery (113 events in the last 48 h at time of writing). Same symptom family as issue #46179's "stuck WindowsApps\Deleted."

Related public reports (please cross-link / dedup)

• #46179 — Windows Store: Claude desktop fails to update due to CoworkVMService file lock and stuck WindowsApps\Deleted (closed without response; its manual fix already included Stop-Process -Name chrome-native-host -Force)
• #81992 — Claude Desktop repeatedly enters Modified, NeedsRemediation state and fails to launch (open)
• Cluster: #49917 (0x80073CF6 after "successful" install), #48437 (0x80073CF6 on Win11), #47877 (MSIX stuck Staged), #37443 (AddPackage hangs on build 26200), #70700 (Modified/NeedsRemediation after LCU despite deployment success)

Impact

Claude Desktop unusable for ~2 hours mid-workflow; an active Cowork/Claude Code workflow orphaned; recovery required manual AppX/event-log forensics well beyond a typical user. Because updates auto-stage while the app runs and the native host outlives the app, every update on an in-use machine rolls these dice.

Suggested fixes (in priority order)

1. Quiesce all package-family processes (native host, tray, helpers) before servicing; retry once quiesced instead of deferring into a broken half-state.
2. Make the repair path truthful: after repair, assert Get-AppxPackage Status is Ok and report failure otherwise.
3. Configure CoworkVMService failure/recovery actions through the MSIX service registration itself (only NT SERVICE\AppXSvc holds SERVICE_CHANGE_CONFIG on packaged services — no runtime or even elevated-admin path can set them), and remove the every-start runtime warning that can never resolve itself.
4. Desktop UI: detect recently-live local sessions with no host process after a crash/repair and offer one-click resume.
5. Clean up WindowsApps\Deleted leftovers (or document that a reboot is required).

Evidence available on request

• Full Microsoft-Windows-AppXDeploymentServer/Operational export (529 Claude events, 08-25 → 08-27)
• C:\ProgramData\Claude\Logs\cowork-service.log (740 KB, 2026-04-22 → present) + coworkd\user-<sid>.log (side note: the per-user coworkd log stopped being written after the post-repair VM boot even though the console reader re-attached — possible separate flushing bug)
• Get-AppxPackage / sc.exe qfailure / sc.exe sdshow output; Windows Error Reporting MoAppHang record for Claude 1.34493.1.0 on 2026-08-25 (the day before — possibly related instability)

What Should Happen?

The auto-updater should quiesce the app's own helper processes (chrome-native-host.exe, tray) before servicing the package, so an update that starts while Claude is in use completes cleanly instead of leaving the package in Modified/NeedsRemediation with the app unable to launch.

If servicing does fail, winget repair should either actually remediate or report failure — not report success while the package remains broken.

CoworkVMService should ship with recovery actions configured through its MSIX service registration; its runtime attempt can never succeed (see DACL evidence in the report), so today a crashed service stays down until reboot.

After a crash/repair, the desktop app should detect recently-live Claude Code sessions whose local host process died and offer to resume them, instead of showing only "computer unreachable."

Error Messages/Logs

Microsoft-Windows-AppXDeploymentServer/Operational, 2026-08-26:

[17:12:24] Event 638 (Information):
"Packages were not updated because affected apps are still running. Running apps: {Claude_pzs8sxrjxfjjc!Claude}, Directly serviced packages: {Claude_1.37937.1.0_x64__pzs8sxrjxfjjc Claude_1.37937.3.0_x64__pzs8sxrjxfjjc} ..."

[17:12:24] Event 658 (Warning):
"Marking package {Claude_1.37937.3.0_x64__pzs8sxrjxfjjc} for deferred registration because {Claude_1.37937.1.0_x64__pzs8sxrjxfjjc} is still running."

[18:56:24 – 19:08:35] Event 5224 (Warning), 17 occurrences:
"Error while deleting file \\?\C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe. Error Code : 0x5."

[19:08:35] Event 300 (Error):
"error 0x80073CF6: Cannot register the Claude_pzs8sxrjxfjjc package due to the following error: Package could not be registered."

[19:08:36] Event 404 (Error):
"AppX Deployment operation failed for package Claude_1.37937.1.0_x64__pzs8sxrjxfjjc with error 0x80073CF6. The specific error text for this failure is: An internal error occurred with error 0x80073D05."

[19:18 onward, still recurring] Event 471 (Information), every 5–60 min:
"error 0x12C: Deleting file \\?\C:\Program Files\WindowsApps\Deleted\Claude_1.37937.1.0_x64__pzs8sxrjxfjjc<guid>\app\v8_context_snapshot.bin failed."

C:\ProgramData\Claude\Logs\cowork-service.log — every service start since 2026-04-22 (112 lines):
"Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied."

sc.exe qfailure CoworkVMService → no failure actions configured (RESET_PERIOD 0, no restart actions).
sc.exe sdshow CoworkVMService →
D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)
(that S-1-5-80 SID resolves to NT SERVICE\AppXSvc — the only principal holding SERVICE_CHANGE_CONFIG)

Steps to Reproduce

Race condition — occurs when an auto-update lands while the app is in use. Observed end-to-end on 2026-08-26; the deferral precondition (steps 1–3) reproduced on every recent update on this machine (2026-08-25 ×2, 2026-08-26 ×2).

1. Windows 11, Claude Desktop (MSIX) running, Claude in Chrome installed so chrome-native-host.exe is alive (it runs from the package's own application data: ...\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\). An active Cowork / Claude Code session makes the timing realistic.
2. Let the auto-updater stage a new version while the app runs → AppXDeploymentServer logs event 638 ("Packages were not updated because affected apps are still running") + 658 ("Marking package … for deferred registration").
3. Close the Claude window. chrome-native-host.exe does NOT exit with the app (verify in Task Manager).
4. AppX servicing then tries to clean/replace package application data while that process holds its own exe → event 5224 "Error Code : 0x5" repeats (17× in this incident).
5. Deployment fails: events 300/401/404 with 0x80073CF6, inner error 0x80073D05. Get-AppxPackage -Name Claude → Status "Modified, NeedsRemediation". App no longer launches.
6. Run winget repair --id Anthropic.Claude → reports success; package still NeedsRemediation, app still broken (defect 2).

Recovery that worked: identify the chrome-native-host.exe PID holding the file, stop it, move the locked file aside, re-register (RegisterByPackageFamilyName with ForceTargetApplicationShutdown → "finished successfully", Status back to Ok).

The CoworkVMService sub-defect reproduces trivially on any machine: restart the service and read C:\ProgramData\Claude\Logs\cowork-service.log (the recovery-actions warning fires on every start); sc.exe qfailure CoworkVMService shows no failure actions; sc.exe sdshow shows only NT SERVICE\AppXSvc holds SERVICE_CHANGE_CONFIG.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.246 (Claude Code) — CLI unaffected; affected component is Claude Desktop MSIX 1.37937.3.0 (auto-updating from 1.37937.1.0)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

The duplicate detector will flag #80444 and #86509 — related family, NOT duplicates. #80444 is a GPU-process crash flagging the package Modified, with surviving cowork-svc.exe (CoworkVMService) locks blocking remediation; #86509 (closed as dup of #80444) is install-dir self-corruption after web fetch with no update involved. This report is a third, distinct trigger converging on the same two systemic problems: (1) the app's own surviving helper processes hold locks that break MSIX servicing — here chrome-native-host.exe locking LocalCache during an auto-update deferral (events 638/658 → 5224 ×17 → 0x80073D05/0x80073CF6); (2) the remediation paths fail or lie (winget repair reports success while the package stays NeedsRemediation). It also root-causes the CoworkVMService recovery-actions defect: the service DACL grants SERVICE_CHANGE_CONFIG only to NT SERVICE\AppXSvc, so neither the service's own runtime attempt ("Access is denied" on every start since at least 2026-04-22) nor an elevated administrator can ever set failure actions — a crashed service stays down until reboot, per its own log.

Also related: #46179 (closed unanswered; chrome-native-host + service locks blocking a Store update), #81992 (open; recurring Modified/NeedsRemediation).

Full AppXDeploymentServer event export (529 events, 08-25 → 08-27) and cowork-service.log are preserved; I'll attach them via a support ticket referencing this issue rather than posting publicly.