openai / openai/codex

[Windows][Auth] Codex CLI 0.145.0 fails OAuth token exchange and device auth while browser authentication works

Open
#40,839 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app auth bug CLI connectivity windows-os
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

What version of the Codex App are you using (From “About Codex” dialog)?

codex-cli 0.145.0 and codex extension vscode 26.5820.60940

What subscription do you have?

enterprise

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

I am unable to authenticate Codex CLI on my corporate Windows machine.

The normal browser-based OAuth flow completes successfully up to the localhost callback, but Codex fails when attempting to exchange the authorization code for a token.

The error shown after browser authentication is:

Sign-in could not be completed

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

Error code:
token_exchange_failed

The browser reaches the expected callback:

http://localhost:1455/auth/callback?code=

so the localhost OAuth callback appears to be working.

I also tested device authentication, which does not depend on the localhost callback, and it fails as well:

codex login --device-auth

Result:

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

This suggests that the problem occurs when the Codex HTTP client communicates with auth.openai.com, rather than in the browser-to-localhost OAuth callback.

Codex version
codex --version

Output:

codex-cli 0.145.0
Network diagnostics

I tested direct HTTPS connectivity to the OpenAI authentication domain:

curl.exe -Iv https://auth.openai.com

DNS resolution succeeds:

Host auth.openai.com:443 was resolved.

IPv6: (none)
IPv4: 172.64.146.15, 104.18.41.241

TCP/TLS connectivity also succeeds:

Trying 172.64.146.15:443...

Established connection to auth.openai.com
(172.64.146.15 port 443)

However, Cloudflare responds to the HEAD request with:

HTTP/1.1 403 Forbidden
Cf-Mitigated: challenge
Server: cloudflare

The relevant response headers include:

< HTTP/1.1 403 Forbidden
< Cf-Mitigated: challenge
< Server: cloudflare
< Content-Security-Policy: ... https://challenges.cloudflare.com ...

So auth.openai.com is reachable from the machine, but a non-browser HTTP request receives a Cloudflare challenge.

Corporate TLS inspection

The machine has Zscaler Client Connector installed and HTTPS traffic is subject to corporate TLS inspection.

When inspecting the certificate presented for:

https://auth.openai.com

the certificate shown by the browser is:

Issued to:
Common Name: auth.openai.com
Organization: Zscaler Inc.
Organizational Unit: Zscaler Inc.

Issued by:
Common Name: Zscaler Intermediate Root CA (zscalerthree.net)
Organization: Zscaler Inc.
Organizational Unit: Zscaler Inc.

Therefore, TLS inspection is active for auth.openai.com.

However, an important observation is that other coworkers in the same corporate environment, with the same role and the same corporate software/security stack, are able to use Codex successfully.

Because of that, this does not appear to be a general company-wide block of Codex by Zscaler.

What steps can reproduce the bug?

Run:
codex login
The browser opens normally.
Authenticate with the corporate ChatGPT/OpenAI account.
Browser authentication succeeds and redirects to:
localhost:1455/auth/callback
Codex then displays:
Sign-in could not be completed

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

Error code:
token_exchange_failed
Try device authentication instead:
codex login --device-auth
It fails immediately with:
Error logging in with device code: error sending request for url
(https://auth.openai.com/api/accounts/deviceauth/usercode)

Check direct connectivity:

curl.exe -Iv https://auth.openai.com
HTTPS connectivity succeeds, but Cloudflare responds:
HTTP/1.1 403 Forbidden
Cf-Mitigated: challenge
Server: cloudflare

What is the expected behavior?

Codex CLI should successfully complete either the standard OAuth flow or device authentication and sign the user in.

If the server is returning an HTTP response such as a Cloudflare challenge, it would also be useful for Codex to expose the actual HTTP status/response rather than reporting only:

error sending request for url (...)

This would make network/authentication issues significantly easier to diagnose.

Additional information

My case may provide an additional data point because coworkers using the same corporate environment can use Codex successfully while authentication consistently fails on this machine.

I can provide additional Codex logs, Windows networking diagnostics, certificate-chain information, or HTTP traces if useful.

any aditional info with the execution of the follow commands:

where.exe codex
C:\Users"user"\AppData\Roaming\npm\codex
C:\Users"user"\AppData\Roaming\npm\codex.cmd

netsh winhttp show proxy

Configuración actual del proxy WinHTTP:

Acceso directo (sin servidor proxy).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the codex login OAuth flow and codex login --device-auth path, focusing on requests to https://auth.openai.com/oauth/token and /api/accounts/deviceauth/usercode. Reproduce on Windows with the reported Zscaler TLS inspection and compare the CLI behavior with curl.exe. Done means authentication works in this environment or the CLI exposes the relevant HTTP status and response instead of only error sending request for url.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
authentication, cli, operating-systems, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.