Codex 接入能读取浏览器运行时信息的工具后，可以查看控制台和失败的网络请求。Chrome DevTools MCP 可以把 Chrome 实例交给这样的调试流程。先复现，再把控制台报错与请求对应起来，修改导致问题的代码，最后重新在浏览器验证。
一位 Codex 用户说，调试时反复把浏览器控制台的错误复制给工具。下文把这些观察交给浏览器工具直接采集。
本文用不需要账号的本地页面做演示。取数据的路径拼错了，页面文档返回 HTTP 200，API 却返回 HTTP 404。截图、控制台和网络响应分别告诉你用户看到了什么、脚本记录了什么、服务端回了什么。
要点
MCP 已登记只能确认配置，打开网页并取得快照才证明运行时能连接。
对照浏览器发出的实际路径和代码里的服务端路由。
修改前先留请求与页面状态。
修复后重复原流程，同时核对请求、日志和页面。
优先用隔离的本地浏览器，报告中去掉敏感数据。
调试要留哪些证据
| 信号 | 工具或界面 | 记录内容 |
|---|---|---|
| 当前页面 | 页面列表和快照 | URL、选定页面、可见症状 |
| 控制台 | list_console_messages、get_console_message | 相关报错、消息 ID 和可见源位置 |
| 网络 | list_network_requests、get_network_request | 方法、路径、状态、请求 ID 和安全响应摘要 |
| 页面结果 | take_screenshot 或快照 | 用户看到的错误或修复后的状态 |
| 代码 | Codex 项目视图 | fetch 路径与对应服务端路由 |
浏览器自动化 Agent能通过快照核对页面显示。调试还需要看造成症状的请求。快照能看到“Could not load preferences”，网络列表能指出失败的是哪条接口。网页自动化指南介绍了浏览器操作本身。
1. 把 Chrome DevTools MCP 接入 Codex
在 Codex CLI 中用官方命令格式登记 MCP。本例固定使用取证时的包版本，并启动隔离、无界面的 Chrome。同时关闭 MCP 使用统计与性能工具的真实用户数据查询。
codex mcp add chrome-devtools -- npx -y chrome-devtools-mcp@1.12.0 \
--headless --isolated --no-usage-statistics --no-performance-crux
codex mcp list配置后开启一个新 Codex 会话，让它列出页面并打开获准的本地地址。列表只证明登记成功，实际网页快照才证明服务能触达浏览器。查阅 OpenAI CLI 文档和 Chrome DevTools MCP 官方仓库。
ChatGPT 应用的内置浏览器在开发者模式下有独立的完整 CDP 开关，组织策略可能限制它。使用该入口时查阅 OpenAI 开发者设置。仅需读取或点击网页时，浏览器 Agent通常已经能完成。若工具和测试服务能互相访问，也可以考虑虚拟浏览器。
2. 复现失败请求
把练习源文件保存为 preferences-fixture.cjs，运行 node preferences-fixture.cjs。服务仅监听本机回环地址并打印 URL。打开该地址，附上 ?stage=before。页面请求一项示例主题设置，随后显示“Could not load preferences”。
让 Codex 报实际 URL、页面症状、对应控制台消息与请求详情。本文用本地 MCP 客户端实际调用 Chrome DevTools MCP 1.12.0；Codex CLI 的配置语法另行检查。实验结果来自浏览器证据。
打开本地练习地址的 ?stage=before 版本，等待偏好状态变化。
返回选定网页 URL、可见状态、相关控制台消息，以及失败 GET 的方法、路径和状态码。
根据请求 ID 查看详情，只在这个本地来源内操作。3. 对齐控制台与网络请求
网页文档返回 200。数据请求 GET /api/prefences 返回 404，响应写着 unknown route。控制台记录 [preferences] GET /api/prefences failed: HTTP 404。这些证据指向 fetch 路径的拼写。只有一条“加载资源失败”还无法定位是哪条请求。
先按请求方法和路径匹配，再用请求 ID 查详情。每次导航的 ID 可能变化。看到 CORS、超时、重定向或 401 时，先判断真实故障类型，别照搬这个拼写修复。
4. 改正路径并复核
练习的 ?stage=after 版本将接口改为 /api/preferences，共用同一服务与页面结构。真实项目应修改对应源文件，再在同一测试环境重放原操作。等待明确的界面状态，避免固定睡眠后猜测成功。
| 验收项 | 修复前 | 修复后 |
|---|---|---|
| 网页文档 | HTTP 200 | HTTP 200 |
| 数据请求 | GET /api/prefences，HTTP 404 | GET /api/preferences，HTTP 200 |
| 控制台 | 偏好请求失败 | 信息日志确认已加载 light 主题 |
| 页面实际显示 | Could not load preferences | Theme: light |
Network 变成 200 但页面仍不对时，继续排查返回字段和渲染逻辑。请工具核对哪个元素必须变化。浏览器 Agent 第一次任务清单提供了按可见状态验收的通用做法。
把调试限定在测试环境
连接已有 Chrome 配置可能暴露已登录页面和请求详情。隔离会话也能发送请求，因此要限定在获准的本地或测试站点。报告只留必要的控制台与请求信息，去掉 Cookie、凭证和私有响应。参见智能体浏览器安全指南。
另一位前端开发者希望检查手动测试使用的同一个浏览器会话。这和在干净会话复现本地故障是两个需求。
浏览网页、读取页面与执行普通任务时，可以用 Tabbit Browser。需要 DevTools 证据时，先核实使用的接入方式是否提供 Network 和 Console。Tabbit 与 Codex解释产品定位，Tabbit 浏览器解析介绍页面上下文和任务入口。
交付一条简短的修复记录即可。写清失败请求、实际改动，以及能证明原症状消失的浏览器结果。
常见问题
Codex 能看 Chrome 控制台吗？
能，前提是当前客户端接入了能读取控制台的浏览器工具。Chrome DevTools MCP 可以列出选定页面的消息，也能按消息 ID 查看详情。
Codex 能检查失败的网络请求吗？
Chrome DevTools MCP 能列出选定页面的请求，并按 ID 查看详情。把请求方法、路径、状态和触发它的动作对应起来。
为什么页面是 200，接口却是 404？
HTML 文档和后续 API 请求是不同的 HTTP 事务。文档成功只说明网页能加载，前端脚本仍可能请求了错误路径。
必须连接已登录的 Chrome 吗？
本地可复现故障通常用独立 Chrome 就够了。确实需要登录时应选择允许的测试配置，并从报告中去掉敏感内容。
Chrome DevTools MCP 和 ChatGPT 应用的完整 CDP 是一回事吗？
是两种接入方式。Chrome DevTools MCP 是独立配置的服务，ChatGPT 应用的内置浏览器有自己的完整 CDP 设置与组织策略。
怎样证明故障修好了？
重复原动作，同时核对请求、控制台和页面实际结果。在本例中正确接口返回 200，页面显示 Theme: light。