这两天我把 ChatGPT 网页端接到了本机工作区。准确说，不是让 ChatGPT 变成 Codex 本体，而是通过 MCP 把一部分本地能力暴露给 ChatGPT：读目录、看文件、运行命令、在允许范围内修改项目。最后的状态有点像“第二个 Codex”：它仍然运行在网页里，但已经能碰到我本机的项目目录。

这个实验很有意思，因为它把几个原本分散的东西串起来了：ChatGPT 的连接器、DevSpace 的 MCP Server、Cloudflare Tunnel 的公网入口、本地 allowed roots、以及一个明确的 Owner password 授权页面。它不复杂，但每一层都必须想清楚边界，否则就会从“方便”变成“把电脑裸露给工具”。

先说结论

我现在会把这种方案定位成“网页端的本地工作入口”，而不是 Codex 的完整替代品。

Codex 的优势仍然是本地开发代理体验更完整：它天然知道工作区、沙箱、命令权限、文件修改和长期上下文，也更适合连续处理一个代码任务。ChatGPT 网页端接 DevSpace 后，优势是入口更轻：不用切到专门的本地 Agent 界面，也能让网页端模型临时查看某个项目、读结构、解释代码，甚至做一些受控修改。

所以它最适合的场景不是“让 ChatGPT 完全接管电脑”，而是多一个可控的工作面：

  1. 在 ChatGPT 里快速查看某个本地仓库。
  2. 让它读取项目结构、README、配置和日志。
  3. 让它做小范围内容更新或文档修改。
  4. 把网页端已有对话上下文直接接到本地文件。
  5. 在明确授权的目录里执行有限命令。

这已经足够有用。

整体架构

这套链路可以拆成四层。

第一层是 ChatGPT 网页端。它负责发起 MCP 连接，并在对话里调用工具。

第二层是公网入口。我用的是 Cloudflare Tunnel，把一个固定子域名转发到本机的 DevSpace 服务。这样 ChatGPT 不需要知道我电脑的内网地址，也不需要我打开路由器端口。

第三层是 DevSpace。它在本机启动 MCP Server，接收 ChatGPT 的工具调用，并把文件、shell、workspace 这些能力包装成 MCP 工具。

第四层是本机 allowed roots。也就是我明确允许它进入的目录。这个边界非常重要：不要为了省事直接暴露整个磁盘，应该只暴露正在做 AI 工作流的项目目录。

最后 ChatGPT 看到的是一个 MCP 地址。它连接时会跳到 DevSpace 的授权页面，输入 Owner password 后才会拿到访问 token。这个密码不是 ChatGPT 密码，也不是 Cloudflare 密码，只是 DevSpace 本地授权用的一把门钥匙。

为什么要用 Cloudflare Tunnel

本地服务默认只在 127.0.0.1 上监听。ChatGPT 网页端在云端访问不到这个地址，所以中间需要一个 HTTPS 入口。

临时 tunnel 可以先跑通实验，但地址每次都会变。长期使用就应该做命名 tunnel，再绑定到自己的子域名。这样 ChatGPT 连接器里填的地址不需要反复改，桌面启动脚本也可以固定下来。

Cloudflare Tunnel 的好处是它是出站连接。我的电脑主动连到 Cloudflare，外部请求再经由这个 tunnel 回到本机服务。这样不需要开放家庭网络入站端口，DNS 也可以由 Cloudflare 直接管理。

我最后选择了一个专门的子域名，只服务 DevSpace，不碰博客主站。主站继续是个人博客，子域名只做 MCP 入口。这个隔离很重要：博客是公开内容，DevSpace 是本地工具入口，两者不应该混在一个路由里。

allowed roots 是真正的权限边界

DevSpace 最关键的配置不是域名，而是 allowed roots。

如果只允许三个工作目录，ChatGPT 就应该只在这三个目录里打开 workspace、读写文件和执行命令。它可能会尝试打开默认路径，比如一个空的工作区目录；这不代表它访问失败，只是它还没有被指向真正的项目。

比较稳的用法是，在 ChatGPT 里直接说清楚：

通过 DevSpace 打开某个已授权项目目录，先只读列出顶层结构，不要修改文件。

如果确认它确实读到了正确目录，再继续让它读 README、项目上下文文档、配置文件和入口代码。不要一上来就说“帮我改一下”，因为网页端对本地项目的理解仍然要先建立。

Owner password 是最后一道人工确认

DevSpace 授权页会显示 Client、Scope 和 Resource。这里要确认三件事：

  1. Client 确实是自己正在连接的 ChatGPT。
  2. Scope 是预期的 DevSpace 权限。
  3. Resource 是自己配置的 MCP 地址。

确认后才输入 Owner password。这个密码应该只在自己主动连接时使用，不要发到聊天窗口里，也不要贴到文章、截图或日志里。

我觉得这个授权页的存在很好。它提醒人：这不是普通网页登录，而是在批准一个外部客户端访问本机工具。每次看到这个页面，都应该停一下，看清楚 Resource。

和 Codex 的差异

把 ChatGPT 接到 DevSpace 后，它确实能做很多像 Codex 的事情，但边界不一样。

Codex 更像一个默认以代码任务为中心的本地代理。它有更明确的工作区、命令执行、文件编辑、验证和长任务协作流程。

ChatGPT 网页端更像一个通用对话界面。接上 MCP 后，它获得了工具，但它不一定天然知道你的 repo 习惯、沙箱边界和验证步骤。你需要在 prompt 里更清楚地说：

  • 先只读。
  • 先列目录。
  • 先读项目上下文。
  • 不要删除。
  • 不要改密钥。
  • 修改后跑构建或测试。
  • 做完列出改动文件。

换句话说，Codex 更像“工程默认项已经调好”的工作台；ChatGPT + DevSpace 更像“给通用模型插上本地工具”。后者能用，但需要人给更清楚的护栏。

我会采用的使用规则

为了长期使用，我会给自己定几条规则。

第一，默认先只读。任何新会话先让它列目录、读项目文档、解释现状，不直接改。

第二，每次只打开一个具体项目。不要让它在多个目录之间来回跳，除非任务本身需要跨项目。

第三，涉及删除、批量移动、清理缓存、改配置、改 token，一律要求它先列计划和候选文件。

第四，不把 Owner password、Cloudflare tunnel 凭据、API key 写进对话或文章。

第五，能构建就构建，能测试就测试。网页端能读写本地文件不等于修改一定正确，最后还是要回到真实命令输出。

第六，长期运行时要准备停止脚本。需要时一键停掉 DevSpace 和 tunnel，比事后再找进程靠谱。

这套东西真正有价值的地方

我最喜欢的不是“ChatGPT 能访问本地”这个噱头，而是它让工作入口变多了。

有些问题我会自然地在 ChatGPT 网页端问，比如方案比较、写作整理、长文本改写、产品想法、工作流复盘。以前问完之后，如果需要落地到本地项目，还要把内容复制回 Codex 或编辑器。现在可以直接让它打开博客仓库，把文章导入、构建、提交这一串接起来。

反过来，Codex 仍然适合更严肃的代码任务：多文件修改、测试修复、长时间调试、需要持续观察命令输出的工作。两个入口不是互相替代，而是分工。

对我来说，“第二 Codex”这个说法的重点不是复制 Codex，而是多一个能进入本机项目的 AI 操作面。网页端保留它擅长的长对话和知识组织，本机侧通过 MCP 提供真实文件和命令。中间用 tunnel 和 allowed roots 做边界。

最后要记住的风险

这套方案有一个很朴素的事实：一旦授权成功，ChatGPT 就不只是聊天框了，它变成了一个可以调用本机工具的客户端。

所以不要把它当玩具。不要把全盘暴露出去，不要在不理解工具调用的情况下批准连接，不要让它执行含糊的大范围命令。真正安全的做法不是“相信模型不会犯错”，而是把它能碰到的范围缩小，把每一步验证做实。

如果把边界管住，它就很有用。ChatGPT 网页端可以成为第二个本地工作入口：没有 Codex 那么工程化，但足够灵活；没有本机 Agent 那么强绑定，但能把网页对话直接连到项目里。

这也是我现在越来越喜欢的 AI 工作流方向：不是追求一个工具包打天下，而是让不同入口都能接到同一批本地项目，并且每个入口都有清楚的权限和验证方式。