[BUG] Windows Cowork: device_bash permanently dead — "no Plan9 drive shares mounted", survives app restart and full OS reboot

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] Windows Cowork: device_bash permanently dead — "no Plan9 drive shares
mounted", survives both app restart and full OS reboot

Summary

On Windows, the local-agent-mode sandbox fails to attach the C: drive Plan9/virtiofs
share. device_bash is therefore unusable — it hard-aborts on every command, including
commands that never touch a mounted folder. This survives a full computer restart, so it
is not stale VM state that a restart clears.

Environment

• Platform: win32 x64
• App version: 1.49585.0
• Electron 44.2.0 / Node 24.20.0
• MSIX package identity: Claude_pzs8sxrjxfjjc
• Two connected folders, both under C:

Original error (scheduled-task runs, 5 identical failures)

Failed on all three paths — resume, create, and re-resume:

resume: RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/Users/<user>/
AppData/Local/Packages/Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/
local-agent-mode-sessions/<account>/<project>/<session>/outputs as outputs:
source path ... is under Plan9 share "c" which is not mounted

create: RPC error -1: ensure user: user <sandbox-name> already exists
unexpectedly: uid=1049 gid=1049

Affected sessions:

• local_7d7a2dbd-2e28-4b6a-a298-807b9ee34c31
• local_707a1acc-c93c-4d0e-9d91-9979687a013e

What I tried, in order

1. Retry the tool call — 5 identical failures, no change.
2. Close and reopen the desktop app — NO EFFECT, identical error.
3. Full computer restart — PARTIAL FIX ONLY (see below).

Post-reboot state — the key finding

The reboot cleared the second fault but not the first:

• FIXED: the ensure user: ... already exists unexpectedly collision is gone. That half

genuinely was stale sandbox state.

• NOT FIXED: the Plan9 C: share still never attaches. The error is now raised earlier

and more cleanly:

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

It aborts on ANY command, e.g. echo hi; id; uname -a, which touches no mount.

Capability matrix after reboot:

| Capability | Status |
|---------------------------------------------------|----------|
| Device link (get_device_info) | works |
| device_list_dir | works |
| device_stage_files | works |
| device_bash | BROKEN |

So the app-level file bridge is healthy while the VM's drive share is not — they fail
independently.

Expected vs actual

Expected: device_bash starts a shell with connected folders mounted under $HOME/mnt/.
Actual: sandbox-helper refuses to start any shell because no drive share is mounted.

Impact

A scheduled task that uses device_bash to file its output cannot complete. In my case a
daily automated data pull runs, produces its file, and then cannot write it — failing
silently in the same shape as a "no data available" run, which corrupts the record used to
detect genuinely missing days.

Note for triage

Because this survives a full OS reboot, the two faults look separate: the stale-user
collision is recoverable state, but the missing C: share appears to be a provisioning
failure that no user-side restart clears.

What Should Happen?

device_bash should start a shell on the local sandbox with the session's connected
folders mounted read/write under $HOME/mnt/, and commands should execute normally.

Specifically:

1. The C: drive Plan9/virtiofs share should be attached to the sandbox VM, so that

mount targets under /mnt/.virtiofs-root/shared/c/... resolve.

1. Connected folders should appear under $HOME/mnt/ and be readable and writable.
2. A command that touches no mounted folder at all (e.g. echo hi; id; uname -a)

should succeed regardless of folder mount state, rather than hard-aborting the
entire shell.

1. If the drive share genuinely cannot be attached, the failure should be recoverable

by restarting the app — and certainly by a full OS reboot. Neither currently
clears it.

Point 3 is worth treating as a separate defect: even when no folders can be mounted,
the sandbox should still provide a working shell, since a scheduled task could
otherwise fall back to the file-bridge tools (device_stage_files /
device_commit_files), which remain healthy while device_bash is down.

Error Messages/Logs

Steps to Reproduce

Note: I have not identified what initially triggers the fault. It appeared
spontaneously between scheduled runs, with no app update, no Windows update, and no
change to connected folders on my side. What follows is the exact sequence I
observed, plus a one-line reproducer for the failed state once it is present.

Minimal reproducer (once the fault is present)

Call device_bash with a command that touches nothing:

echo hi; id; uname -a

Expected: normal output.
Actual: exit code 1, no command output, and:

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

This reproduces 100% of the time, on every invocation, with any command.

Observed sequence

1. Windows desktop app, two folders connected to the session, both under C:.

device_bash had been working normally against these folders for weeks.

1. A scheduled task configured to run daily fired. Its run failed before executing

any task logic — the sandbox itself could not come up. Error (three paths, all
failing):

resume: RPC error -1: failed to mount .../outputs as outputs:
source path ... is under Plan9 share "c" which is not mounted

create: RPC error -1: ensure user: user <sandbox-name> already exists
unexpectedly: uid=1049 gid=1049

1. The next day's scheduled run failed identically — same two-part error, different

session ID and different sandbox name/uid.

1. Retried the tool call 5 times. Byte-identical failure each time; only the internal

"attempt N of 5 since last success" counter changed.

1. Fully closed and reopened the desktop app. NO EFFECT — identical error.
2. Performed a full Windows restart.
3. After reboot, ran the minimal reproducer above. Result: PARTIALLY changed.

• The ensure user: ... already exists unexpectedly error is GONE.
• The Plan9 share failure REMAINS, now surfacing earlier as the

sandbox-helper: no Plan9 drive shares mounted message above.

Confirming the file bridge is unaffected

In the same session, immediately after the failing device_bash call, these all
succeed against the same connected folders:

• get_device_info -> returns device info, folders listed
• device_list_dir -> lists directory contents correctly
• device_stage_files -> transfers file contents intact

So the app-level file bridge and the sandbox VM's drive share fail independently.
This is useful for narrowing where to look: whatever attaches the Plan9 share is
failing while the path used by device_list_dir / device_stage_files is fine.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.49585.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_