ChatGPT 网页能正常登录，但 Codex 命令行登录时反复报 token_exchange_failed，提示无法请求 auth.openai.com/oauth/token。这类问题多半出在本地代理继承与回调链路上，而非账号本身。文章拆解 Codex 的 OAuth 登录流程，给出从代理变量、NO_PROXY、连通性测试到清凭据重登的分步排查清单，并说明账号限制、服务端抖动与第三方代登录各自的风险边界。
浏览器里登录 ChatGPT 一切正常，换成 Codex 命令行就卡在登录页，报 Sign-in could not be completed，错误码 token_exchange_failed，细节写着 error sending request for url (https://auth.openai.com/oauth/token)。同账号、同机器、同网络，网页能过、CLI 过不去，这种落差基本可以把怀疑范围从「账号被封」收窄到本地网络与凭据链路。
下面按登录流程拆开讲，先定位失败发生在哪一步，再给出可逐条执行的排查清单。
先看清 Codex 的登录链路
Codex 的登录是一个标准 OAuth 流程，分三段：
- Codex 进程在本机启动一个监听端口（
127.0.0.1上的随机端口）； - 打开浏览器访问
auth.openai.com完成授权，授权完成后浏览器跳回127.0.0.1:xxxx，把授权码交给本地进程； - Codex 拿着授权码，自己再向
https://auth.openai.com/oauth/token发起一次 HTTPS 请求换取 token。
报错文案里写的是「error sending request」，说明卡在第三步：请求压根没发出去或没拿到响应，而不是服务端返回了 4xx 拒绝。最典型的解释就是——浏览器走系统代理所以能打开网页，而 Codex 是独立进程，没有继承到代理设置。
常见原因对照
| 表现 | 更可能的原因 |
|---|---|
浏览器正常，CLI 报 token_exchange_failed |
Codex 进程没继承代理环境变量 |
| 浏览器授权完卡在回调页、CLI 无反应 | 127.0.0.1 的回调请求被代理转发走了 |
| Windows 侧正常，WSL 里失败 | 代理只在 Windows 侧配置，没进 WSL |
| 换账号、换工作区都一样报错 | 本机到 auth.openai.com 的线路不通 |
| 反复重试偶尔能成功 | 服务端抖动或限流，与本地配置无关 |
| 报错提到 workspace admin / access restricted | 工作区策略限制，不是网络问题 |
分步排查清单
1. 确认代理变量真的进了 Codex 进程
# PowerShell
$env:HTTP_PROXY
$env:HTTPS_PROXY
Get-ChildItem Env: | Where-Object Name -match 'proxy'
# macOS / Linux
env | grep -i proxy
两个细节容易踩坑：
- 大小写都要设。不少工具只认小写
http_proxy/https_proxy，两套都写最保险。 - 设完必须重开终端。已经跑着的 shell 不会自动更新环境变量，
codex自然还是旧环境。
如果确认是「用脚本包一层再启动才正常」，那说明问题就在继承关系上，把变量写进 shell 配置文件（~/.bashrc、~/.zshrc 或 PowerShell 的 profile）比每次手工前置更稳妥。
2. 让本地回调绕开代理
这一步经常被忽略：代理如果连 127.0.0.1 也转发，浏览器回调就交不到 Codex 手上。
export NO_PROXY=127.0.0.1,localhost,::1
export no_proxy=127.0.0.1,localhost,::1
用全局 TUN 或「增强模式」类代理工具时，要在工具里把 127.0.0.1、localhost 加入直连或绕过列表，而不是只改环境变量。
3. 从命令行验证到 auth.openai.com 的连通性
curl -v -o /dev/null -w '%{http_code}\n' https://auth.openai.com/oauth/token
# 再对比一次直连
curl --noproxy '*' -v -o /dev/null -w '%{http_code}\n' https://auth.openai.com/oauth/token
判断标准：返回 4xx（如 400/405）说明链路是通的，只是请求方式不对；超时、连接重置、TLS 握手失败才是真不通。两次结果对比还能告诉你，问题出在「代理没生效」还是「代理节点本身连不上目标」。
4. 清掉旧登录状态再重登
先用 Codex 的登出命令或官方文档给出的凭据清理方式退出，再重新登录。注意：
- 不要同时开多个终端反复点登录，回调端口会互相抢占；
- 确认没有残留的其他账号或工作区配置；
- 清完凭据后，先确保第 1、2 步的变量在新终端里已生效，再发起登录。
5. 换一条出口做交叉验证
用手机热点、另一台机器或另一个网络环境重试一次。如果换了就成功，问题锁定在原出口线路或节点上，回到代理配置和节点质量上排查，而不是继续折腾账号。
6. WSL 与容器场景
- 代理必须在 WSL 内部可见，只在 Windows 侧设置无效；WSL2 的镜像网络模式能让
localhost双向可达，但环境变量仍要显式传进去。 - 容器里跑时，
127.0.0.1指向容器自身，宿主机的回调端口未必透传，登录要在能接触到浏览器的那一侧完成。
分清「登录失败」和「账号被限制」
- 服务端抖动：集中时段用量大，会出现重试几次才成功，或伴随模型设置更新失败、消息提交超时。这类本地改不了，隔一段时间再试即可。
- 工作区策略：报错明确提到管理员或访问受限，属于权限配置，找管理员，不要继续换节点。
- 风控：短时间内频繁切换出口、反复重登、多账号轮换，有时反而更容易触发限制。排查时尽量固定一条稳定线路。
另外提醒一句：报错文案和登录流程会随官方版本调整，具体命令与参数请以官方文档的最新说明为准。
关于第三方「代登录」和共享账号
遇到登录不上时，很容易被引导去找所谓代登录、共享账号或中转授权服务。这类做法不建议碰：OAuth 授权等同于把账号控制权交出去，回调环节理论上可以截取授权码；共享、买卖账号本身违反服务条款，随时可能被封；出问题时也无法申诉。合规的替代路径是：用自己的账号走官方订阅、用 API key 调用官方接口、团队场景由管理员统一开通工作区权限。
长时间在线运行的补充建议
如果 Codex、Claude Code 这类命令行工具需要长时间挂着跑长任务，本地机器休眠、Wi-Fi 切换、代理节点抖动都会打断鉴权和长连接，表现就是任务跑到一半莫名中断、下次启动又要重新登录。这种情况除了把代理配置写进 shell 配置，也可以考虑换个运行位置——例如使用整台放在机房的独享远程 Mac，按月租用、远程连接使用，出口网络稳定且可长期在线，适合挂这类 CLI 工具。这只是可选方案之一，多数人把代理继承和 NO_PROXY 两件事做对就够了。
小结
按这个顺序走一遍，绝大多数 token_exchange_failed 都能定位：
- 报错发生在换 token 这一步，先怀疑 Codex 进程没有代理；
- 代理变量大小写都设，设完重开终端；
NO_PROXY放行127.0.0.1、localhost，代理工具里也加直连；curl分别带代理和--noproxy测一次auth.openai.com；- 清旧凭据、单终端重登，别并发；
- 换网络交叉验证，排除线路问题；
- 报错涉及工作区权限或大面积服务异常时，停止折腾本地配置。