Codex with ChatGPT

一条把一次编码会话拆给两个模型的桥。ChatGPT 网页版负责规划与审查，Codex 保留 shell、测试和提交。这套分工能成立，是因为两半从不共用同一条通道：Codex 用自己应用内的浏览器，把极小的 [C2C] 控制消息敲进 ChatGPT 标签页；ChatGPT 则通过一条 OAuth 保护的只读 MCP 连接，连到开发者本机上的一条回环桥，缺哪几行代码就自己拉哪几行。九个工具全是读的——workspace_info、list_directory、read_file、search_workspace、git_status、git_diff、test_status、execution_summary、execution_output——所以仓库从不上传，提示注入也无处可去，因为写工具根本不存在。对外的半边是一条 Cloudflare 隧道；唯一会出现在浏览器里的秘密，是一次性配对码。界面不是 GUI 而是 Codex Skill：用户用一句话交代要实现什么，agent 自己完成安装、配对并跑起整个循环。

谁做的这个仓库用自己的 issue 区当成服务台，由一个 AI agent 逐条回复，落款一律是「[Agent · codex-with-chatgpt]」：登记反馈、转达作者，并告诉报告者作者在校，预计 48 小时内会看到。51 次提交分在两个身份下：20 次署名「小多」（xiaoduo_@xiaoduodeMacBook-Air.local），19 次署名 XiaoDuoYa 账号，合计 39 次；另有十位贡献者，其中三位提交不止一次。从第一次提交到最后一次共十六天，仓库拿到 6,943 个星和 642 个 fork。

1. 01

   十六天、四个版本，和一个替作者回 issue 的 agent

   第一次提交是 2026-08-28 的 Initial V1: C2C Bridge with read-only MCP, OAuth+pairing, tunnel, CLI and Skill，最后一次是 2026-09-13 的 Accept leftover -w on machine-wide c2c commands.：51 次提交，8 月 35 次、9 月 16 次；四个 release 全挤在头十三天里——2026-08-30 的 v0.1.0 — First Public Release、第二天的 v0.1.1 — Setup Choice, Checkpoints & Sanitized Output、2026-09-04 的 v0.1.2 — Structured MCP, Safer Tunnels & Windows Polish，以及 2026-09-11 的 v0.1.3 — Connector Recovery, Hidden git_status & HTTP/2。动机只用一句话就写清了：付过费的 ChatGPT 网页版额度大量闲置，而编码 agent 却在烧紧张的 API 额度做规划和 Review，于是「思考」交给订阅、「执行」留在本机，不用 API Key，也不搞逆向代理。这十六天周围是 6,943 个星、642 个 fork 和 34 个未关的 issue。仓库还自己管自己：几乎每条 issue 都会收到一条落款 [Agent · codex-with-chatgpt] 的回复，说反馈已登记转达，作者在校，预计 48 小时内看到。侦察报告完整读了最新的三十个 issue 与 pull request，读下来更像一条客服队列——而最难的部分居然是认证，不是模型。

2. 02

   两个模型、两条通道，以及绝不混用的规矩

   这套分工被写成了协议。控制消息以 [C2C] 开头，带键值头和分节，长度必须压在 1 KB 以内：Codex 发 INIT 要方案，ChatGPT 回 PLAN，内容包含理由、动作、可能涉及的文件、测试与成功标准；Codex 再发 EXECUTED 带上本次迭代的元数据，然后是 REVIEW、DONE 或 BLOCKED。docs/protocol.md 把边界说了两遍——「Never mix the two: control messages carry state, never content」，以及「No diffs, no logs, no file bodies」——而 Skill 的第一条 golden rule 对 agent 再重复一次：绝不把文件内容、diff 或日志粘进 ChatGPT，它要看就走 MCP。这就是数据面：九个只读工具跑在无状态的 Streamable HTTP 传输上，而审查环节正建立在它们之上——EXECUTED 之后，ChatGPT 亲自去看真实的 git diff 和记录下来的测试状态，因为 boot prompt 里写着「Do not assume an implementation succeeded just because Codex says so」。架构文档解释了这座桥为什么能保持这么小：「The bridge never re-implements a coding harness.」

3. 03

   一次会话怎么活下来：检查点、交接与 Project

   连续性被刻意做成本地的。c2c session 按工作区在系统应用状态目录里存一个 JSON，里面是 protocolState、waitingFor、原始目标、已完成子任务、已知问题与下一步预期，每个字段都有上限——500、800、800、400 字符。协议里没有 resume 状态，而且明说：「There is no STATE: RESUME。」Codex 中途重启就读检查点；如果连那个对话都没了，就发 HANDOFF——一份由检查点拼出来的简报，「never from logs」——新对话再通过 MCP 把代码读回来。对话有两种形态：每个工作区一条长对话，或者每个工作区一个 ChatGPT Project、每次新对话都开在这个合集里；后者把长期身份放进项目指令，而且只写连接器名字，绝不写会变的地址。信任顺序也写出来了：连接器里的当前代码、本次任务的交接简报、项目指令、项目记忆，过期的记忆排最后。Skill 把同一套纪律带进浏览器：等回复是每 20 到 30 秒做一次便宜的 DOM 检查，而不是 waitFor 五分钟；引入这条规则的提交标题就叫 Poll ChatGPT replies in short DOM checks so a 5-minute browser wait is not treated as failure。

4. 04

   额度这件事，藏在哪些细节里

   这个项目本来就是被额度不对称逼出来的，所以额度不在设置页里，而在细节里。循环有 maxIterations 上限，默认 12，写在可选的 .c2c.json 里；控制消息压在 1 KB 以下；Skill 在每个流程开头跑 c2c update-check 和 c2c sandbox-allow，两条都带缓存，没有变化就只字不提。配对码有效期五分钟、允许五次尝试、每个 IP 每分钟十次、用后即毁；OAuth 访问令牌一小时，refresh 令牌三十天且每次使用都轮换，权限被拆成 workspace.read、workspace.search、git.read、execution.read 和 offline_access。公网地址是 Cloudflare Quick Tunnel，它有 45 秒时间变成 ready；网络把 UDP 挡掉时，README 给的出口是一个环境变量 C2C_TUNNEL_PROTOCOL=http2，而不是让你去架代理。最能说明这是「额度问题」的证据反而在 issue 区：pull request 453 上的审查机器人留下一句「You have reached your Codex usage limits for code reviews」；而一位外部贡献者的 pull request 441 提出了缺的那块——c2c quota 与 c2c route，去读登录账号的剩余额度，低于 20% 就把规划切给 ChatGPT，执行仍归 Codex。那条至今还开着。

5. 05

   作者改了什么，以及这批提交是谁写的

   提交史同时也是「哪个 agent 写了它」的记录。51 次提交里有 36 次带至少一条共同作者尾注，这 36 次共 46 行；其中 28 次署名 Cursor（cursoragent@cursor.com），连第一次提交也在内。其余是人：moonjun 与 pi 各三次、AtlaxTech 两次，再加十位各一次的名字，修 -w 的 hbhuyt 就在其中。改动清单读起来像一份「真实用户踩坏了什么」：Whitelist the C2C state directory in the Codex sandbox on macOS and Windows so new chats stop needing elevation、Keep the ChatGPT in-app tab visible and reused so first-time setup stops stalling、Isolate one ChatGPT connector per workspace so two projects can stay connected at once、Stop opening ChatGPT or sending C2C until doctor reports a healthy local bridge、Unify git_diff sensitive-file rules with MCP reads so secrets cannot leak through renames、Offer an optional Cloudflare named hostname so ChatGPT connectors survive restarts、Remember ChatGPT developer mode and let users pick auto or guided setup，以及 2026-09-02 连着三次不让桥、临时隧道和固定隧道的控制台窗口在 Windows 上闪出来。首次配置只问用户一次：自动配置（可能连续失败两次再降级）还是引导手把手配置（提示里说大约三分钟）。更新也是自助的：每天检查一次，然后 git pull --ff-only、corepack pnpm install && corepack pnpm build、重装 Skill、重启桥，接着继续原来那件事。

6. 06

   社区报了什么，以及那个其实是个参数位的 bug

   反馈集中在不是代码的那部分。macOS 上是配对成功之后卡住：ChatGPT Desktop 的回环回调走不完，持久化的令牌数一直是 0，再点一次 Connect 会得到「This authorization request has expired」，因为第一次点击已经把待处理的请求消耗掉了（457）。别处还有：连接器一直转圈（450）；本地检查全绿但每次 MCP 调用都返回内部错误（449）；桥是健康的，Windows 上走代理的出口能到 cloudflared 却到不了 chatgpt.com 和 Cloudflare 的校验域名，于是照旧报 fetch failed（459）；新分到的 *.trycloudflare.com 域名在那 45 秒窗口里解析不出来（437）。最长的一条串是「每天都要重新授权」，而答案就在代码里：临时隧道会随终端一起死掉，想扛住重启就得有自己的域名（447）。VS Code 里根本没有应用内浏览器，于是那条禁止第三方浏览器的 golden rule 直接把首次配置堵住，直到用户坚持（456）。最好的一条是从误诊开始的：一位用 Clash 的用户报告「更新 Codex with ChatGPT」失败，模型写了一份把 Node 和沙箱都怪上的分析，真正的原因是 update-check 不认 Skill 被要求到处都带的 -w。作者因此重写了 Skill，写明哪些命令要带 -w、哪些不要带，让整机级命令接受并忽略它，给了报告者一个共同作者署名，还在串里道了谢。