Codex 原本用得好好的，你什么都没改，突然每条消息都返回 unexpected status 401 Unauthorized: Incorrect API key provided。更奇怪的是：你根本没用 API key，而是用 ChatGPT 账号登录的。这个报错有三种完全不同的原因，其中只有一种能在你自己的电脑上解决。最快的区分方法，就是看报错信息里被遮盖的那段密钥。
Codex 的 401 "Incorrect API key provided" 是什么意思？
意思是 OpenAI 的服务器拒绝了请求携带的凭证。完整报错通常是这样：
unexpected status 401 Unauthorized: Incorrect API key provided: sk-svcac***...fvMA.
You can find your API key at https://platform.openai.com/account/api-keys.,
url: https://chatgpt.com/backend-api/codex/responses决定一切的细节，是 provided: 后面被遮盖的密钥。它告诉你被拒绝的是哪一个凭证。如果那不是你的密钥，问题就不在你的电脑上，改密码、退出登录、清空配置都没有用。
怎样在 30 秒内判断是你的问题还是 OpenAI 的问题？
把被遮盖密钥的后缀，和 Codex 认为自己正在使用的凭证对比一下。两条命令就够：
codex login status
env | grep -E '^(CODEX|OPENAI)_'第一条会输出 Logged in using ChatGPT 或 Logged in using an API key - sk-proj-***abcde（已保存密钥的前 8 位和后 5 位）。第二条显示你的 shell 里有没有导出任何密钥。拿到这两个结果，对照下表就能找到你的情况：
| 你看到的 | 原因 | 怎么做 |
|---|---|---|
密钥以 sk-svcac 开头，且状态显示 Logged in using ChatGPT | OpenAI 那边的故障 | 查看 status.openai.com，等待恢复 |
只有 codex exec 报错，交互式 codex 正常 | shell 里导出了 CODEX_API_KEY | unset CODEX_API_KEY |
| 被拒绝密钥的后缀和你保存的密钥一致 | 密钥已在控制台被撤销或删除 | codex logout 后重新登录 |
被拒绝的密钥以 sk-svcac 开头：发生了什么？
这是 OpenAI 自己的服务密钥，不是你的。2026年9月25日就发生了这种情况：大约 22:40 到 23:54 UTC（北京时间 9月26日 6:40 到 7:54），所有用 ChatGPT 登录的 Codex 请求都返回同一个 sk-svcac…fvMA，Mac、Windows、Linux 都一样。OpenAI 在官方状态页把这次事故记为 "Issues with Codex"，影响 Codex Web、CLI、VS Code 扩展和 API，并在 23:54 宣布全部恢复。
在有 90 多条评论的 issue #48237 里，几十个人确认本地操作都没用：codex logout 后重新登录、清空 CODEX_HOME、重装应用、轮换密钥。有用户证明，同一个 OAuth token 调 GET /backend-api/codex/models 是正常的，只有 POST /backend-api/codex/responses 失败。被拒绝的凭证是在服务器端被替换掉的。
这种情况下该怎么做：
- 打开
status.openai.com。如果有未关闭的 Codex 事故，就是它。 - 不要轮换或删除你的密钥：报错里的那个密钥不是你的。
- 如果等不了，OpenAI 在事故期间公布的临时办法是改用 API key 登录，按 token 从平台账户计费，不走 ChatGPT 套餐：
printenv OPENAI_API_KEY | codex login --with-api-key事故结束后，用 codex logout 和 codex login 切回正常登录，否则你会在不知不觉中一直按 token 付费。
只有 codex exec 返回 401，交互式 codex 正常：为什么？
因为你的环境里有 CODEX_API_KEY，而 codex exec 会优先使用它，而不是 ChatGPT 登录。这写在 Codex 源代码里（codex-rs/login/src/auth/manager.rs），注释原文是 "API key via env var takes precedence over any other auth method"。codex exec 会读取这个变量；交互式 codex 和 codex login status 不会。
实际效果很隐蔽：codex login status 显示 Logged in using ChatGPT，交互式终端也正常，但你用 codex exec 的 CI 脚本或别名却报 401，用的是留在 .bashrc、.env 或流水线 secret 里的旧密钥。
# 检查变量是否已设置
env | grep -E '^(CODEX|OPENAI)_'
# 从当前会话中移除
unset CODEX_API_KEY
# 再测试一次
codex exec "只回复：OK"如果测试通过，找出导出这个变量的位置（grep -rn CODEX_API_KEY ~/.bashrc ~/.zshrc ~/.profile），删掉它或换成当前有效的密钥。
后缀是你自己的密钥：怎么解决？
那就是 Codex 里保存的密钥已被撤销、删除，或者属于一个没有权限的项目。几个月前用过 codex login --with-api-key、后来又在平台控制台清理过密钥的人，常会遇到。codex login status 会显示已保存密钥的结尾，可以直接和报错里的后缀对比。
codex logout
codex login # 切回 ChatGPT 登录
# 或者继续用 API key：
printenv OPENAI_API_KEY | codex login --with-api-key--with-api-key 从标准输入读取密钥，而不是作为参数。如果你在终端里单独输入 codex login --with-api-key，它会提示需要通过管道传入密钥。
三种情况都不符合怎么办？
运行本地诊断并保存输出：
codex doctor --json它会显示已保存的认证模式（stored auth mode）、是否保存了密钥或 ChatGPT token（stored API key、stored ChatGPT tokens），以及环境里是否存在 OPENAI_API_KEY 或 CODEX_API_KEY，但不会泄露具体值。这样提 issue 时就不会暴露秘密。
值得注意：即使 OpenAI 宣布 9月25日的事故已解决，issue #48237 里仍出现了零星的同样 sk-svcac 报告，一条是 9月26日在 VS Code 扩展里、用完使用额度之后，另一条是 9月28日在装有 CLI 0.158.0 的树莓派上。截至 2026年9月29日，没有维护者回复这两条。如果你也是这种情况，把 codex doctor --json 的输出附到这个未关闭的 issue 里，不要另开新 issue。
当 401 来自服务器时，你电脑上做什么都没用，所有人停工的时间都一样。能减少损失的，是在终端里备好第二个编程智能体。Verboo Code 在终端中运行、token 不限量，在主服务商恢复之前让工作继续下去。
