Enabling Cowork (VirtualMachinePlatform) breaks Windows Sleep/wake — system hangs on resume, requires hard reset

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?

Since enabling Cowork, this machine no longer wakes from Sleep. The power light cycles normally and fans spin up as expected during a wake attempt, but the display stays blank and the system never becomes responsive. A hard power-cycle is required every time. This started immediately after Cowork was enabled and had never happened before.

What Should Happen?

Sleep/wake should continue to function normally after Cowork is installed and enabled, as it did before.

Error Messages/Logs

Steps to Reproduce

1. Enable Cowork on a Windows 10 Pro machine (this enables the VirtualMachinePlatform optional feature).
2. Let the machine Sleep (automatically or manually).
3. Attempt to wake it — fans/power light behave normally, but the system never becomes responsive and requires a hard reset.

Diagnostic steps taken:

1. powercfg /lastwake -> "Wake History Count - 0". No successful wake has ever been recorded, consistent with the resume sequence hanging rather than completing.
2. Get-WinEvent on the System log showed the Windows hypervisor loading on every boot ("Hypervisor successfully started", Id 1), and two Kernel-Power Id 41 events ("system has rebooted without cleanly shutting down first") within roughly 45 minutes on the same morning, each immediately followed by a fresh boot - i.e. two hard resets from hung wake attempts in under an hour.
3. Get-WindowsOptionalFeature -Online showed VirtualMachinePlatform: Enabled, HypervisorPlatform: Disabled, Microsoft-Hyper-V-All: not installed. So only the lightweight virtualization feature that Cowork's Windows backend depends on (per Anthropic's Cowork architecture docs, which describe Hyper-V-based isolation on Windows) is active.
4. Disabled VirtualMachinePlatform (Disable-WindowsOptionalFeature) and rebooted as a test: sleep/wake still failed. This suggests the hypervisor may also be getting forced on by something independent of Cowork's own feature flag - a "Secure Trustlet" (lsaiso.exe) event appears on every boot, the signature of Virtualization-Based Security / Credential Guard, so there may be a compounding or alternate cause.
5. Re-enabled VirtualMachinePlatform to restore Cowork (confirmed working via a basic shell command in the Cowork sandbox), and worked around the sleep issue by switching to manual Hibernate. Hibernate resume works reliably; Sleep does not.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A — this is Claude Desktop (Cowork mode), not the Claude Code CLI. Issue is with Cowork's Windows VM backend (VirtualMachinePlatform), not a CLI version regression.

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

This matches a well-documented general Windows issue, independent of Cowork: enabling "Virtual Machine Platform" is known to break Sleep/Modern Standby wake on a meaningful slice of hardware (see microsoft/WSL#5690, where users report identical symptoms — fans spin, screen stays black, hard reset required — after enabling Virtual Machine Platform, notably on AMD systems). Since Cowork enables this feature silently as part of setup, it may be worth:

• Warning users during Cowork setup that this is a known class of conflict on some hardware
• Investigating whether Cowork's VM truly requires the full VirtualMachinePlatform feature versus a narrower configuration
• Looking into whether Cowork's VM/hypervisor session is suspended/torn down cleanly before host Sleep, since the issue is consistent with reports of VM software not releasing host resources (network adapters, power assertions) cleanly going into Sleep

Workaround currently in place: manual Hibernate (powercfg /hibernate on, standby/hibernate auto-timeouts set to 0, ShowHibernateOption registry flag set so it appears in the Start menu). Hibernate resume works reliably; Sleep does not.

Related: #62645 reports a different symptom on similar AMD hardware (Hyper-V/VirtualMachinePlatform causing boot failure / missing vmms service) — not a duplicate of this sleep/wake hang, but likely the same underlying AMD + VirtualMachinePlatform sensitivity. Happy to provide additional Event Viewer exports if useful.