# ChatGPT 网页好好的，Codex CLI 却卡在 token\_exchange\_failed **URL:** \ **Category:** 问题求助\ **Tags:** 问与答, ChatGPT, AICoding, Codex\ **Created:** [2026 年10 月 25 日 06:54 UTC](https://www.shiqidu.com/t/topic/1777 "2026-10-25T06:54:02Z")\ **Posts on this page:** 1\ **Page:** 1
作者： ![shiqidu\_editor](https://www.shiqidu.com/user_avatar/www.shiqidu.com/shiqidu_editor/32/528_2.png) [@shiqidu\_editor](https://www.shiqidu.com/u/shiqidu_editor)\ 发布日期： [2026 年10 月 25 日 06:54 UTC](https://www.shiqidu.com/t/topic/1777/1 "2026-10-25T06:54:03Z")
装的是 npm 上的 `@openai/codex`，终端跑 `codex login`。浏览器里 ChatGPT 账号能正常登进去，回调页也闪了一下，回到终端却报： ```plaintext Token exchange failed: error sending request for url (https://auth.openai.com/oauth/token) Error code: token_exchange_failed ``` 网页端没事，就 CLI 过不去。跟 VS Code / Cursor 插件一直转圈那种情况不一样，问题出在 CLI 自己的 OAuth：本地起回调、浏览器授权、CLI 再拿 code 去换 token，卡在了最后换 token 这一步。 ## 这步在干什么 按官方登录说明，`codex login` 会开浏览器走 ChatGPT 登录，再把凭证交回 Codex。大致流程是：CLI 在本机听一个回调（常见是 `localhost:1455`），你在 `auth.openai.com` 授权后跳回本地，CLI 再 `POST` 到 `https://auth.openai.com/oauth/token` 做 code → token 交换。网页能登，只说明浏览器这条链路通；`token_exchange_failed` 多半出在 CLI 进程自己访问 token 端点，或者本地回调被弄乱了。 官方也写了：远程 / 无头环境、本机网络把 localhost 回调拦了，浏览器登录 UI 可能就不稳，这时可以改走 `codex login --device-auth`（设备码，需在 ChatGPT 安全设置或工作区权限里打开）。本机有浏览器的话，还是先把默认的浏览器登录排查通。 ## 先查这几处 **1. 跑 CLI 的那个 shell 有没有走代理** 浏览器开了系统代理 / TUN，不代表敲 `codex` 的那个终端也继承了同样的出口。GitHub 上不少 issue 都是这种情况：同一台机器，浏览器授权成功，`curl` 能访问 `auth.openai.com/oauth/token`，Codex 仍报 `error sending request`，原因就是浏览器和 Codex 进程走的不是同一个出口。 若本来就靠 `HTTP_PROXY` / `HTTPS_PROXY` / `ALL_PROXY` 让终端出网，确认： - 变量写在实际启动 `codex` 的那个会话里，改完重开终端再 `codex login` - 代理监听端口还活着；有人踩过：环境变量还指向旧端口，代理早就换了，浏览器走系统规则没事，CLI 还在用那个失效的 `HTTP_PROXY` - `NO_PROXY` 里带上 `localhost,127.0.0.1,::1`，别把 OAuth 回调也塞进代理隧道 公司网还有 TLS 解密的，官方文档支持自定义 CA：设 `CODEX_CA_CERTIFICATE` 指向 PEM；未设时会回退看 `SSL_CERT_FILE`。反过来，过期或指错的 `SSL_CERT_FILE` 也会让 CLI 的 TLS 挂掉，系统浏览器照样能上。Windows 上已有人靠清掉陈旧 `SSL_CERT_FILE` 修好同类报错。 **2. 本地回调端口** 登录时终端一般会打类似 `Starting local login server on http://localhost:1455`。浏览器授权成功后要打回这个地址。代理规则、浏览器扩展、公司策略如果把 `127.0.0.1` 也转发走，回调到不了 CLI，后面换 token 也会出问题。官方 headless 文档里写了用 `ssh -L 1455:localhost:1455` 把回调转回来，本机也一样，先确认 1455（或你日志里那个端口）没被代理劫持、没被别的进程占用。 **3. 旧登录态清掉再走官方路径** CLI 和 IDE 扩展共用缓存登录；凭证可能在 `~/.codex/auth.json`，也可能在系统钥匙串（看 `cli_auth_credentials_store`）。半截失败的会话、换过账号、改过代理之后，直接再登一次有时会更乱。按官方的做法先登出再登： ```bash codex login status codex logout codex login ``` `logout` 清掉当前凭证，再重新走浏览器登录。需要看细节时，直接 `codex login` 会在日志目录写 `codex-login.log`。 API Key 是另一条线（`printenv OPENAI_API_KEY | codex login --with-api-key`），计费走 Platform，跟 ChatGPT 订阅额度不是一回事；本文只说 ChatGPT OAuth 这条 `token_exchange_failed`。 ## 还对不上时 同一错误码底下原因不止一种：代理未覆盖 CLI、陈旧代理/CA 环境变量、回调端口、偶发连通性，issue 里也有「curl 通了 CLI 仍挂」的报告。还排查不出来的，可以把 `codex --version`、是否设了 `HTTP_PROXY`/`HTTPS_PROXY`/`SSL_CERT_FILE`/`CODEX_CA_CERTIFICATE`、回调端口是否起来、以及 `codex-login.log` 里跟 `oauth/token` 相关的几行贴出来，比较好定位。 参考： - Codex 认证说明：[https://developers.openai.com/codex/auth](https://developers.openai.com/codex/auth) - npm 包 `@openai/codex`：[https://www.npmjs.com/package/@openai/codex](https://www.npmjs.com/package/@openai/codex)