[BUG] Interrupted auto-update leaves MSIX in Servicing/Staged state (AddPackage times out after 5 min); orphaned CoworkVMService undeletable via SCM even as SYSTEM
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 a routine auto-update ("Relaunch Claude to update"), Claude Desktop never relaunched
and could not be repaired, uninstalled, or reinstalled. Recovery ultimately required manual
AppX package removal after a reboot PLUS manual registry deletion of the leftover
CoworkVMService key. Full troubleshooting transcript: https://claude.ai/share/0c51c8bc-0c36-4609-80e8-99b4bc293313
Root state found
Two package registrations coexisting:
Name : Claude
PackageFullName : Claude_1.22209.3.0_x64__pzs8sxrjxfjjc
Status : Ok
PackageUserInformation : {S-1-5-21-... [VIVOEHL\EduardoLeitner]: Installed}
Name : Claude
PackageFullName : Claude_1.24012.1.0_x64__pzs8sxrjxfjjc
Status : Servicing
PackageUserInformation : {S-1-5-18 [S-1-5-18]: Staged}
The update transaction (1.24012.1.0) was stuck in Servicing/Staged under SYSTEM. While in
this state:
- The installed app would not launch
- Repair and uninstall failed
- Fresh installer runs failed with "AddPackage failed: AddPackage timed out after 5 minutes"
(running Claude Setup.exe as administrator made no difference; the follow-up dialog
"Administrator access is required..." is misleading — the blocker was the pending transaction)
- Remove-AppxPackage from elevated PowerShell also hung indefinitely (AppXDeploymentServer
event log went silent seconds after the call — queued behind the wedged transaction)
Recovery steps that worked
- Reboot → Get-AppxPackage -AllUsers Claude | Remove-AppxPackage -AllUsers
(both packages removed instantly post-reboot; hung indefinitely pre-reboot)
- Leftover CoworkVMService then blocked cleanup:
- sc.exe delete from elevated PowerShell: "[SC] OpenService FAILED 5: Access is denied."
- sc.exe delete run as SYSTEM (via scheduled task): also failed to remove it
- Service registry key showed PackageFullName = Claude_1.22209.3.0... and PackageOrigin = 5
(MSIX packaged service), ImagePath pointing at the already-deleted WindowsApps folder,
no DeleteFlag set
- Only manual deletion of HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService via
regedit (key ACL was standard; Administrators already owner with Full Control) + reboot
removed it
- Fresh Claude Setup.exe (non-elevated, accepting UAC) then installed successfully in seconds.
Suggested installer improvements
- Detect a package stuck in Servicing/Staged state and offer/perform rollback instead of
letting AddPackage queue for 5 minutes and time out
- When package removal is required, remove the packaged CoworkVMService through the
deployment stack rather than the SCM, so it isn't orphaned (the SCM path is access-denied
by design for MSIX packaged services)
- Fix the "Administrator access is required" dialog — it appears even when elevation is not
the problem
Environment:
OS: Windows 11 Home x64, Version 25H2, OS Build 26200.8875 (ASUS VivoBook Flip 16)
Old installed version: Claude 1.22209.3.0 (MSIX)
Stuck update version: Claude 1.24012.1.0 (Staged, SYSTEM)
Installer log: C:\Users\eduar\AppData\Local\Temp\ClaudeSetup.log (can attach on request)
Note: same failure signature as #37443 (AddPackage timeout on build 26200.8039);
this machine is on 26200.8875, so the issue persists on current 25H2 cumulative updates —
here triggered by an interrupted auto-update rather than appearing spontaneously.
What Should Happen?
The auto-update should complete atomically: either the new version installs and relaunches,
or the update rolls back and the existing version keeps working. An interrupted update should
never leave the package family wedged in a Servicing/Staged state that (a) prevents the
installed app from launching, (b) blocks repair/uninstall/reinstall, and (c) makes fresh
installer runs time out after 5 minutes at AddPackage.
If a reinstall does require removing the old package, the installer should also remove the
packaged CoworkVMService through the deployment stack, rather than orphaning it in a state
where neither an elevated sc.exe delete nor SYSTEM can remove it via the SCM ("[SC]
OpenService FAILED 5: Access is denied."). Recovery should never require the user to
manually delete HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService in regedit.
Error Messages/Logs
Installer dialog 1:
"Installation failed: AddPackage failed: AddPackage timed out after 5 minutes"
Installer dialog 2 (misleading — same result when running Claude Setup.exe as administrator):
"Administrator access is required to install Claude with full features. You can try again or
install without Cowork. Diagnostic log saved to:
C:\Users\<user>\AppData\Local\Temp\ClaudeSetup.log"
Service removal attempts on the orphaned CoworkVMService:
- Elevated PowerShell: sc.exe delete CoworkVMService
→ [SC] OpenService FAILED 5: Access is denied.
- Same command run as SYSTEM via scheduled task → service persisted, no DeleteFlag set
Stuck package state (Get-AppxPackage -AllUsers *Claude*):
- Claude_1.22209.3.0_x64__pzs8sxrjxfjjc — Status: Ok (Installed, current user)
- Claude_1.24012.1.0_x64__pzs8sxrjxfjjc — Status: Servicing (Staged, S-1-5-18/SYSTEM)
Orphaned service registry values (HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService):
ImagePath : "C:\Program Files\WindowsApps\Claude_1.22209.3.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
(folder already deleted at that point)
Start : 4 (Disabled)
PackageFullName : Claude_1.22209.3.0_x64__pzs8sxrjxfjjc
PackageOrigin : 5
DependOnService : {staterepository}
Steps to Reproduce
Not deterministically triggerable on demand — the initial trigger was a routine auto-update
that was interrupted mid-transaction. However, once the system is in the resulting state,
the installer failure reproduces 100% of the time. Observed sequence:
- Claude Desktop 1.22209.3.0 installed and working (MSIX, Windows 11 Home 25H2,
build 26200.8875).
- In-app update notice appears: "Relaunch Claude to update" (target version 1.24012.1.0).
- Relaunch → Claude never starts again. Reboot does not help.
- Repair and uninstall via Windows Settings both fail.
- System state at this point (the reproducing condition):
- Get-AppxPackage -AllUsers Claude shows TWO registrations:
1.22209.3.0 (Status: Ok, Installed for user) and
1.24012.1.0 (Status: Servicing, Staged under S-1-5-18/SYSTEM)
- Download fresh Claude Setup.exe from claude.ai and run it
→ fails every time: "AddPackage failed: AddPackage timed out after 5 minutes",
followed by the "Administrator access is required..." dialog.
Running Claude Setup.exe as administrator: identical failure.
- Remove-AppxPackage -AllUsers from elevated PowerShell also hangs indefinitely
(AppXDeploymentServer/Operational event log goes silent right after the removal
transaction starts — nothing progresses).
- After reboot, the same Remove-AppxPackage completes in seconds and both packages
are gone — but CoworkVMService remains orphaned (ImagePath pointing into the
deleted WindowsApps folder) and cannot be deleted via sc.exe, even run as SYSTEM
("[SC] OpenService FAILED 5: Access is denied.").
- Only after manually deleting HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService
in regedit and rebooting again does a fresh Claude Setup.exe install successfully
(in seconds, via the normal UAC flow).
For maintainers attempting reproduction: killing the app/updater mid-transaction during
step 2–3, or otherwise staging the new MSIX under SYSTEM without completing registration,
should land the machine in the state at step 5, from which steps 6–7 reproduce reliably.
Claude Model
Not sure / Multiple models
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
1.24012.1
Platform
Other
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
_No response_
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗