codex-chatgpt-web：把 ChatGPT 网页版接进 Codex 的本地桥

让 ChatGPT 负责思考，Codex 负责干活——用你已经付费的 ChatGPT 网页额度，去补 Codex API 额度不够用的缺口。

图 1：Codex Web GPT 启动器图标（MIT 协议，Electron 桌面应用）

---

一、一个具体的场景：额度见底的那天下午

你正在用 Codex 改一个跨三个服务的重构任务。模型切换器里，GPT-5.6 Sol 的剩余额度条已经变红——不是"用完了"，而是"快用完了"。你很清楚这次任务真正的消耗点不在写代码，而在读日志、比对方案、做取舍判断这些"想"的部分。

这时候你打开自己另一个标签页：ChatGPT Pro 网页版。它能用，额度独立计算，而且已经订阅了。

codex-chatgpt-web 想解决的正是这个夹缝。它不是一个新模型，不是一个代理服务，而是一座跑在你本机的桥：把 ChatGPT 网页版的模型（Luna / Instant / Medium–High / Extra High / Pro）注册进 Codex 原生的模型下拉框里。你在 Codex 里选一个以 (Web) 结尾的模型项，这一轮请求就会经过本机 daemon，被送进一个新建的 ChatGPT 会话里跑，然后把流式结果原样送回你的 Codex 任务。

关键点：这条链路不消耗 Codex 自己的额度，而是走 ChatGPT 网页版的另一套使用限制——两者是分开的账本。

图 2：README 中的实机演示，Codex 任务外壳 + ChatGPT Web 回应的实时回合

---

二、背景科普：一个"官方不支持但官方零件齐全"的项目

项目出身

仓库 miuuyy/codex-chatgpt-web 创建于 2026 年 7 月 26 日，是个人开发者 miuuyy 的作品，目前版本 v6.1.13（2026-10-21 发布），14 位贡献者、377 次提交，是 2026 年下半年增长最快的 Codex 生态项目之一。

它的思路非常"聪明人"：不逆向 ChatGPT 的私有 API，而是用官方允许的浏览器自动化 + 官方提供的 tunnel-client，把网页版变成 Codex 能理解的 Responses API 服务端。

它依赖的三个"官方零件"

1. Playwright / Chromium BiDi：驱动内嵌浏览器操作 ChatGPT 网页，提取回答、注入提示、监听流式渲染。项目的 src/adapters/chatgpt-web/ 就是这一层。
2. openai/tunnel-client：ChatGPT 官方提供的隧道客户端，让 ChatGPT 端的工具调用可以回连到本机。隧道是出站的，不暴露公网 IP、不需要路由器端口映射。
3. MCP（Model Context Protocol）：ChatGPT 的自定义连接器通过 MCP 把"我要执行本地命令"的请求送回 Codex。

兄弟项目

同类思路还有 XiaoDuoYa/codex-with-chatgpt（主打只读 MCP 桥接，ChatGPT 只做规划与审查，本地执行权完全留在 Codex）和 XiaoDuoYa/codex-with-chatgpt 的各种 fork。但 codex-chatgpt-web 走得更远：它允许 Full harness 模式下 ChatGPT 真正调用本地工具，而不只是"只读建议"。

---

三、类比解释：给 Codex 装了一台"外接显卡"

如果把 Codex 想象成一台配置固定的电脑：模型是它焊在主板上的 GPU，额度是插在墙上的电表——你只能用官方给的那张卡，用官方那条线路。

codex-chatgpt-web 相当于给它接了一块外接显卡：这块卡性能不差（Pro 版的推理能力是实打实的），而且插在另一块电表上（ChatGPT 网页版的独立额度）。同时它还附赠一根双向数据线（MCP + tunnel），让外接显卡能把算力请求反向送回本机工具执行。

但外接显卡有三个绕不开的现实约束：

• 供电与散热是共享的——浏览器自动化有渲染延迟，天然比原生 API 慢；
• 接口是脆弱的——ChatGPT 网页改版就会打断选择器；
• 不能插在服务器的机箱里——它依赖交互式登录，属于"人手操作的桌面工具"，不是可编排的后端服务。

这三条也直接决定了本文后面会讲的"它不适合什么场景"。

---

四、核心功能：三种模式，三层能力

4.1 三种工作模式

模式	发消息方式	本地 Codex 工具	适用场景
Browser-only	自动	❌ 不可用	只想用 ChatGPT Web 的推理质量做分析、评审、写建议
Full harness	自动	✅ 经 MCP	真正的"ChatGPT 规划 + Codex 落地"协作
Zero Risk	手动粘贴发送	✅ 经独立 MCP 连接器	不信任自动注入；自己审一遍提示词再发

Zero Risk 的设计很克制：它不读取也不操作 ChatGPT 页面，由用户自己选模型、自己拼提示词、在启动器里点确认"已发送"。这是一个明确的"信任边界由我掌控"的逃生舱。

4.2 Full harness：把工具调用接回同一个任务

这是整个项目技术含量最高的部分。链路是：

Codex app / CLI
      │ Responses API on loopback (127.0.0.1)
      ▼
codex-chatgpt-web daemon
  ├─ /models 透传 + 固定注入 ChatGPT Web 模型目录
  ├─ 原生 Responses 透传 或 ChatGPT Responses/SSE 桥接
  ├─ ChatGPT 浏览器工作线程（最多 5 个任务绑定的 Electron 标签页）
  ├─ 能力代理器 capability broker（仅 Full 模式）
  └─ stdio MCP server
            ▲
            │ 出站 OpenAI Tunnel
            ▼
      ChatGPT 自定义连接器（名称必须为 Codex Native2）

几个工程细节值得注意：

• 回合级令牌（turn token）：daemon 为每一轮生成随机令牌并埋进那一条浏览器提示中；每次 Codex Native 动作都必须带上同一个令牌。MCP 处理器会幂等地"认领"一个内部绑定，并立即派发动作，内部句柄不暴露给模型。
• 能力收敛：MCP 只能请求当前外层 Codex 回合"已公示可调用"的工具。Codex 侧代码模式（code-mode）里的 exec 网关仍然保留，但桥接层给它套了一层透明代理，强制执行 10 秒 wait_agent 轮询契约，并阻止递归的裸 exec。
• 上下文压缩（compaction）：上下文接近阈值时触发压缩并安装替换历史。GPT-5.6 Plus Medium/High 实测窗口 90,000 tokens，启用实验性 3× context 可达 270,000，压缩阈值 110,000；GPT-6 Sol Pro 为 240,000，压缩阈值 220,000。
• 子智能体（subagents）：内置 skills/pro-researcher，明确要求子代理使用 model: "chatgpt-web/gpt-6-pro"、reasoning_effort: "max"、fork_context: false。也就是说，你可以把"深度调研/架构评审"整块外包给 ChatGPT 6 Pro，让它在同一个仓库里翻代码、查资料、挑战你的假设。

4.3 工程与质量

• 技术栈：TypeScript 为主（3.41 MB），配套 JavaScript（1.05 MB）、CSS、少量 Shell / PowerShell。
• 运行时：Bun 1.4.0（packageManager 锁定），自带 runtime 打包进应用，不需要用户另装 Node/Bun/Chrome。
• 桌面端：Electron 42.11.3 + React 19 + Vite 6，electron-builder 打包出 macOS 13+（arm64/x64）、Windows x64、Linux x64 三平台产物。
• 测试：仓库有 80 个左右的 *.test.ts 单测文件，覆盖浏览器登录、DOM 解析、模型目录、压缩、隧道、子代理、零风险适配器等，CI 在 macOS 15 / Ubuntu / Windows 三平台矩阵上跑 bun run verify + 打包冒烟。
• 版本节奏：v6.1.11 → v6.1.12 → v6.1.13，连续几天内三次发布，每次 20 个 Release 资产。

---

五、上手门槛：比想象中简单，但有两个"必须人工"的环节

5.1 部署方式（桌面应用，非容器）

仓库中没有 Dockerfile、没有 docker-compose、没有 k8s 清单——它是彻底的桌面原生形态。安装脚本只有一行：

# macOS / Linux
curl -fsSL https://github.com/miuuyy/codex-chatgpt-web/releases/latest/download/install-launcher.sh | sh

# Windows PowerShell
irm https://github.com/miuuyy/codex-chatgpt-web/releases/latest/download/install-launcher.ps1 | iex

安装器会校验发布的 SHA-256 清单，并保留你的 ChatGPT 浏览器 profile 与启动器设置。

5.2 上手流程（Browser-only，最快路径）

1. 装好启动器；
2. 在内嵌浏览器里登录 ChatGPT，跑一次浏览器冒烟测试；
3. 点 "Install models"，重启 Codex 一次；
4. 在模型选择器里选名字带 (Web) 的项——自动模式下它与 Codex 原生模型混排在同一个列表里。

5.3 上手流程（Full harness，多 4 步）

在上面的基础上还要：打开启动器 MCP 页 → 建 Tunnel 和常规 API key → 点 "Connect harness" → 在 ChatGPT 侧开启 Developer Mode，新建一个 Tunnel 连接器，名字必须精确为 Codex Native2，认证方式选 None，动作权限选 Allow all actions → 回启动器点 "Verify runtime" 确认已挂载。

项目对连接器名称做了硬校验：只认 Codex Native2，看到旧标识 Codex Native 会报明确的迁移错误，绝不回退。生产环境用 Codex Native2，DEV 驱动用 Codex Native2 DEV，两者可以同时存在于同一个 ChatGPT 账号，互不干扰。

5.4 门槛评估

维度	评价
安装	★☆☆☆☆ 一行脚本，自动校验校验和
依赖	★★☆☆☆ 需要 ChatGPT 账号；Full 模式需 ChatGPT Developer Mode + 管理员策略允许写操作
概念	★★★★☆ 三种模式、Effort 层级、连接器身份、压缩阈值，新概念不少
环境	★★★☆☆ 需要真实桌面（macOS 13+ / Win x64 / Linux x64），非服务器
排错	★★★★☆ 内置 Activity 诊断面板、Settings → Run doctor、TROUBLESHOOTING.md + 视频走查

---

六、争议与局限：不回避问题

6.1 这是"非官方浏览器自动化"，随时可能失效

README 自己写得很直白："This is unofficial browser automation, not an OpenAI API." ChatGPT UI 一改版，选择器就可能失配。项目的应对策略是显式失败（fail explicitly）而不是静默降级——不会悄悄换个模型或传输通道糊弄过去。这是很专业的工程态度，但也意味着上游一变你就得等作者更新。

6.2 合规灰区是绕不开的讨论点

它把"网页版订阅额度"接入到"编程代理"的工作流里，虽然用的都是官方零件（浏览器自动化、官方 tunnel-client、官方 MCP 连接器），但绕过的是额度计量边界。这与 codex-with-chatgpt 的"只读规划桥接"是两种不同的风险姿态——后者只让 ChatGPT 看和提建议，不让它动手；前者允许写文件、跑命令。目前 ToS 层面并未见 OpenAI 对此类用途的明确表态。企业内部使用前建议自行评估合规性。

6.3 登录态是敏感资产

浏览器 profile 是一次性登录凭据，而本机 loopback 监听器对同一 OS 用户下的所有进程可达。项目自己给出了告警：切勿分享启动器 profile，只在可信工作站上使用。

6.4 未签名构建 + 平台限制

构建产物尚未做平台签名，Gatekeeper / SmartScreen 会弹警告。安装器虽校验 SHA-256 清单，但用户仍需自行信任。Linux 只支持 x64，macOS 要求 13+。

6.5 不适合的场景

• 服务器 / CI / 无头环境：没有浏览器 profile，也没有交互式登录，浏览器自动化模式无法工作。
• 容器化部署：仓库无任何容器化资产，且 Electron + 持久化浏览器态的形态天然不适合 K8s。
• 追求确定性延迟：每一轮都要走浏览器渲染 + DOM 抽取，比原生 API 慢一个量级起步。
• 合规敏感的生产流水线：登录态托管、额度共享、模型行为不确定性都是风险点。

---

七、行业意义：一个更大的趋势信号

codex-chatgpt-web 的 14.7k stars（2026 年 7 月至今不到 3 个月）说明一件事：订阅制模型的"闲置额度"正在成为一种可编程资源。

传统做法是买 API Key，按 token 计费；而越来越多用户手上已经为 ChatGPT 订阅付过费了。这两者之间的差额，就是这个项目套利的空间。同类项目在 2026 年下半年密集出现——codex-with-chatgpt、各种 MCP 桥接方案、Chrome 扩展版桥接器——形成了"Web-as-API"这一支流。

它背后还折射出 Codex 生态的一个结构性特征：Codex 的价值从来不只在模型，而在任务外壳——文件、终端、工具调用、审批流、修改记录这一整套 harness。模型可以被替换，harness 不行。所以任何能把新模型塞进既有 harness 的项目，都在争夺"模型选择权"的入口位置。codex-chatgpt-web 把 ChatGPT Web 变成一个可选项，等于在入口处插了一根楔子。

而它最聪明的一步，是把 MCP 接回去了。只做"网页版当大脑"的桥接只是转发；允许 ChatGPT 反向调用本机工具、共享上下文压缩、支持 Pro 子代理并行调研，这才让它从"转述器"变成了真正的协作体——ChatGPT 思考，Codex 干活，两者共享同一个任务上下文。

代价也很明确：脆弱的 DOM 依赖、敏感的本机凭据、不可预测的延迟、以及一条随时可能被上游条款收紧的路径。这是一个精巧但脆弱的工程。它的价值也许不在于长期存在，而在于它把一个此前没人认真做过的问题——"如何把订阅制网页模型变成编程代理的可插拔后端"——完整地演示了一遍。

---

附：项目档案

项目	内容
仓库	miuuyy/codex-chatgpt-web
Stars / Forks	14,786 / 1,160
语言	TypeScript（+ JavaScript / CSS / Shell / PowerShell）
许可证	MIT
创建 / 最近推送	2026-07-26 / 2026-10-22
贡献者 / 提交数	14 / 377
版本	v6.1.13（2026-10-21）
核心依赖	playwright-core、chromium-bidi、@modelcontextprotocol/sdk、tiktoken、zod、turndown
桌面端	Electron 42 + React 19 + Vite 6 + electron-builder
运行时	Bun 1.4.0（随包分发）
平台	macOS 13+ (arm64/x64)、Windows x64、Linux x64
容器化	无 Dockerfile / compose / k8s
文档	README（四语种）+ docs/{architecture,security-model,release-validation,dev-chat}.md + TROUBLESHOOTING.md + SECURITY.md
CI	GitHub Actions，macOS 15 / Ubuntu / Windows 三平台矩阵