[BUG] Windows: update leaves package in deferred-registration loop; app unlaunchable ("Another program is currently using this file") until sign-out or reboot

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?

After an in-app update of Claude Desktop on Windows (1.18286.2.0 to 1.19367.0.0), the app becomes unlaunchable. Every launch attempt shows the Windows dialog "Another program is currently using this file" pointing at C:\Program Files\WindowsApps\Claude_1.19367.0.0_x64__pzs8sxrjxfjjc\... and the app never starts.

Root cause visible in the AppXDeploymentServer/Operational event log: the update is stuck in a deferred-registration loop. Windows believes the old package (1.18286.2.0) is "still running" even with zero Claude processes alive, because cowork-svc.exe respawns via its Windows service and chrome-native-host.exe respawns via Chrome (it runs from %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost). Registration of the new version defers, and each subsequent activation resumes the pending deployment, which opens the exe exclusively and races the user's own launch, producing the sharing violation. The deployment then fails on orphaned package folders left over from two earlier updates (1.13576.4.0 and 1.15962.0.0 were still in WindowsApps but no longer in the package repository) and on a pre-launch service notify error, stays pending, and the loop repeats on every launch.

Sysinternals handle64 shows zero open handles on the package at rest, consistent with the lock existing only during activation.

Extensive elevated cleanup did NOT fix it: killed every process by path (WindowsApps\Claude, Packages\Claude_, cowork-svc, chrome-native-host), stopped CoworkVMService, wsl --shutdown, deleted the three orphaned WindowsApps folders (takeown + icacls + remove), confirmed only 1.19367 registered for a single user, re-registered via Add-AppxPackage -Register AppxManifest.xml -DisableDevelopmentMode -ForceApplicationShutdown (succeeded), and restarted AppXSVC. Activation was still blocked, so the stuck state persists as a pending operation in the State Repository.

Workaround that finally resolved it without reboot: after the cleanup above, a Windows sign-out and sign-in completed the stuck registration and the app launched normally.

What Should Happen?

The updater should quiesce cowork-svc.exe and chrome-native-host.exe (or not depend on their exit) so registration completes without deferral, should clean up superseded package folders in WindowsApps instead of leaving orphans, and should never leave the app in a state where it cannot launch until sign-out or reboot.

Error Messages/Logs

Launch dialog (screenshot attached):
"Another program is currently using this file."
Title path: C:\Program Files\WindowsApps\Claude_1.19367.0.0_x64__pzs8sxrjxfjjc\...

AppXDeploymentServer/Operational log at launch time:
1) "Marking package {Claude_1.19367.0.0_x64__pzs8sxrjxfjjc} for deferred registration because {Claude_1.18286.2.0_x64__pzs8sxrjxfjjc} is still running."
2) "These hardlinks did not have packages in repository: \Program Files\WindowsApps\Claude_1.15962.0.0_x64__pzs8sxrjxfjjc\app\chrome_100_percent.pak; \Program Files\WindowsApps\Claude_1.13576.4.0_x64__pzs8sxrjxfjjc\app\chrome_100_percent.pak; ..."
3) "error 0x80070015: Unable to notify pre-launch service for app Claude_pzs8sxrjxfjjc!Claude install/uninstall."

Steps to Reproduce

1. Windows 11 with Claude Desktop (MSIX), Cowork enabled, Claude in Chrome extension installed, Chrome running.
2. Let the app perform an in-app update (here: 1.18286.2.0 to 1.19367.0.0), then close and relaunch Claude.
3. Launch fails with "Another program is currently using this file." Every retry fails the same way.
4. Killing all Claude processes, deleting stale locks, removing orphaned WindowsApps folders, and re-registering the package does not unblock activation.
5. Only sign-out/sign-in (or reboot) completes the deferred registration and restores launch. Recurs on subsequent updates.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

1.18286.2.0 (ran fine once launched; the failure occurs in the update transition to 1.19367.0.0)

Claude Code Version

Claude Desktop 1.19367.0.0 (MSIX, publisher hash pzs8sxrjxfjjc)

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Unclear if this is a regression or not. The symptom has occurred across multiple recent updates (previously resolved each time by reboot), and orphaned folders from versions 1.13576.4.0 and 1.15962.0.0 indicate earlier updates also failed to finalize cleanly.

Diagnostics performed with Sysinternals handle64 and Listdlls (no holders at rest), Get-AppxPackage -AllUsers (only 1.19367 registered, single user, Installed), and the AppXDeploymentServer/Operational event log quoted above.

Suggested fix directions: have the updater stop/notify the Cowork service and the Chrome native messaging host before finalizing; remove superseded WindowsApps folders on successful update; surface a "sign out to finish updating" prompt instead of the raw sharing-violation dialog.

Related issues: #42776, #41743