Open Cowork Sandbox disabled — yukonSilver marked "unsupported" on Windows 11 Pro with all virtualization features enabled

[acubura]

App Version

3.3.1

Platform

Windows

Bug Description

What happened?
The Sandbox toggle in Open Cowork Settings remains permanently disabled. The app never attempts to download the VM bundle or start the sandbox. No sandbox-related logs are written.

The app appears to be using the yukonSilver platform detection module which incorrectly classifies fully capable Windows 11 Pro x64 systems as "unsupported" (win32/x64) despite all virtualization prerequisites being met and confirmed working.

This is a false negative detection bug that prevents the sandbox from initializing at all.

Steps to Reproduce

1. Fresh install Windows 11 Pro x64
2. Enable all virtualization features: Hyper-V, Virtual Machine Platform, Windows Hypervisor Platform
3. Install WSL2 with Ubuntu-24.04
4. Install Open Cowork v3.3.1
5. Launch Open Cowork as Administrator
6. Go to Settings → Sandbox
7. Observe: The toggle is disabled and cannot be enabled
8. The vm_bundles folder is never created
9. No VM-related logs are written

Expected Behaviour

The Sandbox toggle should enable, allowing the app to create a WSL2 VM environment for isolated command execution.

Actual Behaviour

• The Sandbox toggle is permanently disabled
• The app never downloads the VM bundle
• No VM-related logs appear
• The app runs in native execution mode with path-based restrictions only
• The vm_bundles folder is never created

Relevant Logs or Error Output

===============================================================================
Open Cowork Application Log
Started: 2026-07-16T10:24:28.064Z
Platform: win32
Arch: x64
Node: v22.16.0
Electron: 35.7.5
App Version: 3.3.1
===============================================================================

[2026-07-16 10:24:28.065] [INFO] [dotenv] Loading from: C:\Program Files\Open Cowork\resources\app.asar\.env
[2026-07-16 10:24:28.066] [WARN] [dotenv] Failed to load .env: ENOENT, .env not found in C:\Program Files\Open Cowork\resources\app.asar

---

Second log:

===============================================================================
Open Cowork Application Log
Started: 2026-07-16T10:25:37.155Z
Platform: win32
Arch: x64
Node: v22.16.0
Electron: 35.7.5
App Version: 3.3.1
===============================================================================

[2026-07-16 10:25:37.156] [WARN] [OneShot] Model not in pi-ai registry, using synthetic model: openai/gemma4:e4b → openai-completions

---

**Note:** There are NO sandbox-related logs (`yukonSilver`, `cleanupVMBundleIfUnsupported`, VM startup attempts, etc.). The detection fails silently before any VM-related logging occurs.

Additional Context

System Information:

• OS: Windows 11 Pro x64
• Open Cowork Version: 3.3.1
• Installation: Per-machine install at C:\Program Files\Open Cowork

All Virtualization Features Confirmed Working:

• Hyper-V: Enabled
• Virtual Machine Platform: Enabled
• Windows Hypervisor Platform: Enabled
• WSL2: Installed and running (Ubuntu-24.04, Version 2)
• vmms service: Running
• vmcompute service: Running
• Hardware virtualization (BIOS): Enabled
• systeminfo: "A hypervisor has been detected. Features required for Hyper-V will not be displayed."

What I've Tried (all unsuccessful):

• Enabled all Windows virtualization features
• Installed WSL2 with Ubuntu-24.04
• Confirmed WSL2 is running (wsl -l -v shows Running)
• Confirmed Hyper-V services are running (vmms, vmcompute)
• Confirmed hardware virtualization is enabled in BIOS
• Ran Open Cowork as Administrator
• Uninstalled conflicting software (Claude Desktop was previously installed and removed)
• Full clean reinstall of Open Cowork
• Deleted all app data folders between reinstalls
• Restarted PC multiple times

This appears to be the same yukonSilver detection bug that has affected Claude's Cowork on Windows. The detection module incorrectly classifies win32/x64 on Windows 11 Pro as "unsupported" despite all virtualization features being operational.

Similar issues reported in Claude's Cowork:

• #32004: yukonSilver marked as unsupported on Windows 11 Pro
• #27385: yukonSilver not supported on Windows 11 Pro x64 with Intel Core Ultra 9 285K
• #47327: Cowork tab disabled — yukonSilver unsupported on Windows 11 Pro x64
• #27499: VM not supported (win32/x64) on Windows 11 Pro 25H2

[github-actions]

Thank you for the detailed bug report, @acubura. You've provided excellent diagnostic information.

Issue Confirmation: This is a verified bug in the platform detection logic used to determine sandbox (VM) support on Windows. The sandbox initialization never proceeds because the yukonSilver detection module incorrectly flags win32/x64 as unsupported on Windows 11 Pro, despite all virtualization prerequisites being met.

Relevant code (estimated):

• src/main/sandbox/index.ts or src/main/sandbox/platform-check.ts – the function that calls yukonSilver or equivalent detection. The false negative likely stems from a version check that does not account for Windows 11 or a build number threshold.
• The log evidence is clear: no VM-related logs (cleanupVMBundleIfUnsupported, vmBundles folder creation) appear, confirming the detection fails silently before sandbox initialization.

What the team will investigate:

1. The exact platform/version check that returns unsupported for win32/x64 on Windows 11.
2. Whether the detection filters by Windows release (e.g., 10 vs 11) or WSL2 availability.
3. Ensuring that a fully virtualization-capable Windows 11 system is correctly recognized as supported.

Workaround (temporary): If urgent, you can try running with the --no-sandbox flag to disable sandbox entirely (but this won't enable VM isolation). The proper fix requires code changes in the detection module.

Thank you again for the clear reproduction steps and logs. We'll tag this for the core team to prioritize in the next release.

---

Open Cowork Bot