OpenAI 的 Astra 来了之后,我明显感觉到额度不够用,如果你只是一个 Plus 用户,你在额度消耗完了之后,还想干活的话,该怎么办呢。
其实有两种方式:
- 不用 Astra ,还是用 GPT-5.6 Sol ,额度慢慢消耗;
- 用完 Astra 拉满,额度没了之后,
就休息可以用下面这种方式
先声明前置:我不推荐和鼓励大家使用这种方式,这种方式会有风险,即便你想用,也不要使用你经常订阅的主号。如果你要使用的话,有任何责任和后果不要来找我。
我先来解释一下这种方式的原理:
众所周知,ChatGPT 分为三种模式,Web 端有两种,Chat 、 Work 模式。
Chat 模式不消耗额度(没有官方声明说 Chat 方式会消耗额度或者说有额度限制)
Work 模式消耗的是本地 Codex 的使用额度。
[
image-202609141004431681706×1040 59 KB
](https://cdn3.ldstatic.com/original/4X/3/4/e/34e3e66d25fd64fbbf79499f47bbbfb07408383b.png “image-20260914100443168”)
Codex 客户端的模式分为三种,除了上面两种模式外,还有 Codex 模式,Codex 模式可以理解为专门为编码来设计的。
[
image-20260914100716388486×294 8.59 KB
](https://cdn3.ldstatic.com/original/4X/3/9/2/392cdd48b6ef7ec7979fcf5b8222cc0cf7c48719.png “image-20260914100716388”)
Codex 和 Work 模式都可以对你的本地文件进行操作,这也是 Agent 做的工作。
而 Chat 更像是个聊天机器人,它目前来看无法操纵你本地文件(注意是目前来看)。
[
image-202609141010462111610×696 90.5 KB
](https://cdn3.ldstatic.com/original/4X/0/8/4/0849d6097000dae4a854697f53725841c38ebdbe.png “image-20260914101046211”)
那我如果非要用的话,该怎么样呢?(有人会说你这不是 sb 吗)
折腾!
所以这个方式的原理就一句话:使用 Chat 不消耗订阅额度的方式,通过接入 MCP 来实现帮你干活。
更准确地说,是把一部分原本需要 Work 或 Codex 来做的事情,挪到了 Chat 模式里,再让 ChatGPT 通过 MCP 调用本地工具。实现在不消耗订阅额度的基础上使用顶尖模型的能力。
我知道大家担心的是什么,有没有风险,会不会导致封号之类的,说真的,这些我担保不了,但我能告诉你的是,OpenAI 把这种方式也写在了开发手册上。OpenAI 的 Developers 手册也提及了 MCP 这种方式,所以这种方式并不是空穴来风。
[
image-202609141021109363566×2030 717 KB
](https://cdn3.ldstatic.com/original/4X/0/6/f/06f80cb71efbef9c1e16ec8a6e1b3faf296cdaff.png “image-20260914102110936”)
OpenAI 官方把它叫做 Secure MCP Tunnel。
它解决的问题是:你的 MCP Server 在本地、公司内网或者防火墙后面,ChatGPT 在云端,双方正常情况下互相找不到。tunnel-client 会从内网主动建立一条出站 HTTPS 连接,轮询 OpenAI 托管的 Tunnel 端点,再把收到的 MCP 请求转发到本地。
这样不需要给本地 MCP 开公网端口,也不用把 127.0.0.1 硬暴露出去。
官方文档还明确写了,这条链路可以给 ChatGPT、Codex 和 Responses API 使用。创建 Tunnel、运行 tunnel-client、在 ChatGPT 里创建开发者 App,也都有对应的权限说明。
在开始之前,至少要准备好三样东西:一个 tunnel_id、一枚给 tunnel-client 使用的 Runtime API Key,以及本机能正常访问的 MCP Server。
四种方式
针对这种本地接入 MCP 的方式,我本来想自己搞一个,但我研究了一圈,目前市面上是有四种方式的,所以就不自己做一个了。
这四种方式分别是 WebCodex、DevSpace、codex-with-chatgpt、Mac Developer Bridge。
简单来讲,WebCodex 和 DevSpace 都是让 ChatGPT 直接干活;codex-with-chatgpt 让 ChatGPT 规划、Codex 执行;Mac Developer Bridge 直接把整台 Mac 交给 ChatGPT。
主要区别就两个:ChatGPT 到底能拿到多大的本地权限,以及 Codex 还要不要继续负责执行。
- 先说 WebCodex。 它的架构最完整:ChatGPT 通过 MCP 连接 Server,Runner 在本地负责读写文件、Git、测试、Shell 和长任务。
它能长期连接多个项目、设备和 Runner,还带任务状态、运行记录、人工引导、文件传输和 Computer Use。普通用户可以装 Desktop,再通过 OpenAI Secure Tunnel 连接 ChatGPT。 这套东西的目标很明确:让网页里的 ChatGPT 直接成为 Coding Agent。
WebCodex 的代价是复杂。 Server、Runner、项目注册、Tunnel、token 和 scope 都得正常才行。
- 第二个是 DevSpace。
它同样让 ChatGPT 直接操作本地项目,但默认工具面比较小:open_workspace、read、apply_patch、exec_command、write_stdin、show_changes。这套命名很像 Codex,模型更容易理解。它还支持 Git worktree、AGENTS.md/CLAUDE.md、本地 Skills 和可选子 Agent。
如果你喜欢 Node 工具链,只在一台机器上处理几个仓库,DevSpace 看起来会更清爽。
DevSpace 最大的问题在 Tunnel。它只启动本地 MCP 服务,不替你建立公网连接。Cloudflare Tunnel、ngrok、Tailscale Funnel 或其他 HTTPS 反代,需要自己准备和维护,然后再处理固定地址与 OAuth Owner password。
- 第三个 codex-with-chatgpt,想法很特别。
ChatGPT 负责思考,Codex 负责干活。 ChatGPT 通过 MCP 读取项目、搜索代码、查看 Git diff 和测试记录。
服务端只有 9 个只读工具,没有写文件、删除、Shell、安装依赖和提交代码的能力。 Codex 按 ChatGPT 的方案修改代码,完成后再让 ChatGPT 通过 MCP 检查真实 diff 和测试记录。 这是一套双 Agent 规划与复查流程。
这个 repo 的安全边界是最清晰的。 每个 token 绑定一个 workspace,敏感文件默认拒绝,路径逃逸有专门检查。即使仓库里出现提示词注入,ChatGPT 手里也没有写入和 Shell 工具。 但它没有解决 Codex 执行消耗:规划和 Review 可以转给网页版,写代码、跑测试、Git 操作仍由 Codex 完成。
- 第四个 Mac Developer Bridge,能力最夸张。
它给 ChatGPT 的范围覆盖当前 macOS 用户:任意 Shell、文件读写、真实 PTY、后台任务、历史 Codex 会话,以及已登录 Chrome 的后台操作。通过 AppleScript 或辅助功能,它还能控制桌面应用。
Bridge 本身不调用模型,ChatGPT 负责推理。你可以让它找到昨天的 Codex 会话,进入真实仓库修 CI,再打开浏览器处理后续工作。
这已经超出了 Coding Agent,更像整台 Mac 的远程操作层。 Mac Developer Bridge 的风险也最高。 没有路径白名单、命令白名单、沙箱或内部逐命令审批。MCP 客户端拿到的是 macOS 用户级权限。
我最后选了 WebCodex
之前也是从 L 站看到有佬开发的这个 WebCodex ,这个帖子发在 L 站也是逻辑闭环了。
鉴于上面四种方式的利弊权衡,我最终选择了 WebCodex ,因为后续还是想把这种方式当做常驻的 Coding Agent 。其实 DevSpace 也不错,我看看大家如果感兴趣的话,后面我也写一下 DevSpace 的,然后来实际对比一下。
WebCodex 刚刚发布了 v0.4.1 版本,这次更新比之前白膜的界面有所提升了。
[
image-202609140935296312360×1520 299 KB
](https://cdn3.ldstatic.com/original/4X/4/3/6/436598b810a515f787e8352670c77d0b1a3cea13.png “image-20260914093529631”)
Mac 用户直接下载对应的 Desktop 安装包就行。Apple Silicon 选 darwin-arm64.dmg,Intel Mac 选 darwin-x64.dmg。我这台机器用的是 arm64。
[
image-202609150840205921792×1216 288 KB
](https://cdn3.ldstatic.com/original/4X/3/1/b/31bdec796c0387a739b8d483a7e91411e165eb10.png “image-20260915084020592”)
下面这几步就是实操如何创建 tunnel + 如何创建 API ,然后再通过 plugins 的方式把 MCP 接进去了。
把本地 MCP 接进 Secure Tunnel
首先去 OpenAI 的 platform.openai.com 页面,此时你需要新建一个 Tunnel。
[
image-202609100705379633598×1780 152 KB
](https://cdn3.ldstatic.com/original/4X/1/1/6/116d319e580a8f19bfe1bc582a6647aa247ab3ac.png “image-20260910070537963”)
openai 官方还提供了一个插件叫 tunnel-client ,它的作用是在你第一次在 web 端建了 tunnel 之后,它后续可以通过 tunnel-client 来复用这个 tunnel ,便于维护。
[
image-202609100823329502860×2042 512 KB
](https://cdn3.ldstatic.com/original/4X/c/7/8/c78a83df45f647e40eb73b43414fb6005f6271bc.png “image-20260910082332950”)
从官网上下载下来的 tunnel-client 是命令行程序,单独使用时需要在终端启动。但我这篇文章走的是 WebCodex Desktop,所以这里把结论说清楚:不需要自己执行 tunnel-client run。
第一次只需要在 WebCodex 的 OpenAI Tunnel 配置里填好 Tunnel ID 和 Runtime API Key,再点一次启动。后面 WebCodex Desktop 会在后台托管 tunnel-client,把本地 MCP 挂到 channel=main。ChatGPT 以后通过同一个 Tunnel 发来的任务,都会继续走这个 channel,不需要每次重新创建 Tunnel,也不需要每次打开终端。
只有你完全不使用 WebCodex Desktop,准备让官网下载的
tunnel-client直接连接另一个本地 MCP 时,才需要按照官方的init、doctor、run流程手动启动。这个不是本文采用的方式。
我的 Agent 给我下的是 tunnel-client-v0.0.14-darwin-arm64 这个版本,不过它只是手动运行时的备用方案。本文实际使用的是 WebCodex Desktop 托管的版本,不需要单独运行这份文件。
下载完成后,在右上角的 Create tunnel 中创建 tunnel。
[
image-202609132326579621278×1162 61 KB
](https://cdn3.ldstatic.com/original/4X/a/c/6/ac6f36902ccc60244a295d96f1d7eb7ef750718d.png “image-20260913232657962”)
Organizations 和 workspaces 选默认的就行。
[
image-202609132327597993044×342 16.5 KB
](https://cdn3.ldstatic.com/original/4X/5/4/6/546a84089a858b0eebd8051834931896c09c1ba8.png “image-20260913232759799”)
创建完 tunnel 之后,你还需要创建一个 api-key 。
[
image-202609150929403703058×434 25.9 KB
](https://cdn3.ldstatic.com/original/4X/a/d/6/ad6a95f5d69c67081e0b7187f59373166108ac0f.png “image-20260915092940370”)
注意,这个 api-key 不是让你接入 API ,这个是让你用于隧道认证的。填入它不会把 ChatGPT 网页对话自动切换成按 token 收费的 API 调用。在 ChatGPT 网页里发任务,模型部分仍按 ChatGPT 的套餐和用量规则处理。
tunenl 创建完成后,需要在 WebCodex 中填入相关 Tunnel ID 和 API key。
[
image-202609141032460882360×1520 320 KB
](https://cdn3.ldstatic.com/original/4X/5/7/d/57d1f54f6d7b1ce79420d932dba460fe210e374b.png “image-20260914103246088”)
Key 创建后只完整显示一次,复制出来放进 tunnel-client 或 WebCodex 对应的 Tunnel 配置里。不要贴进聊天窗口,也不要提交到 Git。
现在已经就绪了,接下来就是最后一步:把刚刚创建好的 MCP Tunnel 配置到 ChatGPT 网页里。
打开 ChatGPT,进入 Settings(设置),找到 Security and Login,然后进入开发者相关的配置入口。这里需要开启 Developer mode(开发者模式),然后创建一个自定义的 MCP App。
[
image-202609142215015181328×984 120 KB
](https://cdn3.ldstatic.com/original/4X/5/f/5/5f593f7d3d15496f76d78e0990ce8541f493475d.png “image-20260914221501518”)
回到 ChatGPT 左侧的 Plugins 页面,点击右上角的 Create app。新版 Secure Tunnel 页面不需要填写公网 Endpoint,也不用把 API Key 再粘贴进 ChatGPT,正确配置如下:
[
image-202609142245418532846×1958 251 KB
](https://cdn3.ldstatic.com/original/4X/4/0/3/4039fb6aa669606f715458e727ed1c73b635975a.jpeg “image-20260914224541853”)
创建时按下面填写:
- Name 填
WebCodex。 - Description 可以填
访问本机 WebCodex 中已配置的项目。。 - Connection 选择
Tunnel。 - Available tunnels 选择前面已经运行起来的
nativetunnel。如果列表里没有显示,也可以点击 Use tunnel ID instead,手动填入 Tunnel ID。 - Authentication 选择
No Auth。 - 勾选风险提示下面的确认框,再点击 Create。
这最容易混淆的是两个认证:
- WebCodex 或
tunnel-client里填写的 API Key,只用于让本地客户端接入 OpenAI Secure Tunnel。 - ChatGPT 创建插件时的 Authentication,指 ChatGPT 调用这个 MCP App 时是否还需要第二层认证。我们这里走的是已经绑定好的 Tunnel,所以实际选择的是
No Auth,不需要把 API Key 再填一遍。
点击 Create 后,ChatGPT 会自动读取 WebCodex 暴露的工具清单。进入 Plugins → WebCodex → … → Manage,可以看到已经识别出来的 Actions:
[
image-202609142346033471334×1174 120 KB
](https://cdn3.ldstatic.com/original/4X/6/5/6/656eb7f2fce5fa95dd386aab732b1854c6091eb7.png “image-20260914234603347”)
这里一定要注意:ChatGPT 配置的不是普通的 OpenAI API,也不是一个直接暴露在公网的本地 MCP 地址,而是 OpenAI 官方 Secure Tunnel 关联的 MCP App。
整个链路其实是这样的:
ChatGPT 网页 → OpenAI Secure Tunnel → tunnel-client → WebCodex → 本地文件 / 本地命令
[
ChatGPT 通过 OpenAI Secure MCP Tunnel 调用 WebCodex 操作本地文件的架构图1800×1080 109 KB
](https://cdn3.ldstatic.com/original/4X/5/9/8/59823d7433939e45b905c6ea38453189d4193897.png “ChatGPT 通过 OpenAI Secure MCP Tunnel 调用 WebCodex 操作本地文件的架构图”)
所以 ChatGPT 本身并没有直接获得你电脑的文件权限,而是通过 MCP 调用 WebCodex 提供的工具;WebCodex 再在你本机执行真正的操作。WebCodex Desktop 托管的 tunnel-client 需要一直保持 ready,否则 ChatGPT 虽然还保存着这个 MCP 配置,但已经找不到你本机的 WebCodex 了。这个后台进程由 Desktop 负责,不需要自己开终端守着。
配置完成之后,可以直接点击插件详情页里的 Try in chat;也可以新建一个 ChatGPT 对话,点击输入框左侧的添加按钮并选择 WebCodex。
[
image-202609142247064271836×1256 153 KB
](https://cdn3.ldstatic.com/original/4X/1/9/8/198ba72fc8f4206311ce5a4dde0c51a43becdba9.png “image-20260914224706427”)
选中之后,输入框里会出现 WebCodex 标签,这时就可以像调用一个 Agent 一样直接给它下任务。部分界面也支持输入 @ 调出插件。
比如:
@WebCodex 列一下 Downloads 目录下面有哪些文件。
[
image-202609142151408311686×474 37 KB
](https://cdn3.ldstatic.com/original/4X/5/c/5/5c5b499362e3d62a5c0e59446b5f7eb0493f2f1d.png “image-20260914215140831”)
这时候 ChatGPT 负责理解你的自然语言任务,WebCodex 负责调用本地工具,而真正的文件访问和命令执行仍然发生在你自己的 Mac 上。
配置到这一步,就可以通过 WebCodex 执行任务了。上面这个例子,就是让它列出 Downloads 目录里的内容。
如果是 free 额度的话,使用 chat 模式的背后模型是 GPT-5.6 Luna,而 Luna 本来就免费。
如果是 plus 额度的话,使用 chat 模式的背后模型是 GPT-5.6 Sol。
[
image-202609142302118821544×384 24.1 KB
](https://cdn3.ldstatic.com/original/4X/3/5/6/356bf67310a7c5d2ab9208945ce9bd91d2bcd974.png “image-20260914230211882”)
所以还是建议大家上到 plus 这一层。
[
image-202609151034041931680×1424 275 KB
](https://cdn3.ldstatic.com/original/4X/c/9/f/c9fb29369e9d311dc8b5c01400677d54cda46d6d.png “image-20260915103404193”)
到了这一步,你基本上可以使用 ChatGPT web 端的 Chat 模式来干活了。
这套方式能不能做长期项目?
说到一个大家都关心的问题,这套方式适不适合做长期项目?
说一下结论:按道理来说是可以的,不过仍然有待实测。
因为 Secure Tunnel 和 WebCodex 建好之后,Tunnel ID、channel=main 和本地项目都能继续复用。代码、Git 记录、测试结果也一直留在自己的电脑里。今天做到一半,明天再让 ChatGPT 读取项目状态,它还能接着往下干。
因为 Chat 模式依然是一轮一轮工作的,它有上下文边界,也会受到模型可用性、套餐规则、电脑休眠和网络状态影响。
WebCodex 可以让本地任务继续跑,但 ChatGPT 本身不会因为接了 MCP,就自动获得 Work 或 Codex 里的 /goal 长任务机制。
不过,OpenAI 现在也专门提供了 Long-running work 和 /goal。这套机制适合跑几个小时的迁移、重构和测试循环。
官方还提醒,本地长任务需要让 Mac 保持唤醒。真要把一个项目连续跑几小时,我还是会用 Work 或 Codex;日常改代码、查文件、跑测试和反复迭代,再交给 Chat + WebCodex。
这套方式适合把 ChatGPT 变成一个长期能回来干活的本地 Agent,不适合把它理解成一台永远满血、永远不停机的免费服务器。