[BUG] Cowork: "Failed to create bridge sockets after 5 attempts" on every session since 1.3036.0 (macOS 26.3.1)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Every Cowork session fails immediately after sending a message with "Claude Code process exited with code 1" on Claude Desktop 1.3036.0 (cf521c) on macOS 26.3.1.
The VM itself boots healthy — cowork_vm_swift.log shows clean startup through "API reachability: REACHABLE" and "SDK installed successfully: version=2.1.111". The failure is in the spawned in-VM claude binary, which exits ~1.3–1.8 seconds after spawn with this stderr in cowork_vm_node.log:
[vm-stderr] Error: Failed to create bridge sockets after 5 attempts
This appears to be the same underlying mechanism as #19503, #23746, and #11079 — socat bridge creation failing during sandbox setup.
Affected:
- Both new (isResume=false) and resumed (isResume=true) sessions
- Both claude-sonnet-4-6 and claude-opus-4-7
- Sessions with iCloud-mounted and with local working folders
- Multiple users on the same Mac (my account and my spouse's account)
NOT affected:
- Claude Code CLI (standalone install) — works fine, goes through a different code path
- claude.ai in the browser — works fine
What Should Happen?
Cowork should successfully spawn the in-VM claude process and respond to messages, as it did prior to the 1.3036.0 auto-update earlier today.
Error Messages/Logs
From ~/Library/Logs/Claude/cowork_vm_node.log — repeats on every session spawn, 100% consistently:
[Spawn:vm] id=62a7ae61 Spawn succeeded in 151ms
[vm-stderr 62a7ae61] Error: Failed to create bridge sockets after 5 attempts
[Process:62a7ae61] Exited, code=1, signal=null, duration=1435ms, oom=false
Across 10+ captured crashes, durations cluster tightly between 1246ms and 1761ms — consistent with a deterministic timeout (5 retries × ~250ms) rather than a variable race.
VM itself boots cleanly every time. cowork_vm_swift.log confirms all startup steps complete through "API reachability: REACHABLE" and "SDK installed successfully: version=2.1.111". The failure is in the bridge socket setup performed by the in-VM `claude` binary after spawn.
Host-side lifecycle record from main.log:
unhealthy_reason: 'system_error'
error_message: 'Claude Code process exited with code 1'
error_category: 'process_crashed'
had_first_response: false
seconds_to_outcome: 2
Steps to Reproduce
- Update Claude Desktop to 1.3036.0 (cf521c) dated 2026-04-16T16:17:33.000Z (auto-update)
- Open any Cowork session (new or resumed)
- Send any message
- Observe "Something went wrong — Claude Code process exited with code 1"
- Logs at ~/Library/Logs/Claude/cowork_vm_node.log show "Failed to create bridge sockets after 5 attempts"
100% reproducible since ~13:42 ET on 2026-04-16.
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Earlier build of 1.x today (prior to the 2026-04-16T16:17:33Z auto-update). I do not have the exact previous build number recorded.
Claude Code Version
Claude Desktop 1.3036.0 (cf521c) 2026-04-16T16:17:33.000Z — in-VM SDK reports version 2.1.111
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
Troubleshooting already attempted without success:
- Logout and re-login
- Clearing ~/.local/share/claude
- Full app restart
- Opening new sessions with Sonnet 4.6 and Opus 4.7
- Wiping the VM bundle:
rm -rf ~/Library/Application\ Support/Claude/vm_bundlesandrm -rf /tmp/claude-*, then allowing the app to download and rebuild a fresh bundle - Switching working folder away from iCloud Drive to local disk
Possibly related existing issues:
- #19503 — same "Failed to create bridge sockets" error, identified socat bridge creation against MITM proxy ports as root cause
- #23746 — same error after auto-update to 1.1.2156, affecting all tasks including new ones
- #11079 — same error when TMPDIR is non-existent or non-writable
The consistent 1.3–1.8 second duration between spawn and exit, across 20+ attempts on different sessions/models, suggests a deterministic race or configuration issue in the bridge socket setup path as it exists in SDK 2.1.111 bundled with Desktop 1.3036.0.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗