Codex CLI 的代理配置

Codex CLI 默认通过 OpenAI API 与云端模型交互，国内网络环境下通常需要配置代理。但 Codex 的配置文件 ~/.codex/config.toml 里并没有显式的 proxy 字段。

不过 Codex 支持从 ~/.codex/.env 读取环境变量，这是注入代理配置的正确方式：

tee ~/.codex/.env <<'EOF'
http_proxy="http://192.168.31.10:7897"
https_proxy="http://192.168.31.10:7897"
all_proxy="socks5://192.168.31.10:7897"
EOF

这个 .env 文件会在 Codex 启动时自动加载，不依赖调用方 shell 的环境变量状态。相比在 .bashrc 里全局 export，这种方式更干净——代理范围精确限定在 Codex 进程内，不影响同一 shell 里的其他工具。

为什么不直接在 .bashrc 里 export

很多人会直接在 shell 配置文件里全局设置代理：

export https_proxy="http://192.168.31.10:7897"

这样做有几个问题：

• 污染全局环境：同一个 shell 里的 curl、wget、apt 等所有工具都会走代理，你可能并不希望如此。
• 依赖调用方：通过 IDE 插件、systemd 服务、cron 等非交互方式启动 Codex 时，.bashrc 不会被加载，代理自然失效。
• 难以调试：当代理出问题时，你不确定是哪个层面设的、什么时候设的。

而 ~/.codex/.env 的方案更干净：配置集中管理，出问题只查一个文件。

注意事项

1. 文件权限

.env 文件可能包含敏感信息，建议限制读取权限：

chmod 600 ~/.codex/.env

2. 格式要求

每行一个变量，值为双引号包裹的字符串。不要使用 export 关键字：

# 正确
http_proxy="http://192.168.31.10:7897"

# 错误 —— 不需要 export
export http_proxy="http://192.168.31.10:7897"

# 错误 —— 值缺少引号
http_proxy=http://192.168.31.10:7897

3. 代理未生效时的排查步骤

1. 确认文件存在：ls -la ~/.codex/.env
2. 检查格式是否正确，特别是引号和换行。
3. 确认文件权限可读：chmod 600 ~/.codex/.env
4. 确认代理地址可访问：curl -x http://192.168.31.10:7897 https://api.openai.com/v1

总结

Codex CLI 的代理配置虽然不直观，但通过 ~/.codex/.env 注入环境变量是一种优雅的设计——它把配置限定在工具本身，既不影响系统全局，也不依赖外部 shell 环境。这是一种进程级的代理方案，比会话级的 export 更精准。

如果发现代理没有生效，先检查 ~/.codex/.env 是否存在且格式正确，再确认文件权限（chmod 600 是个好习惯）。