Codex 终于能像前端工程师一样调试浏览器了

今天学到一个很实用的小开关。

现在 Codex 里可以开启内置浏览器的完整 CDP 访问权限，位置在：

设置 -> 浏览器 -> 最下面的完整 CDP 权限。

这个功能一开，Codex 调试前端应用的能力会明显变强。

以前 AI 调试浏览器有多别扭

以前我们让 AI 看网页，很多时候其实挺别扭。它能看到截图，能帮你点按钮，也能根据页面表现猜问题，但它看到的东西非常有限。

比如页面白屏了，它只能猜是路由问题、接口问题、构建问题，还是某个组件挂了。

按钮点了没反应，它也只能根据现象判断，是事件没绑定，还是接口没返回，或者前端状态没有更新。

页面很卡，它更难判断，到底是组件重复渲染、接口阻塞、资源太大，还是某段 JS 执行太久。

说白了，之前 AI 调试浏览器，更像是隔着屏幕看病。

CDP 到底意味着什么

CDP 本质上就是 Chrome DevTools Protocol，也就是 Chrome DevTools 背后那套能力。你平时打开浏览器开发者工具，看 Console、Network、Elements、Performance，其实都离不开这套东西。

当 Codex 拿到完整 CDP 权限以后，它就不只是"看页面"了，而是能进入浏览器内部看问题。

• Console 里有没有报错，它能看
• Network 里哪个请求失败了，它能看
• 接口返回的是 401、403、500，还是 CORS，它能看
• DOM 最后渲染成什么样，CSS 到底是哪条规则生效，它也能看
• 页面卡顿时，还可以进一步看 Performance，判断是不是某段脚本、某个渲染流程或者某个资源加载拖慢了页面

这对前端调试来说，价值非常大。

很多前端问题，表象差不多，根因完全不同

同样是白屏，可能是 JS 报错，也可能是接口失败，也可能是环境变量没配，也可能是某个依赖在浏览器里不兼容。

同样是按钮没反应，可能是点击事件没触发，也可能是请求发出去了但被拦截，也可能是状态更新了但页面没重新渲染。

如果只能看截图，AI 很容易靠猜。但如果它能看 Console、Network、DOM、Performance，判断就会准确很多。

最适合开的场景

这个开关最适合用在调试本地项目、测试环境、前端页面异常、接口联调、性能问题这些场景。

比如你在开发一个 Next.js、Nuxt、React、Vue 项目，页面跑起来以后发现有问题。以前你要把报错复制给 AI，再截图，再描述点了什么按钮。现在如果 Codex 能直接进入浏览器调试，它就能自己看日志、看请求、看页面状态，整个排查链路会顺很多。

开之前要注意安全

不过完整 CDP 权限是一个很高的浏览器权限。它能看到页面、请求、控制台、运行状态，甚至可能接触到一些你当前浏览器环境里的敏感信息。

所以我更建议把它当成"开发调试模式"，而不是日常默认开启。

最好单独开一个浏览器环境，专门用来调试项目。不要直接拿自己平时登录各种账号的主力浏览器来跑。尤其是涉及后台管理、支付、用户数据、生产环境的页面，更要谨慎一点。

这件事不一定非 Codex 才能做

还有一个有意思的点是，这件事并不一定非 Codex 才能做。

CDP 本来就是开放的协议。现在已经有一些开源方案，也在往这个方向走。比如 Chrome DevTools MCP、Playwright MCP、Puppeteer、Playwright 的 CDP 接口，本质上都可以让 AI Agent 更深入地操作和理解浏览器。

所以真正重要的不是 Codex 多了一个按钮。

真正变化的是什么

真正重要的是，AI 调试前端的方式正在变。

过去是截图式调试：AI 看一眼页面，然后猜问题。

以后会更接近 DevTools 式调试：AI 不只是看见页面，而是能看见浏览器里到底发生了什么。

这对前端开发来说，可能是一个很关键的变化。因为前端项目最麻烦的地方，往往不是代码写不出来，而是问题出在浏览器、接口、状态、样式、构建、缓存、跨域、性能这些交叉地带。

人类工程师调试这些问题，靠的是 DevTools。那 AI 真想成为一个靠谱的前端工程助手，也迟早要学会用 DevTools。

Codex 这个完整 CDP 权限，算是往这个方向迈了一步。