Windows MSIX (ARM64): "Relaunch to update" never applies — bundled CoworkVMService keeps the package in-use; update only lands at logon/reboot

Summary

On Windows (ARM64, MSIX/Store install), the Claude desktop app's in-app "Relaunch to update" never applies a staged update. The app relaunches on the same version and the "update available" chip persists. Only a full reboot (or sign-out / sign-in) applies it. This also freezes the bundled Claude Code version until the desktop app updates.

Environment

• Windows 11 ARM64 (Qualcomm Snapdragon, Surface Pro 11)
• MSIX package Claude_<ver>_arm64__pzs8sxrjxfjjc; reproduced across 1.13576.x → 1.15200.0.0 → 1.15962.0.0
• Claude Code runs hosted inside the Claude desktop app

Root cause (diagnosed)

The package declares a LocalSystem Windows service, CoworkVMService (desktop6:Service, Executable=app\resources\cowork-svc.exe, StartAccount=LocalSystem, StartupType=auto; sc qc CoworkVMService → WIN32_PACKAGED_PROCESS, binary path under …\WindowsApps\Claude_<ver>_arm64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe).

Because this service runs from the package directory, it keeps the MSIX package "in use" even after every Claude.exe UI/renderer process exits, so registration of the staged version perpetually defers:

• Microsoft-Windows-AppXDeploymentServer/Operational Event 658: "Marking package {Claude_<new>} for deferred registration because {Claude_<old>} is still running."
• Event 638: "Packages were not updated because affected apps are still running. Running apps: {Claude_pzs8sxrjxfjjc!Claude} …"
• A manual Add-AppxPackage -Register <staged manifest> -ForceApplicationShutdown hangs on the deployment's "PackagesInUseClosed" wait (requires a hard reboot).
• The update only completes via Event 821: "During-logon registration of package Claude_<new> … finished with result: 0x0" at the next sign-in/reboot.

So "Relaunch to update" closes and reopens the UI, but the bundled service is never stopped, the old package stays in-use, and registration never lands.

Steps to reproduce

1. On Windows ARM64 with the MSIX Claude desktop, let an update stage (the "Relaunch to update" chip appears; Get-AppxPackage Claude shows the old version while a newer Claude_<new>_arm64__… folder exists under WindowsApps).
2. Click Relaunch to update.
3. Observe: the app reopens on the same version; the update chip is still shown.
4. Get-Service CoworkVMService → Running, binary path inside the package dir.
5. Only a reboot, or a sign-out / sign-in (logon-time registration), applies the update.

Expected

"Relaunch to update" should apply the staged update without requiring a reboot or sign-out.

Suggested fix

During the update/relaunch, stop the packaged CoworkVMService (and any packaged service) before triggering registration, then restart it for the new version — or perform the registration through the same path the logon-time SYSTEM registration uses (which succeeds because nothing is running).

The service's DACL grants Authenticated Users SERVICE_STOP/SERVICE_START, so the updater can stop/start it without elevation. Once it's stopped (plus the UI processes closed), Add-AppxPackage -RegisterByFamilyName -MainPackage Claude_pzs8sxrjxfjjc applies the staged version cleanly.

Impact

• Users cannot update Claude desktop (or the bundled Claude Code) without a reboot.
• The "update available" UI is misleading — clicking "Relaunch to update" appears to do nothing.

---
Note: this is technically a Claude desktop app bug, filed here because it's the only public Anthropic tracker and it directly affects Claude Code users (the bundled claude-code version cannot update until the desktop host does).