claude-code - 💡(How to fix) Fix Cowork VM: "Failed to create bridge sockets after 5 attempts" on every session start [2 comments, 3 participants]

Environment

• Claude Desktop: 1.3036.0
• Claude Code SDK (in VM): 2.1.111
• macOS: 26.5 beta (build 25F5042g)
• Apple Silicon M3 Max (arm64)

Symptoms

Every Cowork task fails immediately with "Claude Code process exited with code 1". 100% reproducible across: app restart (3x), full VM reboot, complete sessiondata.img reset, fresh session creation, and multiple different tasks (including a brand new session with only "hello" as input).

Logs from ~/Library/Logs/Claude/cowork_vm_node.log

[Spawn:vm] id=<uuid> Spawn succeeded in 58ms
[vm-stderr <uuid>] Error: Failed to create bridge sockets after 5 attempts
[Process:<uuid>] Exited, code=1, signal=null, duration=~1000ms, oom=false

The VM itself boots and reaches guest_ready cleanly ([VM:start] Startup complete, total time: 6154ms, API reachability: REACHABLE, SDK install succeeds). The failure is exclusively at the per-session claude spawn, ~1s after process start.

Root cause traced in the guest claude binary

In the sandbox-runtime function that initializes the Linux HTTP/SOCKS bridges (bundled as u57 in the minified output), two socat processes are spawned:

socat UNIX-LISTEN:/tmp/claude-http-<hex>.sock,fork,reuseaddr  TCP:localhost:<httpPort>,...
socat UNIX-LISTEN:/tmp/claude-socks-<hex>.sock,fork,reuseaddr TCP:localhost:<socksPort>,...

Both spawn calls succeed (no "Linux bridge process died unexpectedly" in logs). The function then polls fs.existsSync on both socket paths for 5 attempts with incremental backoff (0, 100, 200, 300, 400 ms). On each failed iteration the sockets don't appear, and on the 5th the function throws:

throw Error(`Failed to create bridge sockets after ${j} attempts`)

Suspected cause

Elsewhere in the same binary the seccomp-filter module states:

[SeccompFilter] The current seccomp filter only blocks socket(AF_UNIX, ...)

So the sandbox is designed to deny AF_UNIX socket creation to the sandboxed child — but the two socat bridge processes (spawned as children of the parent process to prepare the sandbox) appear to inherit that filter in this environment. That would explain: socat alive, no crash, but no .sock file ever created (the bind() would ENOSYS/EACCES silently for a plain UNIX-LISTEN).

May be macOS-26.5-beta-specific: Virtualization.framework behavior around process-creation / filter inheritance has changed across beta seeds, which could break an assumption the sandbox-runtime makes on stable macOS.

What I tried (none worked)

• Quit Claude.app + relaunch (3×)
• Full VM reboot (VM bundle rebuild, fresh guest_ready)
• Rename ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/sessiondata.img aside and let VM regenerate a fresh empty one
• Brand-new Cowork session with only "hello" as input
• Verified no stale sockets on host side in the session's shim-perm/{requests,responses} dirs

Reproducibility

100% on this machine. Happy to provide fuller log excerpts or run diagnostics — just let me know.