›_ Codex Issues
Codex Issues / #16768

Flag to force ipv4 on windows

Open 💬 4 comments Opened Apr 4, 2026 by tom-huntington
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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_

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #16367
  • #16096
  • #16491

Powered by Codex Action

Ankurdeewan · 4 months ago

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 · 4 months ago

@etraut-openai please review it. I need this flag sometimes.
This problem was GoodbyeDPI (DNS rerouting tool) for me.

graemeh · 1 month ago

A manual CODEX_FORCE_IPV4 escape 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:

  1. After repeated connection timeouts, test the actual Codex service endpoint over IPv4 and IPv6 separately at the TLS/WebSocket or HTTP streaming layer.
  2. If IPv6 fails but IPv4 succeeds, move new Codex connections to IPv4 automatically.
  3. Preserve and resume the interrupted turn without duplicating tool actions.
  4. Cache the fallback briefly for that network, then return to normal dual-stack behavior after a network change or recovery.
  5. Display a specific message:
IPv6 connections are timing out. Codex has switched to IPv4, and your work is safe. Other applications may still be affected. [View Windows recovery steps] [View diagnostics]

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.