[BUG] Cowork tab missing from navigation — "yukonSilver not supported" despite working Hyper-V and existing Cowork settings
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?
Cowork tab is missing from the desktop app navigation (only "Início"/Home and "Code" tabs are shown), even though Cowork settings (Arquivos do Cowork, Pastas confiáveis, Instruções globais) are already configured and populated under Settings → Cowork.
cowork_vm_node.log shows repeated:
[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
The VM never attempts to boot.
What Should Happen?
The Cowork tab should appear in the navigation and the yukonSilver VM configuration should be recognized as supported, since Windows 11 Pro x64 with Hyper-V enabled meets the documented requirements.
Error Messages/Logs
cowork_vm_node.log:
[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
This entry repeats on every app launch. The VM never attempts to boot.Steps to Reproduce
- Install Claude Desktop (latest version) on Windows 11 Pro x64 via MSIX/Store package
- Confirm Hyper-V is enabled and the vmms service is Running (verified via Get-Service vmms and Get-WindowsOptionalFeature)
- Launch Claude Desktop and sign in with a Pro plan account
- Observe that only "Home" and "Code" tabs appear in the top navigation — no "Cowork" tab
- Check Settings → Cowork — settings exist and are already populated
- Check %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\cowork_vm_node.log — shows "yukonSilver not supported (status=unsupported)" on every launch
Claude Model
None
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
N/A — this is Claude Desktop, not Claude Code CLI
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
Claude Desktop version: 1.24012.9 (03c61d)
Installation method: MSIX/Store package (Claude_pzs8sxrjxfjjc)
Subscription: Pro
Troubleshooting already attempted:
- Confirmed Hyper-V enabled and vmms service Running (Get-Service vmms, Get-WindowsOptionalFeature)
- Disabled and re-enabled Hyper-V via PowerShell, with full restarts between steps
- Updated Claude Desktop to the latest version
- Stopped and removed CoworkVMService via elevated PowerShell
- Fully uninstalled the app (Get-AppxPackage Claude | Remove-AppxPackage)
- Manually cleared %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc and %APPDATA%\Claude
- Performed a clean reinstall from the official website
- Tested access via mobile app — same issue (only "Chat" available, since it depends on the desktop session)
This matches the pattern reported in GitHub issues #25136, #27357, #27417, #32004, and #47327.
3 Comments
i can confirm this issue is happening to me on Windows 11 Home with a Claude Pro subscription.
In addition to the repeated
yukonSilver not supported (status=unsupported)
messages in cowork_vm_node.log, the Cowork button is grayed out and hovering over it displays:
Enable the secureVmFeaturesEnabled preference to use this feature
Hyper-V is enabled, CoworkVMService is installed, there are no HKCU or HKLM\SOFTWARE\Policies\Claude registry keys, and a clean reinstall did not resolve the issue.
Oh so the soultion for me was to run co work as an admin
Confirming this on a separate machine — same
yukonSilver not supportedlog line, but on a Squirrel-only install, not MSIX:Msvm_ComputerSystem→EnabledState: 2vmmsservice Running;HypervisorPresent: True;hypervisorlaunchtype: Autoapp-1.24012.9(Squirrel, installed to%LOCALAPPDATA%\AnthropicClaude);Get-AppxPackage *Claude*returns nothing--source msstorereturns "No package found"; a fresh download from claude.com/download also delivered the Squirrel build, not MSIXGiven the matching build number (1.24012.9) and identical log line, this looks like the same root cause but possibly compounded by the Squirrel build lacking whatever the yukonSilver check expects (MSIX packaging/identity?). Might be worth checking whether the unsupported check is incorrectly gated on package type rather than actual virtualization capability.