[BUG] Cowork tab disabled — yukonSilver "unsupported" on Windows 11 Pro x64 (ongoing since March 2026)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/40402
2. https://github.com/anthropics/claude-code/issues/34920
3. https://github.com/anthropics/claude-code/issues/36311

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

Environment:

• OS: Windows 11 Pro 23H2 (Build 22631.6199)
• Claude Desktop: latest version from https://downloads.claude.ai/releases/win32/ClaudeSetup.exe
• Subscription: Pro

Confirmed enabled:

• ✅ Virtual Machine Platform
• ✅ Windows Hypervisor Platform
• ✅ Hyper-V
• ✅ bcdedit /enum shows hypervisorlaunchtype Auto
• ✅ Windows Update: fully up to date
• ✅ Task Manager → CPU → Virtualization: Enabled

Symptom:
Cowork tab does not appear in Claude Desktop. Only "Chat" and "Code" are visible in the sidebar.

Log (%APPDATA%\Claude\logs\cowork_vm_node.log):

2026-04-14 16:00:34 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-04-15 09:41:33 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-04-15 14:49:02 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-04-15 15:18:24 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...

Steps tried:

1. Enabled all required Windows features and restarted
2. Ran bcdedit /set hypervisorlaunchtype auto as Administrator and restarted
3. Fully uninstalled Claude Desktop, deleted %APPDATA%\Claude, reinstalled from official link
4. Contacted Anthropic support (Fin AI Agent) — no resolution

Same issue as described in this thread. All system prerequisites are met. Please advise on any workaround or ETA for a fix.

Confirmed fix: migrate from Squirrel install to MSIX install

Had the identical yukonSilver not supported log on a Squirrel install
of Claude 1.2581.0 on Windows 11 Pro 25H2 (build 26200), Ryzen 9 5950X.

Same version (1.2581.0) installed as MSIX on a second Win 11 Pro 25H2
machine worked fine — Cowork tab present, no "unsupported" log spam.

Migration:

1. Uninstalled Squirrel Claude
2. Installed MSIX from Microsoft Store
3. Cowork tab appeared immediately, Routines also now visible

The yukonSilver platform detection appears broken in Squirrel builds
specifically. Users stuck on Squirrel installs (via legacy .exe installer
from claude.ai/download) need to explicitly migrate to MSIX.

**********************************************************************
Correction: migrating from Squirrel to MSIX is not a durable fix.

Observed on Windows 11:

• Legacy .exe / Squirrel install showed yukonSilver not supported log spam and did not expose Cowork/Routines correctly.
• MSIX initially fixed that: Cowork appeared and the unsupported log spam stopped.

However, the MSIX build later failed repeatedly during/after updates:

• Claude auto-updated, restarted, then failed to launch
• Windows showed: “Another program is currently using this file”
• AppModel/AppX logs showed:
• 0x80070020
• “Cannot create the Desktop AppX container”
• CoworkVMService was active around the time of failure

Reinstalls could also fail after uninstall with:

• 0x80073D05
• “An error occurred while deleting the package's previously existing application data”

The stale locked files were under:

• %LocalAppData%\\Packages\\Claude_...\\SystemAppData\\Helium\\User.dat
• related User.dat.LOG* / UserClasses.dat*

Reset-AppxPackage sometimes repaired the 0x80070020 state temporarily, but the issue recurred after later updates.

Current conclusion:

• Squirrel / legacy .exe builds appear to have a yukonSilver / Cowork detection problem
• MSIX builds may initially enable Cowork, but can later brick on update due to package/runtime state issues

So this appears to be at least two separate Windows packaging problems rather than “MSIX fixes Squirrel”.

Hitting it on Windows 11 Pro also:

2026-04-13 18:40:25 [info] [VM] Loading vmClient (TypeScript) module...
2026-04-13 18:40:25 [info] [VM] Module loaded successfully
2026-04-15 13:57:34 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-04-15 13:57:36 [info] [VM] Loading vmClient (TypeScript) module...
2026-04-15 13:57:36 [info] [VM] Module loaded successfully
2026-04-16 18:41:25 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-04-16 18:41:26 [info] [VM] Loading vmClient (TypeScript) module...
2026-04-16 18:41:26 [info] [VM] Module loaded successfully
2026-04-16 19:09:00 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-04-16 19:09:00 [info] [VM] Loading vmClient (TypeScript) module...
2026-04-16 19:09:00 [info] [VM] Module loaded successfully
2026-04-16 19:21:46 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-04-16 19:21:46 [info] [VM] Loading vmClient (TypeScript) module...
2026-04-16 19:21:46 [info] [VM] Module loaded successfully
2026-04-16 19:24:29 [info] [logout] User navigated to /logout, stopping VM
2026-04-16 19:24:29 [info] [stopVM] stopping VM gracefully
2026-04-16 19:24:29 [error] [logout] Failed to stop VM on logout: not configured: call 'configure' first

Same issue here. Pro subscriber, paying monthly, unable to access Cowork.

Environment:

• OS: Windows 11 Pro 25H2 (Build 26200.7462)
• Processor: 13th Gen Intel Core i9-13900KF
• RAM: 32 GB
• Claude Desktop: Latest version
• Hyper-V: Enabled (confirmed via Get-WindowsOptionalFeature)
• Virtual Machine Platform: Enabled
• Windows Hypervisor Platform: Enabled
• Virtualization-based security: Running
• DISM health check: No component store corruption
• SFC scan: No integrity violations

Log output (%APPDATA%\Claude\logs\cowork_vm_node.log):

2026-04-17 11:27:16 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-04-17 11:27:16 [info] [VM] Loading vmClient (TypeScript) module...
2026-04-17 11:27:16 [info] [VM] Module loaded successfully

This pattern repeats on every launch. The VM never attempts to boot.

What I've tried:

• Enabled Hyper-V via Windows Features GUI (reverted on reboot)
• Enabled Hyper-V via DISM (succeeded, confirmed enabled after reboot)
• Full app restart and system reboot
• Clean reinstall of Claude Desktop

Nothing works. The platform detection continues to flag yukonSilver as unsupported on a fully capable system. This is a paying feature that I cannot use. Please prioritize fixing the Windows platform detection logic.

Adding a data point: Cowork tab works on Windows Home after enabling VirtualMachinePlatform + HypervisorPlatform (no full Hyper-V role required)

Hit the same "missing Cowork tab" symptom and wanted to share what I found, since the resolution contradicts the assumption in https://github.com/anthropics/claude-code/issues/26090 (closed as invalid on the basis that Home can't run Hyper-V).

Environment

Claude Desktop: 1.3109.0.0 (MSIX, Claude_1.3109.0.0_x64__pzs8sxrjxfjjc)
OS: Windows Home, build 26200, x64
CPU: Intel i5-12450H (virtualization capable, HyperVisorPresent: True at baseline)
Initial symptom
Cowork tab completely absent from the Claude Desktop navigation. No error surfaced in the UI.

Log signature (matches the yukonSilver cluster in https://github.com/anthropics/claude-code/issues/25136, https://github.com/anthropics/claude-code/issues/25692, https://github.com/anthropics/claude-code/issues/47327, https://github.com/anthropics/claude-code/issues/48995, https://github.com/anthropics/claude-code/issues/49748)

Log location on MSIX installs — worth noting, since it's not %APPDATA%\Claude\logs as some threads suggest:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\cowork_vm_node.log
Contents before the fix:

[info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
[info] [VM] Loading vmClient (TypeScript) module...
[info] [VM] Module loaded successfully
Same pattern as https://github.com/anthropics/claude-code/issues/48995: vmClient loads fine, but the upstream yukonSilver pre-check marks the platform unsupported and hides the tab.

What actually fixed it

Enabling the two lightweight virtualization features that are available on Windows Home (unlike the full Microsoft-Hyper-V-All role, which isn't), from an elevated PowerShell:

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -NoRestart
Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -NoRestart
Reboot, relaunch Claude Desktop — Cowork tab appears and is functional.

https://github.com/anthropics/claude-code/issues/26090 was closed as invalid on the premise that Home lacks the virtualization stack Cowork needs. Based on this repro, that's not quite right — VirtualMachinePlatform + HypervisorPlatform (both available on Home) are sufficient to pass yukonSilver. The full Hyper-V role doesn't appear to be required.
Regardless of whether Home is officially in-scope, the current UX silently hides the tab instead of surfacing the unmet requirement. A clearer error ("Cowork requires Virtual Machine Platform and Windows Hypervisor Platform — enable them in 'Turn Windows features on or off'") would have saved a couple of hours of log-spelunking and avoided the $99 Pro-upgrade path that several threads currently recommend.

same issue Two weeks ago I killed the process and it worked as a workaround but now it doesn't work and i cannot use cowork. Following last logs found:
2026-04-18 10:19:58 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-04-18 10:19:58 [info] [deleteVMBundle] Deleting reinstall files from C:\Users\opedrals\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
2026-04-18 10:19:58 [info] [deleteVMBundle] Reinstall files deleted (sessiondata.img and rootfs.img.zst preserved)
2026-04-18 10:32:12 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-04-18 10:32:12 [info] [deleteVMBundle] Deleting reinstall files from C:\Users\opedrals\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
2026-04-18 10:32:12 [info] [deleteVMBundle] Reinstall files deleted (sessiondata.img and rootfs.img.zst preserved)

Same issue on Windows 11 Business 25H2 Build 26200.8246.

• yukonSilver continuously marked unsupported since first launch on 2026-04-13
• Hyper-V, VirtualMachinePlatform, HypervisorPlatform all enabled
• HypervisorPresent = True (verified via Win32_ComputerSystem)
• Clean install via ClaudeSetup.exe from claude.com/download
• Fresh machine, no prior Squirrel install

Log excerpt:
2026-05-08 10:03:32 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...

Installation ID: 52b9a989-7f12-4b60-996c-a3e88fc3bdc9

Claude-logs-2026-05-08T08-19-38-365Z.zip

Environment: Windows 11 Enterprise, Claude Desktop v1.6608.0.0
Issue: yukonSilver marked as unsupported since first install — Cowork has never worked on this machine. Not a regression.
Log: cowork_vm_node.log shows only repeated cleanupVMBundleIfUnsupported entries dating back to March 2026, no VM boot ever attempted.
Virtualization features: Virtual Machine Platform ✅, Windows Hypervisor Platform ✅, CoworkVMService running ✅
Notes: Non-admin user in enterprise split-account environment. MSIX installed via Add-AppxProvisionedPackage by admin.

I'm experiencing a related but different symptom: the VM starts successfully
but crashes mid-process. The log files show the same yukonSilver unsupported
error. Possibly the same root cause with different fallback behavior.

My report with full details and log files: #60677

Same issue here.

OS: Windows 11 Pro 25H2 Build 26200.8328
Claude Desktop: 1.12603.1.0 (MSIX)
Subscription: Pro
CoworkVMService: Running ✅
Hyper-V / VMP / vmms: All enabled and running ✅
vm_bundles folder: Never created ❌
Issue present since: April 2026

Log (cowork_vm_node.log):

2026-06-17 08:01:08 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-06-17 08:02:33 [info] [VM] Loading vmClient (TypeScript) module...
2026-06-17 08:02:33 [info] [VM] Module loaded successfully

Clean reinstall does not fix the issue. Persists across all versions since April 2026.

TITLE: Cowork "requires a newer installation" — yukonSilver marked unsupported after KB5094126 took Windows 11 Pro to Build 26200.8655 (regression)

SUMMARY
Cowork worked, then broke after a Windows quality update. The tab is disabled with "Cowork requires a newer installation"; the Reinstall button does nothing. cowork_vm_node.log shows yukonSilver status=unsupported on every launch, with the VM bundle deleted each time. The break correlates exactly with KB5094126 changing the OS build.

ENVIRONMENT

• OS: Windows 11 Pro 25H2, x64, Build 26200.8655 (after KB5094126, installed 2026-06-15)
• Prior working build: 26200.8457
• Machine: domain-joined / managed
• Claude Desktop: 1.12603.1.0 (MSIX; package family Claude_pzs8sxrjxfjjc)
• Virtualization: Hyper-V (Microsoft-Hyper-V-All) Enabled; Windows Hypervisor Platform Enabled; vmms Running/Automatic; vmcompute Running; HypervisorPresent True; hypervisorlaunchtype Auto

REGRESSION TIMELINE

• 2026-06-14: Cowork WORKED. Log shows "[startVM] VM already connected", "[postConnect] Installing SDK version=2.1.170", multiple "[vmOneShot] Running: bash". (Note: it worked even before the Hyper-V role was enabled — vmms was absent then — so virtualization config is not the cause.)
• 2026-06-15 06:52 onward: every launch logs "yukonSilver not supported (status=unsupported)" then deleteVMBundle. VM never boots. KB5094126 was installed 2026-06-15.

LOG SIGNATURE (cowork_vm_node.log)
2026-06-15 06:52:43 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-06-15 06:52:43 [info] [deleteVMBundle] Reinstall files deleted (sessiondata.img and compressed cache preserved)
(repeats on every launch through 2026-06-16)

RULED OUT (with evidence)

• Not account/plan: identical failure across 3 independent Claude accounts on the same machine.
• Not VPN/network: no VPN, no tunnel adapters.
• Not virtualization config: Hyper-V + WHP enabled, vmms + vmcompute Running; also worked before Hyper-V was enabled.
• Not Windows code integrity: CodeIntegrity/Operational log shows ZERO 3076/3077 events referencing any Claude path. Smart App Control (VerifiedAndReputablePolicyState=1) and WDAC (CodeIntegrityPolicyEnforcementStatus=2) are both enforced but are NOT blocking the VM addon.
• Not a stale bundle: app self-deletes it every launch; full clean reinstall (all stacked MSIX versions removed, %APPDATA%\Claude cleared, reinstalled from claude.ai/download) did not help.
• In-app "Reinstall" button does nothing (no download, no error).

CONCLUSION
The yukonSilver compatibility check no longer classifies the platform as supported after the OS build changed from 26200.8457 to 26200.8655 (KB5094126). The unsupported verdict originates in the app's own check, not in any Windows enforcement.

RELATED ISSUES
Matches the yukonSilver "unsupported" detection pattern on capable Windows 11 Pro 26200.x builds: #25136, #27357, #28238, #47327.

REQUEST
Update yukonSilver platform/build detection to recognize Build 26200.8655 as supported.

Environment:

OS: Windows 11 Pro 25H2, x64, Build 26200.8655
KB5094126 installed on 2026-06-10 (elevated build from 26200.x to 26200.8655)
Machine: domain-joined / corporate managed
Claude Desktop: 1.13576.4.0 (MSIX; package family Claude_pzs8sxrjxfjjc)
User account: standard user (ebersono), separate local admin account (eberson.admin)

Symptom:

Cowork tab visible but disabled with "Cowork requires a newer installation". Reinstall button does nothing.
Root cause identified:

cowork_vm_node.log shows yukonSilver not supported (status=unsupported) on every launch since 2026-06-15 — days after KB5094126 was installed. The VM never attempts to boot.
Ruled out (all verified):

✅ Hyper-V enabled (Microsoft-Hyper-V-All State: Enabled)
✅ CoworkVMService running (WIN32_PACKAGED_PROCESS, STATE: RUNNING)
✅ Claude package installed correctly (Status: Ok) for standard user
✅ AppLocker: no rules configured
✅ GPO: no MSIX blocking policies found
✅ AllowAllTrustedApps registry key: enabled
✅ WSL2 running (confirms Hyper-V is functional)
✅ Cowork Readiness Check passes all items except LSA query (Access Denied — corporate restriction, not blocking)
✅ Full clean reinstall attempted multiple times (Remove-AppxPackage + %APPDATA%\Claude cleared)
✅ Helium stale files (User.dat / UserClasses.dat) cleared — no effect

Log signature:
2026-06-15 06:52:43 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
Repeats on every launch. No VM boot attempted. No other entries in cowork_vm_node.log.
Conclusion:

The yukonSilver compatibility check does not recognize build 26200.8655 (post-KB5094126) as a supported platform. This matches the regression pattern described in this issue and related issues #25136, #27357, #28238.
Request:

Update yukonSilver platform/build detection to recognize Build 26200.8655 as supported.

Solution found: a legacy Squirrel install was surviving in %LOCALAPPDATA%\AnthropicClaude alongside the MSIX package. The app was launching via Squirrel instead of MSIX. Deleting the AnthropicClaude folder forced the app to use the MSIX install, which correctly detects yukonSilver as supported. Cowork is now functional.

Adding another instance of this. Previously working on Windows 10 Pro on the same machine and same Pro account. Clean install of Windows 11 Pro (same hardware), same issue immediately.

Environment:

OS: Windows 11 Pro x64 (clean install)
Claude Desktop version: 1.14271.0
Account: Pro
Log (cowork_vm_node.log):

[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
Verified:

Hyper-V enabled and running (HypervisorPresent: True, VBS status: Running)
No network errors, no crashes in any log
Issue persists after full kill and restart
The Windows 10 → Windows 11 transition on identical hardware/account suggests the platform detection regression specifically affects Windows 11.

Environment

• Claude Desktop: v1.15962.1 (traditional NSIS install, %LOCALAPPDATA%\AnthropicClaude)
• OS: Windows 11 Pro, 25H2, Build 26200.8037
• Plan: Max

Virtualization (all confirmed working)

• vmms: Running / Automatic
• vmcompute: Running / Manual
• CoworkVMService: does not exist (never created)

Symptom

Cowork task is accepted and shows under "Active", but nothing executes.
Claude responds in chat but performs no file operations. VM never starts.

Log (%APPDATA%\Claude\logs\cowork_vm_node.log)

[startVM] VM not supported (win32/x64), skipping
yukonSilver not supported (status=unsupported), checking for stale bundle...
Error: VM service not running. The service failed to start.
[Callbacks] Swift VM addon not available for callbacks

Notes

• Windows 11 Pro with full Hyper-V stack (vmms/vmcompute running), Build 26200 (>= 25H2)
• All documented prerequisites met, yet yukonSilver is classified as unsupported
• Same faulty platform detection as #25136 / #28238 / #37016 / #47327, still present on v1.15962.1

Get-Content "$env:APPDATA\Claude\logs\cowork_vm_node.log" -Tail 60

Confirming on Windows 11 Pro Build 28000 (26H1) — extends the affected range past 26200.
Same yukonSilver pre-boot rejection as this thread, on a newer OS build than reported so far. Matches @yyuitakk's v1.15962.1 report from a few days ago almost exactly.
Environment

Claude Desktop: 1.15962.1 (1e236d) — "Check for Updates" confirms latest
OS: Windows 11 Pro, Build 28000.2269 (26H1-class) — newer than the 26200/25H2 builds in the rest of this thread
Arch: x64 (Ryzen AI 9 HX 370)
Plan: Max
Install type: NSIS (%LOCALAPPDATA%\AnthropicClaude) — no MSIX package available to migrate to (winget search Claude --source msstore returns no Anthropic listing; Get-AppxPackage Claude empty)

Virtualization stack — fully present and running

HypervisorPresent: True
Microsoft-Hyper-V-All, VirtualMachinePlatform, HypervisorPlatform: all Enabled (via DISM)
vmcompute, vmms: both Running (verified post-reboot)
%APPDATA%\Claude\vm_bundles: never created

Log signature (post-reboot, services confirmed Running):
2026-06-29 11:10:47 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-06-29 11:14:18 [warn] [startVM] VM not supported (win32/x64), skipping
2026-06-29 11:14:23 [warn] [vm-client] getNetworkDrives unavailable; keeping prior snapshot: Error: VM service not running. The service failed to start.
[error] [Callbacks] Swift VM addon not available for callbacks
Already ruled out: full Hyper-V role + VMP + WHP enabled, hypervisorlaunchtype auto, rebooted, services Running, app on latest, legacy AnthropicClaude folder cleared. The MSIX migration that worked for others isn't available — there's no Anthropic MSIX in the Store for this account/region.
The classifier rejects pre-boot (no HCS/HRESULT error, just "skipping"), so the unsupported verdict originates in the app's own check. Request: extend yukonSilver platform/build detection to recognize Build 28000.x as supported — the existing 26200-focused fixes won't cover it.

I'm hitting what looks like the same root cause on Windows 11 Pro — adding my case since it shows a slightly earlier failure point in the same code path.

Environment:

• Windows 11 Pro
• Claude Desktop (latest, freshly installed)

Verification steps completed:

• Get-Service vmms → Running
• Get-Service vmcompute → Running
• Get-Service CoworkVMService → Running
• Hyper-V, Virtual Machine Platform, and Windows Hypervisor Platform all enabled via Windows Features, confirmed after a restart

Observed behavior:

• Cowork tab does not appear in Claude Desktop
• Test-Path "$env:APPDATA\Claude\logs" returns False — the logs folder itself is never created, suggesting the VM initialization process fails (or is skipped) even before logging starts
• This is one step earlier than the cowork_vm_node.log "yukonSilver not supported (status=unsupported)" signature reported above — in my case there's no log file to check because the folder never gets created at all

Steps already tried (no change):

1. Enabled Hyper-V via optionalfeatures, restarted, confirmed vmms running
2. Full uninstall via Settings > Apps
3. Manually deleted %APPDATA%\Claude and %LOCALAPPDATA%\Claude
4. Restarted
5. Fresh install from claude.com/download
6. Signed in, checked for Cowork tab — still missing, %APPDATA%\Claude\logs still doesn't exist

All services report healthy and Hyper-V is fully enabled at the OS level, so this looks like the same platform-detection issue described here, just caught at an earlier point before any VM logs are written. Happy to provide additional diagnostics (systeminfo, bcdedit output, etc.) if that would help narrow this down.

Still reproducing this issue as of July 8, 2026.

Environment:

• Windows 11 Pro, Build 26200.8655
• Intel Core Ultra CPU (Samsung device)
• Claude Desktop, latest version (reinstalled clean)
• Hyper-V fully enabled and confirmed via PowerShell:

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All
→ State: Enabled

Steps taken:

• Enabled Hyper-V via Enable-WindowsOptionalFeature, rebooted
• Confirmed State: Enabled post-reboot
• Fully closed and restarted Claude Desktop
• Downloaded and reinstalled latest Claude Desktop from claude.com/download
• Cowork tab still does not appear

Log from %APPDATA%\Claude\logs\cowork_vm_node.log shows the same recurring entry on every launch, even after enabling Hyper-V:

2026-07-08 11:12:52 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-07-08 11:17:07 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...

This confirms the yukonSilver platform detection issue is still unresolved as of the July 2026 build.

Same on Windows 11 Pro 25H2, build 10.0.26200, x64.

Clean MSIX install (1.20186.0.0) after full removal — Remove-AppxPackage -AllUsers,
provisioned packages removed, CoworkVMService deleted, reboot. Installer log reports
"MSIX installation succeeded".

main.log:
[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...

cowork_vm_node.log is 0 bytes. CoworkVMService is not recreated after a clean install.
vmms service Running, Hyper-V / VMP / WHP all enabled, VT-x on in BIOS.

In my case the Cowork tab does not appear at all rather than appearing greyed out.
Chat works normally.

Confirming this is still present as of 2026-07-14, exact same build and symptom as this thread and its duplicates (#25136, #27316, #27357, #27385, #27445, #28238, #32004, #73484, #75321).

Environment

• OS: Windows 11 Pro, Build 26200 (matches all prior reports on this thread)
• Claude Desktop: [pega aquí la versión de Get-AppxPackage -Name "*Claude*"]
• Plan: Pro
• Hyper-V: Enabled — verified via Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All → State: Enabled
• Virtual Machine Platform: Enabled — verified via Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform → State: Enabled
• Installed as Administrator, clean MSIX package (no prior Squirrel install)

Symptom
Cowork tab shows "Cowork requires a newer installation." Reinstall button does nothing.

Log (%APPDATA%\Claude\logs\cowork_vm_node.log):

[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...

Repeats on every launch since first install. No [startVM] entry is ever reached — the check aborts before attempting to start Hyper-V.

Troubleshooting already completed (no effect)

• Verified Hyper-V fully enabled (not just Virtual Machine Platform)
• Verified Virtual Machine Platform enabled
• Confirmed clean MSIX install, no Squirrel remnants
• Rebooted after enabling virtualization features
• Get-Service showed no CoworkVMService registered at all before reinstall

Per the source analysis in #27357, the failure point is isHardwareVirtEnabled() inside the native CoworkVMService binary returning false on systems where Hyper-V/VMP are demonstrably enabled — this looks like a native detection bug specific to certain Build 26200 configurations, not a documentation or user-config issue. Given the number of independent reports on this exact build across five+ months with no fix shipped, could someone from Anthropic confirm whether this is being actively worked, or whether there's a known workaround for the native check itself?