CoworkVMService file lock persists after suspend/resume on Modern Standby (S0) systems; neither Power-Troubleshooter Event ID 1 nor SystemEvents.PowerModeChanged fire on resume

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 the PC suspends and resumes, relaunching Claude Desktop fails with "Another program is currently using this file," referencing a file under the MSIX package path. Root cause traced to cowork-svc.exe (CoworkVMService) holding a lock that a plain taskkill/process-kill does not release — consistent with the file-lock behavior reported in #48787, #49655, and #46179, but triggered by suspend/resume rather than an app update.

Additional finding (may be useful beyond this specific bug): Attempted to build a workaround that auto-restarts the service on resume. Two standard Windows resume-detection mechanisms were tested and neither fired on this Modern Standby system:

Windows Event Log, System channel, source Microsoft-Windows-Power-Troubleshooter, Event ID 1 — task never triggered across multiple confirmed suspend/resume cycles.
.NET SystemEvents.PowerModeChanged (the WM_POWERBROADCAST-based resume notification) — confirmed listener was running before resume; no event fired after resume.

This suggests any internal Anthropic logic for detecting resume-from-sleep (if used to restart CoworkVMService, refresh VM state, etc.) may also be unreliable on Modern Standby hardware, since these are the standard OS-level signals apps use for that purpose.

What Should Happen?

File lock should be released for cleanly closing the Claude's VM

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce:

Install Claude Desktop on Windows via the Microsoft Store/MSIX installer (not the legacy Electron installer).
Ensure Cowork is enabled and has been used at least once, so CoworkVMService is registered and running (cowork-svc.exe).
Confirm the system uses Modern Standby: run powercfg /a in an elevated Command Prompt — it should list Standby (S0 Low Power Idle) as supported and Standby (S3) as not supported.
With Claude Desktop closed (or open), suspend the PC (Start → Power → Sleep, or close the lid if a laptop).
Resume the PC.
Attempt to open Claude Desktop.

Expected result: App opens normally.

Actual result: Error dialog: "Another program is currently using this file", referencing a path under C:\Program Files\WindowsApps\Claude_<version>_....

To confirm the root cause is CoworkVMService:

1. Open Task Manager / PowerShell, and note that cowork-svc.exe is still running after the error appears.
2. Force-killing just claude.exe does not resolve the error; the file lock persists until CoworkVMService itself is stopped (net stop CoworkVMService) and restarted.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.46388.3.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_