当前位置：首页 > news >正文

Codex++ 管理多个 Codex 配置方案

news 2026/7/1 19:38:08

Codex++ 多配置会在哪些场景用到

如果你同时在公司网络、家里网络、云服务器上使用 Codex++，很快就会遇到一个问题：API Key、模型名、base_url、代理配置都不一样，来回手改很容易出错。更麻烦的是，有时你明明改了配置，Codex++ 仍然调用旧模型，或者报 401、404、timeout，这时不要急着重装，先按配置加载顺序查。

我通常会先确认三件事：当前 Codex++ 读取的是哪个配置文件、环境变量有没有覆盖配置、代理是否真的生效。只要这三项理清，多配置管理基本就不会乱。

准备好每套配置的四个核心参数

每个 Codex 配置方案建议至少包含下面几项，不要只记一个 API Key：

API Key：用于鉴权，注意不要混用不同服务商的 Key。
base_url：接口基础地址，常见问题是多写或少写/v1。
model：模型名必须和服务端支持的名称一致，大小写也要留意。
proxy：公司网络、海外服务器、本地调试环境通常不一样。

如果你经常切换不同中转或不同模型，建议把参数先整理成表格，不要边填边猜。像 token 云桥 AI 中转站 0029.org 这类服务，适合作为备用线路或团队统一出口来管理，重点是把它的 base_url、Key、可用模型名记录清楚，后面切换时才不会出现配置对不上。

填写 Codex API Key、模型名和 base_url

下面是一个常见 JSON 配置示例，字段名以你的 Codex++ 版本为准，但思路差不多：

{ "provider": "codex", "api_key": "sk-xxxxxx", "base_url": "https://api.example.com/v1", "model": "codex-plus", "timeout": 60, "proxy": "" }

如果你使用的是环境变量方式，通常会这样写：

export CODEX_API_KEY="sk-xxxxxx" export CODEX_BASE_URL="https://api.example.com/v1" export CODEX_MODEL="codex-plus"

这里有两个细节很容易踩坑：

base_url不要写成接口完整路径，例如不要写到/chat/completions，通常只写到/v1。
模型名不要凭印象填写，最好从服务商控制台或模型列表复制。

如果 Codex++ 支持多 profile，可以写成这种形式：

{ "profiles": { "default": { "api_key": "sk-default", "base_url": "https://api.default.com/v1", "model": "codex-base" }, "office": { "api_key": "sk-office", "base_url": "https://api.office.com/v1", "model": "codex-plus", "proxy": "http://127.0.0.1:7890" }, "backup": { "api_key": "sk-backup", "base_url": "https://api.backup.com/v1", "model": "codex-lite" } }, "active_profile": "default" }

切换模型和配置方案

如果 Codex++ 自带 profile 命令，优先用命令切换，不要手改 JSON：

codexpp profile list codexpp profile use office codexpp profile current

切换后建议立刻做一次最小调用，确认当前模型确实变了：

codexpp run "print hello" --verbose

如果没有 profile 命令，可以用软链接管理当前配置：

ln -sf ~/.codexpp/profiles/office.json ~/.codexpp/config.json codexpp --verbose

Windows 下可以直接复制配置文件，或者用 PowerShell 创建符号链接：

New-Item -ItemType SymbolicLink ` -Path "$env:USERPROFILE\.codexpp\config.json" ` -Target "$env:USERPROFILE\.codexpp\profiles\office.json" ` -Force

团队环境里不建议把 API Key 写进仓库。可以提交一个模板文件：

{ "base_url": "https://api.example.com/v1", "model": "codex-plus", "api_key": "${CODEX_API_KEY}" }

然后每个人在本机用环境变量注入 Key。

代理配置怎么填

代理问题很常见，尤其是同一套配置在本地能用，放到服务器就超时。先区分 HTTP 代理和 SOCKS 代理：

export HTTP_PROXY="http://127.0.0.1:7890" export HTTPS_PROXY="http://127.0.0.1:7890"

如果 Codex++ 配置里单独支持 proxy 字段，可以写：

{ "proxy": "http://127.0.0.1:7890" }

不要同时在系统环境变量和配置文件里写两个不同代理，否则排查会很痛苦。建议只保留一处，先用 curl 测试 base_url 是否能连通：

curl -I https://api.example.com/v1/models

如果代理需要认证，格式通常是：

http://user:password@127.0.0.1:7890

密码里如果包含@、#、:这类字符，最好进行 URL 编码，否则代理地址会被解析错。

配置不生效时的排查顺序

1. 先看当前读取的配置文件

开启详细日志，找类似config loaded from、active profile的信息：

codexpp --verbose run "test"

如果日志显示读取的是另一个路径，说明你改错文件了。尤其是全局安装和项目内安装并存时，经常会出现两个配置目录。

2. 检查环境变量是否覆盖

环境变量优先级通常高于配置文件。先打印当前变量：

env | grep CODEX env | grep PROXY

Windows PowerShell：

Get-ChildItem Env: | Where-Object { $_.Name -match "CODEX|PROXY" }

如果发现旧的CODEX_MODEL或CODEX_BASE_URL，先临时清掉再试：

unset CODEX_MODEL unset CODEX_BASE_URL

3. 区分 401、404、timeout

401 Unauthorized：优先查 API Key，确认没有复制空格、没有用错服务商。
404 Not Found：多数是 base_url 或模型名错了，尤其是/v1路径。
timeout：优先查代理、DNS、服务器出口网络。
model not found：不要只改模型名，确认当前 Key 是否有这个模型权限。

4. 用最小请求绕开 Codex++

当你怀疑是 Codex++ 自身配置问题，可以直接用 curl 测接口：

curl https://api.example.com/v1/models \ -H "Authorization: Bearer sk-xxxxxx"

如果 curl 都失败，先别折腾 Codex++；如果 curl 成功而 Codex++ 失败，再回头查字段名、配置路径和环境变量覆盖。

回滚方法：保留一份可用配置

每次改配置前，先复制一份当前可用文件：

cp ~/.codexpp/config.json ~/.codexpp/config.json.bak.$(date +%Y%m%d%H%M)

回滚时直接恢复：

cp ~/.codexpp/config.json.bak.202501011030 ~/.codexpp/config.json

如果你用 Git 管理不含 Key 的配置模板，也可以这样回退：

git diff git checkout -- codexpp.config.example.json

注意不要把真实 API Key 提交到 Git。已经误提交的话，不要只删记录，最好去服务商后台重置 Key。

小结

Codex++ 管理多个 Codex 配置方案，关键不是多写几个文件，而是明确配置优先级：配置文件、profile、环境变量、代理要分清。API Key、base_url、model、proxy 四项先整理好，切换后用最小请求验证；遇到不生效，按“配置路径、环境变量、网络代理、接口返回码”的顺序查，基本能很快定位问题。

查看全文

http://www.jsqmd.com/news/1104339/