chatgpt网页版也可以调教成像codex一样在本地使用了，读代码，写代码，无所不能，具体方法在后面，但是这次我这次不是照着教程顺了一遍。
真实过程是：DevSpace 装好了， devspace init 也跑起来了，但卡在公网 URL；Cloudflare Tunnel 没跑稳；Pinggy 能跑通，但免费版 60 分钟就过期；最后换成 ngrok 才真正稳定下来。
更关键的是，后来还踩了两个很容易误判的坑：
一个是 DevSpace 指向了空目录，ChatGPT 能连上，但看不到真正的项目。
另一个是重连时出现：
invalid_clientInvalid client_id
看起来像工具坏了，其实是旧的 ChatGPT 应用连接信息失效了，需要删掉旧应用重新创建。
所以这篇不是“官方教程复读”，而是把我这次真实配置 DevSpace MCP 的过程复盘一下。
先说结论
最后我跑通的方案是：
DevSpace本地服务-> ngrok 公网 HTTPS 隧道->ChatGPT网页端自定义 MCP 应用->读取/修改本地授权目录里的项目文件
最终效果是，ChatGPT 网页端可以通过 DevSpace 访问本机项目目录，并且在授权后写入了项目文档。
这不是破解工具，也不是绕过官方限制。
它本质上是 MCP：让 ChatGPT 通过一个你本地运行的 MCP Server，访问你明确授权的本地开发环境。
你可以把它理解成：
给 ChatGPT 网页版接上一只本地开发环境的手。
但这只手能不能写文件、能不能执行命令、能不能完整使用工具，跟你的 ChatGPT 账号能力、应用权限、MCP 服务实现都有关系。不要默认所有账号、所有场景都一样。
这次用到的东西
我这次环境是：
macOSNode.js 22npm 10DevSpacengrokChatGPT网页端自定义 MCP 应用
安装过程：先把本地环境准备好
如果你已经有 Node，可以先检查版本：
node -vnpm -v
我这次本机是：
node v22.xnpm 10.x
如果你还没有 Node，可以用 Volta 安装。macOS / Linux 可以执行：
curl https://get.volta.sh | bash
安装完成后，重新打开一个终端。
如果没有生效，可以手动刷新 shell 配置。
zsh 用户执行：
source ~/.zshrc
bash 用户执行：
source ~/.bashrc
然后检查 Volta：
volta -v
安装 Node 22：
volta install node@22
再确认 Node 和 npm：
node -vnpm -v
接着安装 DevSpace：
npm install -g @waishnav/devspace
安装完可以检查命令是否存在：
which devspacedevspace --help
然后初始化 DevSpace：
devspace init
初始化时会让你填写：
允许访问的本地项目目录本地端口公网base URL
本地端口建议先用默认的：
7676
项目目录建议先填一个具体项目目录，不要一上来开放整个电脑。
比如：
/Users/xxx/project
如果你还没有公网 URL，可以先停在这一步，等下面 ngrok 配好后再回来填。
如果你已经初始化过 DevSpace，后面想重新更新配置，可以执行：
devspace init --force
如果只是更新公网地址，不想重新走完整初始化，也可以用：
devspace config set publicBaseUrl https://xxxx.ngrok-free.dev
ngrok 也需要提前安装。
如果你用 Homebrew，可以执行：
brew install ngrok/ngrok/ngrok
也可以直接按 ngrok 官网后台给你的 macOS 安装命令执行。
安装后检查版本：
ngrok version
登录 ngrok 后台复制 authtoken，然后写入本机配置：
ngrok config add-authtoken <你的-ngrok-token>
检查 ngrok 配置是否正常：
ngrok config check
第一个卡点：DevSpace 需要公网 HTTPS 地址
DevSpace 初始化时会问几个问题：
Where are your projects located?Whichlocal port should DevSpaceuse?Whatis the publicbase URL?
前两个好理解：
项目目录就是你允许 ChatGPT 访问的本地目录。
端口默认用 7676 就行。
真正卡人的，是第三个：
publicbase URL
因为 ChatGPT 网页端在云端，它不能直接访问你本机的：
http://127.0.0.1:7676
所以你必须给本地 DevSpace 服务套一层公网 HTTPS 地址。
注意，这里 DevSpace init 里填的是 base URL，不要带 /mcp。
也就是说：
DevSpace init 里填：https://你的公网域名ChatGPT创建 MCP 应用时填：https://你的公网域名/mcp
我先试了 Cloudflare Tunnel，但没跑稳
一开始我按常见思路走 Cloudflare Tunnel。
本地服务目标是：
http://127.0.0.1:7676
理论上用 Cloudflare quick tunnel 暴露出来就可以。
但我这里实际遇到的问题是：公网访问经常失败，页面返回类似 530/1033 的错误。
继续查日志，发现本机到 Cloudflare tunnel edge 的发现过程不稳定，DNS / SRV 查询会超时，网络路由还走到了 VPN 相关的 utun 接口。
说人话就是：
不是 DevSpace 没启动，也不是 ChatGPT 配错了，而是 Cloudflare Tunnel 这条公网通道本身在我当前网络环境下不稳定。
所以我没有继续硬修 Cloudflare。
Pinggy 可以先跑通，但免费版有时间限制
后来我切到 Pinggy，先验证链路能不能跑通。
类似命令是：
ssh -p 443-R0:127.0.0.1:7676 qr@free.pinggy.io
Pinggy 很快能给出一个公网 HTTPS 地址。
我访问 /mcp 时返回：
401MissingAuthorization header
这个反而是好消息。
因为它说明公网已经能访问到 DevSpace，只是还没带认证信息。
但 Pinggy 免费 tunnel 有 60 分钟限制，适合临时验证，不适合长期使用。
所以最后我换成了 ngrok。
最后换成 ngrok，稳定跑通
ngrok 的流程比较直接。
先安装 ngrok，然后登录 ngrok 后台拿 authtoken。
配置 token：
ngrok config add-authtoken <你的-ngrok-token>
检查配置：
ngrok config check
启动 tunnel：
ngrok http 7676
它会给你一个公网 HTTPS 地址，类似：
https://xxxx.ngrok-free.dev
然后把 DevSpace 的 public base URL 更新成这个地址。
如果 DevSpace 已经初始化过，直接执行：
devspace config set publicBaseUrl https://xxxx.ngrok-free.dev
也可以用环境变量临时启动，不写入配置：
DEVSPACE_PUBLIC_BASE_URL=https://xxxx.ngrok-free.dev devspace serve
我这里的关键点是：
DevSpacepublicbase URL 不带/mcpChatGPT里填写的服务器 URL 要带/mcp
也就是：
DevSpace：https://xxxx.ngrok-free.devChatGPT MCP：https://xxxx.ngrok-free.dev/mcp
然后启动 DevSpace：
devspace serve
正常情况下会看到类似输出：
devspace listening on http://127.0.0.1:7676/mcppublicbase url: https://xxxx.ngrok-free.devauth:Owner password approval required
在 ChatGPT 里创建 MCP 应用
到 ChatGPT 设置里，打开开发者相关能力，然后创建新应用。
名称可以写：
DevSpace
服务器 URL 填：
https://xxxx.ngrok-free.dev/mcp
身份验证选择 OAuth。
创建时如果页面提示“自定义 MCP 服务器会引入风险”，这个是正常提醒。
因为你相当于允许 ChatGPT 连接一个你自己提供的工具服务，所以一定要确认这个服务就是你自己本机运行的 DevSpace。
登录密钥在哪里看
DevSpace 会要求 Owner password approval。
本地可以用这个命令查看：
cat ~/.devspace/auth.json
把里面的 owner password 填到 ChatGPT 的验证页面里。
这里有个安全提醒：
不要把这个密钥发给别人。
也不要把它写进文章、截图、仓库、笔记同步工具里。
它相当于你的 DevSpace 管理口令。
第二个大坑：DevSpace 连接上了，但项目目录是空的
我一开始以为“ChatGPT 连上 DevSpace 就等于能打开项目”。
后来发现不是。
DevSpace 只能访问你配置里允许的目录。
我最开始配置的是：
/Users/xxx/workspace/DevSpace
但这个目录本身是空目录。
所以 ChatGPT 能连上 DevSpace，却只能看到一个空目录。
真正要打开的是我的小程序项目：
/Users/xxx/project
为了方便，我最后把 DevSpace 的 allowed root 调整到了：
/Users/xxx
这样 ChatGPT 可以访问我的用户目录下多个项目。
但这里我要强调：
普通用户不建议直接照抄开放整个 /Users/xxx。
更稳妥的做法是只开放具体项目目录，例如：
/Users/xxx/project
或者最多开放一个项目工作区：
/Users/xxx/workspace
权限越大，风险越大。
DevSpace 很方便，但它不是玩具。
invalid_client 是怎么回事
中间我还遇到过这个错误：
{"error":"invalid_client","error_description":"Invalid client_id"}
这个错误很容易让人误以为是 ngrok 坏了，或者 DevSpace 坏了。
但这次真正原因是：
ChatGPT 里旧的 MCP 应用还拿着之前的 client_id。
DevSpace 重启、重新初始化、配置变化后，旧 client_id 可能已经失效。
解决办法不是一直点“重新连接”。
更直接的办法是：
- 删除 ChatGPT 里旧的 DevSpace 应用
- 重新创建一个新的 DevSpace MCP 应用
- 重新填写
https://xxxx.ngrok-free.dev/mcp - 重新输入 DevSpace owner password
这样就能重新走一遍 OAuth 注册流程。
工具授权不要乱点“始终允许”
ChatGPT 调用 DevSpace 工具时，会出现工具授权确认。
比如写文件、执行命令、修改项目文档。
我这次测试时，ChatGPT 成功写入了项目里的文档：
/Users/xxx/project/docs/home-first-dinner-flow-optimization-plan.md
但这里不建议一上来就点“始终允许”。
更好的做法是：
先点“允许一次”，观察它要做什么。
确认工具调用范围、文件路径、动作描述都合理之后，再决定是否给更宽的权限。
尤其是当它要执行 shell 命令、写入配置文件、改项目代码时，一定要看清楚。
最后验证：ChatGPT 已经能写入本地项目
最后我让 ChatGPT 通过 DevSpace 写了一份代码优化文档。
它写入到了真实项目目录：
/Users/xxx/project/docs/home-first-dinner-flow-optimization-plan.md
验证结果显示文件确实存在，并且有内容：
docs/home-first-dinner-flow-optimization-plan.md275 docs/home-first-dinner-flow-optimization-plan.md
这里也纠正我自己的一个误判：
我一开始以为当前环境可能只能读，不能写。
但从这次真实结果看，至少在我的这次配置里，ChatGPT 确实通过 DevSpace 写进了本地项目目录。
所以正确说法应该是：
不同账号、不同 MCP 权限、不同应用形态下能力可能不同，不能一概而论。最终以你自己实际界面和工具调用结果为准。
我建议你按这个顺序排查
如果你也配置 DevSpace，建议按这个顺序判断问题：
第一步，看 DevSpace 本地是否启动：
devspace serve
本地应该能看到：
http://127.0.0.1:7676/mcp
第二步，看公网 tunnel 是否打通：
curl -i https://xxxx.ngrok-free.dev/mcp
如果返回 401MissingAuthorizationheader，说明公网已经能打到 DevSpace。
第三步，看 ChatGPT 里 URL 有没有写错：
正确：https://xxxx.ngrok-free.dev/mcp错误：https://xxxx.ngrok-free.dev
第四步，看 DevSpace public base URL 有没有带 /mcp。
这里反过来：
DevSpacepublicbase URL 不要带/mcpChatGPT服务器 URL 要带/mcp
第五步，看 allowed root 是不是指向空目录。
如果 ChatGPT 能连接，但看不到项目，大概率不是 MCP 坏了，而是目录配错了。
第六步，如果出现 invalid_client，删掉 ChatGPT 里的旧应用，重新创建。
不要在旧应用上反复重连。
这套方案适合谁
我觉得 DevSpace 适合这几类场景：
- 你平时主要用 ChatGPT 网页端做规划、审稿、拆任务
- 你希望 ChatGPT 能直接读取本地项目上下文
- 你想让 ChatGPT 帮你写文档、看代码、跑命令、查 diff
- 你能接受自己管理本地权限和公网 tunnel 风险
但它不适合完全不懂本地命令行的人直接无脑使用。
因为一旦你开放了目录、允许了写入、允许了命令执行，它就不只是聊天工具了。
它真的可以影响你的本地文件。
几个必须注意的点
第一，不要开放根目录 /。
第二，不要把 owner password、ngrok token、完整 tunnel 地址公开发出去。
第三，截图发布前要打码。
第四，建议先开放单个项目目录，不要一上来开放整个用户目录。
第五，工具授权先用“允许一次”，不要一开始就全局“始终允许”。
第六，ngrok 免费域名可能会变化，变了以后要同步更新 DevSpace 和 ChatGPT 应用。
第七，Cloudflare Tunnel、Pinggy、ngrok 都只是公网通道，MCP 真正的服务仍然是你本机的 DevSpace。
总结
这次配置下来，我最大的感受是：
DevSpace 不是让 ChatGPT 变成另一个 Codex。
它更像是把 ChatGPT 网页端和你的本地开发环境接起来。
ChatGPT 负责理解、规划、调用工具；DevSpace 负责把本地文件、命令、项目上下文暴露出来；ngrok 负责让网页端能访问到你本机。
真正麻烦的地方，不在安装 DevSpace。
而在这几个细节：
公网 URL 怎么稳定DevSpacebase URL 和 MCP URL 怎么区分allowed root 有没有配到真实项目OAuth client 失效后怎么重建工具写入权限要不要允许
如果你只是照着教程复制命令，很容易卡在某一步。
但只要把这几个点想清楚，DevSpace 这套方案还是挺实用的。
我的最终建议是：
先用 ngrok 跑通。
先开放一个具体项目。
先只允许单次工具调用。
确认它真的能读、能写、能按你的预期工作之后，再考虑扩大使用范围，这样更稳。
