claude-code - 💡(How to fix) Fix [BUG] Cowork HRESULT 0x80370102 on Windows 11 Pro 24H2 — Hyper-V fully functional in PowerShell context, fails only via AppContainer HCS call path

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Claude Cowork persistently fails with HRESULT 0x80370102 ("Hyper-V is not installed on the host") despite Hyper-V being fully installed and functional on the host machine.

The failure is exclusive to the AppContainer call path used by the Claude Desktop MSIX package. Identical HCS API calls executed from PowerShell admin context succeed without issue on the same machine, in the same session — which isolates the bug to how the MSIX-packaged Claude Desktop process queries hardware virtualization availability.

Cowork tab displays the user-facing error: "A virtualização não está disponível. O workspace do Claude requer Virtual Machine Platform, mas o serviço de virtualização não está respondendo. Reinicie seu computador para resolver isso." Restarting and reinstalling do not resolve.

What Should Happen?

Cowork should detect that Hyper-V is fully enabled and operational on the host (as confirmed by Get-VMHost, New-VM, and Hypervisor-Admin event logs), provision the VM bundle, and start the workspace successfully — matching the behavior on PCs where Cowork works normally with identical OS build and hardware class.

Error Messages/Logs

From %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\cowork_vm_node.log:

[VM:steps] create_vm_config started
[VM:start] VM boot failed: HCS operation failed: failed to create compute system: HcsWaitForOperationResult failed with HRESULT 0x80370102: {"Error":-2143878910,"ErrorMessage":"Não foi possível iniciar a máquina virtual porque um recurso necessário não foi instalado.","ErrorEvents":[{"Message":"Não é possível criar o sistema 'cowork-vm-124417a5' porque o Hyper-V não está instalado no host.","Provider":"17103e3f-3c6e-4677-bb17-3b267eb5be57","EventId":11008,"Data":[{"Type":"String","Value":"cowork-vm-124417a5"},{"Type":"String","Value":"%%2151088386"},{"Type":"String","Value":"0x80370102"}]}]}
[VM:start] HCS error detected, available=true, missing=[], sentinel=HYPERVISOR_SERVICE_ERROR
[VM:start] Startup failed: Error: HYPERVISOR_SERVICE_ERROR
    at Wji (C:\Program Files\WindowsApps\Claude_1.7196.3.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:468:4728)
[VM:start] Heartbeat restart failed, leaving VM offline (will retry on next app launch)

Note: This error repeats on every Cowork launch. The yukonSilver classification, which previously appeared as "unsupported" in earlier log entries (2026-05-14), now passes after MSIX re-register, but the HCS create-compute-system call still fails.

Steps to Reproduce

Reproduction steps (clean repro on a Windows 11 Pro 24H2 machine):

1. Install Windows 11 Pro 24H2 (Build 26100) on a machine with Intel VT-x enabled in BIOS.

2. Enable required Hyper-V features via PowerShell admin: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All -All Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All Restart.

3. Set hypervisor launch type explicit: bcdedit /set hypervisorlaunchtype auto Restart.

4. Independently confirm Hyper-V is fully operational:

   • Get-VMHost returns full host data (32 logical processors, 64 GB, paths configured)
   • New-VM -Name TestHCS -MemoryStartupBytes 512MB succeeds; Get-VM lists the VM with State=Off, Status="Operando normalmente"; Remove-VM clears it
   • Event log Microsoft-Windows-Hyper-V-Hypervisor-Admin shows Event ID 156 (NUMA policy) on every boot
   • vmms, vmcompute, CoworkVMService all Running

5. Install Claude Desktop v1.7196.3.0 (MSIX from claude.ai/download).

6. Launch Claude Desktop, open Cowork tab.

7. Observe: "Virtualização não está disponível" error displayed permanently.

8. Inspect cowork_vm_node.log → HRESULT 0x80370102 as documented above.

Key diagnostic divergence: the same HCS API that refuses to create cowork-vm via the AppContainer call path accepts and successfully creates VMs via Get-VMHost / New-VM in admin PowerShell context.

Cross-reference to source analysis in issue #27357: the function EPt() in app.asar fails at vs().isHardwareVirtEnabled(), which calls into the native CoworkVMService binary. PowerShell admin-context calls to the same underlying API succeed; AppContainer-context calls fail. The divergence is reproducible.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

N/A — this bug is in Claude Desktop (MSIX), not Claude Code CLI. Claude Desktop version: v1.7196.3.0 (package Claude_1.7196.3.0_x64__pzs8sxrjxfjjc).

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

TROUBLESHOOTING ALREADY PERFORMED (none resolved the issue):

• Full MSIX re-register via Add-AppxPackage -Register against AppxManifest.xml
• Complete deletion of vm_bundles using cmd /c rd /s /q (note: Remove-Item -Force silently fails on MSIX LocalCache paths — a separate issue worth flagging to the Claude Desktop team)
• VHDX fully re-downloaded and checksum-validated (initrd.zst, rootfs.vhdx.zst, vmlinuz.zst all OK)
• VBS state reset cycle: was VirtualizationBasedSecurityStatus=1 (Enabled-but-not-running) stuck; cleared via bcdedit hypervisorlaunchtype off → reboot → auto → reboot
• Tailscale (VPN mesh present on machine) stopped to eliminate HNS interference — no effect
• Hyper-V services and features all verified Enabled and Running multiple times
• Watchdog scheduled task configured for service auto-recovery
• DCOM 10016 event log checked — no Claude/Cowork-related entries
• sc.exe failure config attempted on CoworkVMService → Access denied (MSIX-protected service, recovery cannot be user-configured — also worth flagging)
• Set-Service -Name CoworkVMService → Access denied (same MSIX protection)

WMI quirk worth flagging: Win32_ComputerSystem.HypervisorPresent reports False on this build (26100) even when hypervisor is fully active. This is a Windows provider issue, not user-actionable, but worth noting because the AppContainer-context check in Claude Desktop may be reading from this exact WMI property and gating on its (incorrect) value. See related issues #34323, #33784.

RELATED OPEN ISSUES IN ANTHROPICS/CLAUDE-CODE Same HRESULT 0x80370102, similar hardware profile, varying degrees of community workaround success: #44133, #48733, #57717, #47327, #51813, #37312, #38396, #33784, #34323, #27357, #25136

ENVIRONMENT SUMMARY

• Claude Desktop: v1.7196.3.0 (MSIX, package Claude_pzs8sxrjxfjjc)
• OS: Windows 11 Pro 24H2 (Build 26100)
• Hardware: Intel CPU, 32 logical processors, 64 GB RAM, VT-x enabled in BIOS
• VPN present: Tailscale (eliminated as variable via stop test)
• Subscription: Max plan

REQUESTED ACTION

1. Engineering investigation of the AppContainer HCS call path that diverges from admin PowerShell context on the same host.
2. Alternatively, a documented downgrade path to a Claude Desktop build prior to the introduction of this behavior on this hardware profile.
3. If neither is available short-term, official guidance on supported community workarounds (e.g., the Elliot Segler HNS network recreation procedure documented at https://www.elliotsegler.com/fixing-claude-coworks-network-conflict-on-windows.html).

Full PowerShell session transcripts, cowork_vm_node.log captures, Event Viewer entries, and Hyper-V diagnostic command outputs available on request.