claude-code - 💡(How to fix) Fix SDK 2.1.111 regression: "Failed to create bridge sockets" — Claude Code process exits code 1 on every Cowork VM spawn (Windows 11, MSIX) [1 comments, 2 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Claude Cowork (Windows desktop app, MSIX Store install) fails on every session spawn with "Claude Code process exited with code 1" after the SDK auto-upgraded to 2.1.111 on April 16, 2026 at 19:58 local time. Previous versions 2.1.92 and 2.1.101 worked normally.

The claude binary running inside the Cowork Linux VM fails to create its HTTP + SOCKS proxy bridge Unix sockets (part of the bwrap subprocess sandbox setup). It retries 5 times, then exits code 1 within ~1.5 seconds — before the first response.

Crashes started in the exact same minute SDK 2.1.111 was installed. Zero "bridge sockets" errors in the logs before that moment. This is a regression introduced in 2.1.111.

Happens in 100% of spawns, across every project, with no config changes on my side.

Summary

Claude Cowork (Windows desktop app, MSIX Store install) fails on every session spawn with "Claude Code process exited with code 1" after the SDK auto-upgraded to 2.1.111 on April 16, 2026 at 19:58 local time. Previous versions 2.1.92 and 2.1.101 worked normally.

Error

From C:\Users\mfranjo2003\AppData\Roaming\Claude\logs\cowork_vm_node.log (inside the Linux VM stderr):

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

Every session spawn since the 2.1.111 upgrade fails this way, ~1.5-2.5 seconds after spawn confirmation. The process exits before the first response.

SDK version timeline (from main.log)

Crashes began in the same minute the SDK was swapped to 2.1.111. Zero occurrences of "bridge sockets" error before that moment.

Environment

• OS: Windows 11 x64
• Claude desktop app: v1.3036.0.0 (Microsoft Store / MSIX — package Claude_pzs8sxrjxfjjc)
• Claude Code VM SDK: 2.1.111 (235 MB ELF at claude-code-vm\2.1.111\claude)
• Entrypoints affected: claude-desktop, claude-vscode
• Hyper-V services HvHost, vmcompute: Running
• VM bundle freshly rebuilt after Windows restart — same error

What fails inside the binary

The binary (claude-code-vm/2.1.111/claude) contains this logic:

Failed to create bridge sockets after ${O} attempts
...
socat TCP-LISTEN:3128,fork,reuseaddr UNIX-CONNECT:${httpSocketPath}
socat TCP-LISTEN:1080,fork,reuseaddr UNIX-CONNECT:${socksSocketPath}

Bridge socket creation retries 5 times (setTimeout backoff of w*100 ms), then throws. This is the HTTP + SOCKS proxy bridge for bwrap-based subprocess sandboxing. The failure occurs when allowedDomains is set (Cowork passes allowedDomains=25), which triggers needsNetworkRestriction=true and activates the proxy bridges.

What I ruled out

• MCP auth cache (cleared, no effect)
• Malformed permissions in settings.json (fixed, no effect)
• Hooks (none configured)
• wsl --shutdown + Windows restart (no effect — VM rebuilt cleanly, still broken)
• VM bundle corruption (freshly extracted after restart, same error)
• env.CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=0 in ~/.claude/settings.json (no effect — env block is for Bash subprocesses, not the claude process)
• Kozminski University SSL-inspection proxy (today's TLS handshakes show legit Google Trust Services cert for bridge.claudeusercontent.com; the cert-mismatch errors in logs are 3 days old and only affected the separate Claude-in-Chrome MCP)

Cowork load config (may or may not matter)

Every session loads:

• 20 remote MCP servers (Canva, Gamma, Gmail, Calendar, HF, gdrive, Claude in Chrome, mcp-registry, Claude Preview, ccd_session, ccd_directory, pdf-viewer, scheduled-tasks + 7 finance plugin MCPs)
• 5 local CLI plugins (brand-voice, legal, data, productivity, cowork-plugin-management)
• 14 enabled skills
• System prompt 83,178 chars
• Stdin 82 KB at spawn (up to 1.6 MB on resume)

The failure is immediate and consistent regardless of the specific project/session, suggesting it's independent of workload size.

Attached log (first failure after SDK upgrade)

2026-04-16 19:58:29 [info] [LocalAgentModeSessionManager] SDK version 2.1.111 will be used
2026-04-16 19:58:29 [info] [Spawn:vm] Spawn succeeded in <ms>
2026-04-16 19:58:31 [warn] [vm-stderr] Error: Failed to create bridge sockets after 5 attempts
2026-04-16 19:58:31 [info] [Process] Exited, code=1, signal=null, duration=~1500ms, oom=false

Asks

1. Roll back the SDK push to 2.1.101 (last known good).
2. Confirm this is being tracked and give an ETA for a fixed SDK.
3. Add a mechanism to let users pin an older SDK version as a workaround while fixes propagate.

Happy to provide more logs if needed.

What Should Happen?

Claude Code should spawn successfully inside the Cowork VM and respond to my prompt, as it did before the SDK auto-upgrade to 2.1.111.

Error Messages/Logs

UI shown to user:
  "Something went wrong"
  "Claude Code process exited with code 1"
  "You can restart the conversation from an earlier message."

Inside cowork_vm_node.log (Linux VM stderr):
  [vm-stderr <id>] Error: Failed to create bridge sockets after 5 attempts
  [Process:<id>] Exited, code=1, signal=null, duration=~1500ms, oom=false

This fires on every single session spawn since SDK 2.1.111 was pushed.

Steps to Reproduce

1. Launch Claude Cowork desktop app on Windows 11 (MSIX Store install v1.3036.0.0).
2. Open any project (new or existing).
3. Type any prompt, e.g. "hi".
4. Send.
5. Observe: within ~2 seconds the UI shows "Something went wrong / Claude Code process exited with code 1".
6. Check C:\Users<user>\AppData\Roaming\Claude\logs\cowork_vm_node.log — every spawn contains "Failed to create bridge sockets after 5 attempts" followed by exit code=1.

Happens in 100% of spawns, across all projects, with no prior config changes on my side. Started the exact minute the SDK auto-upgraded to 2.1.111 (April 16 19:58 local).

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.101

Claude Code Version

2.1.111 (Claude Code)

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

This reproduces in the Claude Cowork desktop app, not the terminal CLI. The CLI outside Cowork (claude command in PowerShell) works fine because it doesn't use the VM.

Package ID: Claude_pzs8sxrjxfjjc (Microsoft Store MSIX install) App version: 1.3036.0.0 SDK binary path: C:\Users<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude-code-vm\2.1.111\claude (235 MB ELF x86-64) Full diagnostic trail: logs show SDK version transitions 2.1.92 → 2.1.101 → 2.1.92 (rollback) → 2.1.111. Crashes begin at the exact timestamp 2.1.111 is installed. Workaround: using Claude CLI outside Cowork works. Rolling back or pinning SDK would unblock.