为什么切换供应商后 Codex 报错 INVALID_API_KEY？

因为旧版 cc-switch 切换供应商时只重写了 config.toml，却没有更新 ~/.codex/auth.json 里的 OPENAI_API_KEY，导致 Codex 读取到上一个供应商的失效 key。升级到 v3.20.1 后此问题已修复。

为什么 auth.json 会被覆写成只有一个字段的 OPENAI_API_KEY？

在代理接管模式下，旧版 cc-switch 序列化 auth.json 时只显式提取了 OPENAI_API_KEY 字段，丢弃了 auth_mode 等其他字段。v3.20.1 起，切换第三方供应商完全不再写 auth.json，该问题不再出现。

升级到最新版后，之前的配置还能用吗？

可以。v3.20.1 的 config-only 重构重写了存储位置管理方式，数据库侧回填统一把 config 文本里的 bearer token 剥离、收进单一的密钥槽位。存量托管账号可能需要在账号行上点「重新登录」一次，详见发版说明。

添加自定义供应商时提示错误，无法添加怎么办？

添加时 auth.json (JSON) 必须设置 {"OPENAI_API_KEY": "any"}，加完后修改时设成空 {} 没有问题。这是因为旧版对 OPENAI_API_KEY 做了非空检查。

为什么 cc-switch 提示检测到系统环境变量冲突？

这是因为系统环境变量里设置了 OPENAI_API_KEY 触发的。建议在系统环境变量中清除该设置，以免与 cc-switch 管理的配置产生冲突。

auth.json 的 OPENAI_API_KEY 未同步更新 - Codex

Quick fix

升级 cc-switch 至 v3.20.1，切换 Codex 供应商时不再覆写 auth.json，彻底解决 key 残留问题。

Symptom

报错原文

auth.json OPENAI_API_KEY → 匹配 SuperAPI（上一个 provider）✗
config.toml base_url / experimental_bearer_token → 匹配 Vibe Coding ✓

Cause

在 cc-switch v3.20.1 之前，切换 Codex 供应商时存在配置写入逻辑缺陷。核心原因在于 cc-switch 在写入 live 配置时，未能将当前激活供应商的 `settings_config.auth` 内容（特别是 `OPENAI_API_KEY` 和 `auth_mode`）与 `~/.codex/config.toml` 保持同源同步。具体表现为：切换供应商后 `config.toml` 正确更新了 `base_url` 和 `experimental_bearer_token`，但 `~/.codex/auth.json` 仍残留上一个供应商的 key，导致 Codex 启动时读取到不一致的配置组合，实际请求使用错误认证。

此外，在代理接管模式下，cc-switch 写入 `auth.json` 时仅显式提取了 `OPENAI_API_KEY` 字段，丢弃了 `auth_mode` 等其他必要字段，导致第三方 API 无法正常工作。在 v3.20.1 的 config-only 重构中，这些问题已通过重写存储位置管理方式修复：切换第三方供应商完全不再写 `auth.json`，密钥只随供应商自己的 provider 表走，`auth.json` 回归纯粹的官方登录文件。

Fix

升级 cc-switch 到 v3.20.1 或更高版本。该版本对 Codex 配置存储进行了 config-only 重构，切换第三方供应商时不再覆写 auth.json。

// 修复前（被错误覆写）
{
  "OPENAI_API_KEY": "sk-旧供应商的key"
}
// 修复后（不再被覆写，保持官方登录状态）
{
  "OPENAI_API_KEY": "",
  "auth_mode": "chatgpt",
  "token": "..."
}

2
如果升级后仍复现，检查系统环境变量中是否设置了 OPENAI_API_KEY。cc-switch 会检测到系统环境变量冲突并可能影响配置生效，需在系统环境变量中清除该设置。
系统环境变量
```
// 删除或注释掉环境变量
// OPENAI_API_KEY=sk-xxxx
```
对于使用代理接管的用户，如果手动编辑了 auth.json，请确保其中包含 auth_mode 字段。升级到 v3.20.1 后，该字段会随供应商配置自动带出，无需手动维护。

Affected Versions

ToolCodex

Version3.14.1 - 3.19.0（受影响版本），v3.20.1 修复

PlatformsWindowsmacOS

Source Issues

本页汇总自 10 个真实 issue

FAQ

为什么切换供应商后 Codex 报错 INVALID_API_KEY？: 因为旧版 cc-switch 切换供应商时只重写了 config.toml，却没有更新 ~/.codex/auth.json 里的 OPENAI_API_KEY，导致 Codex 读取到上一个供应商的失效 key。升级到 v3.20.1 后此问题已修复。
为什么 auth.json 会被覆写成只有一个字段的 OPENAI_API_KEY？: 在代理接管模式下，旧版 cc-switch 序列化 auth.json 时只显式提取了 OPENAI_API_KEY 字段，丢弃了 auth_mode 等其他字段。v3.20.1 起，切换第三方供应商完全不再写 auth.json，该问题不再出现。
升级到最新版后，之前的配置还能用吗？: 可以。v3.20.1 的 config-only 重构重写了存储位置管理方式，数据库侧回填统一把 config 文本里的 bearer token 剥离、收进单一的密钥槽位。存量托管账号可能需要在账号行上点「重新登录」一次，详见发版说明。
添加自定义供应商时提示错误，无法添加怎么办？: 添加时 auth.json (JSON) 必须设置 {"OPENAI_API_KEY": "any"}，加完后修改时设成空 {} 没有问题。这是因为旧版对 OPENAI_API_KEY 做了非空检查。
为什么 cc-switch 提示检测到系统环境变量冲突？: 这是因为系统环境变量里设置了 OPENAI_API_KEY 触发的。建议在系统环境变量中清除该设置，以免与 cc-switch 管理的配置产生冲突。

auth.json 的 OPENAI_API_KEY 未同步更新 - Codex

Symptom

Cause

Fix

Affected Versions

Source Issues

FAQ

相关问题