Repository navigation
Flag to force ipv4 on windows #16768
Description
What version of Codex CLI is running?
codex-cli 0.118.0
What subscription do you have?
pro
Which model were you using?
No response
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What terminal emulator and version are you using (if applicable)?
windows terminal
What issue are you seeing?
◦ Reconnecting... 2/5 (35s • esc to interrupt)
└ Timeout waiting for child process to exit
without ipv6 available, codex tries reconnecting 5 times, 30 seconds each attempt, for a total of 2m30s, before proceeding with ipv4.
It does this after each /new command. Totally unusable.
The problem is the Windows API does not handle no ipv6 gracefully, and does a long time out before using ipv4. I have problems with other CLIs in the past, and the solution is just to pass a flag through the cli or use WSL (which works as expected with codex).
I'm on Starlink which has ipv6 problems.
What steps can reproduce the bug?
You would have to disable ipv6 somehow
What is the expected behavior?
No response
Additional information
No response
Activity
github-actions commentedon Apr 4, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
codex resumerepeatedly fails with "Timeout waiting for child process to exit" #16491Powered by Codex Action
Add CODEX_FORCE_IPV4 env var to bypass IPv6 connection timeouts on Wi…
Ankurdeewan commentedon Apr 4, 2026
hve put together a fix for this at Ankurdeewan/codex@fix/force-ipv4-flag (diff).
It adds a CODEX_FORCE_IPV4 environment variable (1, true, or yes) that restricts all outbound connections to IPv4, bypassing the long IPv6 timeout on Windows:
reqwest HTTP clients: binds to 0.0.0.0 via local_address() so the OS never creates IPv6 sockets
WebSocket connections (responses API + realtime): resolves hostnames to IPv4 explicitly and connects via TcpStream + client_async_tls_with_config
This follows the existing env-var pattern (CODEX_SANDBOX, CODEX_CA_CERTIFICATE, etc.) and has zero impact when unset.
Usage:
Windows cmd
set CODEX_FORCE_IPV4=1
codex
PowerShell
$env:CODEX_FORCE_IPV4 = "1"
codex
The fork's CI failures are infrastructure-related (no macOS runners, missing release artifacts) — the code compiles and passes cargo fmt / cargo clippy cleanly.
I wasn't able to open a PR directly since the repo restricts that to maintainers. Happy to adjust anything if needed.
fxpoet commentedon Apr 8, 2026
@etraut-openai please review it. I need this flag sometimes.
This problem was GoodbyeDPI (DNS rerouting tool) for me.
graemeh commentedon Jul 16, 2026
A manual
CODEX_FORCE_IPV4escape hatch would help, but Codex Desktop should ideally detect and recover from this condition automatically.A broken IPv6 path is often a partial failure rather than a clean disconnect: basic connectivity checks and some web pages still work, while Codex streaming connections repeatedly time out. In a recent Windows case, Codex was unusable over the affected ISP connection, while IPv4 on the same laptop and a mobile hotspot worked normally. The generic reconnect/timeout behavior made the failure look like a browser, memory, or service problem.
Suggested degraded-mode behavior:
The diagnostic view could show IPv4/IPv6 service reachability, DNS results, connection timing, and the current fallback state. Codex should not silently change Windows adapter configuration; a manual force-IPv4 option can remain available as an escape hatch.
This is not a request for full offline inference. It is an “emergency power” feature: preserve the user's work, keep one functioning communication path alive, and provide enough information to recover from the broader network problem.