[BUG] Cowork VM hangs mounting Plan9 share during startup — deterministic, host-side, distinct from #76094

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?

After fixing the sdk-daemon startup crash described in #76094 (which was masking this bug — the VM used to crash before ever reaching this stage), cowork now hangs indefinitely mounting one specific Plan9 (9P) share during VM startup, causing the host to eventually abort with "connection forcibly closed" or a 60s timeout.

This is not the sdk-daemon crash from #76094 — that's fully fixed and verified (patched binary, confirmed via journal logs). This is a distinct, downstream issue.

Reproduction and evidence

Guest-side journal (captured via SyncIntervalSec=1 journald override + reading rootfs.vhdx directly, since the VM gets killed before the default 5-minute journal flush and loses the trace otherwise):

[hyperv] mounting Plan9 share "c" via vsock port 9902 at /mnt/.virtiofs-root/shared/c
[hyperv] Plan9 share "c" mounted at /mnt/.virtiofs-root/shared/c
[hyperv] mounting Plan9 share "g" via vsock port 9906 at /mnt/.virtiofs-root/shared/g
[hyperv] failed to mount Plan9 share "g": Plan9 mount failed: file exists
[hyperv] mounting Plan9 share "x" via vsock port 9923 at /mnt/.virtiofs-root/shared/x
[hyperv] Plan9 share "x" mounted at /mnt/.virtiofs-root/shared/x
[hyperv] mounting Plan9 share "y" via vsock port 9924 at /mnt/.virtiofs-root/shared/y

...and then nothing. No success message, no failure message, no further coworkd log lines at all. No kernel-level segfault or OOM-kill entry (journalctl -k clean). The mount() syscall for share "y" simply never returns. A few seconds later the host gives up and kills the VM:

failed to send request: failed to write message: An existing connection was forcibly closed by the remote host.

(from the host's perspective — this is the VM being killed out from under the still-open vsock connection, not the guest actively closing anything.)

What I ruled out

This reproduces 100% deterministically, at the exact same point (share "y", vsock port 9924), regardless of:

• rootfs state — reproduces identically on a completely fresh rootfs.vhdx rebuilt from the app's own pristine rootfs.vhdx.zst snapshot, vs. a rootfs.vhdx that had accumulated ~4 months of session history (24 recovered users).
• sdk-daemon binary version/content — same hang with the original binary (before the #76094 crash even applied — different SHA than the one in #76094) and with the patched one.
• Number of enabled plugins — same hang with 6 Anthropic plugins enabled vs. 2 (which should reduce the .remote-plugins/* share count in the mounts= list passed to getVMStorageSubpath).
• Number of previously-mounted shares — always exactly 3 shares attempt-mount successfully/fail-fast (c, g, x), then the 4th (y) hangs forever. Share g additionally fails immediately with "file exists" every time, on both a stale and a completely fresh rootfs — suggesting the mountpoint directory or share-ID assignment has a stale-state bug independent of anything guest-side.

Given the guest's mount() call never returns (not a guest crash — no crash signature anywhere in guest logs), and the host eventually gives up and force-kills the VM (cowork_vm_node.log: "Still waiting for guest connection..." / "request timed out after 30s" / "An existing connection was forcibly closed by the remote host" depending on which stage it's caught at), this looks like the host-side Plan9 (9P) file-server listener for this particular share never accepts the guest's connection — i.e. a bug in the Electron/Node-side share-orchestration code (add_plan9_shares / getVMStorageSubpath), not in the guest.

What Should Happen?

All configured Plan9 shares should mount successfully (or fail fast with a clear error, like share "g" does) within the startup timeout, and cowork should become usable.

Error Messages/Logs

Failed to start Claude's workspace
failed to send request: failed to write message: An existing connection was forcibly closed by the remote host.
Restarting Claude or your computer sometimes resolves this. If it persists, you can reinstall the workspace or share your debug logs to help us improve.

Full cowork_vm_node.log excerpt around the failure:

[VM] Network status: CONNECTED
[VM:steps] sdk_install started
[postConnect] Installing SDK: subpath=c/Users/<user>/AppData/Roaming/Claude/claude-code-vm, version=2.1.205
[error] [VM:start] Startup failed: Error: failed to send request: failed to write message: An existing connection was forcibly closed by the remote host.
[VM:start] Skipping auto-reinstall (already attempted once)

Steps to Reproduce

1. Ensure the sdk-daemon startup crash from #76094 is not occurring (patched binary, or lucky timing)
2. Start Claude Desktop, open cowork
3. Attempt to start a cowork workspace
4. VM boots, coworkd starts, connects RPC successfully, mounts 2-3 Plan9 shares — then hangs indefinitely on one specific share
5. Host times out after 30-60s and kills the VM

Claude Model

Sonnet (default)

Is this a regression?

Unknown — this bug was likely always present but masked by the sdk-daemon startup crash (#76094), which always killed the VM before Plan9 mounting completed. Once that crash is worked around, this becomes the new blocker.

Claude Code Version

This is a claude desktop issue — App 1.20186.1.0

Platform

Claude Pro/Max

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Related: #76094 (the sdk-daemon startup crash that was masking this issue — has a full binary-level root-cause analysis and a working workaround, but that workaround alone is not sufficient to get cowork fully working because of this separate bug).