Linux: Intermittent DNS SERVFAIL from systemd-resolved causes complete WebSocket connection failure with no recovery

What version of Codex is running?

codex-cli 0.117.0

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.17.0-8-generic (Ubuntu, x64) — VPS

What issue are you seeing?

When using codex exec on Linux with systemd-resolved as the DNS resolver, intermittent SERVFAIL responses for chatgpt.com cause the WebSocket connection to fail completely. Codex retries 5 times, fails all 5, then exits with no output.

The DNS resolution is intermittent — dig resolves fine (uses a different code path), but the application-level DNS via systemd-resolved stub (127.0.0.53) occasionally returns SERVFAIL for chatgpt.com, particularly on AAAA (IPv6) queries. When Codex hits one of these transient failures, it gives up entirely.

Error output

2026-03-28T13:45:40.325421Z ERROR rmcp::transport::worker: worker quit with fatal: Transport channel closed, when Client(Reqwest(reqwest::Error { kind: Request, url: "https://chatgpt.com/backend-api/wham/apps", source: hyper_util::client::legacy::Error(Connect, ConnectError("dns error", Custom { kind: Uncategorized, error: "failed to lookup address information: Try again" })) }))
2026-03-28T13:45:59.961716Z ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: IO error: failed to lookup address information: Try again, url: wss://chatgpt.com/backend-api/codex/responses
2026-03-28T13:46:05.373105Z ERROR codex_api::endpoint::responses_websocket: failed to connect to websocket: IO error: failed to lookup address information: Try again, url: wss://chatgpt.com/backend-api/codex/responses
ERROR: Reconnecting... 2/5
...
ERROR: Reconnecting... 5/5

All 5 retries fail because they happen in rapid succession during the DNS outage window (seconds apart). Then Codex exits with no output.

Steps to reproduce

1. Run on a Linux system using systemd-resolved (default on Ubuntu)
2. Have intermittent DNS — reproducible when nslookup chatgpt.com returns success on A record but SERVFAIL on AAAA in the same query
3. Run codex exec "any prompt" — it will sometimes connect fine and sometimes fail all 5 retries

Expected behavior

• Codex should use exponential backoff with jitter (not fixed ~5s intervals)
• After DNS failure, retry with longer delays to survive transient DNS outages
• Optionally: fall back to HTTPS transport instead of giving up entirely
• Optionally: prefer IPv4 (A records) when AAAA resolution fails

Actual behavior

All 5 retries happen within ~50 seconds with fixed intervals. If DNS is flaky for even 1 minute, Codex is guaranteed to fail completely with no output.

Workaround

Adding chatgpt.com IPs to /etc/hosts bypasses the resolver entirely and fixes it:

104.18.32.47 chatgpt.com
172.64.155.209 chatgpt.com

Additional context

• This is related to #13158 (WebSocket fallback) and #15296 (DNS state unavailable) but distinct — our DNS works most of the time, just intermittently fails
• systemd-resolved stub resolver at 127.0.0.53 is the default on all modern Ubuntu installations
• The retry strategy (5 attempts, ~5-6s apart) is too aggressive for transient DNS issues — a single 60-second DNS hiccup kills the session
• This caused a full pipeline failure in our automation (Quorium multi-agent system) — all agent work completed but the Codex synthesis step died, losing hours of work