Cowork: yukonSilver marked unsupported on Precision 3680 (i7-14700) with Hyper-V active

System Information

| Detail | Value |
|--------|-------|
| CPU | Intel Core i7-14700 |
| System | Dell Precision 3680 Tower |
| OS | Windows 11 Pro 23H2, Build 22631.6199 |
| BIOS | Dell 1.12.0 (2025-02-03) |
| Claude Desktop | v1.1.6041 |
| Architecture | win32/x64 |

Problem

Cowork tab is grayed out. The yukonSilver VM configuration is classified as unsupported, preventing the VM bundle from downloading.

Virtualization Status (all healthy)

Windows Optional Features (all enabled):

• Microsoft-Hyper-V (all sub-features): Enabled
• VirtualMachinePlatform: Enabled
• HypervisorPlatform: Enabled
• Containers: Enabled

bcdedit: hypervisorlaunchtype = Auto

CoworkVMService: Running (StartType: Automatic)

WSL2: Functional (confirms hypervisor is working)

systeminfo: "A hypervisor has been detected. Features required for Hyper-V will not be displayed."

Root Cause

WMI reports all three CPU virtualization properties as False:

(Get-CimInstance Win32_Processor).VirtualizationFirmwareEnabled    # False
(Get-CimInstance Win32_Processor).SecondLevelAddressTranslationExtensions  # False
(Get-CimInstance Win32_Processor).VMMonitorModeExtensions          # False

This is expected Windows behavior. When the Hyper-V hypervisor is running, it sits between the OS and the hardware. Windows can no longer directly query the CPU's VT-x flags, so WMI returns False. The systeminfo output confirms this: it says "A hypervisor has been detected" and declines to show the raw hardware capabilities.

The isHardwareVirtEnabled() check in cowork-svc.exe appears to rely on these WMI values, which creates a catch-22: Cowork needs Hyper-V to run its VM, but enabling Hyper-V causes the detection check to fail.

Log Evidence

cowork_vm_node.log shows 662 lines of the same pattern, continuously since 2026-02-19:

2026-02-19 10:53:54 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-02-19 10:54:25 [warn] [startVM] VM not supported (win32/x64), skipping
2026-02-19 10:54:25 [error] [Callbacks] Swift VM addon not available for callbacks

The reason field from EPt() (e.g., hardware_virt_disabled) is never written to the log, making diagnosis from logs alone impossible.

Suggested Fix

Instead of relying on WMI VirtualizationFirmwareEnabled (which is unreliable under an active hypervisor), the detection could check:

1. Whether the Hyper-V hypervisor is running (hypervisorlaunchtype = Auto in bcdedit, or Win32_ComputerSystem.HypervisorPresent)
2. Whether the required Windows features are enabled (Get-WindowsOptionalFeature)
3. Whether CoworkVMService is running

Any of these would correctly identify this system as capable.

Related Issues

#25136, #27357, #30997, #32004