Codex sign-in fails: which stage actually broke

What you see

The client prints one of these, or nothing at all:

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

Starting local login server on http://localhost:1455. If your browser did not open, navigate to this URL to authenticate:

GET http://localhost:1455/auth/callback?code=redacted&scope=openid profile email offline_access&state=redacted
Status 500 / Internal Server Error

Or you land on the “Sign in to Codex CLI with ChatGPT” screen and it never advances. In the remote and headless cases the browser may complete on one machine while the client, running on another, stays signed out — because the callback never reaches the listener that is actually running.

What it usually means

Sign-in is not one step; it is a short chain, and each link fails differently:

1. The browser step — a browser is opened (or should be) and the account is authenticated.
2. The local callback — the browser returns to a listener the client started on localhost:1455. If that listener is unreachable (port conflict, firewall, or the listener living on a different machine), the flow breaks here. This is the stage the official documentation says breaks first in remote, headless and restricted-network environments.
3. The token exchange — the client turns what it received into a usable session credential. A failure here shows the Token exchange failed: ... line.

What the product’s own source code does about the port. First-party source code on the product’s default branch (codex-rs/login/src/server.rs) defines const DEFAULT_PORT: u16 = 1455; and, immediately after it, const FALLBACK_PORT: u16 = 1457; with the comment // Keep in sync with the Codex CLI Hydra redirect URI allow-list. The redirect URI is built from the port that actually got bound: let redirect_uri = format!("http://localhost:{actual_port}/auth/callback"); — not a hardcoded value. The binding routine tries 127.0.0.1:{port}; if that address is in use it sends a cancel request to the previous listener, retries up to 10 times at 200 ms intervals, and only then, if it is still on the default port, moves to the fallback port while emitting a warning that the default login callback port is unavailable.

The practical consequence: a firewall rule that opens only 1455 is insufficient if 1455 is already taken — the client may quietly move to 1457, and the port you need to allow is the one your client actually printed. Caveat: these facts describe the default branch and may differ from the version you have installed.

Quick checks

1. Did a browser open at all? If not, you are in the remote/headless case below (#2021, #4265).
2. Did the callback reach the right machine? On WSL, Remote-SSH or a headless server, the listener runs on the remote host’s 127.0.0.1:1455 while your local browser is sent to localhost:1455 (#4265, #4562). They are different machines.
3. What is the exact terminal line? A Token exchange failed line is a different branch from a localhost:1455 callback 500.
4. Check state without guessing: codex login status prints the active authentication mode (the CLI reference documents it as “Show login status.”), and the documented codex doctor runs diagnostics for startup, connectivity and performance.

Fixes, by branch

If the browser never opens or the callback lands on the wrong machine

This is the remote/headless case. The listener is on the server’s 127.0.0.1:1455, not on your laptop or phone, so the redirect to localhost:1455 cannot reach it (#2021, #4265, #4562). Two documented escapes exist:

• Forward the port so your local localhost:1455 reaches the remote listener: ssh -L 1455:localhost:1455 user@remote (documented in the official auth docs). Then complete the browser flow locally.
• Or use the device-code path, below.

If the callback to localhost:1455 fails

If you see the GET http://localhost:1455/auth/callback?... line followed by Status 500 / Internal Server Error (#5283), the listener is up but the exchange is not completing — usually a local firewall or other network setting between browser and listener. A maintainer’s closing comment on #5283 recommended the headless device-authentication technique for exactly this situation (a routing recommendation, not a diagnosis). Try the device-code path below, and check whether a firewall rule opens the actual port printed.

If you see a token-exchange error

The Token exchange failed: error sending request for url (https://auth.openai.com/oauth/token) line (#6413, #4562) means the client could not complete the exchange with the auth endpoint. Reported environments include Windows 11 + WSL and plain Linux; it is not documented as platform-independent. No maintainer root cause for this class was found in the sources opened for this guide — the closest maintainer input is a diagnostic suggestion (see “What not to do”), not a fix.

If you are stuck on the “Sign in with ChatGPT” screen

#2763 reports the flow spinning indefinitely on the sign-in screen. One reporter observed that signing in worked under bash but not their fish shell, suggesting a shell- or environment-variable difference — this is a single reporter’s hypothesis, not a confirmed cause, and it should be tested rather than treated as fact.

The documented headless / remote escape hatch

• Device code: codex login --device-auth runs the device-code flow instead of launching a browser. The CLI source defines --device-auth as mapping to the device-code login path, and a maintainer on #5283 recommended it for network-blocked cases. Prerequisite (per the official auth docs): device-code login must be enabled in ChatGPT security settings or workspace permissions; if the server does not enable it, Codex falls back to the browser flow.
• API key instead of ChatGPT: printenv OPENAI_API_KEY | codex login --with-api-key reads the key from stdin (the CLI source defines --with-api-key this way). An access token can be supplied similarly via codex login --with-access-token.
• Corporate TLS inspection: the official auth docs describe setting CODEX_CA_CERTIFICATE to a PEM bundle before logging in (falling back to SSL_CERT_FILE when unset).
• Check state: codex login status reports the active mode; codex doctor covers connectivity diagnostics.

What not to do

• Do not delete your whole Codex configuration. rm -rf ~/.codex removes the entire configuration and session directory, not just credentials. It appears in community material and is not a step this guide recommends.
• Do not treat rm ~/.codex/auth.json as a fix. A maintainer on #6413 suggested trying it as a way to help isolate the root cause (“would help isolate”) — that is a diagnostic suggestion, not a confirmed fix. It deletes your stored credentials and is only reversible by signing in again. If you try it, move the file aside rather than deleting it, and understand it is a diagnostic step, not a remedy.
• Do not copy ~/.codex/auth.json between machines as a routine fix. The official auth docs describe a copy-auth.json fallback for headless setups, but it moves a live credential off one machine; do it only with that understanding and the documented caveat that it does not apply when credentials live in an OS credential store.
• Do not run codex login --api-key as a current command. The CLI source marks the bare --api-key flag as hidden and deprecated; it exits with guidance to use --with-api-key.
• Do not paste tokens or credentials into a public issue when asking for help.
• Do not name or assume a specific OS credential store. No source in this research found macOS Keychain, Windows Credential Manager or Linux Secret Service named for Codex; the official text only says “your operating system credential store.”

How to tell it worked

You are done when codex login status reports a signed-in mode, the client reaches a usable signed-in state on the network you normally use, and a normal prompt works. Because some of these failures are intermittent (and a firewall may only block the port that was actually chosen), give it more than one attempt before concluding.

If it is still failing

Collect: the client version, the operating system and whether you are in WSL/Remote-SSH/a headless server, the plan type, the exact terminal line, whether the browser opened, and which port (1455 or 1457) was printed. A maintainer’s recommendation for the network-blocked case is to use device-code authentication rather than to keep retrying the browser flow.

Known limits of this guidance

• Evidence level: reported. This is built from public GitHub issue reports, a maintainer’s diagnostic suggestion, and first-party source-code inspection of the login server and CLI flag definitions — not from a reproduction by this site.
• The canonical developers.openai.com/codex/auth page returned HTTP 403 during research, so the documented details carried from it (per-OS credential-store names and the exact headless command spelling beyond what the source code shows) are not asserted here. macOS Keychain, Windows Credential Manager and Linux Secret Service are deliberately not named because no source in this research found them for Codex.
• No maintainer root cause was found for the token-exchange failure class. The #6413 comment is a diagnostic suggestion; the #5283 comment is a routing recommendation.
• The os error 10013 Windows port-exclusion class was not opened in this research and is not covered here.
• No fix version can be named. Reported versions span 0.19.0 to 0.63.0; the documentation and behaviour may have changed across that range.
• The source-code facts describe the product’s default branch and may differ from the version you have installed.
• ERR_CONNECTION_REFUSED / “This site can’t be reached” appear in third-party write-ups but were not found verbatim in any primary source opened here, so they are not claimed.