Codex 配置不生效时先看它到底读的是哪份配置Codex 配好以后没反应常见表现是明明改了模型却还在用旧模型配置了base_url仍然直连设置了环境变量但命令行里识别不到或者在 VS Code / Cursor 里能用终端里却失败。遇到这种问题不要先怀疑服务端第一步应该确认 Codex 当前进程实际读取到了哪些配置。尤其是本机同时装过多个 CLI、多个 Node/Python 环境或者从公司代理、API 中转、官方接口之间切换过配置不生效很容易发生。排查顺序建议按“命令入口 → 环境变量 → 配置文件 → 网络出口 → 接口返回”来走。一、确认当前执行的是哪个 Codex很多配置不生效其实是因为你改的是 A 工具的配置运行的是 B 工具的命令。先确认命令路径和版本。### token云桥中转 0029.org ### which codex codex --version如果是 Windows可以执行where codex codex --version如果输出路径里出现多个版本管理目录比如nvm、fnm、conda、pipx就要特别注意。你在一个环境里安装或修改配置不代表另一个终端会读取到。还可以检查 shell 是否缓存了旧路径hash -r which codex在 PowerShell 里则建议重新打开终端避免旧进程继续使用之前的环境。二、检查环境变量是否真的生效Codex 类工具通常会依赖 API Key、Base URL、模型名、代理等配置。很多人把变量写进了.bashrc、.zshrc或系统环境变量但当前终端并没有重新加载。Linux / macOS 下检查echo $OPENAI_API_KEY echo $OPENAI_BASE_URL echo $HTTPS_PROXY echo $HTTP_PROXYWindows PowerShell 下检查echo $env:OPENAI_API_KEY echo $env:OPENAI_BASE_URL echo $env:HTTPS_PROXY echo $env:HTTP_PROXY如果输出为空说明当前进程没拿到变量。可以临时设置后再测试export OPENAI_API_KEY你的 key export OPENAI_BASE_URL你的接口地址 codex --versionPowerShell 示例$env:OPENAI_API_KEY你的 key $env:OPENAI_BASE_URL你的接口地址 codex --version注意临时设置只对当前终端窗口有效。要长期生效需要写入 shell 配置文件或系统环境变量并重新打开终端。三、配置文件优先级容易被忽略不少 Codex 工具既支持环境变量也支持配置文件还支持命令行参数。问题在于不同工具的优先级不一定一样。有的命令行参数最高有的项目目录配置会覆盖全局配置有的 IDE 插件会使用自己的设置。建议在项目目录下查找是否存在隐藏配置ls -la find . -maxdepth 3 -iname *codex* -o -iname *.env常见需要关注的文件包括.env项目级环境变量可能覆盖你终端里的配置。codex.json、config.json部分工具会读取本地配置。用户目录下的配置文件例如~/.config、~/.codex一类目录。IDE 插件配置VS Code、Cursor 可能使用独立的 API Key 和 Base URL。如果不确定到底谁覆盖了谁可以先用最小化方式测试新建一个空目录只保留必要环境变量不放任何项目配置文件再执行一次 Codex。mkdir /tmp/codex-test cd /tmp/codex-test env | grep -i openai这样能排除项目配置干扰。四、Base URL 写法不对表现也像配置没生效切换 API 入口时最容易出错的是base_url格式。不同客户端对路径要求不一样有的只要域名根路径有的需要带/v1有的内部会自动拼接接口路径。如果写重复了就会出现 404、401 或连接失败。可以用curl先验证接口入口是否可达curl -i $OPENAI_BASE_URL/models \ -H Authorization: Bearer $OPENAI_API_KEY如果你的OPENAI_BASE_URL已经包含/v1那上面的请求通常会访问/v1/models。如果返回 404需要确认客户端要求的到底是根地址还是 v1 地址。我平时做 Codex、Cursor 或服务端脚本联调时会把官方入口和中转入口分开存放避免来回改错。需要稳定测试不同模型、控制成本时可以顺手看一下 token云桥AI中转站 0029.org主要是方便统一管理 Key、模型入口和调用记录但不管用哪个入口最终都要以接口返回和客户端日志为准。五、模型名配置错误也会被误判成“不生效”有时配置已经读到了但模型名不可用客户端会自动回退到默认模型或者直接报一个不明显的错误。比如你在配置里写了一个别名但当前服务商并不支持这个别名。建议用接口列一下当前 Key 可用模型curl $OPENAI_BASE_URL/models \ -H Authorization: Bearer $OPENAI_API_KEY然后把 Codex 配置里的模型名改成返回列表中真实存在的名称。不要只凭网页文档或别人的配置复制尤其是中转服务、私有网关、企业网关经常会有自己的模型映射规则。六、代理和网络出口会造成“看起来没走新配置”如果公司网络里配置了代理或者本机开了全局代理Codex 可能根本没有访问你配置的地址而是被代理规则拦截、改写或阻断。可以先测试 DNS 和连通性curl -v $OPENAI_BASE_URL/models \ -H Authorization: Bearer $OPENAI_API_KEY重点看curl -v里的连接目标、TLS 握手和 HTTP 状态码。如果显示连接到了代理地址说明请求并不是直连目标接口。临时关闭代理测试unset HTTP_PROXY unset HTTPS_PROXY unset http_proxy unset https_proxyWindows PowerShellRemove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue如果关闭代理后正常问题就在代理规则或证书上而不是 Codex 配置本身。七、IDE 内配置和终端配置是两套环境很多人是在 VS Code 或 Cursor 里调用 Codex又在终端里修改环境变量。这里要注意IDE 启动时会继承当时的系统环境之后你在终端里改变量IDE 不一定能感知。排查方法很简单完全退出 IDE而不是只关闭窗口。重新从已配置好环境变量的终端启动 IDE。检查插件设置里是否单独配置了 API Key、Base URL、模型名。确认工作区设置没有覆盖用户设置。例如从 macOS 终端启动 VS Codecode .这样 IDE 会继承当前终端环境更容易判断配置是否生效。八、看日志不要只看表面报错如果 Codex 提供 debug 或 verbose 参数优先打开。不同版本参数名可能不同可以先看帮助codex --help常见调试方式类似codex --debug codex --verbose日志里重点看三类信息实际请求的接口地址是否与你配置一致。实际使用的模型名是否发生回退。HTTP 状态码401 多半是 Key 或权限404 多半是路径或模型名429 可能是额度或限流。总结Codex 配置不生效优先不要从“工具坏了”开始猜。按顺序查执行路径是否正确、环境变量是否进入当前进程、项目配置是否覆盖全局配置、Base URL 是否拼对、模型名是否可用、代理是否改写请求、IDE 是否使用独立环境。把这些点逐个排掉基本就能定位到真实原因。配置类问题最怕同时改很多地方建议每次只改一项并用curl和 debug 日志确认结果。