claude-code - 💡(How to fix) Fix Cowork VM agents fail with 'Failed to create bridge sockets after 5 attempts' on Claude Desktop 1.3036.0.0 (Windows) [6 comments, 4 participants]

Environment

• Claude Desktop: 1.3036.0.0 (x64, Windows 11)
• Package: Claude_1.3036.0.0_x64__pzs8sxrjxfjjc
• claude-code-vm: 2.1.111
• VM bundle version: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
• Windows: 10.0.19045.7184
• WSL: 2.6.3.0, kernel 6.6.87.2-1
• Cowork service: CoworkVMService (Windows service, user-mode, LocalSystem)
• Dispatch (non-VM agent path): working
• Cowork (VM-based agent path): broken, 100% reproducible

Symptom

Every Cowork agent spawn exits with code 1 approximately 2 seconds after launch. The VM boots cleanly, SDK installs, plan9 mounts succeed, OAuth token is approved, user account epic-wonderful-planck is created in the VM. Then the in-VM /usr/local/bin/claude starts and immediately fails its linuxBridge setup.

Three consecutive reproductions within the same session:

• 13:03:01 [vm-stderr 19005686] Error: Failed to create bridge sockets after 5 attempts
• 13:20:03 [vm-stderr cb56548c] Error: Failed to create bridge sockets after 5 attempts
• 13:48:44 [vm-stderr e26cc6e3] Error: Failed to create bridge sockets after 5 attempts

Host-side log excerpt

From %APPDATA%\Claude\logs\cowork_vm_node.log:

[info] [VM:start] Startup complete, total time: 15680ms
[info] [Spawn:vm] id=cb56548c... OAuth token approved with MITM proxy
[info] [Spawn:vm] id=cb56548c... Spawn succeeded in 85ms
[warn] [vm-stderr cb56548c] Error: Failed to create bridge sockets after 5 attempts
[info] [Process:cb56548c...] Exited, code=1, signal=null, duration=2709ms, oom=false

VM-side log excerpt

From %PROGRAMDATA%\Claude\Logs\coworkd\user-S-*.log:

[proxy] MITM proxy started on /var/run/mitm-proxy.sock
[coworkd] mounted 2/2 Plan9 shares
[process:cb56548c...] started PID 4729
[process:cb56548c...] direct child exited: code=1 signal=<nil>
[cgroup] cgroup cb56548c... is now empty (waited 65µs)

PID 4729 exits in under 2s, before producing any in-VM diagnostic output.

Root cause (decompilation of claude-code-vm/2.1.111/claude)

Function u4K(host, port) spawns two socat processes that forward UNIX sockets to TCP:

K = path.join(os.tmpdir(), `claude-http-${hex}.sock`);
_ = path.join(os.tmpdir(), `claude-socks-${hex}.sock`);
A = [`UNIX-LISTEN:${K},fork,reuseaddr`,
     `TCP:localhost:${H},keepalive,keepidle=10,keepintvl=5,keepcnt=3`];
f = child_process.spawn("socat", A, {stdio:"ignore"});
if (!f.pid) throw Error("Failed to start HTTP bridge process");

The retry loop polls existsSync(K) && existsSync(_) five times at 0/100/200/300/400ms then throws. Process f still has a pid at that point (Node reports pid synchronously; the 'error' event for ENOENT fires asynchronously), so the "Linux bridge process died unexpectedly" branch is not taken. With stdio:"ignore", socat's stderr is discarded — the actual failure reason is invisible.

The in-VM MITM proxy listens on a UNIX socket (/var/run/mitm-proxy.sock), not a TCP port. The socat target is TCP:localhost:${H}. This looks like a protocol mismatch between what the in-VM claude binary bridges to and what the VM exposes in this version.

Reproduction

Any Cowork message in any workspace reproduces. "hello" is sufficient. Does not require specific content or tool use.

What was ruled out

• Stale VM bundle: renamed claudevm.bundle → forced fresh 13 GB recopy from Program Files. Same failure.
• Stale VM SDK cache: renamed claude-code-vm/2.1.111 → forced redownload. Same failure.
• Service not running: verified CoworkVMService was RUNNING across all reproductions.
• Auto-reinstall lock: cleared .auto_reinstall_attempted marker. Same failure.
• Host MCP server interference: removed Obsidian MCP from claude_desktop_config.json. Same failure.
• Host-level config: Dispatch uses the same claude_desktop_config.json and works perfectly.
• isCoworkSdkDebuggingEnabled: true — setting produced no additional detail at the VM/bridge boundary.
• Skill count: ~/.claude/skills/ has 2,628 skills (mostly symlinks). Unrelated — Dispatch loads them fine.
• Windows Subsystem for Linux update: event log shows WSL Update 5.10.102.1 attempted install 2026-04-16 02:40 AM but failed with MSI status 1633 ("not supported by this processor type"). WSL was not actually modified.

Workaround

Use Dispatch (host-side claude-code spawned via dispatchTrustedCodeWorkspaces) instead of Cowork. Dispatch does not use the VM bridge code path and works correctly.

Suggested fixes

1. Capture socat stderr. Change stdio:"ignore" to a piped stream in u4K and log it. The actual bind failure reason will surface.
2. Verify in-VM MITM proxy endpoint. Currently the VM exposes it at /var/run/mitm-proxy.sock (UNIX). The claude binary's bridge targets TCP:localhost:${H}. Reconcile these.
3. Widen the retry window. Current total wait is ~1s (5 × w*100ms where w=0..4). Cold-start socat on a Hyper-V guest under load may need more.
4. Detect ENOENT on spawn. Don't rely solely on !f.pid — attach .once('error', ...) and fail fast with a clear message if the binary isn't found.

Log evidence

Available for upload. Files:

• cowork_vm_node.pre-fix-20260416-125424.log — original failure, before any mitigation
• post-cleanup-cowork_vm_node.log — failure after fresh VM bundle/SDK
• vm-guest-coworkd.log — VM guest perspective (24 MB)
• cowork-service.log — Hyper-V service layer

User impact

Cowork was working on 2026-04-15 and is broken on 2026-04-16. Uninstall + reinstall of Claude Desktop restored it once on 2026-04-15 but did not on 2026-04-16. Bug appears to be consistent with 1.3036.0.0 specifically; a prior installation that self-updated to this version exhibits the same behavior.