看到 Token exchange failed: token endpoint returned status 403 Forbidden，只能确定认证交换请求被拒绝，不能据此认定 OpenAI 宕机、代理异常、地区受限或缓存过期。先确认失败发生在 localhost 回调、出站令牌交换，还是登录后的首次认证请求；在重置前记录 codex --version、执行 codex login status、写清 Codex 实际运行环境，并保存已脱敏的响应正文。拒绝节点不明时，不要删除 ~/.codex、关闭 TLS 校验、绕过地区限制，也不要分享回调地址或令牌。
| 现象 | 拒绝位置 | 第一项有效检查 |
|---|---|---|
| 浏览器没有回到 Codex | localhost 回调 | 浏览器和监听进程是否处于同一可达环境 |
| 浏览器授权成功，随后出现精确的交换 403 | 出站令牌交换 | 响应正文、代理/WAF、CA、地区账号和执行环境 |
| 登录完成，第一次 Codex 请求才报 403 | 认证后的请求 | 工作区权限、模型权限、供应商路由和凭据来源 |
回调失败不等于令牌端点拒绝，登录后的 API 403 也不等于交换失败。只修复能够用证据确认的那一跳；响应正文若已经指向账号、工作区、政策或支持地区，就应停止反复修改代理。
“核验时间：2026-07-12。 当时 OpenAI 状态页未显示全局事故，但绿色状态不能证明你的企业网络、账号、工作区或地区路径正常。
先按这五步排查
1. 在报错的同一环境记录状态
bashcodex --version codex login status
必须在原来的 macOS、Windows、Linux、WSL、容器、SSH 主机或 IDE 终端中执行。当前核验机器显示 codex-cli 0.144.0-alpha.4，这只是样本，不是最低版本要求。
2. 查看当前服务状态
打开 OpenAI 状态页 并记下时间。若正在发生认证或 Codex 事故，保留证据并等待恢复；若状态正常，继续检查本地路径，不能把绿色状态当成排除法的终点。
3. 写清“谁在运行 Codex”
浏览器可能在宿主机，而 Codex 运行在 WSL、容器或远程服务器。浏览器到不了监听端口属于回调拓扑问题；Codex 已收到回调，随后明确报 token endpoint 403，才进入出站交换分支。
4. 保存响应，但先脱敏
保留错误全文、时间与时区、版本、命令、简短错误码和请求 ID。删除授权码、访问/刷新令牌、完整回调 URL、Cookie、API Key、邮箱、组织 ID 与代理凭据。响应正文中的政策码、工作区提示或企业拦截页，往往比 403 本身更能确定责任方。
5. 只做一次受控重试
一次只改变一个变量：升级 Codex、切回批准的网络、修正运行环境、加入企业批准的 CA，或清理当前登录态。成功标准不是“浏览器显示成功”，而是同一环境中登录完成且：
bashcodex login status
显示预期认证方式，并能完成一次小型认证请求。
把登录路径拆成五跳
Codex 登录依次经过：浏览器授权、localhost 回调、用授权码交换令牌、凭据存储、首次认证请求。精确的 token exchange 403 位于第三跳，它缩小了范围，但仍可能由 OpenAI 账号或政策控制、企业代理/WAF、TLS 检查与 CA、错误的执行环境或过期状态触发。
OpenAI 的 Codex 认证文档 是认证方式与凭据存储的事实来源；环境变量文档 记录了自定义 CA 的 CODEX_CA_CERTIFICATE。使用正式的信任链配置，不要关闭证书校验。
按证据选择分支
| 分支 | 证据 | 有边界的动作 | 成功信号 | 停止条件 |
|---|---|---|---|---|
| 代理或 WAF | 企业拦截页、代理请求 ID、批准的直连路径可用 | 请网络管理员放行认证路径，并让回环流量留在本机 | 一次干净登录完成 | 不绕过组织政策 |
| 企业 CA | 证书链错误，且网络明确做 TLS 检查 | 使用批准的 PEM CA 包 | 保持校验开启并完成交换 | 不使用不安全 TLS 参数 |
| WSL/容器/远程 | 浏览器与监听进程不在同一网络空间 | 在回调可达的环境登录，或使用官方替代认证 | 同一 Codex 进程收到回调 | 不公开暴露监听端口 |
| 地区或账号 | 正文出现 unsupported_country_region_territory 或账号限制 | 核对支持国家与地区，错误时联系支持 | 官方路径恢复资格 | 不用 VPN 或借用账号绕过 |
| 工作区 | 个人路径可用，SSO/工作区路径被拒 | 请管理员确认 Codex 权限与身份策略 | 预期工作区登录成功 | 明确是政策后停止改本地代理 |
| 认证缓存 | 路由与政策均正常，重新登录后行为变化 | codex logout 后只做一次干净登录 | 状态与请求均成功 | 不先删除整个目录 |
代理与证书：不要把回环和出站混为一谈
如果环境必须使用代理，localhost 回环通常应留在本机：
bashexport NO_PROXY="localhost,127.0.0.1,::1"
但出站令牌请求可能必须经过企业批准的代理，不要把所有认证域名都盲目加入 NO_PROXY。检查变量时避免泄露用户名和密码：
bashenv | grep -iE '^(HTTP|HTTPS|ALL|NO)_PROXY='
企业确实做 TLS 检查时，向安全团队取得批准的 PEM 文件：
bashexport CODEX_CA_CERTIFICATE="/path/to/company-ca-bundle.pem" codex login
证书错误与 HTTP 403 是两种信号，只有存在证书链或拦截证据时才走 CA 分支。
只重置需要重置的认证层
先用可逆操作：
bashcodex logout codex login
不要把 rm -rf ~/.codex 当第一步。目录里可能还有配置、状态和诊断信息。需要确认文件职责时，参考 Codex config.toml 指南。不要复制他人的 auth.json，也不要把自己的文件发到工单或公开 Issue。
当前 CLI 样本提供 --device-auth、--with-api-key 和 --with-access-token。设备认证适合解决浏览器到 localhost 的拓扑问题，但不能越过账号或地区政策；API Key 是开发者计费路径，功能与账单边界不同，可先看 Codex API Key 与订阅的区别；访问令牌只适合受信任且有文档约束的自动化流程。
按具体症状读取下一步
浏览器停在成功页，终端一直等待
这更像回调没有到达正在等待的 Codex 进程，而不是 token endpoint 已经返回 403。先确认终端是否仍显示等待状态、回调地址是否指向 localhost、浏览器与 Codex 是否位于同一主机或网络空间。WSL 和远程 SSH 最容易出现“浏览器在本机，监听器在另一个环境”的错位。
不要因为网页写着 success 就假设整个认证已经完成。网页只代表用户授权那一步完成；本地进程仍需要收到回调。可以在正确的宿主环境重新发起一次登录，或在当前 CLI 明确支持时使用 device auth。不要把本地监听端口映射到公网来图省事。
终端明确打印 token endpoint 403
此时回调通常已经进入 Codex，关注出站交换。先看响应是 JSON、普通文本，还是企业代理生成的 HTML。三者分别更可能由服务政策、客户端/账号规则和中间网络层拥有。保存短错误码与 request ID，避免只截取最后一行 403 Forbidden。
若同一账号在批准的直连网络可以完成登录，而企业网络稳定返回带品牌的拦截页，证据指向代理或 WAF。相反，若不同网络都返回相同的账号或地区政策码，继续换代理没有价值，应转给 OpenAI Support 或工作区管理员。
证书报错与 403 同时出现
先按时间顺序判断。TLS 握手失败时，客户端通常还没有收到真正的 HTTP 403；所谓“403”可能来自企业代理的拦截页。如果安装批准的 CA 后握手正常，随后仍得到 OpenAI 风格的 JSON 403，那么证书链已修复，剩下的是另一条分支。不要把两个阶段合并成“证书导致所有 403”。
可以让网络团队确认代理是否做 TLS inspection、应使用哪份根证书、认证域名是否被允许，以及代理能否保留必要的请求头。不要从论坛下载陌生证书，也不要把 NODE_TLS_REJECT_UNAUTHORIZED=0 之类的全局关闭方式写进 shell 配置。
只有 WSL、容器或 SSH 环境失败
在宿主机成功、隔离环境失败，是执行环境差异的强证据。分别记录 codex --version、代理变量、NO_PROXY、CA 变量和 codex login status，不要只比较浏览器。容器还可能在每次启动后丢失凭据存储，因此“刚登录成功，下次又要求登录”与交换 403 是两个问题。
选择在哪里完成登录时，以实际要运行 Codex 的环境为准。不要在宿主机生成认证文件后直接复制进容器；这样既可能泄露令牌，也会掩盖原环境的网络或存储问题。
只有公司工作区或 SSO 失败
个人账号能用不代表工作区路径正常。确认浏览器实际选择的账号、组织和身份提供商，避免在多个已登录账号之间误选。管理员需要核对 Codex 是否对该成员开放、SSO 是否强制、条件访问是否允许当前设备，以及身份映射是否落到正确组织。
响应若出现 workspace、organization、entitlement、policy 等明确字样，应把它们作为责任边界，而不是继续清 Cookie 或换 DNS。管理员修正后，用同一工作区、同一环境重新登录并验证一次。
交换成功但第一次请求仍是 403
先运行 codex login status 确认凭据已经保存，再检查首次请求的响应。它可能涉及模型权限、工作区授权、供应商兼容层或 API Key 来源，与 OAuth 交换不是同一故障。若设置了多个凭据来源，还要确认环境变量、系统凭据存储和本地状态中哪个优先。
不要把“API Key 登录成功”当成“ChatGPT 登录已修复”。两条路线都能让 Codex 发请求，但计费、功能和组织边界可能不同。验证报告中应写清使用了哪一种认证方式。
一次可复现的最小记录
支持人员最容易处理的是短而完整的时间线，而不是一堆重复截图。可以按下面的格式记录：
text2026-07-12 17:20 +08:00 OS/runtime: macOS host / WSL / container / SSH Codex: <codex --version 输出> Auth route: ChatGPT / device auth / API key / access token Callback: reached / did not reach / unknown Exchange: 403, body=<脱敏后的短错误码>, request_id=<如有> Network: direct / corporate proxy / TLS inspection Change tried: <只写一个变化> Result: same 403 / login completed / later request failed
这份记录建立了因果顺序：先发生什么、改了什么、结果是否改变。若每次重试同时更换浏览器、网络、账号和 Codex 版本，就无法判断哪一个变量真正生效。
看似快捷但会破坏诊断的动作
- 反复点击登录。 新授权码可能覆盖上一轮时间线，让 request ID 与响应对不上。
- 一次清空浏览器、
~/.codex和系统凭据。 即便恢复，也无法知道责任层，且可能删除其他配置。 - 把所有域名加入
NO_PROXY。 可能修复 localhost，却让必须经过企业代理的出站请求失联。 - 直接换 VPN 或地区。 这既违反政策边界，也会让账号风险与原始网络问题混在一起。
- 在公开 Issue 粘贴完整日志。 回调参数、邮箱、内部主机和代理 URL 都可能泄露。
- 把第三方供应商的 403 当成 OpenAI OAuth 403。 先确认请求最终到达的服务和使用的认证协议；兼容 API 的供应商错误由该供应商拥有。
正确的排查不是尝试次数最多，而是每一次尝试都能排除一个责任层。若一次修改没有改变响应形状、错误码或失败阶段，就回到证据，而不是继续叠加更多修改。
什么时候升级给支持人员
响应正文若点名账号、工作区、政策或地区，应立即升级；否则，在当前版本、批准路径上进行一次干净重试仍失败后升级。提交错误全文与脱敏正文、时间时区、版本、认证方式、操作系统与运行环境、回调是否成功、代理/WAF/TLS 情况、请求或 /feedback 线程 ID，以及唯一一次修改和结果。
不要提交回调 URL、授权码、令牌、API Key、Cookie、完整 auth.json 或未脱敏代理地址。认证恢复后若问题变成额度或用量，再转到 Codex 使用限制。
常见问题
403 是否说明 OpenAI 宕机？
不是。它只说明交换请求被拒。状态页只能排查全局事故，仍需检查响应正文、网络路径、账号工作区和执行环境。
为什么浏览器显示登录成功，Codex 仍失败？
浏览器授权与令牌交换是两跳。用户授权成功后，授权码换令牌的出站请求仍可能被代理、政策或账号规则拒绝。
要不要把 OpenAI 域名加入 NO_PROXY？
不要盲目添加。localhost 回环可保持本地，出站端点可能必须走企业代理，应由网络政策决定。
能否改用 API Key 绕过？
API Key 可以是合适的开发者认证方式，但会改变计费和功能语境，不能绕过账号、工作区或支持地区政策，也不能证明原登录路径已经修复。
何时停止本地排查？
正文出现政策、账号、工作区或地区拒绝时立即停止；否则在批准路径上一次干净重试仍复现相同证据后停止，并把脱敏证据交给真正控制该层的人。