[Windows/WSL] Reconnecting loop: timeout waiting for child process to exit
Open 💬 0 comments Opened May 9, 2026 by Yearnzq
Bug report: Codex Windows WSL environment gets stuck in infinite reconnect loop
Environment
- OS: Windows 11 Pro x64, build 26200
- Codex client: gpt-5.5, Reasoning effort set to medium
- Windows-side settings:
- Agent Environment: WSL (Linux subsystem) — selected
- Integrated Terminal Shell: WSL
- Open target (VS Code): set
- WSL distros:
- Ubuntu-24.04 (default)
- docker-desktop
- WSL details:
- Ubuntu tools installed: bash, git 2.43.0, ripgrep 14.1.0, build-essential, python3, etc.
- PowerShell:
- RemoteSigned execution policy now set to allow profile loading
- Note:
localhost proxy configwarning appears inside WSL, but commands still execute correctly
What I changed
- Installed Ubuntu-24.04 and set it as default distro:
wsl --set-default Ubuntu-24.04
- Verified toolchain in WSL:
which bashrg --versiongit --version
- Confirmed that the commands work when invoked from Windows:
C:\Windows\System32\wsl.exe -d Ubuntu-24.04 -- bash -lc "which bash && rg --version && git --version"
Exact verification output
/usr/bin/bashripgrep 14.1.0git version 2.43.0
Reproduction steps
- Keep current Codex settings above (Agent Environment = WSL, terminal shell = WSL).
- Start Codex, begin a new chat/conversation.
- Observe startup output in the Codex client.
Actual behavior
On each first user message / conversation attempt, Codex keeps entering reconnection retries:
Reconnecting... 2/5timeout waiting for child process to exitReconnecting... 3/5Reconnecting... 4/5Reconnecting... 5/5- then repeats back to:
Reconnecting... 1/5Reconnecting... 2/5
and loops indefinitely until user stops interaction.
No normal model response is returned.
Expected behavior
Codex should start a child shell/process once and run commands normally in the configured WSL environment, then proceed with normal chat interaction.
Notes
- I can run normal WSL commands manually without issue.
- The issue appears to be in Codex process launch/handshake/teardown in this Windows+WSL setup, not missing
/usr/bin/bash. - This behavior is consistent enough to suggest a platform-level lifecycle/permission race or timeout handling bug.
Impact
Codex is unusable for the first conversation after startup when WSL mode is used.