Codex 终于能看懂浏览器现场了：Browser Developer Mode 最新上手指南

为Chrome和Codex内置浏览器引l入开发者模式。
Codex可以使用ChromeDevTools协议（CDP）来调试浏览器问题，通过分析JavaScript性能、检查控制台输出、网络流量和页面状态。

Codex现在能直接调用chromeDevTools调试浏览器问题，做前端和全栈的同行可以试试，省得在应用和调试工具之间来回切。

以前让 Codex 修前端问题，最尴尬的一幕是：你明明看到了页面卡顿、接口 500、按钮点了没反应，但 Codex 只能靠你描述。

现在这个情况变了。

OpenAI 给 Chrome 和 Codex 内置浏览器加了 Developer mode，核心能力是让 Codex 通过 Chrome DevTools Protocol，也就是 CDP，去看浏览器现场：Console、Network、DOM、样式、JavaScript 性能都能查。

这不是“又多了一个开关”这么简单。对前端开发来说，这意味着 Codex 从“听你描述 bug”，开始变成“能进案发现场看证据”。

这个功能到底解决了什么

以前我们让 Codex 修页面，常见流程是这样：

你截图 -> 你描述问题 -> Codex 猜原因 -> 改代码 -> 你再跑一次

这个链路最大的问题是信息损耗太大。

比如一个页面白屏，原因可能是：

  • JS 运行时报错
  • 某个接口 401/500
  • CSS 把内容挤出屏幕
  • hydration 不一致
  • 首屏 JS 太重
  • DOM 里有元素，但样式让它不可见

这些东西只靠截图很难判断。你说“页面白了”，Codex 只能猜。

有了 Developer mode 后，链路变成：

Codex 打开页面 -> 读 Console -> 看 Network -> 查 DOM/Styles -> 需要时抓性能 trace -> 再改代码

这就是质变。

先别急着找开关：它不是所有版本都有

官方文档里写的入口是：

Settings > Browser > Developer mode > Enable full CDP access

但这里有个坑：如果你当前客户端里没看到这个入口，不一定是你找错了。

我建议按这个顺序排查：

1. 确认 Codex app 已更新到 26.609 或更新版本
2. 确认 Settings 里能看到 Browser 相关配置
3. 确认 Browser 插件 / 内置浏览器能力已启用
4. 如果是 Business / Enterprise / Edu workspace，确认组织策略没有禁用 full CDP access
5. 如果仍然没有，说明该功能可能还没有推送到你的账号或当前平台

OpenAI 在 2026-06-11 的 Codex app 26.609 更新里加入了这个能力。也就是说，如果你的 Codex 版本比较旧，只看文档去找这个开关，很可能会白找。

打开后，Codex 可以在你授权的前提下使用完整 CDP 能力。这里有个重点：它不是默认全开。官方文档也明确说，完整 CDP 访问会涉及敏感浏览器内部状态，所以 Codex 在使用前会请求明确授权。

如果你在公司 workspace 里看不到这个开关，也可能是组织策略禁用了。OpenAI 帮助中心里提到，管理员可以通过策略把 browser_use_full_cdp_access 关掉。

在这里插入图片描述

如果你的界面没有这个开关，建议截图这里放“当前 Browser 设置页”，文章里直接说明：当前账号/版本暂无该入口。

@Browser 和 @Chrome 怎么选

这两个别混。

@Browser 用的是 Codex 内置浏览器。适合：

  • 打开本地开发服务
  • 检查未登录页面
  • 做前端视觉验收
  • 看 Console / Network / DOM
  • 让 Codex 一边观察页面一边改代码

@Chrome 用的是你的 Chrome，需要先装 Codex Chrome extension。适合：

  • 需要真实登录态
  • 需要浏览器插件
  • 需要复现你日常 Chrome 里的问题
  • 需要在真实业务系统里排查

我自己的判断是：本地开发优先 @Browser，登录态问题再上 @Chrome。别一上来就把真实 Chrome 丢给 Agent，权限边界要想清楚。

最好用的 4 个场景

1. 查 Console，比你复制错误快多了

以前页面报错，你要复制一堆红字给 Codex。现在可以直接说：

Use @Browser to open http://localhost:5173, inspect console errors, and fix the root cause.

Codex 可以直接看 Console 输出，定位是哪一行、哪个模块、哪个运行时错误。

这种场景非常适合处理：

  • undefined is not a function
  • React render error
  • hydration mismatch
  • 第三方包加载失败
  • sourcemap 能定位到源码的运行时报错
2. 查 Network，接口问题终于不用靠猜

前端页面“不显示数据”，有一半概率不是组件问题，而是接口问题。

以前 Codex 不看 Network 时，经常会顺着组件层一路改。现在可以让它先看请求：

Use @Browser to inspect network traffic on the dashboard page. Check failed requests, response status, payload shape, and whether the frontend parser matches the API response.

我建议你让 Codex 重点看这几项：

  • 请求是否真的发出
  • 状态码是不是 401 / 403 / 404 / 500
  • response body 和前端期望字段是否一致
  • 是否被 CORS 拦住
  • 是否有重复请求或请求风暴

这对管理后台、报表页、列表页特别有用。

3. 查 DOM 和样式，别再只看截图猜 CSS

页面上“看不到”不代表 DOM 里“没有”。

很多 CSS 问题都是这类：

  • 元素存在，但 display: none
  • 宽度被父容器压没
  • z-index 被盖住
  • position: fixed 跑偏
  • 移动端断点样式覆盖了桌面端

现在可以直接让 Codex 查 DOM 和 applied styles：

Use @Browser to inspect the DOM and applied styles for the submit button. Find why it is visible in the DOM but not clickable on mobile.

这类问题以前靠肉眼和截图来回沟通，很烦。CDP 直接把证据摊开。

4. 抓性能 trace，慢在哪里终于能说清楚

页面慢，最怕一句“优化一下性能”。

Codex 有 CDP 访问后，可以抓 JavaScript 性能、网络耗时、页面状态。你可以这样提：

Use @Browser to capture a performance trace for the product list page, then identify whether the bottleneck is JavaScript execution, rendering, or network.

我建议不要让它一上来大改。先让它给结论：

Do not edit files yet. First report the top 3 bottlenecks with evidence from the trace.

等证据清楚了，再让它改代码。

我建议你这样提 Prompt

这类能力最怕一句话说太虚。

别说：

帮我看看这个页面为什么有问题。

换成：

Use @Browser to open http://localhost:5173/orders.
Inspect console output, network requests, and DOM state.
The expected state is: order list should render 10 rows.
Find the root cause first, then make the smallest code change.

这几个信息很关键：

  • 页面地址
  • 期望状态
  • 要看的证据
  • 是否允许直接改代码
  • 修改范围

如果是 Chrome：

Use @Chrome to inspect the current tab.
Check console errors and failed network requests.
Do not click destructive buttons.
Report findings before editing files.

真实登录态里尤其要加最后两句。

注意权限：CDP 很强，也很敏感

CDP 不是普通截图权限。

它能看到很多浏览器内部信息，比如页面状态、请求、响应、脚本执行、DOM、样式。官方也提醒，完整 CDP 访问可能带来数据风险，所以需要你批准。

我的建议很简单：

  • 本地开发页大胆用
  • 测试环境谨慎用
  • 生产后台先限定任务范围
  • 涉及隐私数据的页面，不要让 Agent 到处点

尤其是 @Chrome，它可能接触你的真实登录态。用之前先想清楚：这个页面能不能给 Agent 看，能看到哪些数据，能不能误点危险操作。

和普通 Browser use 有什么区别

普通 Browser use 更像“我能看见页面，也能点点点”。

Developer mode 更像“我能打开 DevTools 看证据”。

区别大概是这样：

能力 普通 Browser use Developer mode
看页面截图 可以 可以
点击、输入 可以 可以
看 Console 不完整 可以
看 Network 不完整 可以
查 DOM / Styles 有限 更深入
性能分析 基本不行 可以
风险等级 较低 更高，需要授权

所以我不会把 Developer mode 当成默认开关，而是把它当成“需要证据时再开”的调试工具。

一个完整的排障模板

如果你要排查前端页面问题，可以直接套这个：

Use @Browser to debug http://localhost:5173/dashboard.

Expected:
- The dashboard should show summary cards and a table.
- The table should load data from /api/dashboard/items.

Please:
1. Inspect console output.
2. Inspect failed or slow network requests.
3. Inspect DOM and applied styles if elements are missing.
4. Report the root cause with evidence.
5. Then make the smallest code change.

如果你只想让它先看，不想让它动代码：

Do not edit files yet. Only inspect and report findings.

这句话非常有用。

我对这个功能的判断

我觉得 Browser Developer mode 是 Codex 前端能力里非常关键的一步。

不是因为它“更智能”，而是因为它让 Agent 多了一双真正能看浏览器现场的眼睛。前端问题很多时候不缺推理，缺的是证据。Console、Network、DOM、Performance 这些信息一拿到，很多 bug 根本不用猜。

但它也不是万能药。

你还是要给清楚的页面地址、期望状态、操作边界。你让 Codex “随便看看”，它就真的只能随便看。你让它“检查这个接口为什么 500、这个 DOM 为什么不可点击、这个页面为什么 JS 执行超过 2 秒”，它才会像一个靠谱的调试助手。

参考资料

# 前端 # web安全
Logo
智能体开发者社区

中国智能体开发者社区，聚焦智能体与大模型开发，提供前沿资讯、实用工具链、开源项目及行业案例。通过技术沙龙、开发者大赛等活动，促进经验交流与协作，助力开发者快速构建创新智能应用。

更多推荐

cover

MAX API v1.0.4-preview.1 预览版：Seedance 2.0 计费与任务协议优化、Responses 兼容增强及多节点用量归因修复

avatar 智能体开发者社区
cover

agent面试必备33-AI Agent 核心进阶：工具编排（Tool Orchestration）

avatar 智能体开发者社区
cover

一人公司必看：Agent 不是升级版 ChatGPT，是你的临时同事

avatar 智能体开发者社区