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

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

- URL: https://blog.laozhang.ai/zh/posts/codex-401-incorrect-api-key
- Published: 2026-10-01
- Updated: 2026-10-01
- Author: LaoZhang AI Team (https://blog.laozhang.ai/zh/about)
- Category: AI
- Tags: Codex, 401 Unauthorized, Incorrect API key, ChatGPT 登录, config.toml

---
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

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

```text
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/responses` | `sk-svcac` 开头、不是你见过的 key | ChatGPT 账号登录 | OpenAI 服务端 | 看状态页，等恢复，不动本地文件 |
| `api.openai.com/v1/responses` | `dummy` | ChatGPT 账号登录 | 本机令牌刷新失败 | 退出后重新登录 |
| 中转或第三方的域名 | 你在那一家申请的 key | 自定义 provider | 那一层的 key 或地址 | 改 config.toml 与环境变量 |
| `api.openai.com` | 你自己的 `sk-` key 的掩码 | API key 登录 | OpenAI Platform | 核对 key、组织与 IP 限制 |

![按报错里的 URL 和 key 文本，把 Codex 401 分成服务端事故、令牌刷新失败、中转配置、key 有误四种来源及对应动作](https://blog.laozhang.ai/posts/zh/codex-401-incorrect-api-key/img/codex-401-four-sources.webp)

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

```bash
codex login status
```

输出 `Logged in using ChatGPT` 说明走的是 ChatGPT 账号登录；`codex login status`、`codex logout` 这两个命令的作用见 [OpenAI 的 Codex 认证文档](https://learn.chatgpt.com/docs/auth)。

还有一种容易混进来的 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](https://github.com/openai/codex/issues/41975) 里用户贴出的报错）。它已经把动作写在提示里了：退出再登录。下面只讲带 `Incorrect API key provided` 的那一种。

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

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

OpenAI 的[事故报告](https://status.openai.com/incidents/01M3DCNWMW57HYK8FJ5FBFPA39/write-up)给出的原因与这个推断一致：一套检测凭据泄露的系统，把支撑 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。
- **状态页公告时段**：[状态页事件](https://status.openai.com/incidents/01M3DCNWMW57HYK8FJ5FBFPA39)从 22:58 UTC 确认故障到 23:54 UTC 标记解决，共 56 分钟，即北京时间 06:58 到 07:54。也就是说，报错出现后大约 25 分钟状态页才有第一条更新。

![北京时间 9 月 26 日 Codex 事故时间轴：受影响时段 06:33 到 07:47，状态页公告 06:58 到 07:54，中间约 25 分钟没有公告](https://blog.laozhang.ai/posts/zh/codex-401-incorrect-api-key/img/codex-incident-timeline.webp)

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

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

1. 打开 [status.openai.com](https://status.openai.com/) 看 Codex 是否有进行中的事件。状态页可能比报错晚出现，所以再看一眼 [openai/codex 的 issue 列表](https://github.com/openai/codex/issues)里有没有刚刚涌入的同款报错。
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 或流中断](https://blog.laozhang.ai/zh/posts/codex-exceeded-retry-limit-429)这类伴随出现的错误也不用单独排查，等这一次事件结束再看。

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

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

- [#48302](https://github.com/openai/codex/issues/48302) 说把 CLI 降级到 0.148.0 后恢复，发帖时间是 23:56 UTC，紧挨着状态页标记解决的 23:54；而 #48241 的评论里，另一位用户在 0.148.0 上复现了同样的失败。
- [#48570](https://github.com/openai/codex/issues/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](https://github.com/openai/codex/issues/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](https://blog.laozhang.ai/zh/posts/codex-token-exchange-failed-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 怎么选](https://blog.laozhang.ai/zh/posts/codex-config-toml)。

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

只有在这条路线上，这句话才是字面意思。[OpenAI 的 API 错误码说明](https://developers.openai.com/api/docs/guides/error-codes#api-errors)对 `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](https://github.com/openai/codex/issues/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 订阅怎么选](https://blog.laozhang.ai/zh/posts/codex-api-key-vs-subscription)。手头的活不急、事故又已经在状态页上确认时，等待通常比切换省事。

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

向 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 开发者社区的帖子](https://community.openai.com/t/codex-is-down-confirmed-by-openai/1400811)里。状态页和事故报告都没有提到重置额度，是否以及何时对每个账号生效没有公开说明，以自己账号里显示的用量为准。

### 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 时，先看状态页。