小白爱摸鱼
@chaozuoye
ChatGPT网页版额度用不完，Codex跑几个重任务却开始心疼usage。于是一个很自然的想法出现了：给ChatGPT接一个能读文件、改代码、跑Shell的本地MCP，它不就能直接干Codex的活了吗？
基于这个思路，从X、L站、GitHub等渠道整理了四种通过ChatGPT web端通过MCP接入本地工作环境的方式。
- WebCodex
它的架构最完整：ChatGPT通过MCP连接Server，Runner在本地负责读写文件、Git、测试、Shell和长任务。它能长期连接多个项目、设备和Runner，还带任务状态、运行记录、人工引导、文件传输和Computer Use。普通用户可以装Desktop，再通过OpenAI Secure Tunnel连接ChatGPT。
这套东西的目标很明确：让网页里的ChatGPT直接成为Coding Agent。
WebCodex的代价是复杂。Server、Runner、项目注册、Tunnel、token和scope都得正常才行。它的结构化文件工具会检查项目边界，但run_shell最终还是以Runner所在的系统用户执行。开放Shell，就要按AI拿到了这个用户的命令执行权来评估。
- 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用户级权限。
选择建议：
想让ChatGPT长期直接写本地项目：WebCodex。
喜欢精简工具面，愿意自己维护Tunnel：DevSpace。
代码敏感，希望ChatGPT只负责规划与复查：codex-with-chatgpt。
希望ChatGPT控制整台Mac，并清楚用户级权限的后果：Mac Developer Bridge。
项目地址：
WebCodex：github.com/yyjeqhc/webcod…
DevSpace：github.com/Waishnav/devsp…
codex-with-chatgpt：github.com/XiaoDuoYa/code…
Mac Developer Bridge：github.com/alexanderradah…
