[BUG] Cowork tab not showing — yukonSilver unsupported despite HCS/Hyper-V confirmed working post-reboot (Windows 11 Pro, Pro plan) Description:

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 does not appear in Claude Desktop despite being on a Pro plan and having all documented local VM prerequisites verified working. Diagnosis below shows the app's own yukonSilver support check reports status=unsupported even after every local-machine requirement it checks for passes, which points to a gate beyond local machine capability (account/workspace-level, not OS-level).

Environment:

OS: Windows 11 Pro, build 10.0.26200, x64
Claude Desktop version: 1.22209.3.0 (MSIX install, package Claude_pzs8sxrjxfjjc)
Install type: Microsoft Store / modern installer (MSIX) — confirmed correct per app's own msix_required check
Plan: Pro
Steps taken before filing:

Enabled "Virtual Machine Platform" Windows optional feature
Rebooted machine (confirmed via Get-CimInstance Win32_OperatingSystem | LastBootUpTime = 2026-07-21 21:39:22)
Relaunched Claude Desktop after reboot
Verified working (all pass):

Hypervisor detected and active (systeminfo confirms Hyper-V requirements met)
vmcompute (Hyper-V Host Compute Service): Running
HvHost (HV Host Service): Running
CoworkVMService (cowork-svc.exe, path: C:\Program Files\WindowsApps\Claude_1.22209.3.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe): Running, StartMode Auto
No local override disabling the feature found in Preferences (checked for secureVmFeaturesEnabled)
Actual behavior:

main.log, timestamped after the reboot, still shows the feature marked unsupported:

2026-07-21 21:41:16 [info] [VM] Loading vmClient (TypeScript) module...
2026-07-21 21:41:16 [info] [VM] Module loaded successfully
2026-07-21 21:41:16 [info] [Bundle:status] rootfs.vhdx missing
2026-07-21 21:41:16 [info] [Bundle:status] vmlinuz missing
2026-07-21 21:41:16 [info] [Bundle:status] initrd missing
and from an earlier run the same session:

[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
Because the check reports unsupported, the app never downloads the required VM bundle files (rootfs.vhdx, vmlinuz, initrd), so Cowork can never initialize.

Code-level analysis (from app.asar, function a$n() which computes the yukonSilver support object):

The check evaluates, in order: platform (win32/darwin) → arch (x64/arm64) → MSIX install → OS build ≥ 19041 → HCS availability (getHcsStatus(), service = vmcompute) → then, only if all of those pass, an account/workspace-level gate:

const n = Oe();
return n.workspace.secureVmEnabled === !1
? unsupported("disabled_by_enterprise")
: n.coworkSurface.enabled
? (Ct("secureVmFeaturesEnabled") === !1 ? unsupported("disabled_by_user") : supported())
: unsupported("disabled_by_enterprise" / reason: "" /);
Every local-machine condition ahead of this block is satisfied on this system (OS build, arch, MSIX, HCS all confirmed live). That means the unsupported result is most likely coming from n.coworkSurface.enabled being false — an account/workspace-side flag, not anything fixable from the OS or app settings. This is not an enterprise-managed account, so disabled_by_enterprise shouldn't apply, which suggests the rollout gate for this account simply isn't flipped on yet despite the account being Pro.

Expected behavior:
Cowork tab should appear and the VM bundle should download, since all documented local prerequisites are met.

Related issues: This appears to be the same underlying issue as #25136, #48407, #50495, #51208 — all report the identical yukonSilver not supported state on Windows 11 Pro machines with virtualization correctly configured.

What Should Happen?

Cowork tab does not appear in Claude Desktop despite being on a Pro plan and having all documented local VM prerequisites verified working. Diagnosis below shows the app's own yukonSilver support check reports status=unsupported even after every local-machine requirement it checks for passes, which points to a gate beyond local machine capability (account/workspace-level, not OS-level).

Environment:

OS: Windows 11 Pro, build 10.0.26200, x64
Claude Desktop version: 1.22209.3.0 (MSIX install, package Claude_pzs8sxrjxfjjc)
Install type: Microsoft Store / modern installer (MSIX) — confirmed correct per app's own msix_required check
Plan: Pro
Steps taken before filing:

Enabled "Virtual Machine Platform" Windows optional feature
Rebooted machine (confirmed via Get-CimInstance Win32_OperatingSystem | LastBootUpTime = 2026-07-21 21:39:22)
Relaunched Claude Desktop after reboot
Verified working (all pass):

Hypervisor detected and active (systeminfo confirms Hyper-V requirements met)
vmcompute (Hyper-V Host Compute Service): Running
HvHost (HV Host Service): Running
CoworkVMService (cowork-svc.exe, path: C:\Program Files\WindowsApps\Claude_1.22209.3.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe): Running, StartMode Auto
No local override disabling the feature found in Preferences (checked for secureVmFeaturesEnabled)
Actual behavior:

main.log, timestamped after the reboot, still shows the feature marked unsupported:

2026-07-21 21:41:16 [info] [VM] Loading vmClient (TypeScript) module...
2026-07-21 21:41:16 [info] [VM] Module loaded successfully
2026-07-21 21:41:16 [info] [Bundle:status] rootfs.vhdx missing
2026-07-21 21:41:16 [info] [Bundle:status] vmlinuz missing
2026-07-21 21:41:16 [info] [Bundle:status] initrd missing
and from an earlier run the same session:

[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
Because the check reports unsupported, the app never downloads the required VM bundle files (rootfs.vhdx, vmlinuz, initrd), so Cowork can never initialize.

Code-level analysis (from app.asar, function a$n() which computes the yukonSilver support object):

The check evaluates, in order: platform (win32/darwin) → arch (x64/arm64) → MSIX install → OS build ≥ 19041 → HCS availability (getHcsStatus(), service = vmcompute) → then, only if all of those pass, an account/workspace-level gate:

const n = Oe();
return n.workspace.secureVmEnabled === !1
? unsupported("disabled_by_enterprise")
: n.coworkSurface.enabled
? (Ct("secureVmFeaturesEnabled") === !1 ? unsupported("disabled_by_user") : supported())
: unsupported("disabled_by_enterprise" / reason: "" /);
Every local-machine condition ahead of this block is satisfied on this system (OS build, arch, MSIX, HCS all confirmed live). That means the unsupported result is most likely coming from n.coworkSurface.enabled being false — an account/workspace-side flag, not anything fixable from the OS or app settings. This is not an enterprise-managed account, so disabled_by_enterprise shouldn't apply, which suggests the rollout gate for this account simply isn't flipped on yet despite the account being Pro.

Expected behavior:
Cowork tab should appear and the VM bundle should download, since all documented local prerequisites are met.

Related issues: This appears to be the same underlying issue as #25136, #48407, #50495, #51208 — all report the identical yukonSilver not supported state on Windows 11 Pro machines with virtualization correctly configured.

Error Messages/Logs

Steps to Reproduce

Cowork tab does not appear in Claude Desktop despite being on a Pro plan and having all documented local VM prerequisites verified working. Diagnosis below shows the app's own yukonSilver support check reports status=unsupported even after every local-machine requirement it checks for passes, which points to a gate beyond local machine capability (account/workspace-level, not OS-level).

Environment:

OS: Windows 11 Pro, build 10.0.26200, x64
Claude Desktop version: 1.22209.3.0 (MSIX install, package Claude_pzs8sxrjxfjjc)
Install type: Microsoft Store / modern installer (MSIX) — confirmed correct per app's own msix_required check
Plan: Pro
Steps taken before filing:

Enabled "Virtual Machine Platform" Windows optional feature
Rebooted machine (confirmed via Get-CimInstance Win32_OperatingSystem | LastBootUpTime = 2026-07-21 21:39:22)
Relaunched Claude Desktop after reboot
Verified working (all pass):

Hypervisor detected and active (systeminfo confirms Hyper-V requirements met)
vmcompute (Hyper-V Host Compute Service): Running
HvHost (HV Host Service): Running
CoworkVMService (cowork-svc.exe, path: C:\Program Files\WindowsApps\Claude_1.22209.3.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe): Running, StartMode Auto
No local override disabling the feature found in Preferences (checked for secureVmFeaturesEnabled)
Actual behavior:

main.log, timestamped after the reboot, still shows the feature marked unsupported:

2026-07-21 21:41:16 [info] [VM] Loading vmClient (TypeScript) module...
2026-07-21 21:41:16 [info] [VM] Module loaded successfully
2026-07-21 21:41:16 [info] [Bundle:status] rootfs.vhdx missing
2026-07-21 21:41:16 [info] [Bundle:status] vmlinuz missing
2026-07-21 21:41:16 [info] [Bundle:status] initrd missing
and from an earlier run the same session:

[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
Because the check reports unsupported, the app never downloads the required VM bundle files (rootfs.vhdx, vmlinuz, initrd), so Cowork can never initialize.

Code-level analysis (from app.asar, function a$n() which computes the yukonSilver support object):

The check evaluates, in order: platform (win32/darwin) → arch (x64/arm64) → MSIX install → OS build ≥ 19041 → HCS availability (getHcsStatus(), service = vmcompute) → then, only if all of those pass, an account/workspace-level gate:

const n = Oe();
return n.workspace.secureVmEnabled === !1
? unsupported("disabled_by_enterprise")
: n.coworkSurface.enabled
? (Ct("secureVmFeaturesEnabled") === !1 ? unsupported("disabled_by_user") : supported())
: unsupported("disabled_by_enterprise" / reason: "" /);
Every local-machine condition ahead of this block is satisfied on this system (OS build, arch, MSIX, HCS all confirmed live). That means the unsupported result is most likely coming from n.coworkSurface.enabled being false — an account/workspace-side flag, not anything fixable from the OS or app settings. This is not an enterprise-managed account, so disabled_by_enterprise shouldn't apply, which suggests the rollout gate for this account simply isn't flipped on yet despite the account being Pro.

Expected behavior:
Cowork tab should appear and the VM bundle should download, since all documented local prerequisites are met.

Related issues: This appears to be the same underlying issue as #25136, #48407, #50495, #51208 — all report the identical yukonSilver not supported state on Windows 11 Pro machines with virtualization correctly configured.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Desktop version: 1.22209.3.0

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Cowork tab does not appear in Claude Desktop despite being on a Pro plan and having all documented local VM prerequisites verified working. Diagnosis below shows the app's own yukonSilver support check reports status=unsupported even after every local-machine requirement it checks for passes, which points to a gate beyond local machine capability (account/workspace-level, not OS-level).

Environment:

OS: Windows 11 Pro, build 10.0.26200, x64
Claude Desktop version: 1.22209.3.0 (MSIX install, package Claude_pzs8sxrjxfjjc)
Install type: Microsoft Store / modern installer (MSIX) — confirmed correct per app's own msix_required check
Plan: Pro
Steps taken before filing:

Enabled "Virtual Machine Platform" Windows optional feature
Rebooted machine (confirmed via Get-CimInstance Win32_OperatingSystem | LastBootUpTime = 2026-07-21 21:39:22)
Relaunched Claude Desktop after reboot
Verified working (all pass):

Hypervisor detected and active (systeminfo confirms Hyper-V requirements met)
vmcompute (Hyper-V Host Compute Service): Running
HvHost (HV Host Service): Running
CoworkVMService (cowork-svc.exe, path: C:\Program Files\WindowsApps\Claude_1.22209.3.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe): Running, StartMode Auto
No local override disabling the feature found in Preferences (checked for secureVmFeaturesEnabled)
Actual behavior:

main.log, timestamped after the reboot, still shows the feature marked unsupported:

2026-07-21 21:41:16 [info] [VM] Loading vmClient (TypeScript) module...
2026-07-21 21:41:16 [info] [VM] Module loaded successfully
2026-07-21 21:41:16 [info] [Bundle:status] rootfs.vhdx missing
2026-07-21 21:41:16 [info] [Bundle:status] vmlinuz missing
2026-07-21 21:41:16 [info] [Bundle:status] initrd missing
and from an earlier run the same session:

[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
Because the check reports unsupported, the app never downloads the required VM bundle files (rootfs.vhdx, vmlinuz, initrd), so Cowork can never initialize.

Code-level analysis (from app.asar, function a$n() which computes the yukonSilver support object):

The check evaluates, in order: platform (win32/darwin) → arch (x64/arm64) → MSIX install → OS build ≥ 19041 → HCS availability (getHcsStatus(), service = vmcompute) → then, only if all of those pass, an account/workspace-level gate:

const n = Oe();
return n.workspace.secureVmEnabled === !1
? unsupported("disabled_by_enterprise")
: n.coworkSurface.enabled
? (Ct("secureVmFeaturesEnabled") === !1 ? unsupported("disabled_by_user") : supported())
: unsupported("disabled_by_enterprise" / reason: "" /);
Every local-machine condition ahead of this block is satisfied on this system (OS build, arch, MSIX, HCS all confirmed live). That means the unsupported result is most likely coming from n.coworkSurface.enabled being false — an account/workspace-side flag, not anything fixable from the OS or app settings. This is not an enterprise-managed account, so disabled_by_enterprise shouldn't apply, which suggests the rollout gate for this account simply isn't flipped on yet despite the account being Pro.

Expected behavior:
Cowork tab should appear and the VM bundle should download, since all documented local prerequisites are met.

Related issues: This appears to be the same underlying issue as #25136, #48407, #50495, #51208 — all report the identical yukonSilver not supported state on Windows 11 Pro machines with virtualization correctly configured.