[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

Status Open
Maintainer reply None cached
Activity 1 comment · opened Sep 9, 2026

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 / HcsStartComputeSystemhr=0x0
  • All 7 Plan9 shares attached via HcsModifyComputeSystem with hr=0x0: c→C:\ (9902), d→D:\ (9903), g→G:\ (9906), i→I:\ (9908), x/y/z → three SMB network drives (9923–9925), all flags=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: CONNECTEDsdk-daemon is readySent plan9Shares notification (7 shares)API reachability: REACHABLE
  • Sessions then get Reusing existing session and each bash call ends Process 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 fresh user-<SID>.log and 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_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗