我在 macOS 上用开源项目 codex-proxy，把本机已经登录的 Codex 包装成了一个 OpenAI-compatible API，跑在 http://127.0.0.1:6769/v1。现在 CC Switch、Claude Code、OpenAI SDK、自研 Agent，凡是支持填 Base URL + API Key 的客户端，都能直接调我的 Codex。
动手之前先把边界说清，免得你读到最后发现不是想要的东西：
- codex-proxy 是第三方开源项目（Max-Leopold/codex-proxy），OpenAI 官方并没有提供这种网关。
- 它只是一层协议转换。Codex 账号原有的 5 小时窗口、周额度、rate limit 全部照常生效，ChatGPT 套餐不会因此变成无限 API。
- 我只在本机
127.0.0.1上跑，用途是个人开发和研究。如果你要生产级 API，应该用正式的 OpenAI API，这篇文章帮不上忙。
执行 codex login 后，Codex CLI 会通过浏览器完成 OpenAI OAuth，并把登录凭据存在本机。codex-proxy 做的事就是复用这套凭据，在本地起一个 HTTP 服务，把 OpenAI 风格的请求转发给 Codex Backend：
text
第三方客户端 (CC Switch / Claude Code / SDK)
│ Authorization: Bearer 本地Key
▼
127.0.0.1:6769 ── codex-proxy
│ /v1/models /v1/responses
▼
Codex OAuth 登录态 ──► Codex Backend对客户端来说，这就是一个普通的 OpenAI endpoint，没有任何特殊之处。
前置条件
- macOS（其他平台路径自行替换）
- Codex CLI 已安装且平时能正常用
- Go 1.22+、git、GitHub CLI（gh）
bash
codex --version
go version第一步：codex login，以及我踩的第一个坑
平时就在用 Codex 的话这步可以跳过。我为了验证完整流程重新跑了一次 codex login，结果浏览器没跳到授权页，直接返回：
json
{
"error": {
"code": "unsupported_country_region_territory",
"message": "Country, region, or territory not supported",
"type": "request_forbidden"
}
}这个报错发生在浏览器访问 auth.openai.com 的 OAuth 地区检查阶段，当时 proxy 连装都没装，所以和 codex-proxy 无关，先查自己的网络出口。
排查时有个容易忽略的点：浏览器和终端走的未必是同一个代理。我当时终端的节点没问题，Chrome 走的却是另一条线路。终端侧可以用：
bash
curl -s https://ipinfo.io/json看 country 字段；浏览器侧直接在地址栏打开 ipinfo.io 看同样的字段。两边出口都正常后重新 codex login 即可。
第二步：编译安装 codex-proxy
bash
mkdir -p ~/.local/src ~/.local/bin
gh repo clone Max-Leopold/codex-proxy ~/.local/src/codex-proxy
cd ~/.local/src/codex-proxy
go build -o ~/.local/bin/codex-proxy .
~/.local/bin/codex-proxy --help最后一条能正常打出帮助信息，就算装好了。
第三步：生成一个本地 API Key
这个 Key 容易误解，先说明白：它和 OpenAI API Key、Codex OAuth Token 都没有关系，它只是你给本地 proxy 设的访问密码，防止本机其他进程随便调这个端口。
bash
mkdir -p ~/.config/codex-proxy
openssl rand -hex 32 > ~/.config/codex-proxy/api-key
chmod 600 ~/.config/codex-proxy/api-key后面所有客户端里填的 "API Key" 就是这个文件里的字符串。别把它提交到任何仓库。
第四步：启动，然后分两层验证
bash
export CODEX_PROXY_API_KEY="$(cat ~/.config/codex-proxy/api-key)"
~/.local/bin/codex-proxy --port 6769服务起来后先列模型：
bash
curl http://127.0.0.1:6769/v1/models \
-H "Authorization: Bearer $CODEX_PROXY_API_KEY"我这里的实际返回（模型列表跟账号和时间有关，每个人测试都可能不一样）：
json
{
"data": [
{"id": "gpt-6-astra", "object": "model", "owned_by": "openai-codex"},
{"id": "gpt-5.6-sol", "object": "model", "owned_by": "openai-codex"},
{"id": "gpt-5.6-terra", "object": "model", "owned_by": "openai-codex"},
{"id": "gpt-5.6-luna", "object": "model", "owned_by": "openai-codex"},
{"id": "gpt-5.5", "object": "model", "owned_by": "openai-codex"}
],
"object": "list"
}然后发一次真实的推理请求：
bash
curl http://127.0.0.1:6769/v1/responses \
-H "Authorization: Bearer $CODEX_PROXY_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model": "gpt-5.6-sol", "input": "只回复 OK"}'模型回了 OK，收工。
这两步验证的意义不一样：/v1/models 通，只能证明鉴权和转发正常；/v1/responses 能推理，才说明从客户端到 Codex Backend 的整条链路真的可用。只验第一步就接客户端，大概率要在后面回头排查。
第五步：接入 CC Switch 和其他客户端
任何支持 OpenAI-compatible API 的工具，都按这三项填：
| 配置项 | 值 |
|---|---|
| Base URL | http://127.0.0.1:6769/v1 |
| API Key | 第三步生成的本地 Key |
| Model | gpt-5.6-sol（或 /v1/models 里列出的任意一个） |
我在 CC Switch 里加了一个叫 Codex Local 的 provider。这样 Claude Code 可以通过 CC Switch 在 Codex、DeepSeek、GLM 之间切换，换模型的时候不用换开发工具。这是我折腾这套东西的主要动机------Codex 本身好不好用是一回事，能不能进我现有的工具链是另一回事。
额度、安全和账号风险
三件事放在一起说，因为它们是同源的：proxy 背后挂着的是你本人的 Codex OAuth 登录态。
额度照常生效。 请求最终走的还是你的 ChatGPT 账号，plus 账号的 5 小时窗口、周额度、rate limit 一个不少。指望靠它绕限制的可以停了。
只绑 127.0.0.1，别绑 0.0.0.0。 把登录态暴露到公网，等于把账号交给拿到 Key 的人。同理，Codex 的 auth.json、access_token、refresh_token、本地 API Key 都不要外发。截图时，OAuth 授权 URL 里的 state、code_challenge 参数也建议打码，虽然不是长期凭据，但公开它没有任何好处。
这是非官方接入方式，风险自己评估。 Codex Backend 的协议、OAuth 流程、模型名任何一处变了，proxy 都可能失效。我自己的使用前提是：本人、本机、不绕额度、不共享、不出售。拿它做多人共享的 API 中转或者商业化服务，性质就完全变了，账号被处理也不冤。账号对你很重要的话，最稳妥的选择就是不用。