先保留现场，再动一项配置
记录你在客户端还是 CLI、运行在哪台主机、版本号、工作目录、请求时间和错误原文。截图先遮住密钥、邮箱及敏感路径。排查时每次只修改一项，随后用同一个短任务验证，否则即使恢复正常也很难知道原因。
codex --version
codex login status
printf '%s\n' "${CODEX_HOME:-$HOME/.codex}"先判断失败发生在哪一层
| 症状 | 第一组检查 | 还不能证明什么 |
|---|---|---|
| 启动时报 TOML 错误 | 引号、重复键、表归属与版本支持 | 不是 Key 是否可用的结论 |
| 401 / 403 | 当前凭据、变量注入和服务端权限 | 不一定只是 Key 过期 |
| 404 | 实际请求路径、Base URL 和协议 | 不能靠无限添加 /v1 解决 |
| 模型不存在 | 供应商模型 ID 与授权 | 展示名称不等于 API ID |
| 一直使用旧模型 | 配置优先级与旧进程 | 改了文件不等于会话重载 |
| 命令执行被拒 | 沙箱、审批和组织要求 | 不等于模型 API 连接失败 |
401：把凭据和路由一起看
先分清使用官方登录缓存还是自定义供应商 env_key。前者检查 codex login status 与凭据存储；后者确认变量对当前进程可见。不要把第三方 Key 用于官方端点，也不要把 ChatGPT 订阅状态当作 API Key 有效的证明。403 还可能与账号、模型或服务端访问权限有关，具体以响应为准。
404：先找实际请求地址
在供应商侧日志或脱敏诊断中找请求路径。确认 Base URL 的前缀是否正确，供应商是否接收 Responses。当前 Codex 的 wire_api 只有 responses；一个能返回 /chat/completions 的服务不一定能承接 /responses。若连日志都没有请求，继续检查 DNS、代理与连接阶段，别先下结论说模型不可用。
客户端和 CLI 不一致时
- 确认两边在同一台执行主机上，且读取相同 CODEX_HOME。
- 检查 CLI 是否用了 --model、--profile 或 -c，以及项目配置是否有覆盖。
- 确认图形客户端是否继承了所需环境变量；终端 export 不保证桌面进程可见。
- 退出旧进程并开启新会话。对于供应商切换，到上游日志核对新请求的目标。
最小复现应该包含什么
客户端 / CLI 与版本：
操作系统及本地 / 远程：
工作目录和 CODEX_HOME（脱敏）：
预期模型 / 供应商：
实际错误和时间：
已检查的配置层：
最短复现步骤：
修改前后结果：无需提供真实 Key、完整 auth.json 或全部聊天记录。配置片段保留字段名与结构即可，服务地址也应按实际敏感程度脱敏。先验证一个小任务，再恢复长会话。若仍无法确定，明确写出“认证已通过、路由尚未确认”这样的边界，比笼统说“全都配好了”更方便继续排查。
依据与版本说明
依据以下官方文档整理。示例中的地址、模型和路径需按你的环境替换；旧版本与组织管理环境可能有不同限制。
资料核对日期：