Codex CLI 接入 DeepAI API 中转站：openai_base_url 不生效仍访问 api.openai.com 的排查

很多站长在把 Codex CLI、Claude Code、OpenClaw 这类代码 Agent 接入 API 中转站时，第一反应是改一个 OPENAI_BASE_URL 或 openai_base_url。但实际排查中经常出现一个很迷惑的现象：配置看起来已经指向 DeepAI API 中转站，本地代理或中转站却收不到任何请求，Codex CLI 仍然访问 https://api.openai.com/v1/responses。

问题背景：配置了 Base URL，为什么还打到官方域名？

在 openai/codex Issue #16719 中，用户描述了一个典型场景：Codex CLI v0.118.0 配置了 openai_base_url，也尝试过 OPENAI_BASE_URL 环境变量，但实际请求仍然发往 api.openai.com。该 Issue 很快被关闭，维护者指出关键原因：示例里的 openai_base_url 放在了错误的 TOML 表下面。

# 错误示例：这个层级不会影响内置 openai provider
model = "gpt-5.4-mini"

[model_provider_config]
openai_base_url = "https://api.deepai.wang/v1"

正确写法要看你使用的是“内置 openai provider”还是“自定义 provider”。如果仍使用内置 openai provider，openai_base_url 是顶层配置键；如果要单独定义 DeepAI API 中转站 provider，则应使用 [model_providers.deepai] 并配合 model_provider = "deepai"。

方案一：覆盖内置 openai provider 的 Base URL

如果你的目标只是让 Codex CLI 继续走内置 OpenAI provider，但把出口改成 DeepAI API 中转站，配置应写在用户级 ~/.codex/config.toml 顶层：

model = "gpt-5.4-mini"
openai_base_url = "https://api.deepai.wang/v1"

这个方案适合中转站完全兼容 OpenAI Responses API，并且你希望最少改动 Codex CLI 的模型选择逻辑。排查时可以在 DeepAI API 中转站后台查看是否出现 /v1/responses 请求；如果没有，说明 Codex 仍未读到这份用户级配置，或者启动命令使用了其他 profile。

方案二：为 DeepAI 建立自定义 model provider

更推荐站长为中转站建立独立 provider。这样日志、模型路由、Key 管理与回滚都更清楚，后续也方便区分 OpenAI 官方、Azure、DeepAI API 中转站和其他 OpenAI Compatible API。

model = "gpt-5.4-mini"
model_provider = "deepai"

[model_providers.deepai]
name = "DeepAI API 中转站"
base_url = "https://api.deepai.wang/v1"
env_key = "DEEPAI_API_KEY"
wire_api = "responses"

注意这里的 base_url 属于 [model_providers.deepai] 表，而不是 openai_base_url。前者定义自定义 provider，后者只覆盖内置 openai provider。很多“中转站没收到请求”的问题，本质上就是这两个概念混用了。

第三个坑：项目级 .codex/config.toml 会忽略 provider 配置

官方 Codex config.toml 文档 还强调了一个容易被忽略的规则：用户级配置在 ~/.codex/config.toml，项目内也可以有 .codex/config.toml，但项目级配置不能覆盖机器本地 provider、auth、profile、telemetry 等关键项。文档明确说明，openai_base_url、model_provider、model_providers 出现在项目本地 .codex/config.toml 时会被忽略。

所以，如果你把 DeepAI API 中转站配置写进某个仓库的 .codex/config.toml，再运行 Codex CLI，看到请求仍然去 api.openai.com 并不奇怪。正确做法是把 provider、Base URL 和认证相关配置放到用户级 ~/.codex/config.toml 或 profile 配置文件中。

DeepAI API 中转站排查清单

1. 确认配置文件路径：优先检查 ~/.codex/config.toml，不要只看项目目录里的 .codex/config.toml。
2. 确认使用哪种方案：内置 openai provider 用顶层 openai_base_url；自定义 DeepAI provider 用 [model_providers.deepai].base_url。
3. 确认 base_url 带 /v1，否则 Codex 请求 /responses 时可能拼出错误路径。
4. 确认环境变量名和配置里的 env_key 一致，例如 env_key = "DEEPAI_API_KEY" 时，启动 shell 中必须真的有这个变量。
5. 在 DeepAI API 中转站日志中搜索 /v1/responses、模型名、状态码和请求时间；如果日志完全没有命中，问题还在 Codex 本地配置层。
6. 如果日志命中但返回 401、404、400，再继续排查 Key、模型映射、Responses API 支持程度和参数兼容性。

如何最小化验证配置已经生效？

不要一上来就跑复杂代码仓库任务。建议先用一句短 prompt 做连通性测试，再看 DeepAI API 中转站是否收到请求：

DEEPAI_API_KEY="你的中转站 Key" codex exec --profile deepai "只回复 ok"

成功的标志不是终端出现了 “ok” 就结束，而是中转站日志也能对应看到同一时间的 /v1/responses 请求、模型名和状态码。如果终端有响应但中转站没有日志，说明你可能仍然走的是官方 OpenAI provider 或另一个 profile。

与 SEO 和产品文档相关的建议

搜索“Codex CLI openai_base_url 不生效”“Codex 仍访问 api.openai.com”“API 中转站 Codex CLI 配置”“OpenAI Compatible Responses API base_url”的用户，往往已经有真实接入需求。DeepAI API 中转站的教程页面可以把这类问题拆成三层：配置是否被读取、请求是否进入中转站、上游模型是否兼容参数。这样既能帮助开发者快速定位，也能自然覆盖 Codex CLI、OpenAI Compatible API、Responses API、AI Agent 接入教程等关键词。

参考资料

• openai/codex Issue #16719：openai_base_url config and OPENAI_BASE_URL env var are ignored
• OpenAI Codex 官方 config.toml 配置参考

总结

Codex CLI 接入 DeepAI API 中转站时，openai_base_url 不生效通常不是中转站不可用，而是配置写错层级、写到了项目级配置、或者混淆了内置 openai provider 与自定义 provider。先用最小 prompt 验证 DeepAI 日志是否收到 /v1/responses，再继续排查模型映射和参数兼容性，能最快把“本地配置问题”和“中转站兼容问题”分开。