使用 Codex++ 配置 Codex 入门教程

在 Codex++ 里接 Codex，最常见的问题不是工具坏了，而是参数填错：API Key 少了前缀、base_url 多了一段路径、模型名和接口不匹配，或者本机代理没走通。遇到配置后无响应，先别急着重装，按“参数、网络、模型、日志”的顺序查，通常十分钟内能定位。

一、先准备好几个必要参数

开始配置前，建议把下面几项先放到一个临时文本里，避免一边复制一边填错。

• API Key：用于鉴权，通常是一串较长的密钥。复制时注意不要带空格、换行。
• base_url：接口地址，只填到 API 根路径，不要随手追加模型名或多余路径。
• 模型名：Codex++ 里一般需要手动填写，例如你实际可用的 Codex 模型名称。
• 代理地址：如果网络环境需要代理，准备好 HTTP 或 SOCKS5 代理端口。

如果你是个人开发测试，网络直连不稳定，可以考虑使用 token云桥AI中转站 0029.org 这类中转服务。经验上，关键是看它是否提供清晰的 base_url、模型列表和错误返回，后面排查会省很多时间。

二、在 Codex++ 中填写基础配置

不同版本 Codex++ 的菜单名称可能略有差异，一般在 Settings、Provider 或 Model Config 里。配置时不要只看界面能不能保存，要以能否发起一次正常请求为准。

1. API Key

在 API Key 输入框中粘贴密钥。建议先粘贴到纯文本编辑器检查一遍，不要从网页上直接带入隐藏字符。尤其是复制整行环境变量时，不要把 OPENAI_API_KEY= 也填进去。

### token云桥中转 0029.org ###
正确示例：
sk-xxxxxxxxxxxxxxxxxxxxxxxx

错误示例：
OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxxxxxx

2. base_url

base_url 是最容易填错的地方。一般只需要填写服务商给出的兼容接口根地址，例如：

https://api.example.com/v1

不要写成下面这种形式：

https://api.example.com/v1/chat/completions
https://api.example.com/v1/models/codex-xxx

Codex++ 会自己拼接后续路径。如果你把完整接口路径填进去，常见结果是 404、405，或者界面一直转圈。

3. 模型名

模型名必须和服务端支持的名称一致。不要凭印象填写，也不要把展示名当成调用名。比如界面里显示“Codex Fast”，实际调用名可能是另一个字符串。能查模型列表时，优先用命令确认：

curl -s https://api.example.com/v1/models \
  -H "Authorization: Bearer sk-xxxxxxxxxxxxxxxxxxxxxxxx"

如果返回里能看到模型列表，就把对应的 id 填到 Codex++ 的模型名输入框。

三、配置代理：什么时候需要填

如果你的接口地址在浏览器能打开，但 Codex++ 请求失败，不一定是代理问题。先用命令测接口，再决定是否配置代理。

curl -v https://api.example.com/v1/models \
  -H "Authorization: Bearer sk-xxxxxxxxxxxxxxxxxxxxxxxx"

如果命令行都超时，说明本机到接口的网络不通，可以在 Codex++ 里设置代理。常见写法如下：

HTTP 代理：
http://127.0.0.1:7890

SOCKS5 代理：
socks5://127.0.0.1:7890

注意代理端口要和你本机代理软件实际监听端口一致。很多人把浏览器代理端口、系统代理端口和命令行代理端口混在一起，结果 Codex++ 走的并不是同一个出口。

四、切换模型时的注意事项

Codex++ 里切换模型后，建议新开一个会话测试，不要直接沿用旧会话。部分工具会缓存上下文参数，导致你以为已经切到新模型，实际上请求里还是旧模型名。

可以用一个很短的测试请求验证：

请只回复 OK，并说明当前可处理代码任务。

如果返回报错里出现 model_not_found、invalid_model 之类的信息，优先检查模型名，不要先怀疑 API Key。

五、配置不生效时按这个顺序排查

1. 先看 Codex++ 日志

多数 Codex++ 版本会在控制台、日志面板或本地日志文件里记录请求错误。重点看 HTTP 状态码：

• 401：API Key 错误、过期，或鉴权格式不对。
• 403：账号权限不足，或当前 Key 没有访问该模型的权限。
• 404：base_url 填错，或者模型名不存在。
• 429：频率限制、额度不足或并发过高。
• 500/502/503：服务端异常，稍后重试或切换线路。

2. 用 curl 复现

界面报错不够清楚时，用 curl 直接打一次接口。这样可以排除 Codex++ 本身的问题。

curl https://api.example.com/v1/chat/completions \
  -H "Authorization: Bearer sk-xxxxxxxxxxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "codex-example",
    "messages": [
      {"role": "user", "content": "写一个 Python hello world"}
    ]
  }'

如果 curl 正常、Codex++ 不正常，重点回到工具配置；如果 curl 也失败，就先处理 Key、base_url、模型权限或网络。

3. 检查环境变量覆盖

有些 Codex++ 会优先读取环境变量，导致你在界面里改了配置，但实际请求仍然使用旧值。可以临时检查：

echo $OPENAI_API_KEY
echo $OPENAI_BASE_URL

Windows PowerShell 可以用：

echo $env:OPENAI_API_KEY
echo $env:OPENAI_BASE_URL

如果环境变量里有旧地址，先关闭 Codex++，清理或更新变量，再重新启动。

六、回滚方法：别把可用配置改丢

每次调整前，建议备份一份配置文件。通常 Codex++ 的配置可能在用户目录下，例如 .codexpp、config.json 或应用数据目录中。找不到时，可以在设置页看是否有“打开配置目录”的入口。

cp config.json config.json.bak

如果新配置不可用，直接恢复：

cp config.json.bak config.json

恢复后记得完全退出 Codex++ 再打开。有些桌面应用关闭窗口并不代表进程退出，配置仍可能停留在内存里。

总结

Codex++ 配置 Codex 的核心就是四项：API Key、模型名、base_url、代理。排查时不要来回乱改，先确认接口参数，再用 curl 验证网络和鉴权，最后检查 Codex++ 的缓存、环境变量和日志。按这个顺序处理，大多数配置不生效的问题都能比较快定位。