[BUG] Cowork Windows 1.49585.0.0: host attaches Plan9 shares (hr=0x0) and guest sdk-daemon reports ready, but guest mounts nothing — every bash call fails "no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared"; guest console log is 0 bytes
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?
What happened
Since the Claude Desktop MSIX auto-updated to 1.49585.0.0 at 03:21 on 2026-09-09 (Asia/Singapore), the Cowork Linux workspace boots but no host drive share is visible inside the guest. Every bash call in every session — local Cowork tasks, scheduled tasks, and remote sessions bridged to this device — fails immediately at the mount step:
sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
or, from a local Cowork session:
bash failed on resume, create, and re-resume.
resume: RPC error -1: failed to mount .../local_.../outputs as outputs:
source path ... is under Plan9 share "c" which is not mounted;
create: RPC error -1: ensure user: user <session-user> already exists unexpectedly: uid=2988 gid=2988
File tools (list/stage/commit) still work, so the host↔app path is fine. Only the guest's view of the shares is broken.
What the host side says (all healthy)
From C:\ProgramData\Claude\Logs\cowork-service.log on every boot since the update (full trace of the 11:00 boot in the attached evidence file, section 6):
HcsCreateComputeSystem/HcsStartComputeSystem→hr=0x0- All 7 Plan9 shares attached via
HcsModifyComputeSystemwithhr=0x0:c→C:\ (9902),d→D:\ (9903),g→G:\ (9906),i→I:\ (9908),x/y/z→ three SMB network drives (9923–9925), allflags=0x10 hasToken=true Starting daemon console reader … log=C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log[Console] Connected to daemon console pipe[RPC] sdk-daemon connected from VM …→Network status: CONNECTED→sdk-daemon is ready→Sent plan9Shares notification (7 shares)→API reachability: REACHABLE- Sessions then get
Reusing existing sessionand each bash call endsProcess oneshot-… exited: code=1
The exact same 7-share sequence with hr=0x0 appears on every boot before the failure too (2026-09-04 through 2026-09-08), so the host-side configuration has not changed.
What the guest side says (nothing)
- The guest console log is empty. After
Stop-Service CoworkVMService,hcsdiag kill, renaming the old console log away and restarting, the service created a freshuser-<SID>.logand it stayed at 0 bytes through boot, sdk-daemon ready, and the shares notification. - For comparison, a healthy boot of the same daemon (2026-03-30, head of the old log — evidence section 4) narrates every step:
````
[coworkd] console output enabled (writing to /dev/vport0p0)
[updater] checking for updates from /smol/bin … sdk-daemon updated … sandbox-helper updated
[coworkd] detected Hyper-V host, using Plan9 mount
[hyperv] mounting Plan9 share via vsock port 9999
[hyperv] mounting with options: trans=fd,rfdno=6,wfdno=6,msize=1048576,cache=loose,noload,aname=home
[hyperv] Plan9 share mounted at /mnt/.virtiofs-root/shared
- The last successful guest mounts are logged at 2026-09-08 22:41–22:44 (evidence section 3):
[coworkd] mounted /mnt/.virtiofs-root/shared/c/Users/kanus/… at /sessions/<user>/mnt/… (mode=rw)— i.e. the per-drive layout was working under the prior app version, on this same Windows build, after the 2026-09 cumulative update had been installed and the machine rebooted.
So: the daemon that connects over vsock after the update neither writes to the console nor mounts the shares it is told about.
What Should Happen?
Guest mounts the 7 shares the host attached (as it did on 2026-09-08 22:44) and ~/mnt/<folder> is populated.
Error Messages/Logs
Steps to Reproduce
- Start Claude Desktop 1.49585.0.0; open any Cowork task with a folder connected.
- Ask it to run
ls ~/mnt(or any bash). - Observe
sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
1.49585.0.0
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
_No response_
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗