Proxy hostname A succeeds but AAAA SERVFAIL aborts requests before connect()

What version of Codex CLI is running?

codex-cli 0.153.4 (bundled with Codex App 26.901.51231)

What subscription do you have?

Enterprise

Which model were you using?

Not applicable. The failure occurs before authentication.

What platform is your computer?

Linux 6.18.33.2-microsoft-standard-WSL2 x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

WSL2 shell. The same failure occurs through Codex Desktop and the bundled CLI.

Codex doctor report

not available in this bundled CLI

What issue are you seeing?

Codex cannot use an HTTP proxy hostname when DNS returns a valid A record but SERVFAIL for the AAAA query.

Both OAuth paths fail with generic transport errors:

Token exchange failed: error sending request for url (https://auth.openai.com/oauth/token)

Error logging in with device code: error sending request for url (https://auth.openai.com/api/accounts/deviceauth/usercode)

curl reaches the same endpoints through the same proxy and validates TLS. A POST without parameters receives the expected HTTP 400 response from OpenAI.

A network syscall trace of codex login --device-auth shows:

1. Codex sends A and AAAA queries for the proxy hostname.
2. The A query returns one private IPv4 address.
3. The AAAA query returns DNS SERVFAIL.
4. Codex retries the AAAA query.
5. Codex reports error sending request without calling connect().

Replacing the proxy hostname in HTTP_PROXY and HTTPS_PROXY with its resolved IPv4 address makes device authorization start immediately. Normal Desktop OAuth token exchange also succeeds after restart.

The proxy hostname and address are omitted because they identify a private corporate network.

What steps can reproduce the bug?

1. Configure a DNS name for an HTTP proxy.
2. Make its A query return a valid IPv4 address.
3. Make its AAAA query return SERVFAIL, not an empty NOERROR response.
4. Set HTTP_PROXY and HTTPS_PROXY to http://proxy.example:<port>.
5. Run:

codex login --device-auth

6. Observe that Codex fails before it displays a device code:

Error logging in with device code: error sending request for url (https://auth.openai.com/api/accounts/deviceauth/usercode)

7. Confirm that no outbound TCP connect() occurs:

strace -f -e trace=network codex login --device-auth

8. Replace proxy.example in the proxy variables with its IPv4 address.
9. Run the command again. Codex now displays the device URL and one-time code.

What is the expected behavior?

Codex should use the valid A result when the AAAA lookup fails.

If it cannot continue, the error should identify proxy hostname resolution as the cause. It should include the underlying DNS error without exposing proxy credentials.

Additional information

I searched open and closed issues before filing. Related reports include #16079 for generic Linux HTTP proxy failures and #44990 for AAAA-only WSL DNS with unroutable IPv6. This case differs because the destination is not resolved AAAA-only. The proxy A record succeeds, but a SERVFAIL AAAA response causes Codex to discard the usable IPv4 result before any connection attempt.

The issue also exposed that Codex loads proxy settings from $CODEX_HOME/.env. Command-level proxy overrides did not change the trace until that file was updated. This behavior is related to #38885, but the persisted proxy itself was valid; only dual-stack DNS handling failed.

Reproduce with codex login --device-auth under WSL2, using HTTP_PROXY/HTTPS_PROXY and strace -f -e trace=network. Trace proxy hostname resolution and request setup, then verify that a valid A result still reaches connect() when AAAA returns SERVFAIL. Done means device auth starts through the hostname, or a proxy-resolution error identifies the DNS failure without credentials.