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。