Claude Desktop Task mode: "Failed to create bridge sockets after 5 attempts" on macOS 26.4

Status Fixed / completed
Reported on v2.1.111
Maintainer reply None cached
Activity 13 comments · opened Apr 16, 2026 · closed Apr 16, 2026

Summary

Task/agent mode in Claude Desktop fails to start any session on macOS 26.4. Every spawn of the in-VM claude CLI exits with code 1 within ~1s. Regular Chat mode works fine; the failure is specific to the agent-mode VM.

Environment

  • Claude Desktop: 1.3036.0
  • macOS: 26.4 (Darwin 25.4.0, Apple Silicon)
  • Claude Code SDK in VM: 2.1.111

Error

From ~/Library/Logs/Claude/cowork_vm_node.log:

[Spawn:vm] Spawn succeeded in 41ms
[vm-stderr] Error: Failed to create bridge sockets after 5 attempts
[Process] Exited, code=1, duration=917ms

Root cause (as far as I can tell)

The VM-side CLI spawns socat TCP-LISTEN:3128 UNIX-CONNECT:/var/run/mitm-proxy.sock (HTTP bridge) and the same for port 1080 (SOCKS). Both fail. The VM itself boots cleanly, network is CONNECTED, and coworkd logs MITM proxy started on /var/run/mitm-proxy.sock, so the socket appears to exist — but the bridge setup fails deterministically.

Likely candidates: race between proxy socket creation and socat connect, permissions on the socket vs. the non-root session user, or a macOS 26.x Virtualization Framework regression.

Reproduction

  1. Launch Claude Desktop on macOS 26.4
  2. Start a Task mode session
  3. Session immediately fails with "error code 1"

What I've tried

  • Killed all Claude processes, reinstalled app — no change
  • Deleted ~/Library/Application Support/Claude/claude-code-vm, local-agent-mode-sessions, vm_bundles — no change
  • Full wipe of ~/Library/Application Support/Claude/ — no change

Chat mode works. claude.ai web works. Only Task mode is affected.

View original on GitHub ↗

13 Comments

paul-a-lebrun-nodal · 4 months ago

Also hitting this on macOS (not 26.4) with Claude 1.3036.0 + SDK 2.1.111. Same signature: "Failed to create bridge sockets after 5 attempts", 100% reproducible, started immediately after the update. socat installed, cache wiped, rebooted — nothing clears it. Filed as #49342 (closed as duplicate of this).

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/19503
  2. https://github.com/anthropics/claude-code/issues/45175
  3. https://github.com/anthropics/claude-code/issues/46661

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

JoeEvans-at · 4 months ago

Confirming this on macOS 26.4.1, Claude Desktop 1.3036.0.

The logs pinpoint the exact moment it broke: the VM SDK auto-updated from 2.1.92 → 2.1.111 during a restart, and every spawn has failed since. Sessions were working fine on 2.1.92 minutes before.

From ~/Library/Logs/Claude/cowork_vm_node.log:

  • 12:50–12:51 — Sessions running normally, SDK version = 2.1.92
  • 12:52:32 — App restarted (VM:shutdown: App quit)
  • 12:52:54 — SDK updated to 2.1.111
  • 13:04:20 — First spawn → "Failed to create bridge sockets after 5 attempts", exit code 1
  • 13:04+ — Every subsequent spawn fails identically, including brand new sessions

Restarting Claude Desktop 3+ times does not resolve it — the 2.1.111 SDK persists across restarts.

rpwf1 · 4 months ago

Confirming this on Windows as well — same error, same versions.

Claude Desktop: 1.3036.0
Claude Code SDK: 2.1.111
VM bundle: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
OS: Windows 11, Hyper-V VM
Node: Tested with both v24.15.0 and v22.22.2 — same result
VM boots fine, network connects (CONNECTED), SDK installs successfully, process spawns — then immediately fails with:

Error: Failed to create bridge sockets after 5 attempts
Process exits with code 1 within ~1-2 seconds. Chat mode works fine — only Cowork/Agent mode is affected.

Tried: full app restart, computer reboot, workspace reinstall, removing custom MCP servers — none resolved it. Started happening suddenly today with no config changes on my end.

bsadeh · 4 months ago

Confirming this on macOS 26.3 (Darwin 25.3.0), Apple Silicon, Claude Desktop 1.3036.0, SDK 2.1.111.

Same signature: every Cowork task — including trivial ones — fails immediately with Failed to create bridge sockets after 5 attempts, exit code 1, ~900-1000ms duration.

Attempted fixes that did NOT resolve it:

  • Deleted ~/Library/Application Support/Claude/vm_bundles/ and let it re-download
  • Deleted ~/Library/Application Support/Claude/claude-code-vm/
  • Removed experimental env vars from ~/.claude/settings.json
  • Manually replaced the VM SDK binary with the 2.1.92 linux-arm64 build — still fails, confirming the bug is in the rootfs/coworkd MITM proxy bridge, not just the CLI binary
  • Full app quit + relaunch between each attempt

CLI in terminal works fine. Only Cowork/Task mode is affected.

danielbranscome · 4 months ago

Seeing exact same issues — affects every Cowork session I try — new or resumed, any model.

Environment

  • Desktop: Claude 1.3036.0 (cf521c) (2026-04-16T16:17:33Z)
  • CLI (host and VM): 2.1.111
  • macOS: 26.4.1 (build 25E253), Apple Silicon (arm64)

Symptom
Every spawned claude process inside the Cowork VM exits with code 1 in ~750–940ms. Stderr is identical each time:

Error: Failed to create bridge sockets after 5 attempts

VM itself is healthy before the crash — from ~/Library/Logs/Claude/cowork_vm_node.log:

  • vm_boot, guest_vsock_connect, static_ip_assignment, guest_ready all complete
  • Network status: CONNECTED, API reachability: REACHABLE
  • install_ca_certificates and sdk_install both succeed (SDK v2.1.111 installs into the guest)
  • Spawn confirms: Spawn succeeded in ~30ms — then ~800ms later, vm-stderr: Failed to create bridge sockets after 5 attempts and exit.

Reproduced across:

  • Models: claude-haiku-4-5-20251001 and claude-sonnet-4-6
  • New sessions and resumed sessions (is_resume: true and false)
  • Host-only sessions (non-Cowork, no VM) are unaffected and work fine
  • Host CLI (claude in Terminal) works fine standalone

Troubleshooting that did not help:

  • Quit and relaunch desktop app
  • Full macOS reboot
  • Deleted entire ~/Library/Application Support/Claude/ and let the app re-stage from scratch
jfcaouette · 4 months ago

Same failure here on Claude.app 1.3036.0, macOS 26.3.1 (25D771280a), arm64 (T6000). Bundle version 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d, VM SDK 2.1.111.

100% reproducible — every Cowork task exits within ~900ms with:

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

Regression started mid-day right after an app update (last successful spawn 10:54 local, first failure 14:13 with the same bundle hash, so host-side only).

Remediations tried — none resolve it:

  • Quit and relaunch Claude.app
  • Full wipe of ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/ (VM re-downloads rootfs.img cleanly, guest boots, CA certs install, SDK installs — then same failure)
  • Full MBP reboot (clean 9.5s VM boot afterwards, bit-identical failure)

Reproduces across fresh sessions and --resume sessions, on both claude-opus-4-6 and claude-opus-4-7, with and without --add-dir mounts. Regular claude CLI outside Cowork works fine.

felippemr · 4 months ago

Confirming on macOS 25.3.0 (Darwin), Apple Silicon, Claude Desktop 1.3036.0, SDK 2.1.111. Same signature.

Trigger: scheduled task — every spawn fails within ~900ms.

[Spawn:vm] id=... Spawn succeeded in 49ms
[vm-stderr] Error: Failed to create bridge sockets after 5 attempts
[Process] Exited, code=1, signal=null, duration=903ms, oom=false

VM is healthy before crash (from cowork_vm_node.log):

  • vm_boot, guest_vsock_connect, static_ip_assignment, guest_ready all succeed
  • Network status: CONNECTED, API reachability: REACHABLE
  • install_ca_certificates and sdk_install both succeed
  • OAuth token approved via MITM proxy
  • Then: bridge sockets fail.

Did not help:

  • Full quit + wipe of ~/Library/Application Support/Claude/claude-code-vm/
  • Relaunch with DEBUG=claude:* and ANTHROPIC_LOG=debug — no additional stderr beyond the one line
  • lsof | grep claude shows no stale sockets; no .sock files anywhere under Library/Application Support/Claude/

Useful data point: same /usr/local/bin/claude binary (v2.1.111) runs fine on the host with the exact Desktop argv (--output-format stream-json --verbose --input-format stream-json --permission-prompt-tool stdio --plugin-dir ...) — stream-json session starts, SessionStart hooks fire, everything works. Failure is strictly inside the Cowork VM.

felippemr · 4 months ago

Workaround: downgrading to Desktop 1.2773.0 (SDK 2.1.92) fixes it.

Confirmed on macOS 25.3.0, Apple Silicon. Installed 1.2773.0 from an older DMG over the broken 1.3036.0, relaunched, ran the same scheduled task that was failing:

[Spawn:create] cmd=/usr/local/bin/claude args=--output-format stream-json --verbose --input-format stream-json ... (identical argv to 1.3036.0)
[Spawn:vm] Spawn succeeded in 45ms
...
[Process] Exited, code=0, signal=null, duration=98521ms, oom=false

No bridge sockets error. Session ran 98s to clean SIGTERM exit. Second session also succeeded.

Key diff in logs: Installing SDK: ... version=2.1.92 instead of 2.1.111. So the regression is in the SDK 2.1.111 bundled with Desktop 1.3036.0 — the host-side spawn argv and VM infrastructure are identical across both versions.

(Will need to block the update feed to stay on 1.2773.0 until a fix ships, since Squirrel will auto-pull 1.3036.0 back.)

MarshallOfSound · 4 months ago

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

RobertHildebrandt-at · 4 months ago

Great news! Still awaiting the update. I've tried restarting the app several times and 'check for updates' and still being told that Claude 1.3036.0 (cf521c) is the latest version.

flowercodes · 4 months ago

Working for me now!

github-actions[bot] · 4 months ago

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.