Chrome DevTools MCP 可以將代理程式連接到現有的 Chrome 工作階段，但自動連線並非零設定。Google 目前的設定要求 Chrome 144 或更新版本、在執行中的瀏覽器啟用遠端偵錯、使用 --autoConnect 旗標，並由使用者手動點擊 Chrome 的「允許」對話框。當這些條件都滿足時，代理程式會繼承該設定檔中已開啟的分頁與登入狀態。官方自動連線指南說明了每一項必要條件以及它所授予的整個設定檔層級的存取權限。Chrome DevTools MCP 需要另外開啟一個瀏覽器供外部控制，而 ego (lite) 本身就是那樣的瀏覽器，無需切換開關，也不必反覆授權。

Chrome DevTools MCP 追蹤器中最受要求的功能從來不是偵錯工具，而是issue #140：讓代理程式連線到我正在使用的 Chrome，並帶入我的登入狀態。本指南依序說明完整流程，包含常見陷阱與限制。

Key takeaways

自動連線需要 Chrome 144+、在 chrome://inspect/#remote-debugging 啟用遠端偵錯、加上 --autoConnect 旗標，並在 Chrome 中核准連線。
目前套件要求 Node 20.19+、22.12+ 或 23+。在 9 月 10 日的檢查中，1.9.0 版在伺服器啟動前拒絕 Node 19.9，改用 Node 22.12 後則完成了真正的除錯工作流程。
Chrome 每次工作階段都會顯示權限對話框；只有在你點擊「允許」之後，代理程式才能取得存取權限。
Chrome 136+ 會忽略針對預設資料目錄的 remote-debugging 參數。手動設定連接埠時，需要另外指定 --user-data-dir。
較舊的做法（搭配專屬 user-data-dir 使用 remote-debugging-port）仍然可行，且在沙箱環境中更為可靠。
自動連線會將整個設定檔暴露給 MCP 用戶端。請限制來源、移除標頭中的敏感資訊，並在政策要求時停用選用的使用統計或 CrUX 查詢功能。

如何安裝 Chrome DevTools MCP Server？

官方伺服器是 npm 套件，因此在 Claude Code 中最快只需一條指令即可設定。它透過 stdio 在本機執行，不需要託管帳戶或 API 金鑰。先檢查 node --version：套件 1.9.0 接受 Node 20.19+、22.12+ 或 23+，較舊的執行環境會在 Chrome 啟動前被拒絕。接著以使用者範圍註冊伺服器，讓所有 Claude Code 專案都能使用。

claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest

新增完成後，在 Claude Code 中執行 /mcp，確認 chrome-devtools 已列出。目前的官方儲存庫也提供 Claude Code 外掛程式，將 MCP 伺服器與其技能整合在一起：新增 ChromeDevTools/chrome-devtools-mcp marketplace、安裝 chrome-devtools-mcp@chrome-devtools-plugins、重新啟動 Claude Code，並用 /skills 驗證。如果已有較舊的手動安裝，請在安裝外掛程式前移除重複的項目，以免 Claude Code 載入兩份副本。

/plugin marketplace add ChromeDevTools/chrome-devtools-mcp
/plugin install chrome-devtools-mcp@chrome-devtools-plugins

有兩項隱私設定很容易被忽略。MCP 工具預設會啟用使用統計資料收集，此功能與 Chrome 瀏覽器的指標收集相互獨立。效能工具也可能將追蹤的頁面 URL 傳送至 Google CrUX API 以取得實地資料。若您的政策不允許上述任一途徑，請在伺服器參數中加入 --no-usage-statistics 與 --no-performance-crux，並確認您的用戶端實際啟動的設定檔中已包含這些旗標。

我們在乾淨的本機環境中驗證了什麼？

2026 年 9 月 10 日，我們從 npm 解析 chrome-devtools-mcp@latest 並在 macOS 上執行，取得的套件版本是 1.9.0。使用 Node 19.9.0 時，它在啟動前結束並輸出最低引擎需求；使用 Node 22.12.0 與 Chrome 152.0.7977.83 時，它啟動隔離瀏覽器，並透過 MCP 協定完成多重證據除錯任務。

檢查	觀察到的結果	這說明了什麼
`--version`	1.9.0	本次測試的套件版本
Node 19.9.0	因 EBADENGINE 而被拒絕	從未啟動的伺服器，可能看起來像是 MCP 連線失敗
Node 22.12.0	說明輸出已完成	目前的旗標可在支援的執行環境中載入

我們實際執行的複雜任務

我們提供了一個受控的營運儀表板，其中包含四個獨立缺陷：同步執行的 240 毫秒彙總工作、延遲載入的主視覺資產、回傳 503 的訂單請求，以及回傳 500 的報表匯出。Chrome DevTools MCP 1.9.0 必須記錄重新載入的追蹤資料、從頁面快照辨識並點擊「Generate report」按鈕，再把可見錯誤與主控台來源位置及網路狀態碼交叉比對。我們停用使用統計與 CrUX 查詢，避免本機測試 URL 進入選用遙測路徑。

LCP: 629 ms
LCP render delay: 627 ms
app.js:10  Orders API returned 503
app.js:18  export failed
GET  /api/orders?range=30d  503
POST /api/export           500

代理點擊「Generate report」並重現 HTTP 500 匯出失敗後的 Chrome DevTools MCP 測試儀表板 — 2026 年 9 月 10 日執行的 Chrome DevTools MCP 1.9.0 一手測試。截圖是最後的可見狀態；相鄰的執行紀錄則顯示可解釋問題的追蹤資料、原始碼行號、請求方法與狀態碼。

追蹤結果顯示 LCP 為 629 毫秒，其中 627 毫秒來自算繪延遲，而非伺服器回應時間。對故障流程更重要的是，主控台與網路工具得出一致結果：初始資料載入在 app.js 第 10 行因 HTTP 503 失敗，點擊後的匯出則在第 18 行因 HTTP 500 失敗。這種交叉驗證正是 DevTools MCP 的實際價值：截圖證明使用者看到的狀態，追蹤與請求證據則定位真正需要修正的工程層。

如何設定 Chrome DevTools MCP Server 自動連線？

Chrome for Developers 官方自動連線指南，顯示整個設定檔的存取範圍、安全界線，以及 Chrome 144 以上版本的必要條件 — 以本頁語言顯示的 Google 官方自動連線指南，於 2026 年 9 月 10 日使用 ego (lite) 擷取。畫面證實文件所述的設定檔資料界線與 Chrome 144 以上版本要求；但這張截圖本身不代表 MCP 已成功連線。

三個步驟，全部都是複製貼上。先決條件：穩定版（Stable）頻道的 Chrome 144 或更新版本（Canary 和 Beta 版需要在設定中指定頻道），以及任何 MCP 用戶端；範例使用 Claude Code。

步驟 1：啟用一次遠端偵錯。 在正在執行的 Chrome 中，開啟 chrome://inspect/#remote-debugging 並開啟遠端偵錯。這是 auto-connect 所依賴的橋樑；沒有它，其他功能都無法運作。

步驟 2：使用該旗標註冊伺服器。

claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --autoConnect

或作為 Cursor 及其他客戶端的 JSON 區塊：

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--autoConnect"]
    }
  }
}

步驟 3：觸發並允許。 要求代理程式與您已開啟的 Chrome 互動（例如「擷取我目前分頁的螢幕截圖」）。Chrome 會為該工作階段顯示權限對話框；按一下「允許」，代理程式即可進入您的即時瀏覽器，存取您的分頁、擴充功能與應用程式狀態。

風險	相關控制項	重要限制
代理程式會觸及不相關的網站	`--allowed-url-pattern`	需要 Chrome 149+；請測試重新導向與子資源
敏感請求標頭會回傳給用戶端	`--redact-network-headers`	敏感資訊遮蔽（redaction）預設為關閉
工具遙測	`--no-usage-statistics`	獨立於 Chrome 瀏覽器指標
追蹤網址已傳送至 CrUX	`--no-performance-crux`	停用實測資料查詢，但不禁用本機追蹤

連線完成後，以下三個起始提示可實際測試自動連線的用途：

「為我目前的分頁擷取螢幕畫面，並描述你看到的內容」（驗證附加連線）、「開始效能追蹤、重新載入此頁面，並告訴我什麼因素延遲了 LCP」（除錯的實際效益），以及「重現我剛才點擊匯出按鈕時看到的錯誤，然後讀出主控台錯誤及其來源」（即時工作階段診斷，這是全新設定檔的瀏覽器無法做到的事）。如果這些都能運作，表示你已具備完整的工具組。

哪三個常見陷阱會導致它失效？

這些情況都會顯示為「無法連線」，且沒有提供有用的錯誤訊息。請依序檢查。

1. 預設設定檔鎖定。 自 Chrome 136 起，針對預設的 Chrome 資料目錄，遠端偵錯旗標會被忽略。Google 在觀察到攻擊者利用遠端偵錯竊取 Cookie 後，做出了這項變更。Auto-connect 的權限對話框流程是連入執行中個人瀏覽器的官方文件途徑；手動連接埠途徑則必須使用非預設的 --user-data-dir，這將在下一節說明。

2. 第二個 Chrome 執行個體。 手動 browserUrl 路由預期 Chrome 是以偵錯連接埠和自訂資料目錄啟動。如果另一個 Chrome 程序佔用了該設定檔，或應用程式重複使用了已在執行的實例，旗標可能無法傳送到你預期的視窗。請關閉測試實例，使用一次性設定檔重新執行文件中的指令，並在啟動 MCP 用戶端前先驗證端點。

3. 連接埠實際上沒有回應。 瀏覽器端必須可連線，手動 browserUrl 路由才能附加。請求 http://127.0.0.1:9222/json/version，確認它回傳瀏覽器中繼資料和 WebSocket 偵錯工具 URL。若使用自動連線，請重新檢查 chrome://inspect/#remote-debugging 和 Chrome 權限對話框。如果 Node 在啟動前就失敗，請先修正執行環境；沒有任何瀏覽器旗標能修復那一層。

擴充功能衝突也值得提醒：管理分頁或封鎖腳本的擴充功能可能干擾 CDP 工作階段，看起來就像隨機不穩定。如果連線在任務中途中斷，請先停用分頁管理類擴充功能重試，再回報問題。

自動連線與 remote-debugging-port 方式相比有何差異？

由 Chrome DevTools 團隊維護的官方 ChromeDevTools/chrome-devtools-mcp GitHub 儲存庫 — 兩條連線途徑皆來自官方 ChromeDevTools/chrome-devtools-mcp 儲存庫。儲存庫的人氣會隨時間變化，因此本指南以持續維護的文件與套件行為為依據，而非星號數量。

在自動連線功能出現之前，標準做法是以明確的偵錯連接埠和專用設定檔目錄啟動 Chrome：

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --remote-debugging-port=9222 \
  --user-data-dir="$HOME/.chrome-debug-profile"

claude mcp add --transport stdio chrome-devtools \
  -- npx -y chrome-devtools-mcp@latest \
  --browserUrl=http://127.0.0.1:9222

取捨很明確。自動連線讓您使用真實設定檔（真正的登入狀態、真實的擴充功能、即時狀態），但每次工作階段都會顯示權限對話框；旗標途徑則提供獨立設定檔，您只需登入一次，該設定檔會在重新啟動後保留，無需對話框，且根據相關實作者的文件記載，在沙盒環境中更為可靠。此外，在 Chrome 144 以下版本，旗標途徑是您唯一的選擇。

並排比較，讓您一眼就能做出選擇：

屬性	自動連線	偵錯連接埠 + 專用設定檔
使用誰的登入資訊	你平常實際使用的設定檔	只需登入一次的次要設定檔
Chrome 版本	144+	任何較新的 Chrome
每次工作階段的額外步驟	每次工作階段都會出現權限對話框	使用這些旗標啟動後，即無需額外步驟
最適合	偵錯你目前正在檢視的應用程式狀態	可重複的已驗證測試，適用於沙箱或接近 CI 的環境設定

兩者都應遵循基本安全原則：代理程式可存取的設定檔不應包含網路銀行與個人電子郵件；工作結束後也應關閉 Chrome，讓連接埠隨之關閉。

如何讓既有的 Chrome 工作階段在多步驟工作中保持啟用？

將 Chrome 程序、設定檔與 MCP 伺服器視為同一個工作階段。先啟動 Chrome，啟用一次遠端偵錯，並在代理程式執行步驟期間保持同一個視窗開啟；請勿在導覽、資料擷取與驗證之間重新啟動 Chrome。Auto-connect 會重新連接至正在執行的瀏覽器，而較舊的 --remote-debugging-port 方式則僅在該偵錯啟動的程序存活期間保持有效。

若要建立可重複的工作階段，請使用帶有 --user-data-dir 的專用設定檔，在 CI 中鎖定 MCP 套件版本，並在首次工具呼叫前加入簡易健康檢查：要求截圖或列出目前的 targets。127.0.0.1:9222 的回應僅證明 CDP 端點存在，並不代表代理程式已取得正確的分頁。請在工作筆記中保留穩定的分頁識別碼，並在每次主要導覽後重新檢查頁面 URL。

代理程式應如何處理驗證與登入流程？

Chrome DevTools MCP 可以在您登入後操作頁面，但它不是驗證繞過工具。一般登入流程中，請前往已核准的登入 URL，讓真人輸入密碼或核准密碼管理員自動填入，並暫停等待 MFA、OTP、CAPTCHA 或安全金鑰提示。只有在真人確認驗證成功後，才繼續操作。

請遵循最小權限原則：使用測試帳號、狹窄的來源允許清單，以及不含網路銀行、個人信箱或無關分頁的設定檔。若網站重新導向至 SSO，請記錄最終來源，並在採取任何動作前確認帳號身分。正式環境的自動化請優先使用服務的官方 API 或 OAuth 裝置流程；請勿嘗試繞過存取控制，或在擁有者核准的範圍之外重複使用私人權杖。

它們可以連線到同一個 MCP 伺服器，但不應同時操作同一個分頁。導覽、焦點與點擊都是共享狀態，因此 Claude Code、Cursor、Gemini CLI 或 OpenCode 可能發生競爭、覆寫彼此的內容，或核准非預期的動作。請使用佇列並指定單一操作者，或為每個代理程式指派獨立分頁並記錄其歸屬。

權限對話框是人工把關的界線，不是自動核准的開關。請保持核准流程為互動式，審視來源端與要求的動作，並在共享任務完成時結束工作階段。若代理程式需要平行作業，隔離的瀏覽器 Spaces 可避免焦點衝突，並讓每個任務的 Cookie 與分頁各自獨立運作。

如何從 WSL 或 Docker 連線到 Windows 上的 Chrome？

在主機上執行 Chrome 及其 CDP 端點，然後讓該端點可從執行 MCP 用戶端的環境存取。在 WSL2 中，請使用 WSL 可看到的 Windows 主機位址，不要假設 127.0.0.1 是共用的；在 Docker 中，請明確發布或路由連接埠，並讓 MCP 程序位於相同的網路路徑。啟動代理程式前，先用 curl 測試 /json/version。

只要用戶端在本機執行，就應將 CDP 綁定至 localhost。若容器需要連到主機，請使用防火牆規則搭配通過驗證的隧道或私人網路，不要將 9222 連接埠暴露到區域網路。請確認容器內的 Node 與 npx 版本符合 MCP 需求，並記得 auto-connect 的 chrome://inspect 權限流程是在主機的 Chrome 中執行，而非在無頭容器內。

本機 AI 代理程式能否透過 Chrome DevTools 通訊協定控制 Brave？

Brave 是以 Chromium 為基礎，使用其官方文件記載的遠端除錯選項啟動時會開放 CDP，因此本機代理程式通常可透過 --browserUrl 連接，方式與專用 Chrome 設定檔相同。但不保證相容：Chrome DevTools MCP 官方支援的是 Chrome，而 Brave 特有的 shields、設定檔路徑與版本差異都可能改變行為。

請先在一次性 Brave 設定檔上驗證：列出 targets、擷取螢幕截圖、點擊無害的本機頁面並檢查 console 輸出。在審視過前述針對 Chrome 說明的 cookie、擴充功能與權限風險之前，請勿將代理程式指向你日常使用的 Brave 設定檔。

如何使用 DevTools MCP 執行 Lighthouse 效能稽核？

使用 DevTools MCP 效能工具開始追蹤、重新載入目標頁面、等待網路穩定，並收集 Lighthouse 風格的效能證據（LCP、CLS、INP、長任務與網路請求）。請代理程式在回報每個指標時一併提供 URL、裝置或節流設定檔、快取狀態與追蹤持續時間；否則分數無法重現。

一個實用的提示詞是：「在目前頁面上執行效能追蹤，以冷快取重新載入一次，找出主執行緒中最長的三個任務，並指出造成每個發現的請求或來源。」在修改程式碼前，先以暖快取重複執行。DevTools 證據能解釋頁面為何緩慢，但不能取代在具代表性的裝置上進行的受控 Lighthouse CI 執行。

為什麼 Chrome DevTools MCP 在 RooCode 或 AnythingLLM 中會失敗？

大多數第三方失敗是客戶端設定問題，而非不同的瀏覽器協定。確認客戶端執行相同的 npx 指令、恰好傳遞一次 --autoConnect 或 --browserUrl，並具備啟動本機程序的權限。接著檢查客戶端的 MCP 日誌中伺服器的 stderr，並獨立驗證 /json/version 或 Chrome 權限對話方塊。

在 RooCode 中，確認伺服器已為目前設定檔啟用，且模型政策允許工具呼叫。在 AnythingLLM 或 Docker 中，檢查 Node 是否可用、通往主機的網路路由，以及 Chrome 設定檔的檔案系統權限。同時升級客戶端與 chrome-devtools-mcp，將問題縮小為一次螢幕截圖呼叫，然後再加入導覽或追蹤。

在 DevTools MCP 中擷取一份精簡的證據包：目前的 URL 與標題、螢幕截圖、相關的 DOM 或無障礙子樹、含來源位置的 console 錯誤，以及含狀態碼與時間的失敗網路請求。將該證據包貼上或儲存供 Cursor 或 Claude Code 使用，並附上確切的重現步驟與瀏覽器版本。

如需更廣泛的連線模型比較，請參閱代理程式如何連線至現有瀏覽器。若優先考量的是降低上下文用量而非 DevTools 深度，請先比較Playwright MCP 與 CLI，再選擇控制層。

分享前先遮罩 Cookie、授權標頭、個人資料與隱藏的表單值。相較於完整的 HAR 匯出，結果確定的交接資料更有用：保留失敗的請求、可見的錯誤，以及足以證明狀態的最小 DOM 片段。接收端代理程式便能提出程式碼修正，而無需接管原始分頁。

什麼時候該改用獨立的代理瀏覽器？

當所有設定都成功之後，有一個事實不變：代理程式是在你正在使用的瀏覽器裡運作。同一個視窗、同一些分頁、同一個焦點。當它瀏覽時，那個分頁就被占用；當你打字時，你又擋到它。Auto-connect 是為除錯工作階段而設計，在這種情境下與代理程式輪流操作很自然。但對於背景任務（「我寫東西的時候，從三個儀表板把數字抓出來」），輪流操作正是問題所在。

ego (lite) 讓 agent 擁有自己的 Space，因此你的視窗仍歸你所有。

任何能執行 shell 指令的代理程式，都能透過 ego-browser skill 驅動它；不需要手動設定偵錯連接埠、不需要 chrome://inspect 步驟，也不需要每次工作階段的權限對話框。相同的 CDP 控制已內建，並連至專為代理操作而設計的瀏覽器。

誠實的分工：保留Chrome DevTools MCP用於它特別擅長的工作（效能追蹤、記憶體快照、偵錯你的即時工作階段），並將日常需要登入的任務交給不需要佔用你視窗的瀏覽器來處理。

這種分工方式有實測數據支持，但有一點需要註明。在Real-World Bench（一個針對真實網站的 31 項任務測試集，使用相同模型、相同獨立評審），此側所測量的工具是 chrome-devtools-cli（官方 CLI 兄弟工具），而非 MCP 伺服器本身：它在 31 項任務中完美完成 61.3%，而 ego (lite) 在 31 項任務中則達到 93.5%。該測試集屬於操作型任務，例如 stockanalysis.com 的篩選器任務，代理程式必須篩選出 Technology、將表格切換到 Valuation 檢視，並依序提取指標。診斷深度與任務完成是兩種不同的工作，而數據的差異也正好呼應了本指南的分工方式。

下載 Mac 版 ego (lite) 或閱讀 Chrome DevTools MCP 與 Playwright MCP 如何分工。兩者皆免費。

常見問題

如何在 Claude Code 中加入 Chrome DevTools MCP？

執行 claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest，若想讓它連接到你正在使用的瀏覽器，請在指令後加上 --autoConnect。在 Claude Code 中輸入 /mcp 進行驗證，然後要求它擷取目前分頁的螢幕截圖。

自動連線功能是否適用於 Cursor 及其他代理程式？

是的；這是 MCP 伺服器的功能，而非用戶端的功能。任何能執行 npx 指令的 MCP 用戶端皆可使用，但瀏覽器端同樣需具備 Chrome 144+ 並啟用 remote-debugging。

將代理程式連線至我已登入的瀏覽器是否安全？

此機制比舊有的開放連接埠方式更安全（每次工作階段皆顯示權限對話框、僅限本機伺服器、不會傳送資料至 Google），但授權範圍相當廣泛：涵蓋 Cookie、儲存空間及所有開啟的分頁。請將其視為將未上鎖的筆電借給他人使用：對於受信任的代理在有限任務上尚可，但涉及銀行或主要電子郵件時則不適合。

代理使用我的 Chrome 時，我還能繼續瀏覽嗎？

技術上可以，實際上不行。你們共用同一個視窗與同一個焦點：當代理導覽或點擊時，它是在你正在觀看的分頁中操作，而你的輸入可能會打斷其動作。自動連線的工作階段最好視為配對程式設計，一次只有一位操作者；這對除錯來說沒問題，但對背景任務來說並不適合。

代理能否在我已登入的網站中工作，而不佔用我的視窗？

無法透過 Chrome DevTools MCP 做到；共用視窗是其設計中固有的特性。在 ego (lite) 中，Space 讓 agent 擁有自己的工作區，因此它可以在執行已登入任務的同時，讓你的視窗與分頁仍歸你所有。

DevTools 路線在真實世界基準測試中的表現如何？

真實世界基準測試（ego-browser-benchmark-framework 儲存庫）以單一模型與獨立評審，透過五種工具在真實網站上執行 31 項任務。受測工具為 chrome-devtools-cli（官方 CLI 兄弟工具，而非 MCP 伺服器）：31 項任務中 61.3% 完美完成，每項任務平均模型成本為 $4.95。若僅將花費分攤到有完成的任務上，則為 $4.95 ÷ 61.3% = 每項完成任務 $8.08，是五種受測工具中最高者。對於以除錯為優先、執行操作工作的工具組而言，這大約是預期結果；這也是本指南將背景任務工作交由其他工具處理的原因。

所有文章免費用 ego (lite)