[BUG] [Cowork] mcp__workspace__bash sandbox VM still fails to start — 2-month persistent outage (ref #76374)

Also hitting this — Windows, Cowork desktop app, persists across full reboot

App version: 1.49585.0 (Electron 44.2.0, Node 24.20.0), Windows x64
device_bash/mcp__workspace__bash has failed on nearly every call over an extended session, cycling through three different error states rather than settling on one:
sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
Workspace unavailable. The isolated Linux environment on this device failed to start. Use device_stage_files / device_commit_files instead.
Once, Workspace still starting. The isolated Linux environment on this device is booting in the background (usually 10–30 seconds). Try again shortly. — the only sign of it attempting to come up — but the very next call reverted to error (1) rather than completing.
Separately (and I think independently), the connected project folder dropped out of the session entirely at one point (connectedFolders came back empty from get_device_info). Re-running the folder-access request fixed that part cleanly and the user was able to approve it — so that specific permission dialog isn't always broken, but see below.
In a different, freshly-started chat, the folder-connect permission dialog was unresponsive — cursor disappeared and clicking "Allow" didn't register, blocking folder connection entirely in that session. Not clear yet whether that's the same root cause or a separate UI bug.
Throughout all of this, get_device_info and device_list_dir reliably succeed and list the real folder contents correctly — so the device connection and file-listing path is solid; the fault is isolated to spinning up the actual Linux VM shell.
Tried, none of which produced a lasting fix: retrying repeatedly, restarting the app, a full machine reboot, re-requesting folder access.
device_stage_files / device_commit_files do work, but can't substitute for a shell — no way to run tests, git, or any build step.

Happy to provide more diagnostics if there's something specific you want checked.

Thanks @idcsmith1-Atlas — that's a second, independent machine with the same failure, which rules out a single-device config issue.

The most actionable clue there is the error: sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared. This localizes the fault to the virtiofs/9p share mount during VM boot, not to the connection layer — get_device_info and device_list_dir succeed reliably, and device_stage_files/device_commit_files work; only spinning up the isolated Linux VM shell fails (60s timeout).

Summary for triage:

• Fault isolated to sandbox VM startup (virtiofs/Plan9 share not mounted), not device connectivity or file listing.
• - Reproduces across independent machines (Windows 11 ARM64 and x64), persists across app restart and full reboot — points to app/infra, not local config.
• - - Ongoing ~2 months (since July 9, 2026).

Happy to capture sandbox-helper logs or run any specific diagnostic if that helps.

Environment

• OS: Windows 11 Home
• Claude Desktop version: 1.49585.0
• Architecture: x64

Symptom

Two related failures, same underlying cause:

1. Cowork initially failed to start the local workspace at all, with the

error "Failed to start Claude's workspace" / VM service not running.

1. After troubleshooting (below) and a full reinstall, a scheduled task

in Cowork still failed partway through — file tools worked, but the
shell tool did not. Verbatim from that task's own output:

> the shell tool needed for md5sum failed to mount 5 times in a row
> this session ("workspace appears wedged... retrying will not help").
> File read/write/glob/grep all worked fine — only the shell sandbox
> is down.

So this isn't an all-or-nothing failure: file read/write/glob/grep
continue to work normally in the same session. Only the shell/bash
sandbox is affected, and it fails consistently rather than
intermittently once it's in this state.

Troubleshooting already completed, in order:

1. Rebooted the computer.
2. Fully quit Claude Desktop from the system tray (not just closed the

window) and relaunched.

1. Confirmed vmcompute (Hyper-V Host Compute Service) is Running

(Get-Service vmcompute).

1. Confirmed the hypervisor is set to launch at boot

(bcdedit /enum → hypervisorlaunchtype Auto).

1. Checked Event Viewer under both

Applications and Services Logs > Microsoft > Windows > Hyper-V-Compute > Admin
and ...> Hyper-V-VMMS > Admin — no Error-level entries around the
failure times in either log.

1. Confirmed ~200GB free on the system drive (C:) — not a disk-space

issue.

1. Fully uninstalled Claude Desktop, rebooted, reinstalled the latest

version from claude.ai — the shell sandbox failure recurred on a
subsequent scheduled task afterward.

None of the standard Hyper-V/VM-level checks or fixes changed anything,
which matches the pattern already reported in #57968, #76374/#92008,
and #55649 — the failure seems to be inside Claude's own VM/sandbox
orchestration rather than a local Hyper-V misconfiguration, since Windows
itself reports a clean bill of health throughout.

Related issues: #92008, #76374, #57968, #55649 — all describe the
same "bash/shell sandbox specifically fails, file tools unaffected"
pattern on Windows.

Ask: is there a known root cause or ETA on this? Happy to share
Claude Desktop's debug logs if that's useful — let me know what you need.

An additional data point for the engineers, from the sibling reports:

#55649 traces the failure to secureconnectionservice.exe crashing, after which CoworkVMService fails to initialize. That lines up with the sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared state reported here — the VM service never brings the virtiofs/9p share up.

This same "shell/bash sandbox fails while file tools keep working" pattern on Windows spans a long chain of reports going back to April/May 2026: #50997, #52359, #55404, #55649, #56145, #57968, #76374 — and at least #55649 and #57968 were closed as not-planned + duplicate + stale with no official response or fix. #92008 is the current live instance.

Given the recurrence, an engineering root-cause on the CoworkVMService / secureconnectionservice startup path (rather than another inactivity close) would really help. Happy to capture Claude Desktop debug logs or the secureconnectionservice crash details if that's useful.