claude-code - 💡(How to fix) Fix Claude Desktop cowork VM startup permanently breaks WSL2 interop (vsock accept4 failed 110) [1 participants]

Summary

Every time Claude Desktop opens a new session, the cowork VM (smol-bin.x64.vhdx) starts up. During its 12–22 second startup window, the Hyper-V vmbus/vsock is disrupted and WSL2 interop breaks permanently for all open terminal sessions — explorer.exe, powershell.exe, and any wsl.exe-based MCP server fail with UtilAcceptVsock:271: accept4 failed 110.

The breakage does not auto-recover. The only fix is wsl --shutdown or opening a new WSL terminal session.

Environment

• Windows 11
• WSL2 distro: WLinux (Pengwin) with systemd, kernel 6.6.87.2-microsoft-standard-WSL2
• Claude Desktop version: 1.3883 / 1.4758
• Claude Code CLI used concurrently in WSL2 terminals

Root Cause

Claude Desktop starts two WSL-dependent subsystems simultaneously on every launch:

1. Cowork VM (smol-bin.x64.vhdx) — takes 12–22 seconds to start, occupies vmcompute/hvsock.sys during boot
2. MCP servers using wsl.exe (e.g. ckan, istat) — try to establish vsock connections to WSL2 during the cowork VM startup window

These two compete on the same Hyper-V vmbus. The result is a vsock timeout that permanently corrupts WSL2 interop state.

Evidence from logs

mcp.log — all MCP servers initialize at the same millisecond, wsl.exe-based ones crash 30 seconds later:

06:55:28 [ckan]  Using MCP server command: wsl.exe
06:55:28 [istat] Using MCP server command: wsl.exe
06:55:29 [ckan]  Server started and connected successfully
06:55:29 [istat] Server started and connected successfully
06:55:59 [ckan]  Unexpected token 'I', "I m p o s "... is not valid JSON  ← Windows UTF-16LE error on stdout
06:55:59 [ckan]  Server disconnected
06:56:29 [istat] Unexpected token 'I', "I m p o s "... is not valid JSON
06:56:29 [istat] Server disconnected

"I m p o s " = "Impossibile..." (Italian Windows error message output as UTF-16LE to stdout, parsed as JSON by the MCP client).

cowork_vm_node.log — VM startup takes 12–22 seconds:

08:55:54  VM:start  Beginning startup
08:56:06  VM        Network status: CONNECTED
08:56:06  VM:start  Startup complete, total time: 12741ms

09:01:08  VM:start  Beginning startup  ← second session restart
09:01:30  VM:start  Startup complete, total time: 21835ms

WSL2 interop test — after cowork VM starts, all Windows interop commands fail:

$ explorer.exe "$(wslpath -w /some/path)"
WSL (xxxxx) ERROR: UtilAcceptVsock:271: accept4 failed 110

Impact

• WSL2 interop permanently broken after every Claude Desktop session start
• All wsl.exe-based MCP servers crash on every launch
• Users who run Claude Code CLI in WSL2 terminals simultaneously with Claude Desktop are particularly affected
• No order of startup is safe: Claude Desktop itself calls wsl.exe for MCP servers at the same time the cowork VM starts

Workaround

Disable CoworkVMService via registry (requires admin):

# Disable
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" -Name "Start" -Value 4
Stop-Service CoworkVMService -Force

# Re-enable when needed
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" -Name "Start" -Value 3
Start-Service CoworkVMService

This eliminates the Hyper-V competition but sacrifices cowork code execution in Claude Desktop.

Suggested Fix

Either:

1. Delay MCP server startup until after cowork VM is fully connected (sequential instead of parallel initialization)
2. Stagger VM startup to avoid competing for vmbus during the critical 12–22s window
3. Don't start cowork VM unless the user explicitly triggers a code execution action (lazy startup)

Related Issues

• #29045 — VM started on every launch even without Cowork usage
• #29932 — vsock port 1024 conflict between cowork-vm and other Hyper-V VMs
• #26216 — cowork-vm-nat permanently breaks WSL2 internet connectivity (fixed in v1.1.4328)
• microsoft/WSL#13864 — UtilAcceptVsock:271: accept4 failed 110 with heavy VM workloads