[Windows/WSL] Reconnecting loop: timeout waiting for child process to exit

[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 config warning appears inside WSL, but commands still execute correctly

What I changed

1. Installed Ubuntu-24.04 and set it as default distro:
   • wsl --set-default Ubuntu-24.04
2. Verified toolchain in WSL:
   • which bash
   • rg --version
   • git --version
3. 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/bash
• ripgrep 14.1.0
• git version 2.43.0

Reproduction steps

1. Keep current Codex settings above (Agent Environment = WSL, terminal shell = WSL).
2. Start Codex, begin a new chat/conversation.
3. Observe startup output in the Codex client.

Actual behavior

On each first user message / conversation attempt, Codex keeps entering reconnection retries:

• Reconnecting... 2/5
• timeout waiting for child process to exit
• Reconnecting... 3/5
• Reconnecting... 4/5
• Reconnecting... 5/5
• then repeats back to:
• Reconnecting... 1/5
• Reconnecting... 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.