claude-code - 💡(How to fix) Fix Cowork/Dispatch VM spawns fail with "Failed to create bridge sockets after 5 attempts" after MSIX 1.2773.0.0 → 1.3036.0.0 update (Windows 11) [4 comments, 4 participants]

Summary

After the Claude Code desktop app auto-updated from MSIX 1.2773.0.0 → 1.3036.0.0 today, every Cowork / Dispatch VM spawn fails immediately with:

Error: Failed to create bridge sockets after 5 attempts

The VM itself boots fine, networking is up, OAuth approval succeeds — failure is deterministic in the VM-side CLI's socat bridge setup, ~800-1000ms after spawn.

Environment

• OS: Windows 11
• Claude Code desktop: 1.3036.0.0 (Microsoft Store MSIX, package Claude_pzs8sxrjxfjjc)
• Previous MSIX (working): 1.2773.0.0 (installed ~Apr 10, updated today Apr 16 14:07 local)
• CCD version: 2.1.111 (was 2.1.92 before — but see "What we ruled out" below)
• Models tried: Opus 4.6 and 4.7 (both fail identically, and model is irrelevant — failure is before any model call)

Timeline (from %APPDATA%\Claude\logs\cowork_vm_node.log + MSIX Get-AppPackageLog)

Failure pattern (every attempt)

VM boots cleanly:

[VM:start] Startup complete, total time: 5614ms
[VM] Network status: CONNECTED
[VM] API reachability: REACHABLE
[VM:steps] sdk_install completed (977ms)

Spawn is confirmed:

[Spawn:vm] OAuth token approved with MITM proxy
[Process] Spawn confirmed, flushing 2 buffered stdin chunks
[Spawn:vm] Spawn succeeded in 72ms

~800-1000ms later, the CLI inside the VM fails and exits 1:

[vm-stderr] Error: Failed to create bridge sockets after 5 attempts
[Process] Exited, code=1, signal=null, duration=1046ms, oom=false

Where it fails (decompiled from the VM-side claude binary)

Roughly:

async function createBridge(httpPort, socksPort) {
    let id = randomBytes(8).toString("hex");
    let httpSock  = path.join(os.tmpdir(), `claude-http-${id}.sock`);
    let socksSock = path.join(os.tmpdir(), `claude-socks-${id}.sock`);

    let a = spawn("socat", [
        `UNIX-LISTEN:${httpSock},fork,reuseaddr`,
        `TCP:localhost:${httpPort},keepalive,keepidle=10,keepintvl=5,keepcnt=3`
    ], { stdio: "ignore" });
    // ... same for socks ...

    for (let w = 0; w < 5; w++) {
        if (!a.pid || a.killed || !o.pid || o.killed)
            throw Error("Linux bridge process died unexpectedly");
        if (existsSync(httpSock) && existsSync(socksSock)) break;
        if (w === 4) throw Error(`Failed to create bridge sockets after 5 attempts`);
        await sleep(w * 100);
    }
}

The loop waits up to ~1s (0+100+200+300+400ms) for socat to create the two UNIX-LISTEN sockets in /tmp inside the VM. It's hitting the final throw, which means either:

1. socat is missing / wrong version in the new rootfs,
2. /tmp isn't writable for the user the CLI runs as in the new VM image, or
3. a new seccomp/AppArmor policy is blocking bind(AF_UNIX, …) or the clone/exec path.

The stderr line is exactly Failed to create bridge sockets after 5 attempts — no died unexpectedly, so the socat processes are starting, they just never create the sockets.

What we ruled out

• Not CCD 2.1.111 vs 2.1.92. I swapped both the host claude.exe and the VM-side Linux claude binary back to verified 2.1.92 builds (SHA-256 matched against downloads.claude.ai/claude-code-releases/2.1.92/...) while leaving the MSIX-supplied components (rootfs bundle, cowork-svc.exe, smol-bin.x64.vhdx) untouched. Same error. Binaries have been reverted to 2.1.111.
• Not corrupt bundle. Deleted %APPDATA%\Claude\vm_bundles\claudevm.bundle\ and let it re-download the full 9.4 GB rootfs.vhdx. Same error. The rootfs that redownloaded is the one the new MSIX's manifest points at (bundle SHA 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d), so this is a new rootfs shipped with 1.3036.0.0.
• Not stale bridge state. Deleted %APPDATA%\Claude\bridge-state.json. Same error.
• Not Defender. Added exclusions for claude.exe, %APPDATA%\Claude, %LOCALAPPDATA%\Claude. Same error.
• Not transient. Full Windows reboot. Same error. 16/16 spawns fail.
• Not auth. OAuth token approved with MITM proxy prints immediately before each failure.

Most likely culprit

The MSIX 1.3036.0.0 update shipped either a new rootfs.vhdx / smol-bin.x64.vhdx that's missing or misconfiguring socat inside the VM, or cowork-svc.exe is mounting /tmp in a way the CLI's UNIX-LISTEN sockets can't use. File mtimes on C:\Program Files\WindowsApps\Claude_1.3036.0.0_x64__pzs8sxrjxfjjc\app\resources\{cowork-svc.exe, smol-bin.x64.vhdx} are both Apr 16 14:07 — i.e. they changed in this update.

What would unblock me

A way to get a VM shell (or cowork-svc debug mode that keeps the VM alive after the CLI exits) so I can which socat, ls -la /tmp, strace the bridge attempt. Happy to run whatever you'd like and attach output.

Logs available on request

• Full cowork_vm_node.log (16 identical failure cycles)
• main.log from the window covering the MSIX update + first failure
• Get-AppPackageLog for the Claude_pzs8sxrjxfjjc package showing the 1.2773→1.3036 upgrade
• SHA-256s for the 2.1.92 host + VM CLI binaries I tested with