[BUG] Cowork (Windows): cloud session guest never mounts the host Plan9/virtiofs folder shares (offered every boot); not fixed by a fresh session or VM rebuild, while device_list_dir/stage/commit work

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?

UPDATE (see the correction comment below): the original framing here - that the mount "never re-attaches until the next session," and that a fresh session rebuilds it - is wrong. On the affected machine the mount stayed down through a fresh session, a full app quit-and-relaunch, deleting the VM session disk, a complete VM-image rebuild, and a workspace reinstall. The host offers all three drive shares on every boot; the guest never mounts them. The text below is the original report, kept for history.

In a Cowork cloud session linked to a Windows desktop, connected folders are exposed to the session's shell (device_bash) as a Plan9/virtiofs share under $HOME/mnt/. When the desktop-app bridge is interrupted while the session keeps running - most reliably by rebooting the Windows machine - the shell mount is severed and never re-attaches for the rest of that session. Every device_bash call touching the folders then fails with:

sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared

Meanwhile the one-shot file tools (device_list_dir, device_stage_files, device_commit_files) recover automatically and keep reaching the same folders by device path. So file access is not lost - only the shell's live mount, which is what bulk operations, in-place edits, and shell-driven skills rely on. The asymmetry (file tools heal, shell mount does not) is the defect.

Rebooting is the reliable trigger, so a machine that reboots nightly loses the mount in any session left running across the night, every night.

What Should Happen?

When the desktop bridge reconnects after an interruption, the session's shell mount should re-attach automatically, exactly as the one-shot device file tools already do over the same bridge - or there should be a supported way to remount it in-session without ending the session. Recovering the file tools but leaving the shell mount permanently dead for the life of the session is the defect.

Error Messages/Logs

sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared

[Note: <folder> failed to mount and cannot be reached from this shell. Those connected folders are still reachable via device_list_dir / device_stage_files / device_commit_files, by their paths on this device.]

Steps to Reproduce

1. Start a Cowork cloud session linked to a Windows desktop, with a local folder connected. Confirm device_bash can list it under $HOME/mnt/.
2. With the session still alive in the cloud, reboot the Windows machine (or otherwise interrupt the desktop-app bridge).
3. After the machine returns and the device link reconnects: device_list_dir on the folder succeeds, but ls "$HOME/mnt/<folder>" via device_bash fails with "sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared".
4. The mount does not return for the rest of the session and there is no in-session remount. Correction: a brand-new session does NOT rebuild it either - nor does quitting and relaunching the app, deleting the VM session disk, rebuilding the whole VM image, or reinstalling the workspace (see the comment below).

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop (Cowork) on Windows 11 Pro - this is a Cowork/desktop issue, not the CLI; exact desktop build not recorded at the time.

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Related to the same cloud-to-desktop bridge fragility as #91645 (VM idle-shutdown, never restarts) and #88921 (silent connect/disconnect loop, "workspace unavailable"), but this is a distinct symptom: the shell folder-mount specifically fails to recover, while the device file tools do recover over the same bridge.

Distinct from the Windows startup-mount-failure family (e.g. #25132, #25096), where the local desktop VM never mounts the host share at boot on Windows Home. Here the cloud session's mount works normally, then drops after a reboot mid-session and never re-attaches, while the one-shot file tools keep working throughout.

Environment: Cloud Cowork session linked to a Windows 11 Pro desktop; connected folder on a local D: drive. The drop is reliably triggered by a Windows reboot while the cloud session stays alive; on a machine that reboots frequently it recurs constantly. There is no known self-serve fix: a fresh session does not rebuild the mount. File access continues through device_list_dir / device_stage_files / device_commit_files; the durable trigger appears to be the machine's frequent reboots, and the fix is Anthropic-side. See the comment below for the full evidence.