Codex 多配置会在哪些场景用到如果你同时在公司网络、家里网络、云服务器上使用 Codex很快就会遇到一个问题API Key、模型名、base_url、代理配置都不一样来回手改很容易出错。更麻烦的是有时你明明改了配置Codex 仍然调用旧模型或者报 401、404、timeout这时不要急着重装先按配置加载顺序查。我通常会先确认三件事当前 Codex 读取的是哪个配置文件、环境变量有没有覆盖配置、代理是否真的生效。只要这三项理清多配置管理基本就不会乱。准备好每套配置的四个核心参数每个 Codex 配置方案建议至少包含下面几项不要只记一个 API KeyAPI Key用于鉴权注意不要混用不同服务商的 Key。base_url接口基础地址常见问题是多写或少写/v1。model模型名必须和服务端支持的名称一致大小写也要留意。proxy公司网络、海外服务器、本地调试环境通常不一样。如果你经常切换不同中转或不同模型建议把参数先整理成表格不要边填边猜。像 token 云桥 AI 中转站 0029.org 这类服务适合作为备用线路或团队统一出口来管理重点是把它的 base_url、Key、可用模型名记录清楚后面切换时才不会出现配置对不上。推荐的配置目录结构不要把所有参数都塞进一个文件里反复改。更稳妥的方式是按环境拆分比如### token云桥中转 0029.org ### ~/.codexpp/ ├── config.json ├── profiles/ │ ├── default.json │ ├── office.json │ ├── proxy.json │ └── backup.json └── currentconfig.json放默认配置profiles目录放不同方案current记录当前启用哪个 profile。不同版本的 Codex 配置文件位置可能不同如果不确定先执行帮助命令或查看启动日志codexpp --help codexpp config path codexpp --verbose如果工具没有提供config path命令就用 verbose 模式看它启动时读取了哪个文件。很多“配置不生效”的问题最后发现是改错文件。填写 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_KEYsk-xxxxxx export CODEX_BASE_URLhttps://api.example.com/v1 export CODEX_MODELcodex-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 命令优先用命令切换不要手改 JSONcodexpp 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 --verboseWindows 下可以直接复制配置文件或者用 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_PROXYhttp://127.0.0.1:7890 export HTTPS_PROXYhttp://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:password127.0.0.1:7890密码里如果包含、#、:这类字符最好进行 URL 编码否则代理地址会被解析错。配置不生效时的排查顺序1. 先看当前读取的配置文件开启详细日志找类似config loaded from、active profile的信息codexpp --verbose run test如果日志显示读取的是另一个路径说明你改错文件了。尤其是全局安装和项目内安装并存时经常会出现两个配置目录。2. 检查环境变量是否覆盖环境变量优先级通常高于配置文件。先打印当前变量env | grep CODEX env | grep PROXYWindows PowerShellGet-ChildItem Env: | Where-Object { $_.Name -match CODEX|PROXY }如果发现旧的CODEX_MODEL或CODEX_BASE_URL先临时清掉再试unset CODEX_MODEL unset CODEX_BASE_URL3. 区分 401、404、timeout401 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 四项先整理好切换后用最小请求验证遇到不生效按“配置路径、环境变量、网络代理、接口返回码”的顺序查基本能很快定位问题。