一、配置了自定义接口，请求却仍打在官方域名上
在尝试让Codex CLI接入第三方OpenAI兼容接口时，许多开发者会遇到一个看似矛盾的现象：配置文件里明明已经写好了自定义的base_url和API key，但实际请求却依然发往OpenAI官方地址，随后收到一行401 Unauthorized错误。报错信息中的URL清晰地指向官方域名，这通常意味着自定义配置根本没有被Codex加载。
这个问题的根源并不复杂——Codex CLI默认使用官方provider，如果配置文件中没有显式声明model_provider指向自定义provider，或者配置被其他层级的设置覆盖，CLI就会静默回退到默认行为。值得注意的是，网上流传的教程版本众多，但多数只告诉你"改这两个参数"，却忽略了配置加载优先级这个关键细节。
二、五步定位：把问题收敛到provider未切换
排查这类问题，可以沿着一条清晰的链路推进。第一步，观察报错中的请求URL，确认请求实际落点；第二步，检查~/.codex/config.toml是否被项目级配置或其他路径覆盖；第三步，确认model_provider是否显式指向自定义provider，并且位于文件靠前位置；第四步，核对env_key声明的环境变量名与shell中export的变量名是否完全一致；第五步，执行codex logout清除可能残留的登录session，避免旧的认证信息抢占优先级。
这套流程走下来，问题范围通常会被收敛到一个点：provider根本没有切换过去。很多人会忽略一个细节——Codex CLI的配置加载遵循默认配置、项目配置、命令行参数的优先级顺序，自定义provider如果写在文件末尾，很可能被默认配置覆盖。
三、最小可用配置：一份可以直接抄的作业
以下配置适用于兼容OpenAI接口协议的第三方服务，不同供应商可能需要微调参数，但整体思路一致。核心配置文件位于~/.codex/config.toml，关键点有三个：model_provider必须指向自定义provider；model_providers.
model = "gpt-5.2-codex"
model_provider = "custom"
model_reasoning_effort = "medium"
[model_providers.custom]
name = "custom"
base_url = "http://api.ABC.com:8317/v1"
env_key = "CUSTOM_API_KEY"
wire_api = "responses"三个参数的含义值得展开说明。base_url是第三方接口的地址；env_key告诉Codex从哪个环境变量读取API key，这里使用CUSTOM_API_KEY而非默认的OPENAI_API_KEY，是为了避免污染OpenAI官方变量，如果需要配置多个provider，可以按同样方式扩展；wire_api指定协议类型，多数第三方服务兼容OpenAI的responses协议，如果遇到兼容性问题，可以尝试切换为chat。
关于auth.json，很多教程建议修改它，但实际上完全不需要。只要在OPENAI_API_KEY字段随便填一个值，例如sk-，就足以跳过初始化流程。真正的认证信息通过环境变量注入。
环境变量的设置方式因操作系统而异。在macOS上，将export语句写入~/.zshrc并执行source即可持久化；在Windows PowerShell中，可以使用SetEnvironmentVariable命令设置用户级变量；图形界面用户则可以通过系统属性中的环境变量面板新建条目。无论哪种方式，变量名必须与config.toml中env_key声明的名称完全一致。
四、快速验证：每一步都能确认是否生效
配置完成后，建议按以下顺序验证。首先在终端执行echo "$CUSTOM_API_KEY"，确认环境变量在当前shell中可用；然后执行codex logout清理可能干扰的登录缓存；接着用curl直接请求第三方接口，验证地址和密钥的有效性；最后用codex -c model_provider=custom覆盖配置文件做快速验证，-c参数会临时覆盖config.toml，最适合用来测试provider是否切换成功。
这次排错经历还有一个值得分享的启示。最初直接向AI提问得到的答案并不准确，回到搜索引擎核对时又发现教程版本混乱，最终是带着错误信息与AI进行多轮对话，追着"请求到底打到哪里"这一核心问题反复确认，才把范围缩小到provider未切换。这个过程说明，面对配置类问题时，与其盲目照搬模板，不如建立系统化的排查思路，理解配置加载的优先级和provider切换的机制，才能真正解决问题。