[BUG] Cowork Windows — Shell/Bash Cannot Mount Connected Folders (Plan9/virtiofs)

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?

Bug Report: Cowork Windows — Shell/Bash Cannot Mount Connected Folders (Plan9/virtiofs)

Summary

On Windows 11, Cowork's shell (bash) tool cannot mount connected project folders via the virtiofs/Plan9 host-share protocol, regardless of how the folder is connected. Every shell command that touches the folder fails with sandbox-helper: no Plan9 drive shares mounted. File-level tools (Read/Write/Edit, and the device_list_dir/device_stage_files/device_commit_files bridge) reach the same folder without any problem, which isolates the failure specifically to the shell-mount path.

This has now been reproduced on two separate, recently-updated Windows 11 machines.
---

What Should Happen?

Shell/bash commands run inside a Cowork task should be able to reach the same connected folder(s) that the file Read/Write/Edit tools already reach, via a properly mounted host share.

Error Messages/Logs

Steps to Reproduce

1. Open Claude Desktop on Windows 11 with Cowork enabled.
2. Connect a local project folder (tested via both the Trusted Cowork Folders list and an ad-hoc mid-session "connect a folder" prompt — same result either way).
3. Start a Cowork task and run any shell command, e.g.:

``
echo shell-ok && python3 --version && python3 -c "import jsonschema; print('jsonschema', jsonschema.__version__)" && ls "$HOME/mnt/"
``

1. Observed: the command fails. stderr shows:

``
sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
``
with Claude noting the connected folder "failed to mount and cannot be reached from this shell," while confirming the same folder is "still reachable via device_list_dir / device_stage_files / device_commit_files."

1. Meanwhile: Read/Write/Edit file operations against the identical folder succeed normally in the same session.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

claude-code-vm 2.1.260

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Environment

| Property | Value |
|---|---|
| OS | Windows 11 (two machines affected) |
| Claude Desktop version | 1.49585.0.0 (x64, MSIX package Claude_pzs8sxrjxfjjc) |
| Cowork/SDK version | claude-code-vm 2.1.260 |
| VM bundle hash | 2a762adfc2eea13eca0d113a2e6452ff00ae3f62 |
| Hyper-V / Virtual Machine Platform | Both confirmed Enabled |
| VM memory setting | 4GB |
| Cloud execution ("Only on this computer") | Enabled (local-only) at time of testing |
| Dispatch (phone remote control) | Off at time of testing |
| Working folder location | Local NTFS folder inside user home directory — not OneDrive, not a network/virtual drive |

Actual Behavior

The shell environment reports zero Plan9 drive shares mounted. Any shell command referencing the connected folder's path fails, while file-level tools against the identical folder work normally in the same session.

Relevant Log Excerpt

From %LOCALAPPDATA%\Claude\Logs\cowork_vm_node.log, after a clean VM boot (Startup complete, total time: 5571ms, API reachability: REACHABLE):

2026-09-10 16:01:05 [info] [vmOneShot] Running: bash [2 arg(s)] as rcw-01vckqsfrm2ifkahudlsno3r
2026-09-10 16:01:06 [warn] [vm-stderr oneshot-] sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
2026-09-10 16:01:11 [info] [vmOneShot] Running: bash [2 arg(s)] as rcw-01vckqsfrm2ifkahudlsno3r
2026-09-10 16:01:11 [warn] [vm-stderr oneshot-] sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared

Secondary Issue Encountered (may share a root cause)

While troubleshooting, we also hit a distinct VM startup failure that may be related:

1. A VM process (vmwp/vmmem) became stuck holding a lock on smol-bin.vhdx. Two consecutive startup attempts (5 minutes apart) both failed at the same step:

``
[warn] [VM:start] smol-bin.vhdx locked by running VM (EBUSY), skipping copy
[info] [VM:start] Configuring Windows VM service...
[error] [VM:start] Startup failed: Error: Request timed out: configure
[warn] [VM:start] Skipping auto-reinstall (service transport error), leaving VM offline (will retry on next app launch)
``

1. Killing vmwp caused it to immediately respawn under a new PID rather than clearing. A full OS reboot was required to actually clear the stuck process.
2. After reboot, a subsequent workspace start hit a different error — workspace re-creation stuck on a "user-already-exists" conflict, with Cowork's own UI stating: "The shell workspace is failing to mount — it hit an infrastructure error (a required folder path isn't mounted, and workspace re-creation is stuck on a user-already-exists conflict. Retrying won't fix this on my end.)"
3. Deleting the VM's writable overlay disk (vm_bundles\claudevm.bundle\sessiondata.vhdx, keeping rootfs.vhdx intact) cleared this specific conflict and the VM subsequently booted cleanly — but the original Plan9 mount failure (this report's main issue) persisted afterward.

Troubleshooting Already Attempted (all ruled out)

1. Confirmed Hyper-V and Virtual Machine Platform Windows features both Enabled via Get-WindowsOptionalFeature -Online.
2. Restarted the vmcompute service.
3. Killed stuck vmwp/vmmem processes — respawned immediately; required a full OS reboot to actually clear.
4. Full OS reboot — resolved the separate stuck-VM/timeout issue described above; VM subsequently booted cleanly and reached API reachability.
5. Confirmed "Only on this computer" (local-only execution / cloud execution mode off) was already enabled — rules out cloud execution as a cause.
6. Confirmed the working folder is a plain local NTFS folder inside the user's home directory — not OneDrive, not a network or virtual drive.
7. Removed and re-added the project folder in Trusted Cowork Folders, then started a fresh Cowork task — no change.
8. Deleted sessiondata.vhdx to clear the stale "user-already-exists" conflict (see above) — fixed that specific conflict, VM now boots cleanly, but the Plan9 mount failure persisted.
9. Confirmed the general Cowork storage folder (C:\Users\<user>\Claude) is not itself separately registered as a Trusted Cowork Folder — rules out a folder-nesting cause (a connected folder living inside another connected folder).
10. Confirmed "Dispatch" (phone remote-control feature) was off during a clean reproduction — rules out the device-bridge/cloud-dispatch path as the cause.
11. Tested two different folder-connection mechanisms (persistent Trusted Cowork Folder entry, and an ad-hoc mid-session "connect a folder" prompt) — identical failure both ways.

Impact

All shell-dependent Cowork workflows (running scripts, checking installed packages, git operations, etc.) are unusable for this project on both affected machines. File-level read/write/edit work is unaffected.