一句话看懂：有开发者发现，通过 OpenAI 官方的 Secure MCP Tunnel 把本地 MCP Server 接入 ChatGPT 的 Chat 模式，可以让网页版 ChatGPT 在不消耗 Codex 订阅额度的前提下操作本地文件和执行任务。这条路官方文档有迹可循，但存在封号和权限失控风险，不建议在主力账号上尝试。
事件核心：发生了什么
据掘金作者 cxuanAI 在 2026 年 9 月 16 日发布的文章，OpenAI 推出 Astra 之后，Plus 用户的额度压力明显增大。作者梳理出一条绕开额度限制的路径：ChatGPT 的 Chat 模式目前没有官方声明的额度限制，而 Work 模式和 Codex 模式消耗的是本地 Codex 额度。既然 Chat 无法直接操作本地文件，那就用 MCP 把本地工具接进来，让 Chat 模式完成原本属于 Work 或 Codex 的工作。
依据是 OpenAI 开发者手册中的 Secure MCP Tunnel。它的机制是：本地 tunnel-client 主动向 OpenAI 托管的 Tunnel 端点建立出站 HTTPS 连接并轮询，把来自云端的 MCP 请求转发到本地 MCP Server，无需开放公网端口或暴露 127.0.0.1。官方文档写明这条链路可供 ChatGPT、Codex 和 Responses API 使用。
作者还盘点了四种现成方案：WebCodex、DevSpace、codex-with-chatgpt、Mac Developer Bridge。区别集中在两点：ChatGPT 能拿到多大的本地权限，以及 Codex 是否仍负责执行。其中 codex-with-chatgpt 只给 ChatGPT 9 个只读工具，安全边界最清晰，但写代码和跑测试仍由 Codex 完成，不节省额度；Mac Developer Bridge 权限最大，覆盖整个 macOS 用户，可操控已登录的 Chrome 和桌面应用，风险也最高。作者最终选择 WebCodex，并给出创建 Tunnel、Runtime API Key 以及在 ChatGPT 插件页创建自定义 MCP App 的完整配置步骤。
为什么重要
这件事的关键不在于“无限 token”本身，而在于 OpenAI 已经通过 Secure MCP Tunnel 把本地工具接入云端模型做成了一条官方支持的通道。这意味着大模型的竞争重点正在从单纯的推理能力，转向 Agent 与本地环境、企业内网、私有工具的连接方式。对闭源厂商来说，MCP 这类开放协议成了模型能力的延伸层；对开发者来说，官方通道的存在降低了自建反向代理的必要性。但目前公开信息显示，OpenAI 并未对“Chat 模式接入 MCP 是否计入额度”作出明确表态，这本身就说明计费边界仍不清晰。
对用户/开发者/创作者的影响
开发者是主要受众。如果你已经在用 Codex 或 Work 模式，这套方案的实际收益是：把规划、检索、Review 这类轻量操作交给网页版 ChatGPT，把真正烧额度的写文件和跑测试留给自己可控的执行端。但代价同样明显——本地权限越大，提示词注入、路径逃逸、误删文件的风险越高。Mac Developer Bridge 没有路径白名单、命令白名单和沙箱，等于把整台机器的用户级权限交出去。对普通创作者和企业用户来说，更现实的做法是观望：企业采购时应该把 MCP Tunnel 的权限范围、审计日志和账号隔离纳入评估，而不是只盯着额度。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是 OpenAI 是否会在计费规则中明确 Chat 模式与 MCP 调用的额度归属，这直接决定这条路径能走多久。二是 WebCodex、DevSpace 等第三方方案的迭代速度，尤其是权限控制与沙箱能力是否补齐。三是 Secure MCP Tunnel 是否扩展到更多套餐类型，以及官方对账号风险的态度是否会从文档默许转向明确限制。
来源：juejin
