WSL vsock error prevents any command execution (UtilBindVsockAnyPort: socket failed 1)

Open 💬 5 comments Opened Dec 19, 2025 by jrbrodie77

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

0.75.0

What subscription do you have?

Plus

Which model were you using?

codex 5.2 max

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

What happened
Any command execution from the Codex CLI inside WSL fails immediately with:
WSL (<pid> - ) ERROR: UtilBindVsockAnyPort:287: socket failed 1

This blocks building and even running wsl.exe --version.

Actual
Immediate failure with:
WSL (xxxx - ) ERROR: UtilBindVsockAnyPort:287: socket failed 1

Environment

WSL version: 2.4.13.0
Kernel version: 5.15.167.4-1
WSLg version: 1.0.65
MSRDC version: 1.2.5716
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26100.7462

What steps can reproduce the bug?

Steps to reproduce

Open WSL (Ubuntu).
Run any command via Codex CLI (example: ./build.sh or powershell.exe -Command "dotnet build Automator2024.sln -c

Debug").

Command fails with the vsock error before executing.

What is the expected behavior?

Expected
Command executes normally.

Additional information

Notes
The error appears to be WSL subsystem related rather than project-specific. It occurs before any build output.

View original on GitHub ↗

5 Comments

Loongphy · 6 months ago

Same here. Works with !command, fails in Codex auto-run..

xinghao2003 · 6 months ago

Still fails on 0.98.0, when running "/mnt/c/Program Files (x86)/Microsoft Visual Studio/2019/Professional/MSBuild/Current/Bin/MSBuild.exe"

etraut-openai contributor · 6 months ago

I don't think we have a repro of this. If someone in the community is able to repro and would like to diagnose the problem, we'd welcome a root cause analysis.

xinghao2003 · 6 months ago

Based on my understanding, I think the codex linux sandbox is blocking the WSL interop socket that required to run Windows executables. Currently, I am disabling sandbox to make it works.

MisterRound · 1 month ago

I now have the requested reproducible RCA. This is a Codex restricted-network
sandbox incompatibility with WSL Windows-executable interop, not necessarily a
broken WSL VM.

Current main restricted seccomp mode denies connect, allows socket() only
for AF_UNIX, and returns EPERM for matches:

Controlled A/B in a current WSL-backed Codex task:

inside restricted Codex child: socket(AF_UNIX) succeeds
inside restricted Codex child: socket(AF_VSOCK) -> EPERM
inside restricted Codex child: cmd.exe /d /c ver
  -> UtilBindVsockAnyPort:309: socket failed 1

outside Codex sandbox: the same AF_VSOCK creation succeeds
outside Codex sandbox: the same cmd.exe command succeeds

WSL's Windows process bridge needs AF_VSOCK, so the Windows executable never
starts under this policy. A user can distinguish this from a real host failure
by running the same minimal command directly in an ordinary WSL terminal: if
that succeeds, restarting WSL is unnecessary.

I posted the fuller diagnosis and product-fix considerations on the current
report, #30040: https://github.com/openai/codex/issues/30040#issuecomment-4949740236