### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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? Environment Claude Desktop 1.49585.0, Electron 44.2.0, Node 24.20.0

[BUG] Connected folders never mount inside VM — host reports Plan9 share added successfully, guest sees none

Status Open

Maintainer reply None cached

Activity 8 comments · 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?

<html>
<body>
<p dir="ltr"><strong>Environment</strong></p>
<ul dir="ltr">
<li>Claude Desktop 1.49585.0, Electron 44.2.0, Node 24.20.0</li>
<li>Windows 11 Home, build 26200 (25H2)</li>
<li>Framework Laptop 13, 12th Gen i5-1240P, 32 GB RAM</li>
<li>C: 237.4 GB used / 1,668.3 GB free</li>
<li>VM bundle freshly downloaded 2026-09-09 (9.01 GB, verified complete)</li>
</ul>
<p dir="ltr"><strong>Summary</strong></p>
<p dir="ltr">The Cowork VM boots successfully and reaches full health, but no connected folder is ever mounted inside it. Any shell command fails before running, with:</p>
<div><div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared</code></pre></div></div></div>
<p dir="ltr">All connected folders fail together, consistent with the single <code>c -> C:\</code> root share never mounting in the guest. Host-side file operations (list / stage / commit) work normally throughout.</p>
<p dir="ltr"><strong>Host log shows complete success</strong></p>
<p dir="ltr"><code>C:\ProgramData\Claude\Logs\cowork-service.log</code>:</p>
<div><div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">18:06:05.797828 [VM] Plan9 share added: c -> C:\ (port=9902, readOnly=false)
18:06:06.049771 [HCS] HcsStartComputeSystem returned: hr=0x0
18:06:06.145425 [VM] Adding Plan9 share via HcsModifyComputeSystem: name=c path=C:\ port=9902 flags=0x10 hasToken=true
18:06:06.145425 [HCS] HcsModifyComputeSystem returned: hr=0x0
18:06:21.700306 [VM] VM started successfully
18:06:24.338784 [RPC] sdk-daemon is ready
18:06:26.073355 [VM] Installed 66 CA certificates in guest
18:06:26.266356 [RPC] API reachability: REACHABLE</code></pre></div></div></div>
<p dir="ltr">No error appears anywhere. The host completes its entire sequence, including <code>API reachability: REACHABLE</code>, while the guest has nothing mounted.</p>
<p dir="ltr"><strong>Ruled out</strong></p>
<div dir="ltr">
Cause | Evidence
-- | --
Virtualization / Windows features | VM boots and reaches REACHABLE
Disk space | 1,668 GB free
Corrupt or stale VM image | Bundle deleted and re-downloaded same day; identical behaviour on the fresh image
Service failure | Separate fault, fixed by reboot; service now runs clean
Individual folder permissions | All four connected folders fail together

</div>
<p dir="ltr"><strong>Additional observation</strong></p>
<p dir="ltr">The app's own logs (<code>...\LocalCache\Roaming\Claude\logs\</code>) have not been written since 2026-08-20 19:48, across at least three app versions. There is a dangling <code>latest</code> symlink in that folder that <code>Copy-Item</code> cannot resolve; removing it did not restore logging. This may be a symptom rather than a separate issue — a guest that can't mount its filesystem view plausibly can't log either.</p>
<p dir="ltr"><strong>Impact</strong></p>
<p dir="ltr"><code>device_bash</code> is entirely unavailable. File staging and committing still work, so the session remains usable for file operations at reduced speed.</p>
<p dir="ltr"><strong>Possibly related:</strong> #60631, #64592, #45883, #56145, #55404</p>
</body>
</html>

What Should Happen?

Connected folders mount inside the VM under $HOME/mnt/<folder-name>, and shell
commands can read and write them.

Error Messages/Logs

Steps to Reproduce

On Windows, connect one or more local folders to a Cowork session.
Open Claude Desktop and let the workspace start.
Confirm the VM booted successfully — C:\ProgramData\Claude\Logs\cowork-service.log

ends with "[RPC] API reachability: REACHABLE".

Run any shell command in the session (e.g. ls).
The command never executes.

Note on reproducibility: onset was spontaneous rather than triggered by a specific
action. Once in this state it is 100% reproducible on every call, and persists across:

restarting the desktop app
stopping and starting CoworkVMService
a full Windows restart
deleting vm_bundles and re-downloading the complete 9.01 GB image

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.49585.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗

4 Comments

guorillas · 2 days ago

Same issue over here. It has something to do with windows update kb:5124008. If you delete this it will work again..

pjosto · 2 days ago

Second machine, same failure — and I can attribute it to a specific Windows update, which this report is missing.

Same error, verbatim:

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

Environment (from get_device_info):

{
  "platform": "win32",
  "arch": "x64",
  "appVersion": "1.49585.0",
  "electronVersion": "44.2.0",
  "nodeVersion": "24.20.0"
}

Identical app/Electron/Node versions to the OP.

Windows:

> Get-ComputerInfo | Select-Object OsBuildNumber, WindowsVersion
OsBuildNumber WindowsVersion
------------- --------------
26200         2009

> Get-HotFix -Id KB5124008
Description      HotFixID     InstalledBy          InstalledOn
-----------      --------     -----------          -----------
Security Update  KB5124008    NT AUTHORITY\SYSTEM  2026-09-09

This looks like the same root cause as #92984. That issue identifies KB5124008 (build 26200.9445) as the trigger; my machine has exactly that KB, installed 2026-09-09, and that is the day device_bash stopped working here. Before that date it had been working for weeks with no configuration change on my side. Suggest linking the two reports.

What still works: only the in-VM mount is broken. The device bridge itself is fine — device_list_dir, device_stage_files and device_commit_files all work normally against the same connected folders, so the host↔guest channel is up and this is specifically the Plan9 share mount. Sessions remain usable through stage/commit, just slower.

Not tried: the wusa /uninstall /kb:5124008 workaround from #92984. It is a security update and Windows Update would re-offer it, so I am waiting for a fix rather than rolling it back. Happy to run diagnostics on an unmodified affected machine if that helps — this box reproduces it 100%.

koes01 · 2 days ago

HFAD_ENV_BUGREPORT_20260910_2002.md

oafcontrols-byte · 2 days ago

Same failure on Windows 11 25H2, x64 — and I believe #92984 has the root cause for this issue: KB5124008.

My environment matches this report exactly:

Claude Desktop 1.49585.0, Electron 44.2.0, Node 24.20.0
Windows 11 Pro, build 26200.9445
x64, so distinct from the ARM64 report in #92958
device_bash fails 100% of the time on every command including echo, with:

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

device_list_dir and device_stage_files work normally throughout

Onset correlates with the KB, not with an app update. KB5124008 installed 2026-09-10; the shell broke the same morning. I had assumed the Claude app update that morning was the trigger until I checked the update history.

Plan9 / Hyper-V component versions here, against those listed in #92984:

| file | this machine | #92984 |
|---|---|---|
| p9rdr.sys | 10.0.26100.9444 | 10.0.26100.9444 ✅ |
| p9np.dll | 10.0.26100.9278 | 10.0.26100.9278 ✅ |
| computestorage.dll | 10.0.26100.9444 | 10.0.26100.9444 ✅ |
| vmcompute.exe | 10.0.26100.1 | 10.0.26100.8875 ❌ |
| vmwp.exe | 10.0.26100.1 | 10.0.26100.8875 ❌ |

The two vm* mismatches may just be how those binaries report FileVersion on this machine — read via (Get-Item ...).VersionInfo.FileVersion. Flagging rather than hiding it.

Already ruled out here, consistent with the original report: multiple full Windows restarts (not one — several across the day), fully quitting and reopening the desktop app, and removing and re-adding the connected folder. None of it changed anything.

Negative control, same account, second machine: a Windows 10 host (build 19045.6466) running the older Claude Desktop 1.46388.4 works normally. Its connected folder mounts as FUSE — /proc/self/fd/3 on <folder> type fuse — and /mnt/.virtiofs-root/shared does not exist on it at all. So the Plan9 share mechanism appears to be new in 1.49585.0, and KB5124008 is a Windows 11 24H2/25H2 update that a Windows 10 host cannot receive. That would account for only the newer app on Windows 11 being affected.

I have not uninstalled the KB — this is a working laptop and I'd rather not drop September's security fixes. Happy to run diagnostics if it would help narrow it.

Showing cached comments. Read the full discussion on GitHub ↗