Windows 下配置 Codex App 使用自定义 Base URL：以 ijushan 中转和 CC Proxy 为例

文章目录[隐藏]

适用场景
一、准备 CC Proxy / 中转服务
二、确认 Windows 使用的是新版 Codex App 自带 CLI
三、编辑 Codex 配置文件
四、设置或刷新 API Key
五、重启并验证配置是否生效
六、正常配置完成后的预期结果
七、如果有问题，再按下面顺序排查
八、故障判断速查表
九、安全建议
结论

关键词：Codex App、Codex CLI、Windows、OpenAI-compatible Base URL、CC Proxy、API 中转、config.toml

本文先说明一套推荐的正向配置流程：Windows 上如何让 Codex App / Codex CLI 使用 CC Proxy 或类似 OpenAI-compatible 中转。后半部分再说明遇到 401、仍然请求 api.openai.com、Reconnecting 等问题时怎么排查。

适用场景

你已经有一个可用的 CC Proxy / OpenAI-compatible 中转地址，例如：

https://codex.ijushan.com/

并且希望 Windows 上的 Codex App 不直接请求官方：

https://api.openai.com/v1/responses

而是请求你的中转地址。这样可以在服务端统一管理账号、Key、模型路由、额度和日志。

本文以 ijushan 中转为例，其他 CC Proxy、Sub2API、New API、LiteLLM、OpenRouter、自建 OpenAI-compatible gateway 的思路类似。

一、准备 CC Proxy / 中转服务

先确认网关侧已经准备好，而不是一上来就改本机 Codex 配置。

CC Proxy 或中转服务至少要满足这几点：

对外提供 OpenAI-compatible API 地址；
Windows 机器能访问这个地址，例如：https://codex.ijushan.com/；
网关里已经配置好可用模型，例如：gpt-5.5；
网关给 Codex 使用的是中转侧自己的 Key，而不是随便混用一个官方 OpenAI Key；
如果要给新版 Codex App 用，最好支持 Responses API，也就是 /v1/responses 这一类请求。

可以简单理解：Codex 本机只负责把请求发到 base_url；真正的账号、模型、额度、上游路由由 CC Proxy 负责。

二、确认 Windows 使用的是新版 Codex App 自带 CLI

Windows 上可能同时存在多个 codex：

旧 npm 全局安装版；
新版 Codex App 自带的 codex.exe；
其他包管理器或旧脚本里的版本。

先打开一个新的 PowerShell / CMD，执行：

where.exe codex
codex --version
codex app --help

新版 Codex App 自带二进制通常在：

C:Users你的用户名AppDataLocalOpenAICodexbincodex.exe

如果 where.exe codex 第一项是类似下面的旧 npm 路径：

C:Users你的用户名AppDataRoamingnpmcodex.ps1
C:Users你的用户名AppDataRoamingnpmcodex.cmd

就需要把 Codex App 自带路径放到用户 PATH 更靠前的位置。

推荐把下面目录放到 Windows 用户 PATH 前面：

C:Users你的用户名AppDataLocalOpenAICodexbin

修改 PATH 后，必须重新打开 PowerShell / CMD / Windows Terminal；如果你从桌面图标、VS Code、Cursor、JetBrains 或其他 IDE 调用 Codex，也要把那些程序完全退出后重开。

三、编辑 Codex 配置文件

Windows 下配置文件一般是：

C:Users你的用户名.codexconfig.toml

不要只写顶层：

base_url = "https://codex.ijushan.com/"

更稳妥的写法是显式声明 model_provider，并定义对应的 provider block。

以 ijushan 中转为例：

model = "gpt-5.5"
model_provider = "ijushan"
preferred_auth_method = "apikey"

[model_providers.ijushan]
name = "ijushan"
base_url = "https://codex.ijushan.com/"
wire_api = "responses"
temp_env_key = "OPENAI_API_KEY"
requires_openai_auth = true

几个关键字段说明：

model = "gpt-5.5"：填写 CC Proxy / 中转里实际可用的模型名；
model_provider = "ijushan"：告诉 Codex 当前使用哪个 provider；
[model_providers.ijushan]：定义名为 ijushan 的 provider；
base_url = "https://codex.ijushan.com/"：Codex 请求要发往的中转地址；
wire_api = "responses"：使用 Responses API 格式；
temp_env_key = "OPENAI_API_KEY"：让 Codex 仍从 OpenAI 风格环境变量或认证状态里取 Key；
requires_openai_auth = true：沿用 OpenAI 认证方式，但请求发往自定义 Base URL。

如果你用的不是 ijushan 中转，可以改成自己的名字和地址：

model = "你的模型名"
model_provider = "custom"
preferred_auth_method = "apikey"

[model_providers.custom]
name = "custom"
base_url = "https://your-cc-proxy.example.com/"
wire_api = "responses"
temp_env_key = "OPENAI_API_KEY"
requires_openai_auth = true

四、设置或刷新 API Key

不要把真实 API Key 写进教程、截图、Obsidian 笔记或 Git 仓库。

临时测试可以只在当前 PowerShell 里设置：

$env:OPENAI_API_KEY = "***"
codex login status

长期使用可以走 Codex 自己的登录/认证方式，或者配置 Windows 用户环境变量。注意：修改用户环境变量后，旧终端、旧 Codex App、旧 IDE 进程不会自动刷新，必须重开。

更推荐的团队做法是：

每个人使用 CC Proxy / 中转侧单独生成的 Key；
不直接分发上游真实 Key；
中转侧保留访问日志和限额策略；
哪个 Key 出问题就回收哪个，不影响其他人。

五、重启并验证配置是否生效

改完 config.toml 和环境变量后，建议按这个顺序刷新：

退出 Codex App；
退出所有会调用 codex 的 IDE / 编辑器；
关闭旧 PowerShell、CMD、Windows Terminal；
重新打开终端；
再执行：

where.exe codex
codex --version
codex login status
codex app --help

然后启动 Codex App 或发一个简单请求。

最关键的验证点不是先看 Key 对不对，而是看报错或网关日志里的 URL：

如果请求已经打到 https://codex.ijushan.com/...，说明本地 Base URL 已经生效；
如果仍然是 https://api.openai.com/v1/responses，说明本地配置没有生效。

六、正常配置完成后的预期结果

配置正确时，整体链路应该是：

Codex App / Codex CLI
  → 读取 C:Users你的用户名.codexconfig.toml
  → 使用 model_provider 指定的 provider
  → 请求 https://codex.ijushan.com/ 或你的 CC Proxy 地址
  → CC Proxy 再转发到上游模型服务

也就是说，Codex 本机不应该再直接打到官方 api.openai.com。

七、如果有问题，再按下面顺序排查

下面是故障排查部分。建议先完成前面的正向配置，再看这里。

1. 仍然请求官方 OpenAI 地址

如果错误里出现：

unexpected status 401 Unauthorized: Incorrect API key provided: sk-***
url: https://api.openai.com/v1/responses

这通常不是 CC Proxy 的 Key 问题，而是 Codex 根本没有走你的中转。

优先检查：

where.exe codex 第一项是不是新版 Codex App 自带路径；
C:Users你的用户名.codexconfig.toml 是否在正确用户目录；
是否写了 model_provider = "ijushan"；
是否存在 [model_providers.ijushan] 这个 provider block；
base_url 是否写在 provider block 下面；
改完后是否完全重启 Codex App、终端和 IDE；
是否有其他环境变量或启动脚本覆盖配置。

2. URL 已经变成 CC Proxy，但仍然 401

如果错误 URL 已经变成：

https://codex.ijushan.com/...

但仍然 401，说明请求已经进了 CC Proxy，问题转到网关侧：

中转 Key 是否正确；
Key 是否过期、禁用或额度耗尽；
网关认证 header 是否符合要求；
Codex 实际传过去的是不是你以为的那个 Key；
CC Proxy 日志里有没有对应请求。

3. URL 是 CC Proxy，但返回 404 或接口不支持

这通常是接口兼容问题，例如：

网关不支持 /v1/responses；
wire_api = "responses" 与网关能力不匹配；
网关只支持 Chat Completions；
反代路径配置有问题。

处理方向：

确认 CC Proxy 是否支持 Responses API；
检查反代是否保留了 /v1/responses 路径；
必要时更换支持 Responses API 的网关或调整 Codex 当前版本支持的 wire_api。

4. 提示模型不存在

说明 Codex 已经请求到网关，但 model 名称和网关里的模型名不一致。

检查：

model = "gpt-5.5"

是否和 CC Proxy 后台暴露的模型名完全一致。大小写、别名、前缀都可能影响匹配。

5. 一直 Reconnecting

Reconnecting... 不一定是 Key 错，也可能是：

Codex App 旧进程仍在使用旧环境；
Windows 代理或网络不通；
CC Proxy 流式输出不兼容；
上游模型响应太慢或连接被断开；
网关限流或超时。

建议先重启 App 和 IDE，再看 CC Proxy 日志。只盯着本机配置容易绕远。

八、故障判断速查表

现象	更可能的问题	处理方向
报错 URL 是 `api.openai.com`	Codex 没读到自定义 provider / base_url	检查 `model_provider`、provider block、配置路径、是否重启 App
报错 URL 是你的 CC Proxy，但 401	网关 Key 不对或认证头不符合	检查中转 Key、账号状态、网关认证方式
报错 URL 是你的 CC Proxy，但 404	路径或 API 类型不兼容	检查是否支持 `/v1/responses` 或 `wire_api = "responses"`
报模型不存在	`model` 名称和网关模型名不一致	换成 CC Proxy 里实际可用的模型名
一直 Reconnecting	旧进程、网络、代理或流式输出兼容问题	重启 App，检查网关日志和 Windows 网络

九、安全建议

公开文章、截图、Obsidian 笔记里不要出现真实 API Key、Access Token、Cookie 或 OAuth refresh token；
如果截图里已经露出 Key，直接作废重建，不要只靠打码后的截图继续流转；
团队使用时尽量给每个人发中转侧独立 Key，方便限额和回收；
CC Proxy / 网关侧要保留访问日志，排查时优先看请求有没有打到网关；
遇到 401 时，不要马上把 Key 到处复制测试，先判断 URL 是官方还是自己的中转。

结论

Windows 下配置 Codex App 使用 CC Proxy / 自定义 Base URL，推荐顺序是：

先准备并确认 CC Proxy 可用；
再确认 Windows 命中的是新版 Codex App 自带 codex.exe；
然后在 C:Users你的用户名.codexconfig.toml 里配置 model_provider 和 provider block；
最后重启 Codex App、终端和 IDE，验证请求 URL 是否已经变成你的中转地址。

排错时也按这个思路拆开：

URL 还是 api.openai.com：本地 Codex 配置没生效；
URL 已经是 CC Proxy：查网关 Key、模型、路由和接口兼容性。

这样写和排查会更清楚：先正向配置，后故障定位。