Chat 模式不烧订阅额度，这件事本身不算新闻。真正有意思的是，能不能让这个不烧额度的入口，反过来驱动你本机的文件和命令。答案是能，靠的就是 Open AI 官方的 Secure MCP Tunnel。
先把丑话说前面：这条路子官方文档里有依据，但它属于灰色操作，封不封号我担保不了。要不要用，自己掂量。
三种模式，额度账本不一样
Chat GPT 的 Web 端有两种用法。Chat 是纯聊天，官方从没说过它消耗订阅额度，也没给出额度约束；Work 走的是本地 Codex 的额度池。
除此之外还有 Codex 客户端，它同样吃 Codex 额度。
关键差别在能力边界上。Work 和 Codex 都能动你的本地文件，因为它们本质是 Agent。Chat 目前只是个聊天机器人，碰不到你硬盘上的东西。
那想把 Chat 变成能干活的东西，思路就一句话：用 Chat 不消耗订阅额度这个特性，通过 MCP 把本地工具接进去。原本该由 Work 或 Codex 承担的任务，挪到 Chat 里执行。
代价是折腾。收益是用顶级模型的能力，不额外烧额度。
Secure MCP Tunnel 到底解决了什么
问题很朴素：你的 MCP Server 跑在本地、公司内网或者防火墙后面，Chat GPT 在云端，两边正常情况下互相看不见。
tunnel-client 的做法是从内网主动发起一条出站 HTTPS 连接，轮询 Open AI 托管的 Tunnel 端点，把收到的 MCP 请求转发到本地。
好处是不用给本地 MCP 开公网端口，也不用把 127.0.0.1 硬暴露出去。官方明确写了这条链路可以供 Chat GPT、Codex 和 Responses API 使用。
动手前至少准备三样：一个 tunnel_id、一枚给 tunnel-client 用的 Runtime API Key、一个本机能正常访问的 MCP Server。
四条路线，授权尺度差很多
市面上能走通的有四种：Web Codex、Dev Space、codex-with-chatgpt、Mac Developer Bridge。
区别集中在两点：Chat GPT 能拿到多大的本地授权，以及 Codex 还要不要继续承担执行。
Web Codex 结构最完整。Chat GPT 通过 MCP 连上 Server，Runner 在本地负责读写文件、Git、验证、Shell 和长任务。它能长期连接多个工程、设备和 Runner，带任务状态、运行记录、人工介入、文件传输和 Computer Use。普通用户装个 Desktop，再通过 Secure Tunnel 连上 Chat GPT 就行。目标很直接：让网页里的 Chat GPT 变成 Coding Agent。代价是复杂，Server、Runner、工程注册、Tunnel、token、scope 一个都不能错。
Dev Space 同样让 Chat GPT 直接操作本地工程，但默认工具面小一圈：open_workspace、read、apply_patch、exec_command、write_stdin、show_changes。命名风格贴近 Codex，模型理解起来更轻松。它还有 Git worktree、AGENTS.md／CLAUDE.md、本地 Skills 和可选子 Agent。如果你习惯 Node 工具链，只在一台机器上管几个库，Dev Space 更清爽。它最大的坑在 Tunnel：只启动本地 MCP，不替你搭公网通道。Cloudflare Tunnel、ngrok、Tailscale Funnel 或者其他 HTTPS 反代，都得自己准备和维护，还要处理固定地址和 OAuth Owner password。
codex-with-chatgpt 的想法最特别：Chat GPT 负责想，Codex 负责干。Chat GPT 通过 MCP 读工程、搜代码、看 Git diff 和验证记录。支撑端只有 9 个只读工具，没有写文件、删除、Shell、装依赖和提交代码的能力。Codex 按 Chat GPT 的策略改代码，改完 Chat GPT 再通过 MCP 检查真实 diff 和验证记录。这是一套双 Agent 的规划加复查链路。它的安全边界最清楚：每个 token 绑定一个 workspace，敏感文件默认拒绝，路径逃逸有专门检查。就算库里出现提示词注入，Chat GPT 手里也没有写入和 Shell 工具。但它没解决 Codex 执行消耗的问题——规划和 Review 能转给网页版，写代码、跑验证、Git 操作还是 Codex 干。
Mac Developer Bridge 能力最夸张。它给 Chat GPT 的边界覆盖当前 macOS 用户：任意 Shell、文件读写、真实 PTY、后台任务、历史 Codex 会话，以及已登录 Chrome 的后台操作。它还能通过 AppleScript 或辅助功能控制桌面应用。Bridge 本身不触发模型，Chat GPT 负责推理。你可以让它翻出昨天的 Codex 会话，进真实仓库修 CI，再打开浏览器处理后续。这已经超出 Coding Agent，更像整台 Mac 的远程操作层。风险也最高：没有路径白名单、命令白名单、沙箱或内部逐命令审批。MCP 客户端拿到的是 macOS 用户级授权。
我最后选了 Web Codex，因为打算把它当常驻的 Coding Agent 用。Dev Space 其实也不错，后面可以单独写。
装 Desktop 和建 Tunnel
Web Codex 刚发了 v0.4.1，界面比之前白膜版本好看了些。
Mac 用户直接下对应的 Desktop 安装包。Apple Silicon 选 darwin-arm64.dmg，Intel Mac 选 darwin-x64.dmg。我这台是 arm64。
第一步去 platform.openai.com 新建一个 Tunnel。
Open AI 还提供 tunnel-client 这个组件，作用是你第一次在 Web 端建好 tunnel 之后，后续可以通过它复用同一个 tunnel。
下载下来的 tunnel-client 是命令行程序，单独用要在终端启动。但走 Web Codex Desktop 这条路，结论先说清楚：不需要自己执行 tunnel-client run。
第一次只要在 Web Codex 的 Open AI Tunnel 设置里填好 Tunnel ID 和 Runtime API Key，点一次启动。之后 Web Codex Desktop 会在后台托管 tunnel-client，把本地 MCP 挂到 channel=main。以后 Chat GPT 通过同一个 Tunnel 发来的任务都走这个 channel，不用每次重建。
只有你完全不用 Web Codex Desktop，准备拿下载的 tunnel-client 直接连另一个本地 MCP 时，才需要按官方的 init、doctor、run 流程手动启动。那不是本文的用法。
我的 Agent 给我下的是 tunnel-client-v0.0.14-darwin-arm64，不过它只是手动运行时的备用方案。本文实际用的是 Web Codex Desktop 托管的版本，不用单独跑这份文件。
下载完，在右上角 Create tunnel 里创建 tunnel。
Organizations 和 workspaces 选默认的就行。
建完 tunnel，接着创建一个 api-key。
注意这个 api-key 不是用来接 API 的，它是给隧道做认证的。填进去不会把 Chat GPT 网页对话自动切成按 token 计费的 API 触发。在网页里发任务，模型依然按 Chat GPT 的套餐和用量规则处理。
tunnel 建好后，在 Web Codex 里填入对应的 Tunnel ID 和 API key。
Key 创建后只完整显示一次，复制出来放进 tunnel-client 或 Web Codex 的 Tunnel 设置里。别贴进聊天窗口，也别提交到 Git。
在 Chat GPT 里创建 MCP App
现在准备工作差不多了，最后一步是把刚建好的 MCP Tunnel 配到 Chat GPT 网页里。
打开 Chat GPT，进 Settings（设置），找到 Security and Login，再进开发者相关的设置入口。这里要开启 Developer mode（开发者模式），然后创建一个自定义的 MCP App。
回到 Chat GPT 左侧的 Plugins 页面，点右上角 Create app。新版 Secure Tunnel 页面不需要填公网 Endpoint，也不用把 API Key 再粘进 Chat GPT。
创建时按下面填：
- Name 填 Web Codex。
- Description 可以填 访问本机 Web Codex 中已配置的工程。
- Connection 选 Tunnel。
- Available tunnels 选前面已经跑起来的 nativetunnel。如果列表里没有，可以点 Use tunnel ID instead，手动填 Tunnel ID。
- Authentication 选 No Auth。
- 勾选风险提示下面的确认框，点 Create。
这里最容易混的是两个认证。Web Codex 或 tunnel-client 里填的 API Key，只用于让本地客户端接入 Open AI Secure Tunnel。Chat GPT 创建组件时的 Authentication，指的是 Chat GPT 调用这个 MCP App 时是否还需要第二层认证。我们走的是已经绑定好的 Tunnel，所以这里选 No Auth，不需要把 API Key 再填一遍。
点 Create 后，Chat GPT 会自动读取 Web Codex 暴露的工具清单。进 Plugins → Web Codex → … → Manage，能看到已经识别出来的 Actions。
链路长什么样，谁在真正碰你的文件
这里必须说清楚：Chat GPT 配的不是普通的 Open AI API，也不是一个直接暴露在公网的本地 MCP 地址，而是 Open AI 官方 Secure Tunnel 关联的 MCP App。
整个链路是这样的：
Chat GPT 网页 → Open AI Secure Tunnel → tunnel-client → Web Codex → 本地文件 / 本地命令
所以 Chat GPT 本身并没有直接拿到你电脑的文件授权，它是通过 MCP 调用 Web Codex 提供的工具，Web Codex 再在你本机执行真实操作。Web Codex Desktop 托管的 tunnel-client 需要一直保持 ready，否则 Chat GPT 虽然还留着这个 MCP 配置，但已经找不到你本机的 Web Codex 了。这个后台进程由 Desktop 负责，不用自己开终端守着。
配完之后，可以直接点组件详情页里的 Try in chat；也可以新建一个 Chat GPT 对话，点输入框左侧的添加按钮选 Web Codex。
选中后输入框里会出现 Web Codex 标签，这时就能像调用一个 Agent 一样直接下任务。部分界面也支持输入 @ 调出插件。比如：
@Web Codex 列一下 Downloads 目录下面有哪些文件。
这时 Chat GPT 负责理解你的自然语言任务，Web Codex 负责调用本地工具，真实的文件访问和命令执行仍然发生在你自己的 Mac 上。
到这一步就能通过 Web Codex 干活了。上面这个例子，就是让它列出 Downloads 目录里的内容。
模型和额度的实际差别
如果是 free 额度，Chat 方式背后的模型是 GPT-5.6 Luna，Luna 本来就免费。
如果是 plus 额度，Chat 方式背后的模型是 GPT-5.6 Sol。
所以还是建议上到 plus 这一层。
能不能拿它做长期工程
结论是：理论上可以，但有待实测。
Secure Tunnel 和 Web Codex 建好之后，Tunnel ID、channel=main 和本地工程都能持续复用。代码、Git 记录、验证结果始终留在自己电脑里。今天做到一半，明天再让 Chat GPT 读取工程状态，它还能接着往下干。
但它有上下文限制，也会受模型可用性、套餐规则、电脑休眠和网络状态影响。Chat 方式仍是一轮一轮的交互，Web Codex 能让本地任务持续跑，但 Chat GPT 本身不会因为接了 MCP，就自动获得 Work 或 Codex 里的 /goal 长任务机制。
不过 Open AI 现在也专门提供了 Long-running work 和 /goal。这套机制适合跑几个小时的迁移、重构和验证循环。
官方还提醒，本地长任务需要让 Mac 保持唤醒。真要把一个工程连续跑几小时，我还是会用 Work 或 Codex；日常改代码、查文件、跑验证和反复迭代，再交给 Chat + Web Codex。
这套方法适合把 Chat GPT 变成一个能长期回来干活的本地 Agent，不适合把它理解成一台永远满血、永远不停机的免费服务器。
作者：武晓燕
来源：cxuan AI
