Codex with ChatGPT：把 ChatGPT 网页版变成编码智能体的"规划大脑"

一、两个订阅额度打架的日常

设想一个典型的下午。你给 Codex（OpenAI 的编码智能体）派了个不大不小的活：给项目加一套新的配置加载机制。几秒钟后 Codex 报回一串计划——"我准备先读 src/config/paths.ts，再动 src/loader.ts，最后补测试"。这份计划本身思路清晰，但它消耗的是你 API 账号里按量计费的额度。

与此同时，你另一张卡上躺着 ChatGPT Plus/Pro 的订阅。这个月你每天都在用网页版聊天、写文档、翻译，额度却大把大把地闲置着。你忍不住想：规划、审查、调试策略这些"动脑子的活"，为什么不交给那个你已经在付费、却几乎用不完的网页版？

Codex with ChatGPT 就是冲着这个矛盾来的。它的口号只有两句：ChatGPT thinks. Codex works.（ChatGPT 负责思考，Codex 负责干活。）截至分析时，这个 2026 年 8 月底才建仓的项目已经攒下 7600+ star、700+ fork，而且作者明确在 README 里写了一句"Unofficial community project, not affiliated with or endorsed by OpenAI"。

二、它到底在做什么：把两个智能体拼成一条流水线

先把生活化的比喻放在前面。想象你是一位不太会写代码的团队负责人。你有一个特别聪明的"军师"（ChatGPT 网页版），负责想清楚这件事该怎么做、这么做有没有坑；你还有一个手脚利落的"施工队长"（Codex），负责真正搬砖——改文件、敲命令、跑测试。过去的问题在于：军师和施工队之间只能靠你手写邮件来回传话，代码片段要你复制粘贴，既啰嗦又容易泄密。

这个项目做的事，是给军师和施工队之间装一条专线，而且这条线上只允许"看"，不允许"改"。

具体拆开看，是两条平行通道：

• 控制面（Control Plane）：走 Computer Use，也就是模拟在 ChatGPT 网页上打字。传的是极小的结构化状态消息，形如 [C2C] STATE: PLAN / TASK_ID: c2c_f81a / ITERATION: 1，正文部分是 GOAL、RATIONALE、ACTIONS、FILES_LIKELY_INVOLVED、SUCCESS_CRITERIA。协议文档里明文规定每条消息必须小于 1 KB，禁止粘贴 diff、日志和文件正文。
• 数据面（Data Plane）：走 MCP（Model Context Protocol）。ChatGPT 端主动通过 10 个只读工具去拉它需要的东西——workspace_info、list_directory、read_file、search_workspace、git_status、git_diff、test_status、execution_summary、execution_output、read_image。

这条设计是整个项目的技术内核：军师不靠别人转述现场，它自己去看现场。

状态机被作者定义得相当克制：

INIT → PLAN → EXECUTING → EXECUTED → REVIEW → PLAN | DONE | BLOCKED | ERROR

Codex 发 INIT 请求规划，ChatGPT 回 PLAN，Codex 执行完发 EXECUTED（只带"改了 4 个文件、27 个测试通过"这种元数据），然后 ChatGPT 通过 MCP 独立去看真实的 git diff 和测试记录——它不会盲目相信"全部测试通过"这句自夸。这是整个流程里最值得称道的一环：审查者能查证执行者的说法。

另外还有一条 HANDOFF 通道，用于 Codex 中途重启或换聊天窗口时，从本地 checkpoint（而非日志）重建交接简报。

三、安全设计：把"AI 看得见你的代码"变成可控风险

任何把本地仓库暴露给云端模型的方案，用户第一反应都是"这不危险吗"。作者显然被追问过很多次——docs/security.md 是一份完整威胁模型表格，条目之细甚至有点用力过猛：

只读是构造出来的，不是约定出来的。 服务端根本不存在写文件、删文件、执行 shell、commit 这些工具。没有工具，就没有"提示词注入导致越权"这条路——这是最关键的设计取舍。

一个工作区就是一条边界。 每个 OAuth token 都绑定到唯一的 workspace_id，拿 A 项目的 token 打 B 项目的桥接，直接 403。

路径收敛靠 realpath。 读文件前先把最深存在祖先目录的 realpath 解出来，再做包含性检查，符号链接、../、绝对路径逃逸、Windows 大小写差异全部拦掉，且都有对应测试。敏感文件（.env*、密钥、SSH、云凭据）默认拒读，.env.example 放行，另外还能用 .c2cignore 加自己的规则。

知道 URL 也没用。 公网 MCP 端点强制 OAuth 2.1：PKCE S256 必选（明文 PKCE 直接拒）、动态客户端注册（RFC 7591）、刷新令牌每次使用即轮换（旧令牌重放会失败）、撤销端点齐全。令牌是不透明随机串，落盘只存 SHA-256 哈希，access token 一小时过期，refresh token 三十天。

唯一进过浏览器的秘密是一次性配对码。 8 位、31 字符 CSPRNG 字母表（约 40 bit 熵）、5 分钟 TTL、5 次尝试上限、按 IP 限流 10 次/分钟、用后即焚。

隧道这一层也不松。 桥接服务只绑 127.0.0.1（拒绝 0.0.0.0），公网面只有 HTTPS 隧道；管理 API 是 loopback-only + 随机 admin token + 拒绝带 cf-connecting-ip/x-forwarded-for 的请求；日志会脱敏 token 前缀、Bearer 头、配对码形状的字符串和家目录路径；执行输出还有一层本地 sanitizer，会打码 token、拒收私钥块、限制长度。

作者也老实交代了 V1 的短板：客户端注册和令牌哈希是文件存储而非系统钥匙串，钥匙串集成留到 V2。

四、上手门槛：给小白写的一段话安装

README 里有一整块专门叫"One-paste install"，面向"不懂 git、Node、终端"的用户。做法是把一段自然语言指令原样复制给你的编码智能体：

请帮我完整安装并配置 Codex with ChatGPT，全程自动，我是不懂技术的小白，所有事情你自己做：1. 环境自检……2. 下载……3. 构建……4. 安装 Skill……

然后由 Codex 自己去装 Homebrew/winget、克隆仓库、跑 corepack pnpm install && corepack pnpm build、把 skill/SKILL.md 复制到 ~/.codex/skills/ 下、跑 c2c setup、用内置浏览器打开 ChatGPT 配置连接器并输入配对码。过程中只有关键词是"不要向我解释 MCP、OAuth、Tunnel、端口这些词"。

从工程角度看，真正扛起交互体验的是那份 42KB 的 skill/SKILL.md——它才是这个项目的"用户界面层"，SKILL 里甚至内嵌了 Codex 的沙箱白名单配置逻辑（c2c sandbox-allow）和每天一次的自动更新检查。

对开发者，手动路径同样干净：

pnpm install
pnpm build          # -> dist/，暴露 c2c 可执行文件
pnpm test           # vitest：约 150 个用例
c2c setup           # 桥接 + 隧道 + 配对码，一步到位
c2c status / doctor / pair / unpair / logs / stop

需要 Node.js >= 20、git，以及 cloudflared（QUIC 被封时可用 C2C_TUNNEL_PROTOCOL=http2 切换）。安装到可用的完整链路大致 15-30 分钟，难点不在构建，而在首次需要人参与的那两次登录（ChatGPT 账号；如果你要固定域名，还要登一次 Cloudflare）。

五、争议与局限：这不是没有代价的免费午餐

最直接的问题是它依赖"官方网页版"这个非官方接口面。 项目通过 Computer Use 模拟人在 ChatGPT 网页上的操作来收发控制消息，这意味着：官方 UI 一改版、页面结构一变、或者风控收紧，链路就可能断。作者用 docs/troubleshooting.md 和 Skill 里的 "doctor 自愈" 逻辑来对冲，但这是猫鼠游戏，不是长久之计。而且它明确"非官方"，账号被风控的风险由用户自己承担。

其次是公网暴露面。 尽管只读 + OAuth 双保险，它仍然要求你在公网上开一个临时 HTTPS 入口。默认用的 Cloudflare Quick Tunnel 每次重启 URL 就变，Codex 得删掉并重建 ChatGPT 连接器才能恢复。想要稳定地址就得绑定自己的 Cloudflare 域名，代价是多一次登录和一个真实域名。

第三是"思考"其实并没有被省下来。 省的是 API token，不是 ChatGPT 订阅额度——而且 ChatGPT 网页版的响应速度、并发和每日限额都不受你控制。用它做规划，意味着你的编码流水线速度被拖进了网页 UI 的节奏里。

第四，工作区内容是典型的不可信输入。 README、注释、diff 里都可能埋着提示词注入。作者在每个 MCP 工具描述里都加了警告、工具权限不基于文件内容动态授予，这是对的；但一旦未来引入写操作，这个边界要重新论证。

最后一点小提醒：SKILL 里"不要向用户解释技术细节"的强约束虽然提升了体验，但也让故障排查对普通用户变得更困难。

六、代码质量与行业意义

从代码看，这不是典型的"AI 套壳 demo"。仓库结构干净，职责切分清晰：bridge / mcp / auth / pairing / workspace / tunnel / execution / process / cli 九个模块各自为政；TypeScript 严格模式、zod 做运行时校验、vitest 覆盖约 150 个用例且安全路径都有专门测试；pnpm-workspace.yaml + pnpm-lock.yaml 管理依赖；测试与实现同目录，命名规范一致。代码质量分我给到 87 分——扣分主要在 CLI 单文件接近 5 万字符、偏大，以及 V1 的密钥管理还是文件态。

这个项目真正的行业意义，不在于技术难度，而在于它提出了一个很现实的资源调度命题：AI 编码时代，不同模型、不同入口的额度是不同的商品。同一个用户手里有"按量付费的 API 额度"和"订阅制网页版额度"两种资源，最朴素的优化就是把前者留给执行、后者留给思考。这个思路目前是手工的、需要自己搭桥的，但它一定会被更上层的工具吸收——OpenAI 自己如果做官方 ChatGPT 网页版连接器，这一整层胶水代码就会被直接吞掉。

反过来看这也是一个警示：它证明了一件让很多人不安的事——只要愿意用浏览器自动化去模拟人工操作，理论上任何网页产品的算力都能被"编排"进自动化流水线。官方会不会用条款堵住这条路，以及社区会不会在堵与被堵之间持续演化，将是接下来最值得观察的戏码。

快速结论

维度	结论
定位	ChatGPT 网页版与 Codex 之间的只读 MCP 桥接层，非独立 AI 应用
技术栈	TypeScript / Node.js 20+ / Express 5 / MCP SDK / OAuth 2.1 / Cloudflare Tunnel
部署形态	本地 CLI + 后台守护进程，无 Dockerfile、无 Web UI，不可容器化一键部署
上手难度	中等：构建简单，难点在首次 ChatGPT/Cloudflare 登录与连接器配置
安全水位	较高：只读工具集、realpath 收敛、敏感文件拒读、PKCE+轮换刷新令牌、日志脱敏
主要风险	依赖非官方网页自动化，官方 UI 变动即断链；临时公网隧道需重建连接器；账号风控风险自担
适合人群	已有 ChatGPT 付费订阅、同时重度使用 Codex API 额度的高级编码用户