用 Codex Proxy 搭建本地 API：从配置到客户端接入

作者：袖梨 2026-09-14

不少 AI 编程客户端允许自定义 Base URL 和 API Key，但 Codex 默认并不是一个可直接填入这些工具的本地接口。借助第三方项目 codex-proxy，可以复用已经完成登录的 Codex CLI 凭据，在本机启动兼容 OpenAI 协议的服务。下面从安装、鉴权和请求验证开始，梳理完整配置过程及其安全边界。

我在 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，这篇文章帮不上忙。

20260914-1.png

执行 codex login 后，Codex CLI 会通过浏览器完成 OpenAI OAuth，并把登录凭据存在本机。codex-proxy 做的事就是复用这套凭据，在本地起一个 HTTP 服务，把 OpenAI 风格的请求转发给 Codex Backend：

第三方客户端 (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）
codex --version
go version

第一步：codex login，以及我踩的第一个坑

平时就在用 Codex 的话这步可以跳过。我为了验证完整流程重新跑了一次 codex login，结果浏览器没跳到授权页，直接返回：

{
  "error": {
    "code": "unsupported_country_region_territory",
    "message": "Country, region, or territory not supported",
    "type": "request_forbidden"
  }
}

这个报错发生在浏览器访问 auth.openai.com 的 OAuth 地区检查阶段，当时 proxy 连装都没装，所以和 codex-proxy 无关，先查自己的网络出口。

排查时有个容易忽略的点：浏览器和终端走的未必是同一个代理。我当时终端的节点没问题，Chrome 走的却是另一条线路。终端侧可以用：

curl -s https://ipinfo.io/json

看 country 字段；浏览器侧直接在地址栏打开 ipinfo.io 看同样的字段。两边出口都正常后重新 codex login 即可。

第二步：编译安装 codex-proxy

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 设的访问密码，防止本机其他进程随便调这个端口。

mkdir -p ~/.config/codex-proxy
openssl rand -hex 32 > ~/.config/codex-proxy/api-key
chmod 600 ~/.config/codex-proxy/api-key

后面所有客户端里填的 "API Key" 就是这个文件里的字符串。别把它提交到任何仓库。

第四步：启动，然后分两层验证

export CODEX_PROXY_API_KEY="$(cat ~/.config/codex-proxy/api-key)"
~/.local/bin/codex-proxy --port 6769

服务起来后先列模型：

curl http://127.0.0.1:6769/v1/models 
  -H "Authorization: Bearer $CODEX_PROXY_API_KEY"

我这里的实际返回（模型列表跟账号和时间有关，每个人测试都可能不一样）：

{
  "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"
}

然后发一次真实的推理请求：

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 URLhttp://127.0.0.1:6769/v1
API Key第三步生成的本地 Key
Modelgpt-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 中转或者商业化服务，性质就完全变了，账号被处理也不冤。账号对你很重要的话，最稳妥的选择就是不用。

相关文章

精彩推荐