按错误后缀定位故障环节

同样表现为 Codex 登录失败，但完整错误后缀与日志特征决定了排查方向。建议对照下表逐行处理：每次只执行一项优先操作并观察日志变化，同时改动多项会使分流判断失效。

  • 错误文本包含 error sending request for url（指向 auth.openai.com/oauth/token）：问题出在客户端令牌交换的代理或证书环节，应核对启动进程的代理变量与证书链。
  • 日志记录 HTTP CONNECT 返回 407：企业代理认证未完成，需与管理员确认代理支持的认证方式，并携带诊断信息提交支持。
  • 浏览器中 localhost 回调页无法访问：仍处于浏览器回调阶段，应核对回调地址，远程主机改用设备码或 SSH 转发。
  • 返回 403 或 400：属于服务端响应，需阅读正文，记录响应内容与请求 ID，不能直接判定为账号或出口问题。
  • 多账号、多网络在同一时段集体失败：可能是服务端波动，可观察等待，历史个案约两小时后自行恢复。

需要明确：浏览器授权、localhost 回调、令牌交换是三个不同阶段，回调成功并不能证明客户端请求成功；登录后的 401 属于另一条排查线。

Windows 下让代理变量真正进入启动进程

在企业网络必须经 HTTP 代理出网的环境里，浏览器能正常授权、Codex 普通启动却令牌交换失败，常见原因是代理变量没有进入实际启动进程——.env 中写了不等于进程会采用，有排查者抓到直连 443 停在 SYN_SENT 状态。处理顺序如下：

  1. 确认代理客户端真实监听的协议与端口，不要使用已过期的端口。
  2. 保存任务并完整退出 Codex 桌面程序。
  3. 在 PowerShell 中设置会话级变量；HTTPS_PROXY 的 http:// 前缀表示 HTTP CONNECT 代理，并不要求本地代理支持 TLS。
  4. 在同一个 PowerShell 会话中启动实际安装的桌面可执行程序，重新走登录流程。
  5. 登录后发送一条真实请求，确认能拿到模型响应。

会话级变量设置示例：

  • $env:HTTP_PROXY = "http://127.0.0.1:端口"
  • $env:HTTPS_PROXY = "http://127.0.0.1:端口"
  • $env:ALL_PROXY = "http://127.0.0.1:端口"
  • $env:NO_PROXY = "localhost,127.0.0.1,::1"

这套会话级启动方式有单人实测恢复记录，覆盖了升级后仍失败的场景；但也存在子进程继承变量后依旧失败的记录，说明传入变量不等于问题解决，还需继续核对残留配置与证书链。

清理残留代理条目与协议冲突

旧代理工具卸载后，.codex/.env 中常残留旧的 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 条目，端口早已失效，客户端却仍按旧值连接，有用户清理后即恢复。处理时先备份整个 .env，只更正或移除确认失效的代理项；必须经代理出网的网络不能清空后直连。清理顺序：

  1. 退出 Codex，将 .codex/.env 与 config.toml 复制留底。
  2. 逐项核对，仅对端口连不通、工具已卸载的条目进行移除或更正。
  3. 确认协议匹配：SOCKS 监听应使用客户端自带的 HTTP 端口，HTTP 监听则直接填写。
  4. 重启客户端重走登录，用真实响应验收。

协议不匹配属于另一类冲突：只有 SOCKS5 监听却把端口填进 HTTP 变量，连接不会按预期建立；仅把 socks5:// 改写成 http:// 并不算完成协议转换。有一个单人组合案例：借助已有可信工具把本地 SOCKS5 转成本地 HTTP 监听，配合干净的 CODEX_HOME 完成认证，并在备份隔离原 .env 与 config.toml 后，CLI、桌面与真实请求均恢复正常。原帖示例命令为：gost -L http://127.0.0.1:8899 -F socks5://127.0.0.1:7890。使用前须有可信工具并核对协议与端口，优先采用客户端自带的 HTTP 监听，不要认定某个配置项就是根因。干净 CODEX_HOME 仅用于定位差异：隔离目录下成功只说明原配置存在差异，不要删除原目录与数据库。

证书校验失败时挂载可信 CA

只有当日志明确出现 TLS handshake or certificate validation failed 一类证据时，才进入本分支。在企业 TLS 检查或私有根 CA 场景下，浏览器与 curl 走系统信任库所以正常，而客户端信任库不同，因而失败。官方支持在登录前设置 CODEX_CA_CERTIFICATE 指向可信 PEM 包，未设置时回退到 SSL_CERT_FILE，覆盖登录、HTTPS 与安全 WebSocket。操作顺序：

  1. 从管理员或可信系统来源取得正确的 PEM 链，不要下载来路不明的证书。
  2. 在启动会话中设置变量，路径按实际情况替换。
  3. 在同一会话执行 codex login 或启动桌面程序，重走登录。
  4. 确认原先失败的登录与真实请求均已成功。

变量写法示例：

  • Windows PowerShell：$env:CODEX_CA_CERTIFICATE = "C:\path\to\corp-ca.pem"
  • macOS / Linux：export CODEX_CA_CERTIFICATE=/path/to/corp-ca.pem

老版本可按支持情况使用 SSL_CERT_FILE。全程不得降低安全等级：不使用 curl -k、不设置 NODE_TLS_REJECT_UNAUTHORIZED=0，也不关闭安全软件。有单人提供系统根 CA 包后登录成功的记录，其中对内置信任库的解释属于个人诊断，不宜外推。

407、设备码与登录验收

CONNECT 返回 407 说明请求已到达代理，卡在认证环节。企业代理要求 Negotiate 或 NTLM 时，curl 使用集成认证可以连通，客户端可能没有对应实现，目前没有已验证的通用修复方案：应让管理员核查支持的认证方式，携带脱敏诊断提交官方支持，重填变量或更换节点均无恢复记录支撑。

官方 codex login –device-auth 面向回调不便的无头环境，需要账号与工作区允许；它仍要连接认证服务，网络问题未解决照样失败。回调不可达的远程主机，官方做法是用 SSH 转发本地 1455 端口；已收到 callback 且 state_valid=true 的情况不必优先折腾 1455。历史上存在多账号多网络同时失败、约两小时后自行恢复的个案，虽无官方事故确认，但说明不能全部归因于本地。

恢复动作完成后，按三步验收：

  1. codex login 返回成功，客户端显示已登录。
  2. 发送一条真实请求并拿到模型响应；curl 返回 400 只证明到达端点，不代表登录已恢复。
  3. 完全退出并重启客户端，确认登录与请求均正常。

三步全部通过才算闭环；任何一步失败，都应整理脱敏诊断信息（时间、版本、命令、状态码、请求 ID）提交官方支持。授权阶段卡住可参考 Codex 登录卡住排查，登录后的 401 按 Codex 401 排查分流。

常见问题解答

  • error sending request for url 与 token 额度不足是一回事吗？不是。前者是授权成功后客户端交换令牌失败，多发生在代理、证书、配置环节；额度不足属于用量问题。
  • curl 能连通 auth.openai.com 就代表 Codex 能登录吗？不能。curl 返回 400 只证明到达端点，客户端未必走同一路径、同一信任链，应以真实响应为准。
  • 设备码登录能绕开代理问题吗？不能。device-auth 面向回调不便场景，仍要连接认证服务，网络问题未解决照样失败。
  • 清理 .codex/.env 之前要做什么？备份整个文件，只更正或移除失效代理项，其余保留；必须经代理出网的不能清空后直连。

总结

Codex token exchange failed 是授权成功后、客户端令牌交换阶段失败的统称，完整后缀与日志特征决定排查方向。Windows 会话级代理变量、残留配置清理、证书链挂载可信 CA 是本地可闭环的主线；407 企业代理认证没有通用修复方案，设备码也不是绕开网络问题的捷径；多账号多网络同时失败时，要给服务端波动留出位置。主线只有一条：每次只改一处，改完回到登录与真实模型响应验收，curl 能通不算数。逐条核对后若结论指向网络路径，可参考 https://www.ipxss.com/ 了解海外 AI 网络方案，用固定归属出口做对照验收，再决定是否切换。