›_ Codex Issues
Codex Issues / #9996

Token exchange fails on IPv6-enabled systems (Linux)

Resolved 💬 3 comments Opened Jan 27, 2026 by ESKRiPO Closed Jan 27, 2026

Bug Report

What version of Codex is running?

codex-cli 0.92.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

N/A (login issue)

What platform is your computer?

Linux 6.18.7-2-cachyos x86_64 (Arch-based)

What issue are you seeing?

codex login and codex login --device-auth both fail with:

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

or

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

Root Cause Identified

The issue is IPv6 connectivity. When the system resolves auth.openai.com to an IPv6 address first (e.g., 2a06:98c1:3106::ac40:920f), the Codex CLI fails to connect.

Proof

  1. curl -v https://auth.openai.com works fine (both IPv4 and IPv6)
  2. opencode auth login (different CLI tool using same OAuth endpoint) works fine
  3. After adding IPv4 address to /etc/hosts:

``
172.64.146.15 auth.openai.com
`
codex login --device-auth` works successfully

Expected Behavior

Codex CLI should work on systems with IPv6 enabled, either by:

  • Properly supporting IPv6 connections
  • Falling back to IPv4 when IPv6 fails
  • Using happy eyeballs (RFC 6555) for connection attempts

Workaround

Force IPv4 by adding to /etc/hosts:

172.64.146.15 auth.openai.com

Additional Context

  • The reqwest Rust HTTP client may be the source of the issue
  • This affects Linux users with dual-stack (IPv4+IPv6) networking
  • ISP: Orange Slovakia (standard residential connection)

View original on GitHub ↗

3 Comments

ESKRiPO · 7 months ago

Update: The IPv6 issue affects not only authentication but also regular API communication.

After successful login, Codex fails during normal operation with:

Stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)

Extended workaround - add both domains to /etc/hosts:

172.64.146.15 auth.openai.com
172.64.155.209 chatgpt.com

This suggests the IPv6 connectivity issue is systemic in the Codex CLI's HTTP client, not limited to the authentication flow.

ESKRiPO · 7 months ago

Update: Root cause identified - NOT a Codex CLI bug

After further investigation, the issue was not caused by Codex CLI's IPv6 handling. The actual problem was a local DNS misconfiguration:

Real cause (combination of two issues):

  1. /etc/resolv.conf was static without nameserver - Applications with their own DNS resolver (like Codex CLI, Steam, Chromium-based apps) couldn't perform DNS lookups
  2. Router was sending invalid IPv6 DNS - fe80::1 (link-local address) was unreachable

Actual fix:

  1. Link resolv.conf to systemd-resolved stub:

``bash
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
``

  1. Configure router IPv6 to use Dynamic IP (SLAAC/DHCPv6)

Apology

The /etc/hosts workaround worked temporarily but was masking the real issue. This is not a bug in Codex CLI - it was a local system/network configuration problem.

I recommend closing this issue as "not a bug".

ESKRiPO · 7 months ago

Closing as not a bug - was local DNS misconfiguration.