[BUG] Windows desktop app fails to launch after sleep/wake: "file in use by another program" (MSIX update blocked by lingering CoworkVMService)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Description

After the PC wakes from sleep, launching the Claude desktop app on Windows sometimes fails with a native error dialog:

このファイルはほかのプログラムで使われています。(This file is being used by another program.)

reported from C:\Program Files\WindowsApps\Claude_2.2553.1.0_x64__.... The app cannot start at all. A full PC restart reliably fixes it until it recurs after a later sleep cycle.

Root cause (from Windows Event Log investigation)

The Microsoft-Windows-AppXDeploymentServer/Operational log shows a repeating pattern across several version bumps (1.52386.x → 2.110.x → 2.2553.x):

Warning (Id 658): {Claude_<old version>} is still running, marking package {Claude_<new version>} for deferred registration.
Error   (Id 728, 0x80070015): Unable to notify pre-launch service for install/uninstall of app Claude_pzs8sxrjxfjjc!Claude / !SshProxy / !SshAskpass.
Error   (Id 404/401/419, 0x80073D02): Deployment failed — the following app must be closed before it can be installed: Claude_<old version>.

In parallel, the CoworkVMService (binary: ...\app\resources\cowork-svc.exe, the background service backing the Cowork/sandbox VM feature) repeatedly logs to the Application log:

Warning: Claude VM Service: failed to configure SCM recovery actions; if the service crashes it will not restart until the machine reboots: open service: Access is denied.
Warning: Claude VM Service: failed to disarm SCM recovery actions for this stop; ... service may be auto-restarted during package servicing: open service: Access is denied.

with the service stopping/starting in a tight loop (observed multiple restarts within the same minute).

Hypothesized mechanism

1. The app auto-updates in the background. If the previous version's process or CoworkVMService is still holding file handles, MSIX registration of the new package is deferred instead of completing.
2. Windows attempts to finish this deferred package registration on resume from sleep.
3. If CoworkVMService/leftover processes still hold locks on package files at that moment, the resume-time registration attempt surfaces to the user as the native "file in use by another program" dialog, and the app fails to launch entirely.
4. A full reboot clears all handles, letting the deferred registration finish, which is why restarting "fixes" it until the next sleep/update cycle.

What Should Happen?

The app should update cleanly without leaving the package in a "deferred registration" state, and/or CoworkVMService should release its file handles and shut down cleanly during package servicing so a sleep/wake cycle never surfaces a blocking "file in use" dialog on next launch.

Error Messages/Logs

AppXDeploymentServer/Operational, Id 658:
{Claude_2.2553.0.0_x64__pzs8sxrjxfjjc} is still running, marking package {Claude_2.2553.1.0_x64__pzs8sxrjxfjjc} for deferred registration.

AppXDeploymentServer/Operational, Id 728:
Error 0x80070015: Unable to notify pre-launch service for install/uninstall of app Claude_pzs8sxrjxfjjc!SshProxy / !SshAskpass / !Claude.

AppXDeploymentServer/Operational, Id 404/401/419:
Error 0x80073D02: Cannot install because the following app must be closed: Claude_<previous version>.

Application log, ProviderName=CoworkVMService:
"Claude VM Service: failed to configure SCM recovery actions; if the service crashes it will not restart until the machine reboots: open service: Access is denied."
"Claude VM Service: failed to disarm SCM recovery actions for this stop; if the stop overruns, the service may be auto-restarted during package servicing: open service: Access is denied."

Steps to Reproduce

1. Use the Claude desktop app on Windows normally (with the Cowork/sandbox feature available, i.e. CoworkVMService present and set to Automatic startup).
2. Let the app sit while a background auto-update becomes available/pending.
3. Put the PC to sleep, then wake it.
4. Attempt to launch Claude from the Start menu / taskbar.

Result (intermittent, not every cycle): native dialog "このファイルはほかのプログラムで使われています。" (this file is being used by another program), and the app does not start.

Workaround: Restart the PC. This releases all handles and lets the deferred MSIX registration complete, after which the app launches normally again — until the next sleep + update cycle.

Claude Model

Not applicable (fails before the app UI loads)

Is this a regression?

Unknown — observed across multiple recent versions (1.52386.x through 2.2553.1.0), so likely a longstanding issue in the update/service lifecycle rather than a single-version regression.

Last Working Version

N/A — recurs across versions

Claude Code Version

2.2553.1.0 (Claude desktop app); bundled Claude Code CLI 2.1.275

Platform

Windows

Operating System

Windows 11 Pro (10.0.26200)

Terminal/Shell

N/A (desktop app launch failure, occurs before any terminal/session starts)

Additional Information

Diagnosed via PowerShell Get-WinEvent against the Application and Microsoft-Windows-AppXDeploymentServer/Operational logs. Happy to pull additional log excerpts (e.g. C:\ProgramData\Claude\Logs\cowork-service.log) if useful for reproduction.