客户端 · CLI
不登录 ChatGPT,把第三方 API 接进 Codex
优先用 CC Switch 可视化接入;需要手动配置时,本站再带你完成 API Key、Base URL、客户端与 CLI,并按 401 / 404 / 旧配置验收。
独立整理的接入说明,与 OpenAI 无关。字段含义综合社区与公开配置约定,以你本机 Codex 版本为准。
先选你的情况,不要三套配置一起试
很多 401 和“配置不生效”都来自混用了登录方式。只走与你当前情况相符的一条。
先分清:ChatGPT 登录 vs API Key
同一时刻只有一套生效凭据。CLI 与客户端共用;一边 logout,另一边也要重新登录。
| 对比 | ChatGPT 登录 | API Key |
|---|---|---|
| 怎么进 | codex login(浏览器授权) | printenv … | codex login --with-api-key |
| 费用从哪扣 | ChatGPT 套餐里的 Codex 额度 | API / 网关按量(与套餐额度分开) |
| 适合谁 | 想用订阅额度、少碰网关 | CI、自定义 base_url、兼容网关、本站接入 |
| 环境变量 alone 够不够 | 不涉及 | 不够:只 export 不会自动登录,必须显式 login 或写 provider |
看当前生效哪一套:终端跑 codex login status。清空用 codex logout。
三种接到 Key 的方式
官方 Platform Key、兼容网关 Key 都可以。使用自定义 API 时,端点需要能被 Codex 以 Responses 协议访问(2026 年 2 月后 wire_api 仅支持 responses)。
CLI:管道登录(最常见)
把 Key 从 stdin 喂给 login。成功后写入凭据存储,之后开会话按 API 计费。不要把 Key 写进 shell 历史里的 echo 明文(能避免就避免)。
export OPENAI_API_KEY="sk-..."
printenv OPENAI_API_KEY | codex login --with-api-key
codex login statusauth.json / 系统钥匙串
file 模式下落在 ~/.codex/auth.json;也可改用 OS keyring。CLI 与客户端读同一份缓存。当密码对待:勿提交仓库、勿贴聊天。
{
"OPENAI_API_KEY": "sk-your-key"
}config.toml 自定义 model_providers
第三方 / 自建 / 本站兼容网关:在用户级 config 定义 base_url + env_key(或 requires_openai_auth)。密钥只放环境变量名,不要把明文写进 TOML。
CLI:从登录到确认
建议顺序:export → 管道 login → status → 再开 codex。CI 里用 secrets 管道进 login,不要把 Key 打进日志。
export OPENAI_API_KEY="sk-..."
printenv OPENAI_API_KEY | codex login --with-api-key
codex login status
codex只设置 OPENAI_API_KEY 不等于已经登录。使用内置 openai provider 时,显式 --with-api-key(或写好自定义 provider 的 env_key)才是稳妥做法。
凭据存在哪:file / keyring / auto
在用户级 ~/.codex/config.toml 用 cli_auth_credentials_store 控制。换机器或排查「明明 login 了却读不到」时,先看这个。
file
写入 $CODEX_HOME/auth.json(默认 CODEX_HOME=~/.codex)。好排查,也更容易被误提交。
keyring
写入系统凭据库。更安全,但跨环境、SSH、无桌面会话时可能踩坑。
auto
优先 keyring,不可用时回退 auth.json。
cli_auth_credentials_store = "file"auth.json 里是明文级敏感信息。权限尽量仅本人可读;不要放进 iCloud/网盘同步的明文目录。
客户端:和 CLI 共用登录缓存
桌面客户端 / 应用客户端读的是同一套用户级缓存。一边登出,另一边也会失效。改完配置要「完全退出」再开,只关窗口常常不够。
- 1
先确认用户级目录
默认 ~/.codex。可用环境变量 CODEX_HOME 改根目录——改了就要保证 CLI 与客户端看的是同一路径。
- 2
用 CLI 登录或写好 provider
客户端很少单独再走一遍管道登录;多数情况是共用 CLI 已经写好的 auth / config。
- 3
完全退出客户端再打开
让进程重新加载 auth.json 与 config.toml。若仍在使用旧 API,对照下面「用户级 vs 项目级」。
用户级 vs 项目级:provider 只能写在用户级
这是社区里最高频的「改了不生效」原因之一。项目目录里的 .codex/config.toml 在信任项目后会加载,但 provider 与 API 地址相关的键会被忽略。
用户级 ~/.codex/config.toml
放 model_provider、model_providers、openai_base_url、凭据相关键。CLI 与客户端都认这里。
项目级 .codex/config.toml
可放工作流偏好;但 model_providers / model_provider / openai_base_url 等会被忽略,并可能在启动时警告。把网关写进项目配置 = 白改。
多个 API 用 profile
用户级可放 profile-name.config.toml,启动时 --profile profile-name 切换,比来回改默认文件更干净。
config.toml:自定义兼容网关
自定义 provider 不能占用保留 id:openai、ollama、lmstudio。model_provider 的值必须与 [model_providers.xxx] 的 xxx 一致。
- 1
只编辑用户级文件
路径:~/.codex/config.toml(或 $CODEX_HOME/config.toml)。
- 2
env_key 填变量名,不填密钥本身
例如 env_key = "OPENAI_API_KEY",然后在 shell 里 export 真正的值。写错成明文密钥字符串会导致鉴权失败。
- 3
base_url 按网关文档写
常见兼容网关带 /v1,末尾不要多余斜杠。Azure 形态另有 /openai 或 /openai/v1 差异,以你拿到的说明为准。
- 4
重启会话验证
新开终端再跑 codex;客户端完全退出重开。也可用工具箱里的 CC Switch 写入后同样重启。
model_provider = "codexfree"
model = "gpt-5"
[model_providers.codexfree]
name = "CodexFree"
base_url = "https://YOUR-GATEWAY-HOST/v1"
wire_api = "responses"
env_key = "OPENAI_API_KEY"
env_key_instructions = "export OPENAI_API_KEY before starting Codex"
requires_openai_auth = false
request_max_retries = 4
stream_max_retries = 5
stream_idle_timeout_ms = 300000字段速查
| 字段 | 含义 |
|---|---|
| model_provider | 当前选用的 provider id,必须对应下方表名。 |
| model | 默认模型名;Azure 场景常为「部署名」而非家族名。 |
| name | 界面/日志里的显示名。 |
| base_url | API 根地址。兼容网关多数以 /v1 结尾。 |
| wire_api | 协议。2026-02 后仅 responses;写 chat 会启动失败。 |
| env_key | 存放 Key 的环境变量名(不是 Key 字符串)。 |
| requires_openai_auth | true 时走 OpenAI 登录缓存,并忽略 env_key;代理若要复用官方登录再开。 |
| query_params | 额外查询参数(如部分 Azure 的 api-version)。 |
| http_headers / env_http_headers | 静态或从环境变量注入的请求头。 |
| request_max_retries / stream_* | 重试与 SSE 空闲超时;弱网可酌情加大。 |
若旧教程让你写 wire_api = "chat":那是过时做法。Codex 已移除 Chat Completions 支持,只接受 Responses。网关若只有 /chat/completions,需要网关侧提供 Responses,或用本地路由转换协议(见工具箱)。
更轻的写法:只改 openai_base_url
如果只是把内置 openai provider 指到代理 / 路由器,不必新建 model_providers —— 在用户级 config 设 openai_base_url 即可。真正的多供应商、不同 Key、不同协议细节,仍用完整 model_providers。
openai_base_url = "https://YOUR-PROXY-HOST/v1"踩坑对照表
现象 → 优先检查什么。
改了项目里的 config,完全不生效
provider 相关键在项目级会被忽略。改 ~/.codex/config.toml。
401 / 鉴权失败
env_key 是否只是变量名;该变量是否在启动 Codex 的同一个 shell 里;是否误开 requires_openai_auth 导致忽略 env_key。
404 / Unsupported endpoint
base_url 路径(/v1、末尾斜杠)、以及网关是否真的暴露 Responses。旧 chat 端点对当前 Codex 不够。
export 了 Key 却仍像未登录
对内置 openai provider 执行管道 login,或改用自定义 provider + env_key。
切了网关还在请求旧 API
新开终端;客户端完全退出;确认 model_provider id 与表名一致;用 cat ~/.codex/config.toml 核对。
CLI 好了、客户端还是旧的
是否 CODEX_HOME 不一致;客户端是否未完全退出;钥匙串与 file 模式是否看的不是同一处。
最后别靠感觉:用四步确认请求真的走对
保存文件只说明语法可能写进去了。身份、配置位置、进程和供应商日志都对得上,才算接入完成。
codex login status
printenv CODEX_HOME
cat ${CODEX_HOME:-$HOME/.codex}/config.toml
codex第 1 项
确认当前身份
login status 应与你选择的 ChatGPT 或 API Key 方式一致;不一致先 logout,再只重做一条路径。
第 2 项
确认读的是哪份文件
检查 CODEX_HOME。provider 必须出现在用户级 config.toml,不是在项目里的 .codex。
第 3 项
彻底重启两个入口
CLI 新开终端;客户端完全退出再打开。窗口关闭不一定等于进程退出。
第 4 项
发送短任务并看上游
问一句短问题,再看供应商日志或余额。401 查 Key,404 查 Base URL / Responses,没记录就查旧进程和 model_provider。
还没有可用的 Key?
可先预约本站即将开放的兼容接口额度,再到本页完成接入;或用工具箱里的 CC Switch 减少手改。
- 接入页留下邮箱,等额度开放
- CLI:管道 login,并确认 login status
- 自定义网关:用户级 config.toml + wire_api = responses
- 客户端:共用 ~/.codex,完全退出后重开
FAQ
客户端和 CLI 是不是两套配置?
不是。默认共用 ~/.codex 下的 auth 与 config。一边 logout,另一边也要重新登录。
为什么项目目录改 provider 没用?
出于安全与主机边界,项目级配置会忽略 model_providers 等键。网关必须写在用户级。
wire_api 还能写 chat 吗?
不能。2026 年 2 月后仅 responses。看到 chat 教程请当过期处理。
env_key 里直接写 sk- 可以吗?
不可以。env_key 是环境变量的名字;真正的密钥用 export 注入。
openai_base_url 和 model_providers 选哪个?
只改内置 openai 的地址用 openai_base_url;多供应商、不同 Key、完整字段用 model_providers。
和本站免费接入怎么配合?
拿到 Key 与 base_url 后,按本页自定义 provider 示例填写,或用工具箱 CC Switch 启用后重启会话。