在 Codex 中接入第三方 API：从手动配置到统一切换

Codex 默认适合通过官方 ChatGPT / OpenAI 账号使用。如果你需要接入自建网关、统一管理多个模型，或者想在不同供应商之间快速切换，可以给 Codex 配置兼容 Responses API 的第三方入口。

本文以 Windows 11 为操作环境，以 三方作为示例上游地址，整理三种常见做法：直接编辑 config.toml、使用 Codex++ 管理桌面端，以及使用 CC Switch 切换供应商。只有上游不支持 Responses API 时，才需要额外部署 CCX 做协议转换。示例中的模型名和密钥需要按你的实际账号调整。

第三方服务涉及账号、费用和数据安全。llapi.org 在本文中是配置示例地址，不代表对服务能力、稳定性或合规性的保证。请先确认服务条款，给密钥设置额度，并避免把真实密钥放入截图、代码仓库或公开文档。

先选适合自己的方案

方案	更适合	主要优点	需要留意
手动配置	想理解 Codex 配置、方便排查问题的人	依赖少，配置透明	需要自己维护 config.toml
Codex++	主要使用 Codex 桌面 App、偏好图形界面的人	可以用界面管理供应商和模型	属于第三方启动器，更新后可能需要适配
CC Switch	有多个渠道、希望一键切换的人	图形界面完整，可管理模型、MCP 和 Skills	开启本地路由后要留意代理端口

如果你刚开始使用 Codex，先用官方登录完成基础任务即可。第三方 API 是扩展能力，不是入门前提。

方案一：直接编辑 config.toml

Windows 上的 Codex 配置目录位于当前用户目录下：

%USERPROFILE%\.codex\config.toml

鉴权文件位于：

%USERPROFILE%\.codex\auth.json

修改前打开 PowerShell，先备份这两个文件：

Copy-Item "$env:USERPROFILE\.codex\config.toml" "$env:USERPROFILE\.codex\config.toml.backup"
Copy-Item "$env:USERPROFILE\.codex\auth.json" "$env:USERPROFILE\.codex\auth.json.backup"

两种鉴权方式

保留 ChatGPT 登录态：继续使用已经登录的 ChatGPT / OpenAI 身份，只把请求入口交给兼容网关。此方式取决于网关是否接受该登录方式。

使用 API Key：将密钥放在环境变量中，由 Codex 按 provider 配置调用上游。多数第三方服务更适合这种方式。

第一次配置建议只添加一个 provider，确认请求成功后再扩展多套 profile，避免多个变量同时变化导致排查困难。

使用 API Key 示例

用 Windows 记事本打开配置文件：

notepad "$env:USERPROFILE\.codex\config.toml"

加入或调整以下内容：

model = "gpt-5.6-sol"
model_provider = "llapi"
model_reasoning_effort = "high"
disable_response_storage = true

[model_providers.llapi]
name = "llapi.org"
base_url = "https://llapi.org/v1"
wire_api = "responses"
env_key = "OPENAI_API_KEY"
requires_openai_auth = false

这里有几个容易写错的地方：

• model_provider 的值必须和 [model_providers.llapi] 中的名称完全一致。
• base_url 一般写到 /v1，不要再手动拼接 /responses。
• wire_api = "responses" 表示 Codex 按 Responses API 的请求格式发送请求。
• requires_openai_auth = false 表示使用环境变量中的 API Key，而不是强制依赖官方登录态。

临时测试时，可以在 PowerShell 当前会话设置环境变量：

$env:OPENAI_API_KEY = "sk-your-llapi-key"

如果你使用的是 Codex CLI，在同一个 PowerShell 窗口启动即可继承这个变量：

codex

如果你使用 Codex 桌面 App，推荐通过 Codex++ 或 CC Switch 管理 Key；这样不需要把密钥明文写入 config.toml，也不必处理桌面进程是否继承 PowerShell 环境变量的问题。

API Key 的保存方式

推荐优先使用环境变量，或者交给 Codex++、CC Switch 写入本机鉴权文件。只有在确实需要手动处理时，才编辑 %USERPROFILE%\.codex\auth.json。无论采用哪种方式，都要确认真实 Key 没有进入截图和 Git 仓库。

配置后的最小验证

1. 在任务栏托盘和任务管理器中确认 Codex 已经完全退出，再重新打开。
2. 让 Codex 执行一个只读任务，例如列出当前目录结构或概括项目文件。
3. 如果请求失败，依次检查 provider 名称、base_url、wire_api、环境变量继承情况和 API Key 权限。
4. 遇到认证错误时，优先恢复备份配置，不要把真实密钥反复粘贴到聊天窗口。

如果上游只提供 Chat Completions，不提供 Responses API，单独修改 config.toml 通常不够，需要增加协议转换网关。

方案二：使用 Codex++

Codex++ 是面向 Codex 桌面 App 的启动和配置管理工具。在 Windows 上可以直接使用管理工具维护供应商、模型和 Key，不必反复手写配置文件。

基本流程

1. 安装 Windows 版 Codex++ 管理工具和 Codex++ App。
2. 打开管理工具，在左侧选择“概览”，确认 Codex 应用、启动入口和插件状态正常。
3. 进入“供应商配置”，打开“启用供应商配置切换”。
4. 点击“添加供应商”，接入方式选择“纯 API”，协议选择 Responses API。
5. 将 Base URL 填为 https://llapi.org/v1，填写 API Key 和默认模型。
6. 保存后点击连通性测试；测试成功再点“使用”。
7. 点击右上角“重启 Codex++”，以后也从 Codex++ 入口启动 Codex。

这是本机 Windows 版 Codex++ 的供应商配置完整界面。列表中可以直接看到协议类型和当前启用按钮：

Codex++ 写入的 provider 结构通常类似下面这样，具体字段以工具版本为准：

model_provider = "CodexPlusPlus"

[model_providers.CodexPlusPlus]
name = "CodexPlusPlus"
wire_api = "responses"
requires_openai_auth = false
base_url = "https://llapi.org/v1"
env_key = "OPENAI_API_KEY"

如果插件或增强菜单没有出现，先确认启动入口，再检查 Codex++ 是否与当前 Codex 版本兼容。想恢复官方模式时，在管理工具中清除 API 配置并切回官方登录态即可。升级 Codex 后，第三方注入工具可能需要等待更新。

方案三：使用 Windows 版 CC Switch

CC Switch 可以统一管理 Codex、Claude Code、Gemini 等工具的供应商、MCP、Skills 和会话。可以直接在 CC Switch 中添加供应商，不必先部署 CCX。

下面是本机 Windows 版 CC Switch 的完整主界面。当前列表只保留官方路由和个人配置，绿色卡片表示正在使用：

第一步：添加 供应商

在 CC Switch 顶部选择 Codex，然后点击右上角加号。填写以下内容：

• 供应商名称：可以写“灵链云 API”或你自己的备注名；
• 官网链接：xxx；
• API Key：填写控制台创建的 Key；
• API 请求地址：xxx 或服务文档指定的完整 Responses 地址；
• 默认模型：填写账户当前可用的模型名；
• 上游格式：选择“Responses（原生）”。

下图展示完整的供应商编辑窗口。API Key 已由软件掩码，不会在截图中泄露：

第二步：核对生成的 Codex 配置

CC Switch 会生成 auth.json 和 config.toml。保存前重点核对模型名、Base URL、wire_api = "responses" 和鉴权方式。下图是软件内生成的 config.toml 完整界面，不包含 Key：

工具生成的 provider 名称可能是 custom，也可能使用你设置的名称。关键是顶层 model_provider 必须和 [model_providers.xxx] 中的 xxx 保持一致。

第三步：启用并重启 Codex

回到供应商列表，点击卡片上的“启用”。如果顶部显示“Codex 路由中”，说明 CC Switch 正在通过本地代理热切换供应商；这时应保持 CC Switch 运行。

切换后完全退出并重新打开 Codex，再执行一个只读任务验证模型是否能响应。

什么时候需要 CCX

只有当上游提供的是 Chat Completions 或其他协议、不能直接响应 Codex 的 Responses API 请求时，才需要 CCX 之类的网关做协议转换。此时 Codex 或 CC Switch 的 Base URL 应指向本地 CCX 地址，例如 http://localhost:3000，再由 CCX 转发。

常见故障排查

现象	优先检查
切换后没有变化	是否彻底重启 Codex，provider 名称是否匹配
认证失败	API Key 是否有效，当前终端是否继承了环境变量
接口路径报错	base_url 是否只写到 /v1，是否重复追加 /responses
模型没有响应	上游是否支持 Responses API，必要时是否开启 CCX 转换
桌面 App 与 PowerShell 表现不同	桌面进程是否继承环境变量；优先用 Codex++ 或 CC Switch 管理 Key
插件或 Skills 消失	切换工具是否覆盖了通用配置，是否有备份
历史会话不可见	是否切换到了不同 provider 或 profile

排查时先做只读请求，再逐项修改。不要在同一时间更换模型、网关、密钥和配置文件，否则很难判断问题来自哪一层。

结语

手动配置适合想掌握底层细节的人，Codex++ 适合 Codex 桌面端图形化管理，CC Switch 更适合多渠道切换；只有上游协议不兼容时才需要再加 CCX。无论选择哪条路线，都建议先备份 Windows 用户目录下的配置、限制密钥权限，并用一个简单的只读任务验证链路。

本文示例统一使用 llapi.org 作为第三方 API 入口；实际使用前，请以该服务当前提供的模型、鉴权方式和接口文档为准。