[BUG] Cowork: "yukonSilver not supported" on Windows 11 Pro x64 with Intel Core Ultra 9 285K — all prerequisites met

Status Fixed / completed
Maintainer reply None cached
Activity 6 comments · opened Feb 21, 2026 · closed Feb 22, 2026

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?

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?

After a fresh install of Claude Desktop on Windows 11 Pro x64, Cowork fails to start with the error "Virtualisierung ist nicht aktiviert" (Virtualization is not enabled). The cowork_vm_node.log shows yukonSilver not supported (status=unsupported) despite all virtualization prerequisites being met and verified.

This appears to be the same root cause as #25136 and #25142 — the VM configuration yukonSilver is incorrectly classified as "unsupported" on a fully capable system.

Environment

| Component | Details |
|-----------|---------|
| OS | Windows 11 Pro, Build 26200.7840, x64 |
| CPU | Intel Core Ultra 9 285K (Arrow Lake) |
| Claude Desktop | v1.1.3918.0 (MSIX, installed Feb 21, 2026) |
| Subscription | Max plan |
| Model | Opus 4.6 |
| API | Anthropic API |

Virtualization Status (all verified)

| Feature | Status |
|---------|--------|
| Intel VT-x (BIOS) | ✅ Enabled |
| Hyper-V (all components) | ✅ Enabled |
| Virtual Machine Platform | ✅ Enabled |
| Windows Hypervisor Platform | ✅ Enabled |
| vmcompute service | ✅ Running |
| CoworkVMService | ✅ Running (WIN32_PACKAGED_PROCESS) |
| Task Manager → Virtualization | ✅ Enabled |

Installation context

System was upgraded from Windows 11 Home to Pro specifically for Cowork/Hyper-V support. Claude Desktop was freshly installed after the Pro upgrade. The installer correctly detects Windows edition: Professional (confirmed in ClaudeSetup.log).

Steps to Reproduce

  1. Fresh Windows 11 Pro x64 system with all virtualization features enabled
  2. Download and install Claude Desktop from claude.ai/download (with admin elevation)
  3. Open Claude Desktop → Click "Cowork" tab
  4. Observe: "Virtualisierung ist nicht aktiviert" error banner
  5. Check cowork_vm_node.logyukonSilver not supported

Expected Behavior

Cowork workspace should start successfully and connect to the Claude API, as all system prerequisites are met.

Actual Behavior

Cowork displays "Virtualisierung ist nicht aktiviert" and the VM never starts. The log shows repeated [startVM] VM not supported (win32/x64), skipping messages.

Relevant Logs

cowork_vm_node.log

2026-02-21 11:48:31 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-02-21 11:48:54 [warn] [startVM] VM not supported (win32/x64), skipping
2026-02-21 11:48:54 [info] [Callbacks] Initializing VM event callbacks...
2026-02-21 11:48:54 [info] [VM] Loading vmClient (TypeScript) module...
2026-02-21 11:48:54 [info] [VM] Module loaded successfully
2026-02-21 11:48:54 [info] [Callbacks] VM event callbacks initialized
2026-02-21 11:48:55 [warn] [startVM] VM not supported (win32/x64), skipping
2026-02-21 11:48:57 [warn] [startVM] VM not supported (win32/x64), skipping
2026-02-21 11:49:01 [warn] [startVM] VM not supported (win32/x64), skipping
[repeats indefinitely]

ClaudeSetup.log (relevant excerpt)

2026/02/21 11:48:26.841487 Windows edition: Professional
2026/02/21 11:48:26.842022 Windows version: 10.0.26200
2026/02/21 11:48:26.842022 Native arch: x64
2026/02/21 11:48:26.842022 Elevation type: Full
2026/02/21 11:48:26.842022 Is elevated: true
2026/02/21 11:48:29.397599 MSIX package installed successfully
2026/02/21 11:48:29.401649 MSIX installation succeeded

Service verification

> sc query CoworkVMService
STATE: 4 RUNNING (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)

> sc query vmcompute
STATE: 4 RUNNING

MSIX package info

Name:              Claude
InstallLocation:   C:\Program Files\WindowsApps\Claude_1.1.3918.0_x64__pzs8sxrjxfjjc
PackageFamilyName: Claude_pzs8sxrjxfjjc

Troubleshooting Already Attempted

  • [x] Complete uninstall + fresh install (twice)
  • [x] Manual removal of CoworkVMService (sc stop + sc delete)
  • [x] Deletion of all Claude app data directories
  • [x] Deletion of ClaudeSetup.log before reinstall
  • [x] Installation with full admin elevation
  • [x] PC reboot between uninstall and reinstall
  • [x] Verified Windows edition is correctly detected as "Professional" in installer log
  • [x] Upgraded from Windows 11 Home to Pro (with reboot) before installing Claude

Possibly Related Issues

  • #25136 — yukonSilver marked as unsupported on Windows 11 Pro x64
  • #25142 — Cowork tab not showing, same yukonSilver root cause
  • #25663 — Cowork workspace bricked after Chrome automation (Windows 11 Home)
  • #24918 — Cannot connect to Claude API from workspace (Windows 11 Home)

Additional Context

The cleanupVMBundleIfUnsupported function appears to have a platform detection issue that incorrectly marks yukonSilver as unsupported on systems that meet all documented requirements. This may be related to the Intel Arrow Lake (Core Ultra 200 series) processor architecture, which is relatively new. A clearer error message indicating why the platform is considered unsupported would greatly help diagnosis.

What Should Happen?

Solve the Problem

Error Messages/Logs

Steps to Reproduce

  1. Fresh Windows 11 Pro x64 system with all virtualization features enabled
  2. Download and install Claude Desktop from claude.ai/download (with admin elevation)
  3. Open Claude Desktop → Click "Cowork" tab
  4. Observe: "Virtualisierung ist nicht aktiviert" error banner
  5. Check cowork_vm_node.logyukonSilver not supported

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude_1.1.3918.0_x64__pzs8sxrjxfjjc

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_

View original on GitHub ↗

6 Comments

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/27354
  2. https://github.com/anthropics/claude-code/issues/27357
  3. https://github.com/anthropics/claude-code/issues/25034

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Pereapotecari · 6 months ago

I can confirm I am experiencing the exact same issue on the exact same Windows build.

My Environment:

OS: Windows 11 Pro, version 25H2, OS Build 26200.7840

CPU: 12th Gen Intel Core i5-12400

Antivirus: ESET Endpoint Antivirus (Firewall completely paused for testing)

Troubleshooting done:

Verified VT-x is enabled in the BIOS.

Verified Hyper-V, Virtual Machine Platform, and Windows Hypervisor Platform are all enabled in Windows features.

Paused the antivirus/firewall completely to rule out network blocking.

Did a completely clean install of Claude Desktop.

Result:
I get the same instant "Virtualization is not enabled" error. I checked the %LOCALAPPDATA%\Packages\...\LocalCache directory, and the vm_bundles and claude-code-vm folders are never even created. The app just instantly fails the system check on this Windows build.

Hopefully, this gets patched soon as it's definitely a platform detection bug on Build 26200!

smilyte · 6 months ago

Same issue. Have tried everything advised in the similar issues and numerous fresh installs - nothing. First time installing Claude Desktop.

CrybabyGeeks · 6 months ago

Confirmed — same issue here. Working fix below.

I hit the exact same yukonSilver not supported (status=unsupported) error after updating to v1.1.3918.0. Cowork tab showed "Virtualization is not enabled" despite Hyper-V being fully functional. Used an AI coding agent (Codex in VS Code) to debug and it found a stable workaround.

Root Cause

The Hyper-V stack itself is fine — v1.1.3918.0 has a bug in its virtualization detection logic. It reports hardware_virt_disabled even on systems where Hyper-V can create and run VMs without issue. This is a regression from the previous build.

Fix: Downgrade to v1.1.3647.0 + Block Auto-Update

Step 1 — Downgrade the MSIX package

You'll need the v1.1.3647.0 installer. Once you have it, install it to replace the current package. After downgrade, your install location should show:

C:\Program Files\WindowsApps\Claude_1.1.3647.0_x64__pzs8sxrjxfjjc

Step 2 — Block auto-update to prevent re-upgrading to 1.1.3918

Open C:\Windows\System32\drivers\etc\hosts as Administrator and add:

# Temporary Claude update block — remove once Anthropic fixes yukonSilver detection
0.0.0.0 downloads.claude.ai
⚠️ Back up your hosts file first before making changes.

Step 3 — Verify

  • Claude renderer should now report yukonSilver: supported
  • cowork_vm_node.log should show VM startup complete / VM already connected
  • Update checks will fail with net::ERR_ADDRESS_INVALID — this is expected and intentional

Once Anthropic Ships a Fix

  1. Remove the 0.0.0.0 downloads.claude.ai line from your hosts file
  2. Restart Claude Desktop and let it update to the latest version

System Info

  • OS: Windows 11 Pro x64
  • CPU: Intel Core i9-10850K @ 3.60GHz (Comet Lake)
  • Claude Desktop: Downgraded from v1.1.3918.0 → v1.1.3647.0
  • Hyper-V: Fully enabled and functional (verified by creating a test VM independently)

Note: The OP is on an Intel Core Ultra 9 285K (Arrow Lake) — the fact that this also reproduces on a 10th-gen Comet Lake chip confirms the detection regression in v1.1.3918 is not architecture-specific. It appears to affect a broad range of Intel systems.

Hope this helps others stuck on this — the key takeaway is that your Hyper-V setup is almost certainly fine, it's the app's detection that's broken in 3918.

MarshallOfSound · 6 months ago

Closing as duplicate of #27316 which was very rapidly fixed in the v1.1.3963 release

github-actions[bot] · 6 months ago

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.