[BUG] Cowork crashes since v1.3036.0 is installed

I am having this same issue as well.

MacOS 15.7.4
Apple Macbook Air M4

Claude Chat + Code are operational, Cowork is not.

Same issue for me on Windows

I am having the same issue with my M4

Same issue on Windows 11

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/49346
2. https://github.com/anthropics/claude-code/issues/49328
3. https://github.com/anthropics/claude-code/issues/49341

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Same issue Macbook pro m3 max with Tahoe 26.4.1

Also showing:

Failed to start Claude's workspace
VM service not running. The service failed to start.
Restarting Claude or your computer sometimes resolves this. If it persists, you can reinstall the workspace.

Even after restarting everything

Same issue. iMac 2021 with Sonoma 14.6.1

OG bug report https://github.com/anthropics/claude-code/issues/49328#issue-4277519879

Same

• macOS 26.3.1 (Tahoe)
• MacBook Air M3, 24GB RAM (Mac15,13 — 2024 model)

Having the same issue on windows 11, claude desktop latest version

Same issue. iMac just bought in 2026 with Tahoe 26.4.1

Mac 26.3.1 M4 w/32GB, same error #1

Same issue ->

Same repro on macOS (Darwin 25.2.0), Claude Desktop v1.3036.0.

Symptom: Cowork sessions exit immediately with code 1.

VM log:

Error: Failed to create bridge sockets after 5 attempts

Version correlation: Worked earlier today on Claude Code SDK 2.1.92, broken on 2.1.111 (server-served to the VM, so client-side cache clears don't help — the newer SDK is re-fetched).

I tried Clear Cache and Restart, did not work

Workaround: Running Claude Code directly in the terminal works fine — the bridge-socket layer is Cowork-VM-specific.

Installation ID: 56906e65-10c8-4788-a02b-8bf85c6eb850

Observations:

• Deterministic: every VM spawn fails the same way, ~1s after spawn confirmation.
• Happens after postConnect installs SDK version=2.1.111 — the VM starts, then the SDK running inside it immediately errors on bridge-socket setup.
• Timing: spawn succeeds in ~50–85ms, bridge-socket error ~800–1000ms later (5 retries × ~170ms).

Here are the logs:

2026-04-16 10:57:51 [info] [Spawn:vm] id=<uuid> OAuth token approved with MITM proxy
2026-04-16 10:57:51 [info] [Process:<uuid>] Spawn confirmed, flushing 2 buffered stdin chunks
2026-04-16 10:57:51 [info] [Spawn:vm] id=<uuid> Spawn succeeded in 52ms
2026-04-16 10:57:52 [warn] [vm-stderr <uuid>] Error: Failed to create bridge sockets after 5 attempts
2026-04-16 10:57:52 [info] [Process:<uuid>] Exited, code=1, signal=null, duration=1050ms, oom=false
2026-04-16 10:58:28 [info] [postConnect] Installing SDK: subpath=<path>, version=2.1.111
... [same pattern repeats on every spawn attempt]

Reproduces identically on Windows 11 / MSIX 1.3036.0.0 — so this is not macOS-specific. SDK bundle is 2.1.111 in both cases.

Exact failure

From %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\cowork_vm_node.log, every spawn fails the same way ~1.3–2s after Spawn succeeded:

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

VM itself is healthy beforehand: Network status: CONNECTED, API reachability: REACHABLE, sdk_install completed. Failure is strictly post-spawn, inside the guest.

Suspected root cause

The error string lives in the bundled SDK at claude-code-vm/2.1.111/claude in function u4K (HTTP/SOCKS bridge setup). It spawns two socat processes:

socat UNIX-LISTEN:${tmpdir}/claude-http-${rand}.sock,fork,reuseaddr  TCP:localhost:${httpProxyPort},...
socat UNIX-LISTEN:${tmpdir}/claude-socks-${rand}.sock,fork,reuseaddr TCP:localhost:${socksProxyPort},...

Then polls existsSync on both socket paths 5 times with 0/100/200/300/400 ms backoff (~1s total). Both socat pid checks pass (no "Failed to start HTTP bridge process" / "Linux bridge process died unexpectedly"), so the children launch — but the .sock files never appear in time.

Top candidates:

1. TMPDIR set to /tmp/claude (via mS$) but the dir isn't pre-created in the guest before socat runs — UNIX-LISTEN then fails to bind silently. A simple mkdirSync(tmpdir, {recursive:true}) before spawning the bridges would fix it.
2. A seccomp/bwrap policy change in this release blocking bind(AF_UNIX) for child processes.
3. socat missing or broken in the new smol-bin.x64.vhdx rootfs.

Confirms reporter's findings

• Full Claude Desktop restart (kill all claude.exe + stop/start CoworkVMService) — no effect
• Fresh VM bundle (deleted vm_bundles/claudevm.bundle, app rebuilds it) — no effect
• latest/redirect from the update endpoint still returns 1.3036.0 — no fix shipped yet

Workaround

Native Claude Code CLI on the host is unaffected (doesn't go through Cowork's microVM bridge).

Same issue Mac M1 - after update. Chat working - cowork issue remains.

Also having this issue,

App version: 1.3036.0
macOS version: Tahoe 26.2
Error: Failed to create bridge sockets after 5 attempts from ~/Library/Logs/Claude/cowork_vm_node.log

Hey folks, this issue has been resolved in the v1.3109.0 release of Claude Desktop. Please "Check for Updates".

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.