Codex 配置不生效的原因分析

原创于 2026-06-26 11:01:35 发布 · 2 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#Codex #OpenAI #AI

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_PROXY

Windows 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 --version

PowerShell 示例：

$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_proxy

Windows PowerShell：

Remove-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 Code：

code .

这样 IDE 会继承当前终端环境，更容易判断配置是否生效。

八、看日志，不要只看表面报错

如果 Codex 提供 debug 或 verbose 参数，优先打开。不同版本参数名可能不同，可以先看帮助：

codex --help

常见调试方式类似：

codex --debug
codex --verbose

日志里重点看三类信息：

实际请求的接口地址，是否与你配置一致。
实际使用的模型名，是否发生回退。
HTTP 状态码，401 多半是 Key 或权限，404 多半是路径或模型名，429 可能是额度或限流。

总结

Codex 配置不生效，优先不要从“工具坏了”开始猜。按顺序查：执行路径是否正确、环境变量是否进入当前进程、项目配置是否覆盖全局配置、Base URL 是否拼对、模型名是否可用、代理是否改写请求、IDE 是否使用独立环境。把这些点逐个排掉，基本就能定位到真实原因。配置类问题最怕同时改很多地方，建议每次只改一项，并用 curl 和 debug 日志确认结果。