[BUG] Cowork shows "Virtualization is not available" on Windows 11 Pro despite Hyper-V fully enabled and services running**

Same issue here. Windows 11 Pro, AMD Ryzen 9 5900X, MSI X570S Edge Max WiFi. All three Windows features enabled (Hyper-V, Virtual Machine Platform, Windows Hypervisor Platform). SVM enabled in BIOS. vmms, vmcompute, and CoworkVMService all running. hypervisorlaunchtype set to Auto. %APPDATA%\Claude\logs\ does not exist — VM never initializes.

Same issue here.
System info:

OS: Windows 11 Pro 25H2 (Build 26200.8039)
CPU: AMD Ryzen 5 5500
Claude Desktop: latest version

All virtualization features confirmed enabled:

SVM Mode (BIOS): Enabled
VirtualMachinePlatform: Enabled
HypervisorPlatform: Enabled
Microsoft-Hyper-V: Installed via DISM
vmcompute: Running
vmms: Running (Automatic)
HvHost: Running
bcdedit hypervisorlaunchtype: Auto

Symptoms:

Cowork shows "Virtualization is not available" immediately
%APPDATA%\Claude folder does not exist — VM never attempts to initialize
No logs generated
Restarting does not resolve it
Clean reinstall does not resolve it

This is clearly an app-side detection bug. Please prioritize a fix.

Same Bug: Cowork "Virtualization is not available" on Windows 11 Pro — VM never initializes, no logs created

Error message
Claude's workspace requires Virtual Machine Platform, but the virtualization service isn't responding.

System info
OS: Windows 11 Pro, Build 26100, 64-bit
Claude Desktop: 1.2.234.0 (installed via MSIX package)
Note: Originally on Windows 11 Home, upgraded to Pro specifically to resolve this issue so hope I didn't waste $100 on that

Verification steps completed

Hyper-V ✅ Enabled
Virtual Machine Platform ✅ Enabled
Windows Hypervisor Platform ✅ Enabled
Microsoft-Hyper-V-All ✅ Enabled
Microsoft-Hyper-V-Hypervisor ✅ Enabled
Microsoft-Hyper-V-Services ✅ Enabled
CoworkVMService ✅ Running
bcdedit hypervisorlaunchtype ✅ Set to Auto
Task Manager → Virtualization ✅ Enabled
%APPDATA%\Claude\logs ❌ Does not exist — VM never initializes

Steps tried
Full clean reinstall: removed app via Get-AppxPackage, deleted %APPDATA%\Claude and %LOCALAPPDATA%\Claude, rebooted, reinstalled via MSIX
Ran installer as Administrator
Multiple full restarts performed

Conclusion
All system-level virtualization checks pass. The VM never attempts to start and no logs are generated. This appears to be the same app-side platform detection bug reported in #27316, #27420, #29887, #32004, #37265.

Same issue. Re-starting, re-installing does not work.
Haver run the following in powershell:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform
bcdedit /set hypervisorlaunchtype auto
Remove-Item -Recurse -Force "$env:APPDATA\Claude\vm_bundles"

When runnign the last command powershell throws this error:
Remove-Item : Cannot find path 'C:\Users\DanielMalm\AppData\Roaming\Claude\vm_bundles' because it does not exist.
At line:1 char:1

• Remove-Item -Recurse -Force "$env:APPDATA\Claude\vm_bundles"
• ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
• CategoryInfo : ObjectNotFound: (C:\Users\Daniel...aude\vm_bundles:String) [Remove-Item], ItemNotFoundEx

ception

• FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand

The above shows the vm_bundles folder never gets created, which confirms Cowork is failing before it even tries to initialize the VM.

[BUG] Cowork: vmcompute (Hyper-V Host Compute Service) fails to start — Access Denied, no actionable error

Environment

• OS: Windows 11 Pro (Build 22631.6199)
• Claude Desktop version: 1.569.0.0
• Subscription: Pro
• Hyper-V: Enabled (Microsoft-Hyper-V-All, State: Enabled)
• Hypervisor: Running (HypervisorPresent: True)
• VBS: Running (VirtualizationBasedSecurityStatus: 2)
• Credential Guard: Not active (SecurityServicesRunning: 0)
• Memory Integrity / Smart App Control: Disabled
• WSL2: Installed and functional
• Antivirus: Windows Defender only (no third-party AV)
• Physical machine (not a VM)

What's wrong

Cowork fails to start with "VM service not running. The service failed to start." every time. The root cause is that the Windows service vmcompute (Hyper-V Host Compute Service) cannot be started — it starts and immediately exits with "General Access Denied" (Event ID in System log).

From cowork_vm_node.log:
VM downloads all required files successfully (rootfs.vhdx, vmlinuz, initrd, smol-bin.vhdx), but fails at the "Configuring Windows VM service" step after ~5 seconds. One attempt got further and failed with Request timed out: startVM at the create_vm_config step.

Troubleshooting attempted (all failed):

• Restarted Claude Desktop and computer multiple times
• Reinstalled workspace via Help → Troubleshooting → Reinstall Workspace
• Verified all vmcompute dependencies are running: rpcss, wcifs, hvsocketcontrol, condrv ✅
• Reset vmcompute service security descriptor via sc.exe sdset
• Disabled and re-enabled Microsoft-Hyper-V-All via DISM
• Ran sfc /scannow — found and repaired corrupt files (Bluetooth drivers, unrelated to Hyper-V)
• Ran DISM /Online /Cleanup-Image /RestoreHealth — completed successfully
• Shut down WSL2 before attempting to start vmcompute
• Verified bcdedit: hypervisorlaunchtype = Auto
• Checked Hyper-V Compute Operational log — only shows start/stop events (1000/1002), no error events
• vmms service starts successfully after restart; vmcompute does not

Expected behavior
Cowork workspace should start successfully.

Additional notes
This appears related to the ongoing vmcompute / Cowork regression reported in issues #27801, #29428, #25206 and others. The Hyper-V stack appears healthy at the OS level but vmcompute consistently exits immediately with Access Denied. No actionable error is surfaced in any log.

Same issue: Windows 11 Pro user. Tried all suggested fixes: restarted, ran bcdedit /set hypervisorlaunchtype auto, verified CoworkVMService and vmcompute both showing Running, did a full clean reinstall including deleting %APPDATA%\Claude and %LOCALAPPDATA%\Claude folders and reinstalling as administrator. After reinstall the Cowork tab briefly appeared without the error, but the error returned immediately after switching to the Chat tab and back. VM never actually initializes. Cowork is completely unusable.

Same issue here....

Adding a variant worth checking before the other steps in this thread — my vmcompute service was set to DISABLED (not just stopped), likely from an old debloat script or a stale Android Studio / Docker install. The "restart your computer" message cannot fix this state, since restart won't start a disabled service.

Diagnosis:

sc qc vmcompute

Look for START_TYPE : 4 DISABLED.

Fix (elevated PowerShell):

Set-Service -Name vmcompute -StartupType Manual
Start-Service vmcompute

Confirmed working on Windows 10 Pro (19045) — Cowork launched successfully immediately after, no reboot needed.

Suggestion for the app: when the VM backend is unreachable, probe the service START_TYPE and surface a specific message (e.g. "vmcompute is disabled — run Set-Service vmcompute -StartupType Manual in an elevated shell") instead of the generic "restart your computer" hint, which is wrong advice for this case.

running Win 11 Pro, vmcompute is running and the bug is still there

Jumping on the bandwagon... same issue here Win 11 Pro. WSL and Hyper-V VMs work great so the hypervisor is working fine.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.