跳转到主要内容

Codex 报 401 Incorrect API key provided：先看 URL 和 key 文本

报错里的 key 以 sk-svcac 开头，是 OpenAI 服务端事故，只能等；key 是 dummy 要重新登录，URL 是中转地址或 key 是你自己的才改配置。

LaoZhang AI Team发布于16 分钟阅读
文章目录
Codex 报 401 先看 URL 和 key：sk-svcac 开头等恢复，dummy 重新登录，中转域名改 config.toml，自己的 key 则核对 key

Codex 的 unexpected status 401 Unauthorized: Incorrect API key provided 不一定在说你的 key。同一句话至少有四个来源：OpenAI 服务端自己的凭据出了问题、本机的登录令牌刷新失败、config.toml 把请求送到了中转或第三方地址、你填的 OpenAI API key 确实不对。四种情况的处理动作互不相同，有的只能等，有的动了反而丢东西。

区分它们不需要猜。报错这一行里已经带着两条线索：url: 后面的地址，和 Incorrect API key provided: 后面那段打了掩码的 key。再加上 codex login status 显示的登录方式，就能定位到是哪一种。

报错里的 URL 和 key 文本对应哪一种 401

先把完整报错复制出来，不要只看前半句。一条典型的报错长这样：

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, cf-ray: …, request id: …

然后对照下表：

报错里的 URL报错里的 key 文本登录方式来源该做什么
chatgpt.com/backend-api/codex/responsessk-svcac 开头、不是你见过的 keyChatGPT 账号登录OpenAI 服务端看状态页，等恢复，不动本地文件
api.openai.com/v1/responsesdummyChatGPT 账号登录本机令牌刷新失败退出后重新登录
中转或第三方的域名你在那一家申请的 key自定义 provider那一层的 key 或地址改 config.toml 与环境变量
api.openai.com你自己的 sk- key 的掩码API key 登录OpenAI Platform核对 key、组织与 IP 限制

按报错里的 URL 和 key 文本，把 Codex 401 分成服务端事故、令牌刷新失败、中转配置、key 有误四种来源及对应动作

登录方式用一条命令确认：

bash
codex login status

输出 Logged in using ChatGPT 说明走的是 ChatGPT 账号登录；codex login status、codex logout 这两个命令的作用见 OpenAI 的 Codex 认证文档。

还有一种容易混进来的 401，消息体不是这句话，而是 {"detail":"Unauthorized"}，并伴随 “Your access token could not be refreshed because your refresh token was revoked. Please log out and sign in again.”（openai/codex #41975 里用户贴出的报错）。它已经把动作写在提示里了：退出再登录。下面只讲带 Incorrect API key provided 的那一种。

key 以 sk-svcac 开头且不是你的：OpenAI 服务端事故

你用 ChatGPT 账号登录，从没配过 API key，报错里却出现一个 sk-svcac 开头的 key，这不是本机的问题。2026 年 9 月 25 日的事故里，#48237、#48241 等多个 issue 的报告者贴出的掩码首尾完全相同，都是 sk-svcac…fvMA；他们的 codex login status 显示 Logged in using ChatGPT，环境里没有 OPENAI_API_KEY、CODEX_API_KEY、OPENAI_BASE_URL。不同的人、不同的机器看到同一个 key，由此可以推断它不属于任何一位用户。

OpenAI 的事故报告给出的原因与这个推断一致：一套检测凭据泄露的系统，把支撑 Codex 的内部服务间通信凭据误判为可能泄露，这些凭据随后被一次绕过既有保护的人工操作吊销。OpenAI 确认触发判断的流量是合法的，内部凭据并没有泄露。报告没有说明报错里显示的就是哪一个凭据，sk-svcac 这个前缀的含义也没有公开解释，但报告同样没有提到任何用户凭据受影响。

时间上有两个口径，不要混在一起：

  • 受影响时段：事故报告写的是 9 月 25 日约 3:33 p.m. 到 4:47 p.m. PDT，约 74 分钟。PDT 比 UTC 晚 7 小时、北京时间比 UTC 早 8 小时，换算过来是北京时间 9 月 26 日 06:33 到 07:47。
  • 状态页公告时段：状态页事件从 22:58 UTC 确认故障到 23:54 UTC 标记解决，共 56 分钟，即北京时间 06:58 到 07:54。也就是说，报错出现后大约 25 分钟状态页才有第一条更新。

北京时间 9 月 26 日 Codex 事故时间轴：受影响时段 06:33 到 07:47，状态页公告 06:58 到 07:54，中间约 25 分钟没有公告

受影响的是用 Sign in with ChatGPT 的 Codex 用户，表现为 401 认证错误和 502 网关错误；事故报告明确写了，用自备 API key 访问 Codex 不受影响。

遇到这种特征，正确动作只有三个：

  1. 打开 status.openai.com 看 Codex 是否有进行中的事件。状态页可能比报错晚出现，所以再看一眼 openai/codex 的 issue 列表里有没有刚刚涌入的同款报错。
  2. 等。恢复是分批铺开的：OpenAI 的工程师在 #48237 里 23:51 UTC 的回复是 “Issue has been mitigated. Recovery is rolling out through clusters.”，事故报告的措辞也是 “largely recovered”。别人恢复了你还没恢复，在一段时间内是正常的。
  3. 不需要再提交报告。同一位工程师在 23:30 UTC 写的是 “No need to post additional reports or /feedback”。

状态页上已经有事件时，Codex 报 exceeded retry limit、429 或流中断这类伴随出现的错误也不用单独排查，等这一次事件结束再看。

事故期间删 auth.json、降级或重启，为什么不算修复

因为这些操作和服务端恢复发生在同一段时间，分不出是谁起了作用。事故当晚出现过几种“本地修好了”的说法，逐一对照时间：

  • #48302 说把 CLI 降级到 0.148.0 后恢复，发帖时间是 23:56 UTC，紧挨着状态页标记解决的 23:54；而 #48241 的评论里，另一位用户在 0.148.0 上复现了同样的失败。
  • #48570 说没有重新登录，只是再次关机重启后恢复；他记录的失败时段是北京时间 9 月 26 日 07:00 到 09:00，正好盖住事故与恢复分批铺开的那段时间。
  • 英文网络上流传的另一套做法是结束进程，删除 auth.json 和 state_5.sqlite* 再重新登录，同时提醒这样可能清掉本地缓存的任务和会话状态。

前两种没有伤害，只是浪费时间。第三种有代价：~/.codex/auth.json 是登录凭据的缓存，删掉后必须重新登录，而事故期间服务端本身不可用；CLI 与 IDE 扩展共用同一份缓存，一处登出两处都要重登。至于 state_5.sqlite，OpenAI 的认证文档没有提到这个文件，更没有把删除它列为恢复步骤。

所以当报错符合上一节的特征时，不要删 ~/.codex 下的文件，不要去 Platform 新建或更换 API key（报错里的 key 不是你的，换了也不会改变它），也不要反复 codex logout。

Incorrect API key provided: dummy：本机令牌刷新失败

key 文本是 dummy、URL 是 wss://api.openai.com/v1/responses 时，问题在本机的登录状态，与 OpenAI 的事故无关。#37192 的报告者在 CLI 0.145.0 上遇到的情形是：用 ChatGPT 账号登录，中途切换了网络，访问令牌刷新失败，Codex 回落到一个写死的 dummy key 去请求 API 地址，于是收到 Incorrect API key provided: dummy.。这是用户对代码路径的分析，issue 仍未关闭，没有官方确认或修复版本号；但 key 文本和 URL 这两个判别特征是报错原文里的。

处理方式是把登录重做一遍：

bash
codex logout
codex login
codex login status

如果 codex login 这一步本身就报 403，那是另一个问题，按 Codex 令牌交换失败 403 去查登录、代理和地区。

切回官方登录了还报 401：config.toml 里残留的 provider

codex login status 显示已用 ChatGPT 登录，报错里的 URL 却是中转或第三方的域名，说明请求根本没走 OpenAI 登录这条路。Codex 发请求时看的是 config.toml 里当前生效的 provider，而不是你最近一次登录用的账号。手动接过中转、或用配置切换工具改过 config.toml 之后再切回官方登录，旧的 provider 定义往往还在。

OpenAI 认证文档对自定义 provider 的认证规定了三种写法，只能选一种：

toml
[model_providers.example]
base_url = "https://example.com/v1"

# 写法一：沿用 OpenAI 登录，此时 env_key 会被忽略
requires_openai_auth = true

# 写法二：用环境变量里的 provider key
# env_key = "EXAMPLE_API_KEY"

# 写法三：两项都不写，视为不需要认证

对照这三种写法检查：

  • 想走官方登录：把顶层的 model_provider 改回默认值或删掉这一行，确认没有哪个 profile 还指向旧 provider。之后报错里的 URL 应该变回 chatgpt.com/backend-api。
  • 想继续用中转或第三方 key：确认 env_key 指向的环境变量在当前终端里确实有值，而且是那一家发的 key，不是 OpenAI 的 key；base_url 是那一家给的地址。IDE 扩展和桌面端不一定继承你在 shell 配置文件里导出的变量，在终端里正常、在扩展里 401 时先查这一点。
  • 顺手看环境变量：OPENAI_API_KEY、CODEX_API_KEY、OPENAI_BASE_URL。事故 issue 里的报告者排除本机因素时，逐一确认的正是这三个。

这种情况下，401 是中转或第三方那一层返回的，报错文字只是沿用了 OpenAI 的格式。它会把你引向 OpenAI 的 key 管理页，而真正要改的是 provider 配置。各字段的完整写法见 Codex 自定义 API 配置：Key、Base URL 与 Provider 怎么选。

用 OpenAI API key 登录时的 Incorrect API key provided

只有在这条路线上，这句话才是字面意思。OpenAI 的 API 错误码说明对 401 - Incorrect API key provided 的解释是 “The requesting API key is not correct.”，处理建议是确认所用的 key 正确，或者重新生成一个。

报错里的掩码会显示 key 的开头和结尾几位，先拿它和你以为在用的那个 key 比对：

  • 首尾对不上：Codex 读到的是另一个 key。检查环境变量是否在别处被覆盖，再用 printenv OPENAI_API_KEY | codex login --with-api-key 重新写入。
  • 首尾对得上：key 可能已在 Platform 被删除或停用，去 API keys 页面确认，必要时新建一个。

同一份错误码说明里还列着另外几种 401：Invalid Authentication、账号不属于任何 organization、IP not authorized。它们的报错文字不同，换 key 解决不了，要按文字去查组织归属或 IP 白名单。

事故已经结束还在报 401：再查什么

状态页没有进行中的事件，报错仍然是 chatgpt.com/backend-api 加上不属于你的 key 时，按这个顺序查：

  1. 完全退出 Codex 再打开。桌面端和扩展可能还留着事故期间的失败状态。
  2. 运行 codex login status。显示未登录或登录方式不是你预期的那一种，就执行 codex logout 后重新 codex login。受管理的公司设备上，管理员可以用 forced_login_method 限定只能用 chatgpt 或 api，登录方式不匹配时 Codex 会登出并退出，这种情况要找管理员。
  3. 检查安全软件和防火墙。一位 Windows 11 用户在 #48316 里报告：Codex Desktop 更新后 codex.exe 换到了新的目录，Malwarebytes 把它当成新程序拦截出站 HTTPS，日志里是 Workspace routing is unavailable 和 Desktop network policy does not allow this destination，界面上最终显示的却是同一条 401。这是单个用户的报告，没有得到 OpenAI 确认，但更新后才开始报错、且同一账号在别的设备上正常时，值得看一眼。
  4. 换一个网络或关掉代理再试一次，排除令牌刷新被网络打断的可能。

到这里仍未恢复，本地能做的就做完了。继续删文件、重装、换版本不会带来新信息，下一步是带着证据求助。

能不能先切到 API key 登录顶一下：可以，但按量计费

可以。事故当晚 23:19 UTC 状态页的更新就是 “Login via API key will unblock access at this time.”，事故报告也确认 API key 路线没有受影响。命令是：

bash
printenv OPENAI_API_KEY | codex login --with-api-key

切之前要清楚三件事，都写在认证文档里：

  • API key 登录的用量按 OpenAI Platform 的标准 API 价格计费，不使用 ChatGPT 套餐里包含的额度。
  • 依赖 ChatGPT workspace 或云服务的部分功能在 API key 登录下受限或不可用；Codex cloud 只能用 ChatGPT 登录。
  • CLI 与扩展共用登录缓存，切换后两边都变成 API key 登录。事故结束后记得 codex logout 再用 ChatGPT 账号登回去，否则会一直按量计费。

两种登录方式各包含什么、分别由谁计费，见 Codex API Key 和 ChatGPT 订阅怎么选。手头的活不急、事故又已经在状态页上确认时，等待通常比切换省事。

求助时带什么信息，哪些文件不能贴

向 OpenAI 支持或在 GitHub 提 issue 时，带上这些内容对方才能定位：

  • 完整的报错原文，包括 url、cf-ray 和 request id。key 在报错里已经打了掩码，可以保留。
  • 出错时间和时区。
  • codex login status 的输出、Codex 版本、操作系统，以及用的是 CLI、桌面端还是哪个 IDE 扩展。
  • 所用模型；如果定义了自定义 provider，贴出 config.toml 里对应的一段，key 不要贴。
  • 登录失败时，日志目录里的 codex-login.log。

OpenAI 的错误码说明对 API 路线要求的也是这几样：模型、错误信息与代码、请求数据与请求头、带时区的时间戳。

~/.codex/auth.json 不能贴，也不能提交进仓库。认证文档的要求是把它当密码对待：里面是明文的访问令牌。

常见疑问

Codex 事故期间浪费的额度会补吗？

OpenAI 的 Codex 负责人 Tibo 在 X 上表示 “we’ll reset usage limits for all paid users across codex and ChatGPT work”，这条发言被转到了 OpenAI 开发者社区的帖子里。状态页和事故报告都没有提到重置额度，是否以及何时对每个账号生效没有公开说明，以自己账号里显示的用量为准。

Codex 报 Incorrect API key provided，要不要新建一个 API key？

只有在你用 API key 登录、并且报错里掩码的首尾与你的 key 对得上时才需要。用 ChatGPT 账号登录的人没有 key 可换；走中转或第三方的人要换的是那一家的 key，不是 OpenAI 的。

是 Codex 挂了，还是我自己的问题？

看报错里的 key 文本。它不是你配置过的任何一个 key、URL 又是 chatgpt.com/backend-api，就先当成服务端问题去查状态页和 issue 列表；key 文本是 dummy、是你自己的 key，或者 URL 是你配置过的中转地址，问题就在本机的登录状态或配置里。

OpenAI 之后还会出现同样的事故吗？

事故报告列出了三项后续改进：加强对影响内部服务凭据的操作的保护、改进凭据被误禁用后的恢复工具、调整内部服务的认证方式以减少对这类凭据的依赖。这些是计划而不是已经完成的事实，所以判断方法仍然有用：再次看到一个不属于自己的 key 时，先看状态页。

继续阅读

更多 ChatGPT 与 OpenAI