[BUG] Cowork HRESULT 0x80370102 fires with no observable Hyper-V/HCS activity — likely a pre-flight check issue, not an actual hypervisor failure

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?

[BUG] Cowork HRESULT 0x80370102 fires with no observable Hyper-V/HCS activity — likely a pre-flight check issue, not an actual hypervisor failure

Summary

Cowork fails to start its workspace with:

Claude's workspace failed to start with HRESULT 0x80370102 (hypervisor not running). Hardware virtualization (Intel VT-x or AMD-V) is disabled in this device's firmware...

I have ruled out every cause the error message and related issues (#59035, #60371) point to. Process Monitor traces covering the actual workspace-launch attempt show zero interaction with vmcompute.exe, vmms.exe, vmwp.exe, any HCS object, hvsocket, or any named pipe / local network call that could be a provisioning request — meaning the error appears to fire without Claude Desktop ever making an OS-level call toward Hyper-V on this machine. This points away from "virtualization is actually broken" and toward the app's own pre-flight check being wrong.

System

• Windows 11 Pro, Build 26100 (24H2)
• ASUS ROG STRIX B550-F GAMING WIFI II, BIOS 2.20.1271 (AMI, 2025)
• AMD Ryzen 7 5800X3D
• Claude Desktop MSIX 1.21459.0.0

Diagnostics performed (all clean / not the cause)

1. BIOS: SVM Mode = Enabled, NX Mode = Enabled (screenshots available). This rules out the fix that resolved #59035 for other users — that was a different root cause than mine.
2. msinfo32: "A hypervisor has been detected." Virtualization-based security: Running.
3. DISM: Hyper-V, Microsoft-Hyper-V-Hypervisor, Microsoft-Hyper-V-Services all report State: Enabled.
4. Services: vmms and vmcompute both Running.
5. Driver files: vid.sys and vmswitch.sys both present on disk.
6. BCD: Clean config, hypervisorlaunchtype: Auto.
7. WDAC / Application Control: CiTool.exe -lp -json shows only Microsoft's default built-in system policies (VerifiedAndReputableDesktop, Windows Driver Policy, VBS Policy, Endpoint Security Policy, Cross Certificates policies) — standard on any current Windows 11 24H2 install, not a custom enterprise lockdown. CodeIntegrity operational log shows only routine policy-refresh events (3099/3116) at boot, no block/audit events (3076/3077) correlated with a Cowork launch attempt.
8. Clean reinstall of Claude Desktop, 20+ restarts.

Process Monitor evidence (the key finding)

Capture taken, filtered on Process Name contains claude and Process Name contains cowork:

• Capture (~262k events, ~100s): spans an actual workspace-launch attempt. This is confirmed by a new session-specific folder (local_<guid>) being created and its .claude.json polled once per second for the full capture, with no forward progress — consistent with the app waiting on a workspace that never finishes initializing.

Searching for vmcompute, vmms.exe, vmwp.exe, HCS, hvsocket, \Device\Vid, RPC/ALPC endpoints (RPC Control, ncalrpc), and any named pipe or TCP/UDP connection to a local service: no matches. Whatever produces the HRESULT 0x80370102 / "hypervisor not running" message does not appear to touch the file system, registry, or network in a way that would indicate it queried the actual Hyper-V state on this machine.

Suggestion for engineering

Given the above, I'd ask that the check producing this error be reviewed directly rather than assuming it's another BIOS/OS environmental issue:

1. Is virtualization capability determined via a live call (e.g., WinHvPlatform/HCS API, or Win32_ComputerSystem.HypervisorPresent), or via a cached flag set at install time / first run that isn't being refreshed?
2. If it's a live call, what mechanism does it use? My traces suggest it isn't going through any Win32 API that Process Monitor would observe under File System, Registry, or Network — worth confirming whether it's a pure in-process check (e.g., a bundled native module returning a hardcoded result) that could be wrong independent of actual host state.
3. As raised in #60371, distinguishing "Hyper-V not installed" from "Hyper-V installed and running, but Cowork's pre-flight check failed for another reason" in the UI would help users self-diagnose instead of chasing BIOS settings that are already correct.

What Should Happen?

Cowork should run without the Virtualization error.

Error Messages/Logs

Steps to Reproduce

Install Claude Desktop.
Open a Cowork session in Claude Desktop.
See 'pop up error': Virtualization is not available
Claude’s workspace requires hardware virtualization. Enable virtualization in your computer’s BIOS/UEFI settings, then restart.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.209

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_