Repository navigation
[BUG] Cowork for windows: yukonSilver not supported #25034
Description
Activity
Found 3 possible duplicate issues:
- [BUG] [Cowork] Windows: sessiondata.vhdx not created + network diagnostics uses macOS commands #24974
- [BUG] Cowork Windows - CSP blocks a-api.anthropic.com, VM starts but API unreachable (Win 11 25H2) #25024
- Cowork VM fails on Windows 11 Home: wrong DNS config, missing sessiondata.vhdx, no NAT #24962
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
Reacted by Jonathan Larkin, Yikun Ji, Jon Silver, pjohn and Shadow-GrassI finally got it to work. Here is the summary:
[BUG] Claude Desktop MSIX installer fails silently on Windows Enterprise with split user/admin accounts — Cowork unavailable
Preflight Checklist
- I have searched existing issues and this hasn't been reported yet
- This is a single bug report
- I am using the latest version of Claude Desktop
Environment
- Claude Desktop version: 1.1.2685 (f39a62)
- OS: Windows 11 Enterprise 25H2 (OS Build 26200.7623)
- Architecture: x64
- Hyper-V: Fully enabled (all components)
- Account setup: Standard user account (
REDACTED_USER) with separate admin account (REDACTED_ADMIN) for elevation — common enterprise configuration
Summary
The Claude Desktop installer fails silently during the MSIX installation path on Windows Enterprise systems where the logged-in user account and the admin account used for UAC elevation are different user profiles. This prevents Cowork from being available, as Cowork requires the MSIX install (which includes
CoworkVMService).The Squirrel (EXE) install path works fine but does not include Cowork functionality.
Steps to Reproduce
- Log in to Windows as a standard user (e.g.,
REDACTED_USER) - Download Claude Desktop installer from claude.com/download
- Run the installer — it begins the MSIX path automatically
- First progress bar completes (MSIX download)
- UAC prompt appears — enter credentials for a separate admin account (e.g.,
REDACTED_ADMIN) - Second progress bar starts, halts at ~50%, then the installer exits silently with no error message
- Claude is not installed for the standard user
Expected Behavior
The MSIX package should install for the logged-in user (
REDACTED_USER), regardless of which admin account is used for UAC elevation.Actual Behavior
The installer appears to install the MSIX under the admin account's context rather than the logged-in user. Subsequent install attempts detect a conflicting
CoworkVMServicefrom the orphaned previous install, which blocks future MSIX installations.Detailed Installer Log Analysis
From
ClaudeSetup.log, a successful MSIX install shows:2026/02/11 14:52:38.927912 Standard user — attempting MSIX install with credential prompt 2026/02/11 14:52:41.488568 Self-elevating: Claude Setup.exe --elevated --msix-path "...\Claude-4097097947.msix" --log-path "...\ClaudeSetup.log" 2026/02/11 14:52:54.301279 Is elevated: true 2026/02/11 14:52:57.202025 Squirrel process prefix: c:\users\REDACTED_ADMIN\appdata\local\anthropicclaude\ 2026/02/11 14:53:05.427158 Add-AppxPackage stdout: INSTALL_SUCCESS 2026/02/11 14:53:06.067128 === Claude Setup completed successfully ===Note: The elevated process checks for Squirrel processes under
REDACTED_ADMIN(the admin account), notREDACTED_USER(the logged-in user).However, when the user subsequently runs the installer again (e.g., because Claude didn't appear to install correctly), the log shows:
2026/02/11 14:55:29.045773 WARNING: CoworkVMService already exists (potential conflict) 2026/02/11 14:55:29.045773 Conflicting service: trueThis causes the installer to fall back to the Squirrel (EXE) path, which does not include Cowork.
Cowork VM Log
Even when the MSIX was installed, Cowork never worked. The cowork log consistently showed:
[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...And earlier versions logged:
[SwiftVM] Failed to load module: Error: Cannot find package '...\node_modules\@ant\claude-swift\js\index.js' [Bundle:status] rootfs.img missingRoot Cause Analysis
The core issue appears to be that the MSIX installer's elevation step changes the user context to the admin account. In enterprise environments where users have separate standard and admin accounts (a very common security practice), this causes:
- MSIX installs under the wrong profile —
Get-AppxPackageshows the package registered toREDACTED_ADMIN, notREDACTED_USER - Orphaned CoworkVMService — The packaged service (
WIN32_PACKAGED_PROCESStype) persists even after the MSIX is removed, and cannot be deleted withsc.exe delete(access denied even as admin) - Subsequent installs blocked — The conflicting service forces fallback to the Squirrel path
- yukonSilver reports unsupported — Even when MSIX is present, the VM engine reports as unsupported, possibly because the MSIX and the logged-in user are mismatched
Workaround
After extensive debugging, the following workaround was found:
- Remove the orphaned MSIX package:
Get-AppxPackage -AllUsers -Name "Claude" | Remove-AppxPackage -AllUsers
- Remove the orphaned provisioned package:
(These two steps together remove the orphaned
Get-AppxProvisionedPackage -Online | Where-Object {$_.DisplayName -like "*Claude*"} | Remove-AppxProvisionedPackage -Online
CoworkVMService) - Remove all leftover data from both user profiles
- Reboot
- Run the installer as the standard user, enter admin credentials when prompted — MSIX installs successfully this time
- However, the Squirrel install may also run and overwrite the MSIX. To use the MSIX version with Cowork, manually remove the Squirrel install folder (
%LOCALAPPDATA%\AnthropicClaude) and launch via:explorer.exe shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude
Suggested Fixes
- The MSIX installer should install the package for the logged-in user, not the elevated admin user. Use
Add-AppxPackagewith appropriate user targeting. - The installer should handle
CoworkVMServiceconflicts gracefully — detect and clean up orphaned services before attempting install. - The installer should not install both MSIX and Squirrel versions — if MSIX succeeds, the Squirrel fallback should not trigger.
- The "Application not found" error after failed installs should be handled — provide a clear error message instead of failing silently.
- Consider supporting the split admin account pattern explicitly — this is standard practice in enterprise environments (separate standard and admin accounts per user).
Additional Context
- A colleague on the same network, same Windows Enterprise version, same group policies (verified via
whoami /groups), but using a single account with admin rights, installed Claude with Cowork successfully on the first attempt. - The Squirrel (EXE) install via
-exeflag works perfectly but does not include Cowork. - All Hyper-V features are confirmed enabled.
- The issue is reproducible across multiple clean install attempts.
Reacted by Yikun Ji and Arek SzolcExperiencing the same issue. Cowork tab does not appear — only Chat and Code are visible.
Environment:
- Claude Desktop: v1.1.2685 (f39a62)
- Windows 11 Enterprise 25H2, Build 26200.7623
- HP ZBook Power 16 inch G11 Mobile Workstation
- Intel Core Ultra 9 185H (2.30 GHz)
- 64GB RAM, x64-based processor
- Team plan (premium seat), Cowork confirmed enabled by org admin
Virtualization features (all enabled, confirmed after reboot):
- Hyper-V ✅
- Virtual Machine Platform ✅
- Windows Hypervisor Platform ✅
No conflicting service:
C:\Windows\System32>sc query CoworkVMService [SC] EnumQueryServicesStatus:OpenService FAILED 1060: The specified service does not exist as an installed service.Log output (
%APPDATA%\Claude\logs\cowork_vm_node.log):2026-01-23 18:45:42 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...This has been repeating on every app launch since Jan 23, 2026.
Troubleshooting attempted:
- Signed out and back in
- Full app restart
- Reinstalled latest version as admin
- Enabled all virtualization features and rebooted
- Confirmed Cowork enabled by Team org admin
- Contacted Anthropic support (bot only, no resolution)
This is a corporate-managed machine but with full admin rights and all virtualisation features available and enabled. The VM support check appears to be incorrectly returning "unsupported" for this configuration.
Reacted by WillExperiencing the same issue. Cowork tab does not appear — only Chat and Code are visible.
Environment:
- Claude Desktop: Version 1.1.3363 (ee4247)
- Windows 10 Pro 22H2, Build 19045.6466
- Vivobook_ASUSLaptop X7400PC_N7400PC
- CPU - 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz
- 16GB, x64-based processor
- Pro plan
Virtualization features (all enabled, confirmed after reboot):
- Hyper-V ✅
- Virtual Machine Platform ✅
- Windows Hypervisor Platform ✅
Hyper-V Virtual Machine Management service: Running ✅
Log output (%APPDATA%\Claude\logs\cowork_vm_node.log):
2026-02-18 07:15:00 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-02-18 07:16:23 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-02-18 07:16:24 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-02-18 07:22:26 [warn] [startVM] VM not supported (win32/x64), skipping
2026-02-18 07:22:26 [info] [Callbacks] Initializing VM event callbacks...
2026-02-18 07:22:26 [error] [Callbacks] Swift VM addon not available for callbacks
2026-02-18 07:22:28 [warn] [startVM] VM not supported (win32/x64), skipping
2026-02-18 07:22:30 [warn] [startVM] VM not supported (win32/x64), skipping
2026-02-18 07:22:34 [warn] [startVM] VM not supported (win32/x64), skippingTroubleshooting attempted:
- Signed out and back in ✅
- Downloaded and installed latest app version today (Feb 18, 2026) ✅
- Enabled all virtualization features and rebooted ✅
Cowork tab missing on Windows 11 Pro x64 — yukonSilver still marked "unsupported" in v1.1.3189
Adding my report to the ongoing yukonSilver issues (#25136, #25142, #25205).
Environment
Field | Value -- | -- Claude Desktop | v1.1.3189 (1b7b58), 2026-02-14 OS | Windows 11 Pro x64 Subscription | Pro ($20/month) Hyper-V | Enabled and running vmcompute | Running vmms | Running vm_bundles folder | Does not exist (never downloaded)What's happening
The Cowork tab does not appear in the main UI. Only "Chat" and "Code" are visible. However, Cowork is visible and configurable in Settings (see screenshot below), confirming the feature flag is active.
The VM module loads successfully but immediately skips startup due to platform detection:
2026-02-17 11:58:43 [info] [VM] Loading vmClient (TypeScript) module... 2026-02-17 11:58:43 [info] [VM] Module loaded successfully 2026-02-17 11:58:43 [info] [Callbacks] VM event callbacks initialized 2026-02-17 11:59:00 [warn] [startVM] VM not supported (win32/x64), skippingThe cleanup routine then marks the configuration as unsupported:
2026-02-17 11:58:40 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...The
%APPDATA%\Claude\vm_bundles\directory does not exist — the VM bundle was never downloaded.What I've tried (nothing worked)
- ✅ All Hyper-V features enabled (Hyper-V, VMP, WHP)
- ✅ vmcompute and vmms both running
- ✅ Logged out and back in
- ✅ Full app reinstall from claude.com/download
- ✅ App restarted multiple times
- ✅ Confirmed latest version v1.1.3189
Hyper-V services confirmed running
powershellPS> Get-Service vmcompute, vmms | Format-Table Name, Status Name Status ---- ------ vmcompute Running vmms RunningKey observation
In #26302, another user on the same version (v1.1.3189) reports that the Cowork VM now starts unconditionally — whereas previous versions logged "yukonSilver not supported, skipping". This suggests the fix is being rolled out via a server-side feature flag that has not yet reached all accounts.
Additionally, the official release notes list Cowork for Pro as "macOS only" so far. If Pro on Windows is still in staged rollout, it would explain why the feature flag is active (Settings visible) but the VM platform check still blocks.
Request
Could someone from the team clarify:
- Is Cowork on Windows currently available for Pro plan users, or only Max/Team/Enterprise?
- If it's a staged rollout, is there an ETA for full availability on Pro + Windows?
- Is the
yukonSilverplatform check controlled server-side (feature flag) or client-side?
Screenshots
[Cowork visible in Settings but tab missing in main UI — screenshot attached]
Confirming this bug on v1.1.3918.0.
Key detail: this is a regression — Cowork was fully working on my machine before this update. Nothing changed on my end (no OS update, no BIOS change, no feature toggle). Only the Claude Desktop auto-update broke it.
Environment: Windows 11 Pro 24H2, Intel i7-14700F, Hyper-V enabled, vmcompute/vmms/CoworkVMService all running. Log shows the same
yukonSilver not supported (status=unsupported)and[startVM] VM not supported (win32/x64), skippingon repeat.Reacted by Simon ProtheroeI also confirming this bug on v1.1.3918. Cowork doesn't work. I kept getting message that Virtualization is not enabled. Windows 11 Pro 24H2, intel Core Ultra 5 125H (1.2Ghz), 32GM. Hyper-V enabled, vm platform enabled, hypervisor enabled.
Log shows yukonSilver not supported (status=unsupported), checking for stale bundle.... and [startVM] VM not supported (win32/x64), skippingConfirming on v1.1.3918.0 with a slightly different environment that may help narrow this down.
Environment:
- Claude Desktop: v1.1.3918.0 (MSIX install via
Get-AppxPackage) - Windows 11 Business 25H2, Build 26200
- Intel Core Ultra 7 255H (Arrow Lake)
- Plan: Max
- Hyper-V: enabled,
vmcompute+vmmsboth Running CoworkVMService: Running (type WIN32_PACKAGED_PROCESS, no errors)vm_bundlesdirectory: does not exist (bundle never downloaded)
Logs (
cowork_vm_node.log):2026-02-21 02:20:18 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle... 2026-02-21 02:20:22 [warn] [startVM] VM not supported (win32/x64), skipping 2026-02-21 02:20:22 [info] [VM] Loading vmClient (TypeScript) module... 2026-02-21 02:20:22 [info] [VM] Module loaded successfully 2026-02-21 02:20:22 [info] [Callbacks] VM event callbacks initialized 2026-02-21 02:20:24 [warn] [startVM] VM not supported (win32/x64), skipping- Claude Desktop: v1.1.3918.0 (MSIX install via
Cowork was working fine yesterday, but after the auto-update it stopped working.
Now it shows the error: "Virtualization is not enabled. Claude's workspace requires hardware virtualization (Hyper-V)."
However, all virtualization settings are properly configured:
Hyper-V: ✅ Enabled
Windows Hypervisor Platform: ✅ Enabled
bcdedit hypervisorlaunchtype: Auto
Hyper-V services: Running
OS: Windows 11 Pro 25H2 (Build 26200)
Claude version: 1.1.3918This appears to be a regression introduced in a recent update. Please fix this.
+1
Hyper-V Enabled.
WSL2 Enabled/working
Chat/Code working.
Docker working.
VT-d/vt-x enabled in bios
Virt machine windows components enabled
Cowork only affected components.=== SYSTEM INFORMATION ===
Platform: win32
Architecture: x64
OS Type: Windows_NT
OS Release: 10.0.19045
OS Version: Windows 10 Pro
CPU Model: Intel(R) Core(TM) Ultra 7 265K
Asus Proart Z890=== APP INFORMATION ===
App Name: Claude
App Version: 1.1.3918
Electron Version: 40.4.1
Chrome Version: 144.0.7559.173
Node Version: 24.13.0
V8 Version: 14.4.258.24-electron.0Bug Report: Claude Cowork — "Virtualization not enabled" on fully compatible Windows 11 Pro x64
Note: Same issue as reported here, with one difference: the Cowork tab does display correctly in Claude Desktop navigation. The error only appears inside the Cowork tab when attempting to start the workspace, preventing any actual use of Cowork.
Date: 2026-02-21 Related issues: #25034, #25136, #25692
Summary
Claude Cowork fails to start on a fully compatible Windows 11 Pro x64 system with Hyper-V properly enabled. The UI displays a misleading error message suggesting BIOS virtualization is disabled, while the actual root cause — confirmed by logs — is that the
yukonSilverVM configuration is incorrectly classified asunsupportedfor thewin32/x64platform by Claude Desktop's internal detection logic.
Environment
Property Value OS Microsoft Windows 11 Pro OS Version 10.0.26100 (Build 26100) OS Edition 24H2 Architecture x64-based PC / 64-bit CPU Intel Core i5 (12th Gen, x64) Claude Desktop Version 1.1.3918.0 (x64)
Windows Virtualization Features — All Enabled ✅
Verified via
optionalfeatures(Windows Features dialog):- Hyper-V ✅ (including all sub-components)
- Virtual Machine Platform ✅
- Windows Hypervisor Platform ✅
PowerShell verification:
Get-ComputerInfo -Property "HyperV*"HyperVisorPresent : True
HyperVRequirementDataExecutionPreventionAvailable :
HyperVRequirementSecondLevelAddressTranslation :
HyperVRequirementVirtualizationFirmwareEnabled :
HyperVRequirementVMMonitorModeExtensions :
Note: The empty
HyperVRequirementfields are expected and normal when Hyper-V is already running — these fields only populate when Hyper-V is NOT active.Windows Services:
Name Status StartType CoworkVMService Running Automatic vmms Running AutomaticBoth
CoworkVMServiceand the Hyper-V Virtual Machine Management service (vmms) are running correctly.
Error Message Displayed in UI
Virtualization is not enabled Claude's workspace requires hardware virtualization (Hyper-V). Enable virtualization in your computer's BIOS/UEFI settings, then restart.This message is misleading and inaccurate — virtualization is confirmed active at both BIOS and OS level. The Cowork tab is visible and accessible, but this error is shown immediately upon entering the tab.
Root Cause —
cowork_vm_node.log2026-02-21 13:32:54 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle... 2026-02-21 13:34:36 [warn] [startVM] VM not supported (win32/x64), skipping 2026-02-21 13:34:36 [info] [Callbacks] Initializing VM event callbacks... 2026-02-21 13:34:36 [info] [VM] Loading vmClient (TypeScript) module... 2026-02-21 13:34:36 [info] [VM] Module loaded successfully 2026-02-21 13:34:36 [info] [Callbacks] VM event callbacks initialized 2026-02-21 13:34:37 [warn] [startVM] VM not supported (win32/x64), skipping 2026-02-21 13:34:40 [warn] [startVM] VM not supported (win32/x64), skipping 2026-02-21 13:36:07 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle... 2026-02-21 13:36:10 [warn] [startVM] VM not supported (win32/x64), skipping 2026-02-21 13:43:11 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle... 2026-02-21 13:43:13 [warn] [startVM] VM not supported (win32/x64), skipping 2026-02-21 13:45:56 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle... 2026-02-21 13:45:58 [warn] [startVM] VM not supported (win32/x64), skipping 2026-02-21 13:50:56 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle... 2026-02-21 13:50:58 [warn] [startVM] VM not supported (win32/x64), skipping [... pattern repeats on every launch attempt ...]The log clearly shows that
yukonSilver(the Cowork VM configuration) is being flagged asstatus=unsupportedand skipped entirely — before any actual VM boot attempt is made. This is a platform detection logic issue inside Claude Desktop, not a hardware or OS configuration problem.
Troubleshooting Steps Attempted — All Unsuccessful
The following fixes were attempted in order:
-
Enabled Hyper-V in BIOS (HP laptop UEFI settings)
- Confirmed Intel VT-x enabled in firmware
- Result: No change
-
Enabled all 3 Windows virtualization features
- Hyper-V (with all sub-components)
- Virtual Machine Platform
- Windows Hypervisor Platform
- Restarted after each change
- Result: No change
-
Clean reinstall of Claude Desktop
- Full uninstall via Windows Settings
- Manual deletion of
%APPDATA%\Claudedirectory - Fresh install from claude.ai/download (v1.1.3918.0)
- Result: No change — same log pattern on first launch
-
Launched Claude Desktop as Administrator
- Right-click → Run as administrator
- Result: No change
-
Disabled ProtonVPN
- In case network filtering interfered with VM detection
- Result: No change
-
Verified CoworkVMService is running
Get-Service CoworkVMService→ Status: Running, StartType: Automatic- Result: Service is running but VM is still classified as unsupported before any boot attempt
Conclusion
The hardware and OS configuration is fully compliant with Cowork requirements:
- Hyper-V is active (
HyperVisorPresent: True) CoworkVMServiceis running- Windows 11 Pro 24H2 x64 — fully supported edition and architecture
- Claude Desktop v1.1.3918.0 — latest available version as of 2026-02-21
The failure originates entirely from Claude Desktop's internal
yukonSilverplatform detection logic incorrectly markingwin32/x64as unsupported. The UI error message pointing to BIOS settings is a red herring that leads users through unnecessary and ineffective troubleshooting steps.Requested fix: Review and correct the
yukonSilverplatform detection logic forwin32/x64on Windows 11 Pro 24H2 (Build 26100). Also consider updating the UI error message to better reflect the actual cause when the issue is a platform detection failure rather than a missing BIOS setting.
System identifiers have been anonymized. This report was generated with the assistance of Claude Chat (claude.ai).
Reacted by Shadow-Grass2 remaining items
Some combo of enabling the "Containers" windows feature (not virtualization, not hyper-v) and installing straight from the msix worked for m on Win 10 Pro (+Ext support).
https://claude.ai/api/desktop/win32/x64/msix/latest/redirect.I had to ensure all of the following were re-enabled after a windows update:
Get-WindowsOptionalFeature -Online | Where-Object {$_.FeatureName -match 'Hyper-V|VirtualMachine|Containers'} | Select FeatureName, State(Found Containers was not enabled).
Fixed in v1.1.3963.0 — Cowork is working again on my machine (Windows 11 Pro 24H2, i7-14700F).
Official acknowledgment: https://status.claude.com/incidents/j6qqhxswnpgw
Additional diagnostic: confirmed
hardware_virt_disabledroot cause — WMI false negative when Hyper-V is already runningReproduces on: Razer Blade / Intel i7-8750H / 32 GB / Windows 11 Pro for Workstations Build 26100 / Claude Desktop 1.1.3918 (a4b368)
main.loggives the explicit reason code (not justcowork_vm_node.log):2026-02-21 20:37:22 [info] [warm] Skipping VM warm download - YukonSilver not supported (hardware_virt_disabled)The WMI contradiction that causes it:
# Returns FALSE on this machine — expected when Hyper-V hypervisor is already running Get-CimInstance Win32_Processor | Select-Object VirtualizationFirmwareEnabled # → False # Returns TRUE — hypervisor IS active (Get-CimInstance Win32_ComputerSystem).HypervisorPresent # → True
When Hyper-V is running, the hypervisor takes ownership of VT-x at boot. From that point on,
Win32_Processor.VirtualizationFirmwareEnabled(and equivalent CPUID/firmware-query paths) returnFalsebecause the OS can no longer query the hardware directly — the hypervisor has abstracted it. This is documented, expected Windows behavior.HypervisorPresent = Trueis the correct API to confirm a hypervisor is active.Full environment confirmation — Hyper-V is fully operational:
Microsoft-Hyper-V-All / Microsoft-Hyper-V / Microsoft-Hyper-V-Hypervisor: Enabled vmcompute: Running | vmms: Running | hypervisorlaunchtype: Auto Get-VMHost: responds with real data (12 logical processors, 32 GB)Proposed fix: In the yukonSilver platform detection function,
hardware_virt_disabledshould not be raised whenHypervisorPresent = True. The check should be:supported = HypervisorPresent === true OR (VirtualizationFirmwareEnabled === true AND Hyper-V features enabled)Not
VirtualizationFirmwareEnabledin isolation — that property is architecturallyFalseon any machine where Hyper-V is already running.Secondary issue (same regression, same timestamp): MCP servers show a startup race condition introduced by the same update — servers connect successfully then fire
server transport closed unexpectedlywithin ~100ms on first Desktop launch, then recover. Both issues began simultaneously when updating from a working version to 1.1.3918. Likely the same startup-sequence regression.Resolution confirmed: v1.1.3963 fixes the yukonSilver detection failure on this machine.
Updated environment: Claude Desktop 1.1.3963 (71a7ae) / Razer Blade i7-8750H / Windows 11 Pro for Workstations Build 26100
Cowork — fully resolved. First successful startup sequence on v1.1.3963:
2026-02-21 22:27:55 [info] rootfs.vhdx not found, downloading... 2026-02-21 22:30:09 [info] rootfs.vhdx.zst checksum validated 2026-02-21 22:30:10 [info] vmlinuz.zst checksum validated 2026-02-21 22:30:19 [info] initrd.zst checksum validated 2026-02-21 22:30:19 [info] All files ready in ...claudevm.bundle 2026-02-21 22:30:38 [info] [VM] Network status: CONNECTED 2026-02-21 22:30:38 [info] [VM] API reachability: REACHABLE 2026-02-21 22:30:41 [info] [VM:start] Startup complete, total time: 165110msNo
yukonSilver not supportedorhardware_virt_disabledentries. Detection logic is corrected in this version.MCP issue — partially resolved, clarification needed. The obsidian server startup disconnects from v1.1.3918 are no longer present in the v1.1.3963 session logs. However, MCP errors are still appearing specifically when clicking the Cowork tab. From main.log,
mcp-registryandClaude in Chromeare both requested at initial app start and then again ~6 seconds later when Cowork is clicked — the Cowork-triggered initialization is showing brief errors that then recover. Whether this is a v1.1.3918 regression or pre-existing behavior on Cowork tab click is unclear without earlier logs to compare against.Separate issue still open: Cowork session data lost across reinstall cycle. The extensive uninstall/reinstall process required to work around the v1.1.3918 regression (full cache deletion, service removal, MSIX package removal) resulted in loss of all prior Cowork workspace sessions. This is a secondary impact of the regression that the fix alone cannot recover — will file separately.
Reacted by colin b. erdmanHey folks, not going to close this out just yet but letting people know that the resolution here is better in-app messaging for why cowork isn't available, something we'll hopefully be doing soon.
For now you can actually find the underlying reason in debug logs for the savvy folks out there (Help -> Troubleshooting -> Show logs).
99% of the time the reason is that you haven't switched to the build of Claude Desktop that supports cowork, you can get this build from claude.com/download - Don't worry it will handle migrating everything from the old build for you, just download it, run it and you should be good
Reacted by colin b. erdmanReacted by jpbehrensFor now you can actually find the underlying reason in debug logs for the savvy folks out there (Help -> Troubleshooting -> Show logs).
Thanks!
After reading your comment, I found the yukonSilver unsupported issue in supported-features-info.json - along with the reason being that it requires MSIX. I don't remember the exakt wording.
I managed to find, download and install from the Claude.msix, after which the Cowork tab was enabled.
Perfect, we just shipped the better in-app messaging for Cowork being disabled. You should now have a disabled Cowork with a handy tooltip explaining what you need to do, or explaining why Cowork is not supported on your system.
Reacted by dkinga and pfI had the same issue, troubleshoot it with claude actually and it did figure out that the the yukonSilver unsupported issue and tried to fix it but couldn't figure it out. eventually I had to open a case [BUG] Cowork tab shows "requires a newer installation" on Windows 11 Build 26200 — yukonSilver marked unsupported #28238
The VM compatibility check rejects Windows 11 Build 26200 as unsupported. This is similar to #25136 which was reportedly fixed in v1.1.2998, but the issue persists on v1.1.4088.any advice on this?
still getting same issue
Same issue here.
Environment:
- Windows 11 Pro, Build 26200, 64-Bit
- AMD Ryzen 7 7700X
- Claude Desktop app-1.1.381 (also tested on 1.0.3218 and 1.1.351)
- WSL2 installed (Ubuntu-24.04, default version 2)
- Hypervisor detected (
systeminfoconfirms)
Logs (
claude_vm_node.log):[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported) [Bundle:status] rootfs.img missing [SwiftVM] Failed to load module: Cannot find package '@ant/claude-swift'This has persisted across multiple app versions and reinstalls. The
@ant/claude-swiftmodule has never been present in any Windows build. Cowork tab does not appear.Update: Enabling Hyper-V fixed the issue.
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All -All
After reboot, Cowork works without errors. The misleading error message ("VM service not running") gives no indication that Hyper-V needs to be enabled manually — a clearer error or automatic prompt would help.
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.
- locked as resolved and limited conversation to collaborators
on Mar 8, 2026
Preflight Checklist
What's Wrong?
I do not get the Cowork tab on Windows Desktop.
Windows 11 Enterprise, 25H2
Hyper-V fully enabled
Latest Claude Desktop (1.1.2685)
Paid plan (Max)
Cowork logs show yukonSilver not supported (status=unsupported) on every launch and @ant/claude-swift module fails to load
What Should Happen?
I should get the Cowork tab.
Error Messages/Logs
Steps to Reproduce
Quit Claude for Windows
Quit system service in the system tray
Download latest Claude
Intall
Windows Features: enabled Hyper V, Virtual Machine Platform, Windows HyperVisor Platform
Shutdown machine
Restart
Launch Claude Desktop for Windows
No cowork 😢
Claude Model
Opus
Is this a regression?
No, this never worked
Last Working Version
No response
Claude Code Version
Claude 1.1.2685 (f39a62) 2026-02-10T19:42:56.000Z
Platform
Other
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
No response