[BUG] [Windows] Idle "stealth update" quits Claude Desktop, then MSIX re-registration fails at windows.fileTypeAssociation (0x80070005 → 0x80073CF6) — app left unlaunchable until reinstall

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?

This is a Claude Desktop (Windows, MSIX) bug, not a Claude Code CLI bug — filing here since
this repo tracks area:desktop issues (see #83932, #75337).

Claude Desktop closes itself while idle to apply a staged update, and then never comes back.
Windows fails to register the staged MSIX package, the rollback to the previous version fails
too, and the package family is left half-registered. Clicking the icon after that produces
no window, no error dialog, and no log line at all — only a reinstall (or a manual
Add-AppxPackage -Register) brings the app back.

It happened 4 times in ~31 hours (2026-09-03 → 2026-09-04), each on a different version bump.
Because the app quits silently while idle, I only noticed hours later: one outage lasted
10 h 47 m (quit 09-04 09:51, back 09-04 20:38).

The registration always fails at the same place:

AppxManifest.xml(111,10): error 0x80070005: Cannot register the
Claude_1.46388.2.0_x64__pzs8sxrjxfjjc package because the following error was encountered
while registering the windows.fileTypeAssociation extension: Access is denied.

Manifest line 111 is the windows.fileTypeAssociation extension (the "documents" association
for .csv/.xlsx/.pdf/.docx/.png/…).

Contributing factor: CoworkVMService / cowork-svc.exe is declared in the same MSIX package
(windows.service, StartupType=auto, LocalSystem) and keeps running after the app quits, so
the old package is still "in use" when deployment runs:

Marking package {Claude_1.46388.2.0_x64__pzs8sxrjxfjjc} for deferred registration
because {Claude_1.46388.1.0_x64__pzs8sxrjxfjjc} is still running.

Ruled out: not a crash (Crashpad reports dir is empty; every shutdown is the clean
beforeQuitForUpdate path), not memory/disk (3.7 GB RAM and 22.5 GB disk free at the time),
not antivirus (Defender only, Controlled Folder Access off), not file-association ACLs
(HKCU\Software\Classes\.{csv,xlsx,pdf,docx,…} and Explorer\FileExts are all user-writable
with no Deny ACEs), not policy (no DefaultAssociationsConfiguration GPO).

What Should Happen?

The stealth update should either complete and relaunch the app (as it did on 2026-09-02,
where quit at 03:15:31 and relaunch at 03:15:37 took 6 seconds), or fail safely — leaving
the previous working version registered and telling the user something went wrong.

Instead the app quits itself, both the new and the old package fail to register, and the
user is left with a dead icon and no indication that an update failed or that a reinstall
is needed.

Error Messages/Logs

=== %LOCALAPPDATA%\Claude\logs\main.log — the self-quit (every incident looks like this) ===
2026-09-04 23:37:02 [info] [stealth-update] Triggering stealth update after idle timeout
2026-09-04 23:37:02 [info] [stealth-relaunch] Saved navigation history (2 entries, active=1)
2026-09-04 23:37:02 [info] [CCD] Killing 1 PTY process tree(s) on quit
2026-09-04 23:37:03 [info] beforeQuitForUpdate handler fired, going down for update
2026-09-04 23:37:03 [info] Windows session ending (close-app) - quitting the app
--- app never relaunches; user finds a dead icon and reinstalls ---
2026-09-04 23:45:42 [info] Starting app { appVersion: '1.46388.2', isPackaged: true, platform: 'win32', arch: 'x64' }
2026-09-04 23:45:43 [info] [updater] Version changed since last launch: 1.46388.1 → 1.46388.2
2026-09-04 23:45:43 [info] [event-loop-stall] update relaunch (stale marker) stands in for an unheard suspend

=== main.log — for contrast, the one time it worked (2026-09-02) ===
2026-09-02 03:15:30 [info] [stealth-update] Triggering stealth update after idle timeout
2026-09-02 03:15:31 [info] beforeQuitForUpdate handler fired, going down for update
2026-09-02 03:15:37 [info] [updater] Version changed since last launch: 1.40609.0 → 1.40609.1
2026-09-02 03:15:37 [info] [stealth-relaunch] Detected via marker file (windowVisible=true, ...)
2026-09-02 03:15:37 [info] [stealth-relaunch] Restoring navigation (15 entries, active=14, dropped=0)
2026-09-02 03:15:38 [info] [stealth-relaunch] Restored z-order: our 0x710610 behind anchor 0x5b00c2

=== Windows event log: Microsoft-Windows-AppXDeploymentServer/Operational ===
=== (the 09-04 09:51 incident — 10 h 47 m outage) ===
09-04 09:40:37  658  Warning  Marking package {Claude_1.46388.1.0_x64__pzs8sxrjxfjjc} for deferred
                              registration because {Claude_1.44121.4.0_x64__pzs8sxrjxfjjc} is still running.
09-04 09:51:12  6801 Error    AppxManifest.xml(111,10): error 0x80070005: Cannot register the
                              Claude_1.46388.1.0_x64__pzs8sxrjxfjjc package because the following error was
                              encountered while registering the windows.fileTypeAssociation extension:
                              Access is denied.
09-04 09:51:12  300  Error    error 0x80073CF6: Cannot register the Claude_pzs8sxrjxfjjc package.
09-04 09:51:13  6801 Error    (same error again, now against the OLD package Claude_1.44121.4.0 — rollback)
09-04 09:51:14  401  Error    Deployment Register operation ... failed with error 0x80073CF6
09-04 09:51:14  404  Error    AppX Deployment operation failed for package Claude_1.46388.1.0 with 0x80073CF6
09-04 11:09:55  323  Error    error 0x80070490: Cannot register Claude_1.44121.4.0 ... element not found
09-04 11:09:55  751  Warning  Windows failed to undo changes with error code 0x80073CF6 to package
                              Claude_1.44121.4.0_x64__pzs8sxrjxfjjc. The package needs to be reinstalled.
09-04 15:22:17  6801 Error    (retried automatically hours later, same failure)

=== later the same day, during recovery attempts ===
09-04 21:39:31  419  Error  error 0x80073D02: Unable to install because the following apps need to be
                            closed Claude_1.46388.1.0_x64__pzs8sxrjxfjjc.
09-04 21:49:05  717  Error  Windows cannot remove Claude_1.46388.1.0_x64__pzs8sxrjxfjjc because the
                            PreserveApplicationData flag can only be used on a package that was deployed
                            in development mode.  (0x80073CFA — same as #83932)

=== long-running debris, repeating daily for weeks ===
471  Information  error 0x12C: Deleting file \\?\C:\Program Files\WindowsApps\Deleted\
                  Claude_1.37937.0.0_x64__pzs8sxrjxfjjc<guid>\app\icudtl.dat failed.
1230 Warning      These hardlinks did not have packages in repository:
                  \Program Files\WindowsApps\Claude_1.21459.3.0_x64__pzs8sxrjxfjjc\app\chrome_100_percent.pak; ...

Steps to Reproduce

1. Install Claude Desktop on Windows 11 x64 as the MSIX package (family Claude_pzs8sxrjxfjjc).

CoworkVMService is installed by the package and runs as LocalSystem with StartupType=auto.

1. Leave the app running and idle while a new version is published, so the app stages an

update and triggers its own idle "stealth update" (main.log:
"[stealth-update] Triggering stealth update after idle timeout").

1. The app quits itself ("beforeQuitForUpdate handler fired, going down for update").

CoworkVMService / cowork-svc.exe keeps running, so AppX marks the staged package for
deferred registration (event 658).

1. Deferred registration then fails: event 6801, AppxManifest.xml(111,10) error 0x80070005 on

the windows.fileTypeAssociation extension → deployment fails 0x80073CF6 (events 401/404).

1. The rollback re-registration of the previous version fails the same way; event 751:

"The package needs to be reinstalled."

1. Click the Claude icon in the Start Menu / taskbar → nothing happens. No window, no error

dialog, and no new lines in main.log.

1. Reinstalling the app (or running

Get-AppxPackage -Name Claude | ForEach-Object { Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppxManifest.xml" })
restores it — until the next update, when the cycle repeats.

Observed 4 times in 31 hours (self-quit → next successful start):
09-02 03:15:31 → 03:15:37 6 s 1.40609.0 → 1.40609.1 (the one time it worked)
09-03 06:27:20 → 08:43:20 2 h 16 m 1.40609.1 → 1.44121.2
09-03 16:43:33 → 18:39:32 1 h 56 m 1.44121.2 → 1.44121.4
09-04 09:51:11 → 20:38:08 10 h 47 m 1.44121.4 → 1.46388.1
09-04 20:50:09 → 21:49:08 59 m 1.46388.1 (unchanged)
09-04 23:37:03 → 23:45:42 8 m 1.46388.1 → 1.46388.2

At 09-03 18:39:32 main.log shows 9 "Starting app" entries within one second, most immediately
followed by "Not main instance, returning early from app ready" — me repeatedly clicking an
icon that does nothing.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Claude Desktop 1.40609.1 (last version the stealth relaunch completed successfully, 2026-09-02)

Claude Code Version

2.1.260 (bundled Claude Code in Claude Desktop 1.46388.2 — the bug is in the Desktop MSIX updater, not the CLI)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Environment

• App: Claude Desktop 1.46388.2 (failures on 1.44121.2 → 1.44121.4 → 1.46388.1 → 1.46388.2)
• Install: MSIX, package family Claude_pzs8sxrjxfjjc, SignatureKind: Developer
• Electron 42.10.0 / Chrome 148.0.7778.280 / Node 24.18.1
• OS: Windows 11 Enterprise 10.0.26200 (build 26100), x64, locale zh-TW
• Hardware: Ryzen 5 2400G, 15 GB RAM, 22.5 GB free on C:
• Security: Windows Defender only, Controlled Folder Access off, no third-party AV
• Policies: no DefaultAssociationsConfiguration GPO, no Explorer policies

Why this differs from the existing "won't relaunch after update" reports

Existing reports (#40645, #42776, #45896, #51954, #75337, #88586) describe a user-initiated
"Restart to update" failing with a visible error ("Another program is currently using this
file", "Another copy of Claude is already running"). Here:

1. The quit is unattended — nobody clicked anything; the app closed itself while idle.
2. There is no error surface at all: no window, no dialog, no log line. Nothing tells the

user an update failed or that a reinstall is needed.

1. The failure point is windows.fileTypeAssociation / 0x80070005, which I could not find in

#49655, #75337, #83932 or #53247 — those cite 0x80073CF9, 0x80073D02, 0x80070020
(sharing violation on cowork-svc.exe) or 0x80070015.

1. The rollback fails too, so the machine isn't left on the old working version — it's left

on nothing.

Suggested fixes

1. Don't quit for a stealth update while the package's own service still holds the package.

Stop/quiesce CoworkVMService + cowork-svc.exe (and chrome-native-host.exe) as part of
beforeQuitForUpdate, or skip the stealth update if they can't be stopped.

1. Verify the relaunch happened. The app already writes a relaunch marker and detects it as

stale on the next start ("update relaunch (stale marker)"). A stale marker means the update
demonstrably failed — surface it instead of logging it as an aside.

1. Fail safe, not dark. If registration fails, re-register the previous version and leave the

user on a working app; if that's impossible, leave something visible (toast / launcher stub)
explaining what happened, instead of a dead icon.

1. Stop using PreserveApplicationData on non-development packages in the recovery path — it

can only ever fail with 0x80073CFA (also reported in #83932).

1. Clean up WindowsApps\Deleted\Claude_* leftovers and stale hardlink entries; they accumulate

for weeks and show up in every deployment run.

Workaround for other users

Re-registering is much faster than reinstalling and preserves data:

Get-AppxPackage -Name Claude | ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppxManifest.xml"
}

If that still fails, stop the service first (elevated) and retry:

Stop-Service CoworkVMService -Force
Stop-Process -Name cowork-svc, claude -Force -ErrorAction SilentlyContinue

Signing out of Windows and back in also completes the deferred registration (per #75337).

Related issues

• #83932 — auto-update deploys into running claude.exe + CoworkVMService; app left

unlaunchable; same PreserveApplicationData 0x80073CFA recovery churn (open)

• #75337 — update leaves package in deferred-registration loop, app unlaunchable until

sign-out (closed as duplicate of #53247)

• #49655 — update fails 0x80073CF6 while CoworkVMService is running (closed)
• #53247 — orphaned Silo / Job Object after crash, only logoff or reboot recovers
• #42776 / #88586 / #45896 / #51954 / #40645 — relaunch-after-update failures from orphaned

processes holding the single-instance lock or file locks

How to collect the same diagnostics

Select-String -Path "$env:LOCALAPPDATA\Claude\logs\main.log" `
-Pattern 'stealth-update|beforeQuitForUpdate|Starting app|stale marker'

Get-WinEvent -FilterHashtable @{
LogName='Microsoft-Windows-AppXDeploymentServer/Operational'; Level=1,2,3
} | Where-Object Message -match 'Claude' | Sort-Object TimeCreated |
Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap