codex默认连接官方服务，但在国内网络环境或者想使用其他模型供应商的场景下，接入第三方API往往是更现实的选择。整个接入过程的核心就是环境变量配置：把第三方服务的接口地址和密钥告诉codex，让它知道该往哪里发请求、用什么身份发请求。看似简单，但变量名写错、配置文件放错位置、shell配置不生效等问题层出不穷，下面把配置要点和排错方法完整梳理一遍。
一、codex接入第三方API需要哪些环境变量
接入第三方API主要涉及三个关键信息：服务地址、密钥、模型名称。在codex的配置体系里，这三个信息分别通过不同的环境变量来传递。最核心的是OPENAI_API_KEY和OPENAI_BASE_URL（部分版本也支持OPENAI_API_BASE），前者存放第三方服务给你的密钥，后者指定接口的基础地址，比如第三方服务提供的地址通常形如https://ipipp.com/v1这样的格式。
为什么是这两个变量？因为codex底层走的是OpenAI兼容协议，大多数第三方中转服务也都实现了这套协议。只要地址和密钥配对了，codex就把它当成正常的服务端来请求。需要注意的是，有些第三方服务要求地址末尾必须带/v1，有些则不带，这取决于服务端的路由设计，配置前最好查阅服务商的文档说明，不确定的话两种写法都试一下。
除了这两个核心变量，有些场景还会用到代理相关配置，比如HTTP_PROXY和HTTPS_PROXY。如果你的网络需要走代理才能访问第三方接口，这两个变量也得一起设置，否则请求会直接超时。另外，在配置文件中还可以指定默认模型名称，这部分放到后面配置文件一节详细说。
二、不同操作系统下的环境变量设置方法
环境变量的设置方式因操作系统和shell而异，这是最容易出错的地方之一。在Linux和macOS系统下，如果你用的是bash，需要在用户目录下的~/.bashrc文件末尾追加配置：
export OPENAI_API_KEY="sk-你的第三方密钥" export OPENAI_BASE_URL="https://ipipp.com/v1"</code>
如果你用的是zsh（macOS默认shell），则要编辑~/.zshrc文件。追加之后执行source ~/.zshrc让配置立即生效，或者重新打开终端窗口。很多人改完配置文件却忘了source，结果以为配置没用，这是最常见的低级错误。
在Windows系统下，如果使用PowerShell，可以用命令临时设置，或者写入PowerShell的配置文件$PROFILE实现持久化：
# 临时生效，仅当前会话有效
$env:OPENAI_API_KEY = "sk-你的第三方密钥"
$env:OPENAI_BASE_URL = "https://ipipp.com/v1"
# 持久化设置（写入用户环境变量）
[Environment]::SetEnvironmentVariable("OPENAI_API_KEY", "sk-你的第三方密钥", "User")
[Environment]::SetEnvironmentVariable("OPENAI_BASE_URL", "https://ipipp.com/v1", "User")用CMD的话语法稍有不同，用set命令只能临时生效，持久化建议通过系统设置面板里的环境变量管理界面操作，或者用setx命令。临时变量只在当前窗口有效，新开窗口就丢失了，这一点务必区分清楚，否则会出现“刚才还能用现在不行了”的诡异现象。
三、通过配置文件管理第三方服务
除了环境变量，codex还支持通过配置文件来管理服务信息。配置文件位于~/.codex/config.toml，同时密钥可以放在~/.codex/auth.json里。用配置文件的好处是可以定义多个provider，切换起来比改环境变量方便。一个典型的配置示例：
model = "gpt-4o" model_provider = "third_party" [model_providers.third_party] name = "ThirdParty" base_url = "https://ipipp.com/v1" env_key = "OPENAI_API_KEY" wire_api = "chat"
这里的env_key指定了密钥从哪个环境变量读取，所以即使用了配置文件，密钥本身仍然通过环境变量传入，避免明文写在配置文件里。wire_api表示使用chat completions接口，如果第三方服务支持responses接口，也可以改成responses。配置文件方式适合长期固定使用某个第三方服务的情况，环境变量方式适合临时切换和测试。
两者还可以配合使用：配置文件定义好provider，环境变量提供密钥，启动时通过codex --profile xxx选择不同的配置组合。对于需要在多个服务商之间频繁切换的用户，这种组合方式明显更省心。
四、配置不生效的排查思路
配置完成后第一步是验证。最直接的办法是在终端执行echo $OPENAI_API_KEY（Linux/macOS）或echo %OPENAI_API_KEY%（CMD），确认变量确实存在且值正确。如果输出为空，说明变量没有写进当前shell的启动脚本，或者写错了文件。
如果变量存在但请求仍然失败，按以下顺序排查：第一，确认base url格式正确，重点检查末尾有没有多余的斜杠或者缺失的/v1路径；第二，检查密钥是否有效，可以直接用curl请求第三方服务的models接口测试，能返回模型列表说明密钥和地址都没问题；第三，确认没有其他变量冲突，比如系统里残留了旧的OPENAI_API_BASE指向别处；第四，检查代理设置，如果本地开了代理软件，HTTP_PROXY和NO_PROXY配置不当可能导致请求绕路或者被拦截。
# 用curl验证第三方API是否可用 curl https://ipipp.com/v1/models \ -H "Authorization: Bearer sk-你的第三方密钥"
还有一种常见情况是报401错误，这基本可以断定是密钥问题：要么密钥抄错了，要么密钥没有对应的模型权限。报404则多半是地址路径不对，报连接超时则要往网络和代理方向查。按这个思路逐层排除，基本能把配置问题定位清楚。配置好之后建议先用一个简单的提示词跑通完整流程，确认响应正常后再投入日常使用。