OpenAI 的 Astra 来了之后,我明显感觉到额度不够用,如果你只是一个 Plus 用户,你在额度消耗完了之后,还想干活的话,该怎么办呢。

其实有两种方式:

  1. 不用 Astra ,还是用 GPT-5.6 Sol ,额度慢慢消耗;
  2. 用完 Astra 拉满,额度没了之后,就休息 可以用下面这种方式

先声明前置:我不推荐和鼓励大家使用这种方式,这种方式会有风险,即便你想用,也不要使用你经常订阅的主号。如果你要使用的话,有任何责任和后果不要来找我。

我先来解释一下这种方式的原理:

众所周知,ChatGPT 分为三种模式,Web 端有两种,Chat 、 Work 模式。

Chat 模式不消耗额度(没有官方声明说 Chat 方式会消耗额度或者说有额度限制)

Work 模式消耗的是本地 Codex 的使用额度。

[image-20260914100443168

image-202609141004431681706×1040 59 KB

](https://cdn3.ldstatic.com/original/4X/3/4/e/34e3e66d25fd64fbbf79499f47bbbfb07408383b.png “image-20260914100443168”)

Codex 客户端的模式分为三种,除了上面两种模式外,还有 Codex 模式,Codex 模式可以理解为专门为编码来设计的。

[image-20260914100716388

image-20260914100716388486×294 8.59 KB

](https://cdn3.ldstatic.com/original/4X/3/9/2/392cdd48b6ef7ec7979fcf5b8222cc0cf7c48719.png “image-20260914100716388”)

Codex 和 Work 模式都可以对你的本地文件进行操作,这也是 Agent 做的工作。

而 Chat 更像是个聊天机器人,它目前来看无法操纵你本地文件(注意是目前来看)。

[image-20260914101046211

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-20260914102110936

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-20260914093529631

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-20260915084020592

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-20260910070537963

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-20260910082332950

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 时,才需要按照官方的 initdoctorrun 流程手动启动。这个不是本文采用的方式。

我的 Agent 给我下的是 tunnel-client-v0.0.14-darwin-arm64 这个版本,不过它只是手动运行时的备用方案。本文实际使用的是 WebCodex Desktop 托管的版本,不需要单独运行这份文件。

下载完成后,在右上角的 Create tunnel 中创建 tunnel。

[image-20260913232657962

image-202609132326579621278×1162 61 KB

](https://cdn3.ldstatic.com/original/4X/a/c/6/ac6f36902ccc60244a295d96f1d7eb7ef750718d.png “image-20260913232657962”)

Organizations 和 workspaces 选默认的就行。

[image-20260913232759799

image-202609132327597993044×342 16.5 KB

](https://cdn3.ldstatic.com/original/4X/5/4/6/546a84089a858b0eebd8051834931896c09c1ba8.png “image-20260913232759799”)

创建完 tunnel 之后,你还需要创建一个 api-key 。

[image-20260915092940370

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-20260914103246088

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-20260914221501518

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-20260914224541853

image-202609142245418532846×1958 251 KB

](https://cdn3.ldstatic.com/original/4X/4/0/3/4039fb6aa669606f715458e727ed1c73b635975a.jpeg “image-20260914224541853”)

创建时按下面填写:

  1. Name 填 WebCodex
  2. Description 可以填 访问本机 WebCodex 中已配置的项目。
  3. Connection 选择 Tunnel
  4. Available tunnels 选择前面已经运行起来的 nativetunnel。如果列表里没有显示,也可以点击 Use tunnel ID instead,手动填入 Tunnel ID。
  5. Authentication 选择 No Auth
  6. 勾选风险提示下面的确认框,再点击 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-20260914234603347

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 操作本地文件的架构图

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-20260914224706427

image-202609142247064271836×1256 153 KB

](https://cdn3.ldstatic.com/original/4X/1/9/8/198ba72fc8f4206311ce5a4dde0c51a43becdba9.png “image-20260914224706427”)

选中之后,输入框里会出现 WebCodex 标签,这时就可以像调用一个 Agent 一样直接给它下任务。部分界面也支持输入 @ 调出插件。

比如:

@WebCodex 列一下 Downloads 目录下面有哪些文件。

[image-20260914215140831

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-20260914230211882

image-202609142302118821544×384 24.1 KB

](https://cdn3.ldstatic.com/original/4X/3/5/6/356bf67310a7c5d2ab9208945ce9bd91d2bcd974.png “image-20260914230211882”)

所以还是建议大家上到 plus 这一层。

[image-20260915103404193

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 IDchannel=main 和本地项目都能继续复用。代码、Git 记录、测试结果也一直留在自己的电脑里。今天做到一半,明天再让 ChatGPT 读取项目状态,它还能接着往下干。

因为 Chat 模式依然是一轮一轮工作的,它有上下文边界,也会受到模型可用性、套餐规则、电脑休眠和网络状态影响。

WebCodex 可以让本地任务继续跑,但 ChatGPT 本身不会因为接了 MCP,就自动获得 Work 或 Codex 里的 /goal 长任务机制。

不过,OpenAI 现在也专门提供了 Long-running work 和 /goal。这套机制适合跑几个小时的迁移、重构和测试循环。

官方还提醒,本地长任务需要让 Mac 保持唤醒。真要把一个项目连续跑几小时,我还是会用 Work 或 Codex;日常改代码、查文件、跑测试和反复迭代,再交给 Chat + WebCodex。

这套方式适合把 ChatGPT 变成一个长期能回来干活的本地 Agent,不适合把它理解成一台永远满血、永远不停机的免费服务器。

相关链接