Codex Proxy：把 Codex Responses API 接到 Cursor、Claude Code、Continue

用 Codex 写代码，最大的限制不在模型，在客户端。

Codex Desktop 的 Responses API 是 OpenAI 给自家客户端的内部接口，能力够强，模型迭代快，但官方明确只支持 Codex Desktop 一家。你想让 Cursor 用 Codex 模型？不行，Cursor 只认 OpenAI 官方 API。想让 Claude Code 调用 Codex？也卡在这里，Claude Code 走 Anthropic 协议。

各客户端的协议壁垒，是 AI 编程工具生态里最鸡肋的一层。你付了 ChatGPT Plus 的钱，Codex 模型跑着快，但用不到自己最喜欢的编辑器里。

Codex Proxy 就是干这个的。一个本地跑的中转服务，把 Codex Desktop 的 Responses API 转换成 OpenAI、Anthropic、Gemini 等标准协议。你的 Cursor、Claude Code、Continue 只要指向本地 Codex Proxy 的端口，就能用 Codex 模型。

[!WARNING] 写在前面：本文涉及的技术方案处于灰色地带，官方 TOS 大概率不允许第三方调用 Responses API。用之前自己评估风险，本文只做技术介绍，不承担使用后果。

这是什么

Codex Proxy 是一个本地轻量级中转服务。核心定位：把 Codex Desktop 的 Responses API 转成各客户端能识别的标准协议。

说人话：一个 API 网关。上游接 ChatGPT 账号驱动的 Codex 后端，下游兼容 Cursor、Claude Code、Continue 这类主流 AI 编程客户端。

支持四套协议同时开：OpenAI 的 /v1/chat/completions、Anthropic 的 /v1/messages、Gemini 协议，以及 Codex Responses 直通。你想用哪套协议，就配哪套路径。

Docker 一键部署，Web 控制面板管理账号、看用量、配模型映射。支持 Windows、macOS、Linux，本地跑，也支持局域网访问。

几个核心能力

协议转换：Responses API 到标准接口

Responses API 是 OpenAI 的新一代接口，Codex Desktop 用它，但格式和其他 API 不一样。Cursor 认的是 Chat Completions，Claude Code 认的是 Messages，Gemini 客户端认的是 GenerationContent。每个客户端一套协议，接一套多一套。

Codex Proxy 在这一层做转换。你发一个 Anthropic Messages 请求过来，它内部转换成 Codex Responses 请求发到官方后端，把响应再转回 Messages 格式返回。整个过程对客户端透明，Cursor、Claude Code 感觉自己在直接和官方 API 对话。

Function Calling 也做了适配。各客户端的 tool call 格式不完全一样，Proxy 会做字段映射，让工具调用能通。

多账号轮换：least_used、round_robin、sticky

ChatGPT Plus 或 Pro 订阅的账号有每日请求配额，跑一段就爆。单账号跑 AI 编程基本撑不过半小时。

Codex Proxy 支持多账号接入。用 OAuth PKCE 登录流程，可以添加多个 ChatGPT 账号到同一个代理。请求进来时按策略分配账号。

三种策略：least_used 优先分给用得最少的账号，避免单号爆表；round_robin 轮询，简单但可能撞配额；sticky 让一个 session 里的请求固定走一个账号，会话状态不容易丢失。

封禁检测也做了。某个账号被官方限制时，Proxy 会把它标记出来，之后不再分配新请求过去。剩下的账号继续跑，不中断服务。

TLS 指纹伪装：Rust Native TLS 请求头一致

这是技术方案里最灰色的一块。OpenAI 官方接口会检查请求的 TLS 指纹和请求头，非 Codex Desktop 客户端发来的请求会被识别出来拒掉。

Codex Proxy 用 Rust 原生实现 TLS 层，指纹模拟成和真实 Codex Desktop 一致。请求头、Cookie 也自动同步。从官方接口的视角看，这些请求和真人在 Codex Desktop 里点发送没区别。

这个能力直接决定了代理能不能长期稳定跑。TLS 指纹是官方做风控的主要信号之一，伪装不到位的方案很快会被封。Rust 原生 TLS 相比 Python/OpenSSL 的组合，指纹更接近原生应用。

客户端兼容：Claude Code、Cursor、Continue

主流 AI 编程客户端都有官方 API Key 配置项。Codex Proxy 提供兼容 OpenAI 的 /v1 接口，把官方 Base URL 换成本地 Proxy 地址、API Key 换成 Proxy 生成的 Key，客户端就会把请求发到本地。

• Claude Code：ANTHROPIC_BASE_URL 指向 Proxy 的 /anthropic 路径，用 Proxy 生成的 Key。
• Cursor：Settings 里添加新的 Provider，Base URL 指向 Proxy 的 /v1。
• Continue：配置 OpenAI Provider，Base URL 和 Key 都指向 Proxy。

一次配置，多个客户端共用同一个网关。加一个新客户端不用再重配。

Web 控制面板：账号、用量、模型映射

提供 Web UI 做管理。左侧是账号列表，能看到每个账号的今日用量、配额剩余、状态（正常/受限/封禁）。右侧是模型映射配置，把内部模型名映射到代理对外暴露的模型名。

用量统计按账号、按模型、按时间维度分类，可以判断哪个账号被用得最多、哪个模型最吃配额。做长期规划时是刚需。

API Key 也在控制面板生成和管理。给每个客户端分配一个独立 Key，出问题能追溯到源头。

Docker 一键部署

部署命令一行搞定。镜像启动后自动初始化数据库、监听端口、暴露 Web UI。

配置文件通过环境变量或挂载卷传入。ChatGPT 账号通过 Web UI 登录添加，本地持久化。容器重启不丢状态。

支持 x86、ARM 两种架构，Apple Silicon 也能跑。CPU 和内存占用都很低，跑在 Mac Mini、树莓派上都没压力。

实测体验

部署用了大概 5 分钟。docker run -d -p 8787:8787 -v ./data:/data codex-proxy，起来后打开 http://localhost:8787 是控制面板。

登录了 3 个 ChatGPT Plus 账号。用 OAuth PKCE 流程，每个账号走一遍浏览器登录，Proxy 保存 OAuth token。之后请求走轮换。

接了 Cursor。在 Cursor Settings 里加了个 OpenAI Provider，Base URL 填 http://localhost:8787/v1，API Key 用 Proxy 生成的 Key。选个 gpt-5.5 模型开始写代码。流式输出正常，Function Calling 正常，工具调用返回和官方 API 差不多。

跑了一小时混合请求。Cursor 写代码、Claude Code 生成注释、Continue 补全。整体响应速度和官方 API 差距不大，偶尔某个账号被限速时会切到下一个，客户端有 1 到 2 秒延迟感知。

跑了下 TLS 指纹。用 curl 从 Proxy 发起请求，抓包对比请求头，TLS 版本、加密套件、扩展字段都和 Codex Desktop 一致。这一层技术是做了的。

几个真实感受：

1. 多协议转换是真省事：之前想在自己工具里用 Codex，得写转换脚本或换客户端。现在一个网关搞定，Cursor、Claude Code 各配一条 Base URL 就行。
2. 账号轮换是真能撑时长：3 个账号轮换跑，之前单账号 2 小时就爆，现在能跑一整天。策略选 least_used 最稳。
3. TLS 指纹伪装确实到位：抓包看请求头，官方视角下就是 Codex Desktop 发的请求。这也是这类工具能活下来的关键。
4. Docker 部署是真简单：一条 docker run 命令，不需要额外配置，控制面板自动初始化。适合折腾玩家快速验证方案。

风险要说清：

• OpenAI 官方 TOS 大概率不允许第三方调用 Codex Responses API。这个接口在官方文档里没公开，只是 Codex Desktop 内部使用。用 Proxy 走这个接口，本质上是绕过官方限制。账号被封的风险是真实存在的。
• TLS 指纹伪装的目的就是让官方无法识别请求来源。这是灰色地带。个人小范围用可能没事，大规模商用风险很高。
• Codex Proxy 项目本身处于“用户自己承担风险”的状态。作者不承担封号责任，使用者需要自己评估是否值得。
• 不适合的场景：企业商用场景（合规风险太大）；对稳定 SLA 有要求的团队（随时可能被封）；不想承担封号风险的普通用户。

和别家怎么比

• 和直接用 OpenAI 官方 API 比：官方 API 稳定、合规、有 SLA，但按 token 收费，跑 AI 编程场景成本很高。Codex Proxy 用 ChatGPT 订阅号替代，成本固定，但合规风险大。适合个人开发、内部测试，不适合生产。
• 和其他自建网关（One-API、LobeChat 网关）比：这类网关主要聚合公开 API（OpenAI、Anthropic、Google、Claude），不做协议伪装。Codex Proxy 的核心差异是能做 Responses API 到标准协议的转换，加上 TLS 指纹伪装，覆盖的是“官方内部接口”这块空白。
• 和 Codex CLI 比：Codex CLI 是 OpenAI 官方命令行工具，只能在终端跑，客户端兼容性有限。Codex Proxy 是完整网关，兼容主流 IDE 客户端，覆盖更广。

收尾

适合用 Codex Proxy 的人：AI 编程重度用户、想节省 API 成本的独立开发者、技术折腾玩家、需要本地多模型统一接入的团队。前提是你愿意承担账号被封的风险。

不适合：企业生产环境（合规风险）；对稳定性 SLA 有硬要求的团队；不想承担封号风险的普通用户。

几个使用提醒：账号轮换优先选 least_used 策略。Docker 部署数据要挂载持久化卷，避免容器重启丢账号。请求头同步要开启，否则风控检测容易命中。

获取方式：GitHub 搜 Codex-Proxy，按 README 部署。项目属于个人维护性质，使用前建议看下 issue 里最新的封号情况。

Codex Proxy 这个名字挺直白。Proxy 是代理，做的是把 Codex 代理给你任何想用的客户端。它解决的是“我有 Codex 模型但用不到自己工具里”这个生态错位。技术上把 Responses API 打通了，客户端兼容性也做全了。灰色地带的问题在于：官方可能不允许。用之前想清楚自己愿意承担什么风险。