Cowork (Windows): plan9 share of a mapped SMB network-drive folder goes stale mid-session and never remounts; sessions end without outputs

Status Open

Reported on v2.1.219

Maintainer reply None cached

Activity 0 comments · opened Aug 4, 2026

Summary

In Cowork sessions on Windows, a project folder that lives on a mapped SMB network drive (e.g. R: → \server\share) is bridged into the sandbox VM as a plan9 share. Mid-session, that share goes stale: paths under the VM-side mount start returning No such file or directory, workspaceMcpServer bash commands begin timing out at exactly 45000 ms, and the mount never recovers for the life of the VM. Sessions end without being able to write their final outputs back to the network folder. Restarting the desktop app (rebuilding the VM) is the only recovery.

The host-side drive is healthy the entire time: Windows logs zero SMB disconnect events over the same period, and the same folders read instantly from any other process.

Environment

Claude desktop app 1.24012.x (MS Store install, Claude_1.24012.9.0_x64__pzs8sxrjxfjjc), updater last seen 1.24012.11
claude-code VM SDK 2.1.219
Windows 11 Pro 10.0.26200
Folder attached to the Cowork session lives on a mapped network drive R: backed by \<fileserver>\<share> (SMB, same LAN, sub-ms latency)

Symptoms (from `%APPDATA%\Claude\logs`)

cowork_vm_node.log — the VM-side mount of the attached network folder disappears mid-session (folder names redacted):

2026-08-03 16:50:02 [warn] [vm-stderr oneshot-] cp: cannot create regular file '/home/rcw-…/mnt/<FOLDER>/<SUBFOLDER>/<FILE>.docx': No such file or directory
2026-07-15 10:01:19 [warn] [vm-stderr oneshot-] ls: cannot access '/sessions/…/mnt/<FOLDER>/<SUBFOLDER>/': No such file or directory
2026-07-14 08:48:52 [warn] [vm-stderr oneshot-] cp: cannot create regular file '/sessions/…/mnt/<FOLDER>/<SUBFOLDER>/<FILE>.docx': No such file or directory

main.log — around the same episodes, every bash command through the workspace bridge dies at the 45 s ceiling (seen 7/29, 7/30, 7/31 ×2, 8/03):

2026-08-03 08:04:59 [warn] [workspaceMcpServer] bash failed: Command timed out after 45000ms { failedMounts: [], … }

Note failedMounts: [] — the stale share is not detected as failed, so nothing attempts a remount.

Host-side during the same window: Microsoft-Windows-SMBClient/Connectivity has no events, net use shows the drive OK, and Test-Path/directory listing of the same folders from PowerShell responds in ~1 ms.

Impact

Long-running Cowork sessions working against network-drive folders fail near the end: all processing succeeds, but the final copy of deliverables back to the mounted folder hits ENOENT, so the session ends with no usable output where the user expects it.
The mount never self-heals; users keep prompting a session whose filesystem bridge is dead.

Expected

Either (a) the plan9 share layer detects a stale handle on an SMB-backed host path and re-opens/remounts transparently, or (b) the failure is surfaced to the agent/user as "workspace folder disconnected — reattach or restart" instead of generic ENOENT + 45 s command timeouts.

Possibly related

The non-Cowork local file bridge shows a similar pattern with network paths: claude.ai-web.log has 100+ LocalFileAccessError: [INVALID_PATH] Failed to resolve path: R:\… from FileSystem_readLocalFile when chats reference files on the mapped drive across sessions.

View original on GitHub ↗