Cowork: in-app yukonSilver reports unsupported on arm64, but Anthropic's own Readiness Check reports SUPPORTED (Snapdragon X2 Elite / Win11 26H1)

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?

Anthropic's Cowork Readiness Check reports Result: SUPPORTED on this machine, yet the in-app gate refuses on every launch with yukonSilver not supported (status=unsupported) and never attempts to start the VM. The two tools disagree, specifically on the hardware-virtualization check on arm64: the readiness checker prints Hardware virtualization — skipped on arm64, but the in-app gate runs that check anyway and false-negatives.
This is the same core defect as the (closed-as-not-planned) #39045, but with new evidence: it reproduces on current X2 silicon + the 26H1 platform branch, and Anthropic's own readiness tool directly contradicts the app.
The contradiction (same machine, same session):
Official Cowork Readiness Check — Result: SUPPORTED:
[PASS] Windows version 10.0 build 28000
[PASS] Architecture arm64
[PASS] Hardware virtualization skipped on arm64
[PASS] Virtual Machine Platform services present: vmcompute, HNS, vfpext
[PASS] Windows edition Professional
Result: SUPPORTED
In-app log refuses every launch, no VM start attempt (see Logs field).

What Should Happen?

When the Readiness Check reports SUPPORTED, the in-app gate should apply the same arm64 logic — skip the hardware-virt probe on arm64 as the readiness checker does, download the arm64 VM bundle (smol-bin.arm64.vhdx), and start the Cowork workspace. The two tools should not disagree on the same machine.

Error Messages/Logs

%APPDATA%\Claude\logs\cowork_vm_node.log (repeats every launch since 18 June; persists after a full clean uninstall/purge/reinstall):

2026-06-18 12:29:18 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-06-19 11:14:29 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-06-22 14:29:31 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...

Steps to Reproduce

On a Snapdragon X2 Elite device running Windows 11 26H1 (Arm64, Pro), confirm VirtualMachinePlatform and HypervisorPlatform are Enabled and HypervisorPresent = True.
Install the Arm64 MSIX build of Claude Desktop from claude.ai/download.
Run the official Cowork Readiness Check → Result: SUPPORTED.
Open Claude Desktop → Cowork tab → "Cowork requires a newer installation" banner; the VM never starts.
Check %APPDATA%\Claude\logs\cowork_vm_node.log → yukonSilver not supported on every launch.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.13576.4.0 (Arm64, MSIX) — note: this is a Cowork/Desktop issue, not the Claude Code CLI.

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

(this is where the rest goes — and drag your Readiness Check screenshot in here)

Environment: Lenovo Yoga Slim 7x (CsModel 83QR) · Snapdragon X2 Elite X2E88100 (Qualcomm Oryon, 18-core) · Windows 11 26H1 ("Bromine"), Arm64, build 28000 (factory image; ProductName cosmetically reads "Windows 10 Pro") · Pro edition · Claude Desktop 1.13576.4.0 Arm64 MSIX · Max plan · HypervisorPresent = True.
Causes ruled out:

Wrong arch / emulation — confirmed native Arm64 MSIX via Get-AppxPackage.
Virtualization — VirtualMachinePlatform + HypervisorPlatform Enabled and rebooted; HypervisorPresent = True; checker shows VM Platform services present (vmcompute, HNS, vfpext).
VM service logon right — elevated secedit confirms SeServiceLogonRight grants *S-1-5-83-0 (NT VIRTUAL MACHINE\Virtual Machines); no SeDenyServiceLogonRight entry.
Page file / commit — raised to 16384/32768 MB, rebooted. No change.
Stale install — full uninstall + purge (%APPDATA%\Claude, %LOCALAPPDATA%\Claude, package cache) + reboot + fresh reinstall. Persists.
Old version — 1.13576.4.0 is current.

Suspected root cause: per the decompiled EPt() analysis in #27357, the gate ends in a native isHardwareVirtEnabled() call. The standalone Readiness Check explicitly skips this on arm64 (and passes), but the in-app gate does not skip it on arm64, so it false-negatives. The in-app arm64 path doesn't match the readiness tool's arm64 logic.
Prior hardware: Cowork worked correctly on the same account on a previous Snapdragon X Elite (X1E-78-100) machine — so this is specific to the X2 / 26H1 platform, not the account or app feature flag visibility.
Related: #39045 (same ARM64 case, closed as not planned, lacked the readiness-check contradiction), #27357 (decompiled root-cause analysis), #49997, #32004.
Impact: Blocks Cowork on current-gen Snapdragon X2 Copilot+ hardware on the 26H1 branch. Fleet-scale: 50 × Yoga Slim 7x (same config) inbound. Note the readiness checker returns SUPPORTED on this exact config, so it cannot be used to pre-validate the fleet.

<img width="1598" height="642" alt="Image" src="https://github.com/user-attachments/assets/a6a5882b-bd77-4178-8c42-35e860f45ea4" />