Chrome 155 的 chrome.debugger 被政策擋住？先查兩種錯誤

先掌握 Chrome 155 的時間與範圍#

Chrome for Developers 列出的時間是：

這不是所有 chrome.debugger 呼叫都會被封鎖。官方說明的條件是：瀏覽器受企業管理，且管理員設定了 runtime_blocked_hosts、DisableScreenshots 或 DLP 規則。未受管理的瀏覽器，或沒有這些特定限制的受管理環境，API 仍照常運作。

兩種錯誤訊息代表不同政策#

chrome.debugger 能把 Chrome DevTools Protocol（CDP）帶進擴充功能，執行 script、攔截網路或修改 DOM，因此 Chrome 155 採用 attach 時的 all-or-nothing policy check。這也是為什麼「某個頁面已在 allowlist」不一定能拯救整個 debugger session。

在程式碼中保留可讀的錯誤分流#

Manifest V3 可以把 attach() rejection 轉成支援人員看得懂的訊息。先確認 manifest 宣告了 debugger permission，再在 attach 邊界處理政策錯誤：

1
{
2
  "manifest_version": 3,
3
  "permissions": ["debugger"]
4
}

1
async function attachDebugger(tabId) {
2
  try {
3
    await chrome.debugger.attach({ tabId }, "1.3");
4
    return { ok: true };
5
  } catch (error) {
6
    const message = error instanceof Error ? error.message : String(error);
7

8
    if (message.includes("Host access is restricted by policy")) {
9
      return {
10
        ok: false,
11
        reason: "enterprise-host-policy",
12
        message: "此瀏覽器的 host policy 不允許 debugger。",
13
      };
14
    }
15

16
    if (message.includes("Screenshot capture is restricted by policy")) {
17
      return {
18
        ok: false,
19
        reason: "enterprise-screenshot-policy",
20
        message: "此瀏覽器的截圖或 DLP policy 不允許 debugger。",
21
      };
22
    }
23

24
    return { ok: false, reason: "other-attach-error", message };
25
  }
26
}

不要只顯示「Debugger failed」。把 Chrome 版本、是否受管理、target tab id、錯誤原文與擴充功能版本一起記到不含敏感內容的診斷資料，支援人員才有辦法分辨政策拒絕和一般的 attach 失敗。

排錯順序：先政策，再 target#

當錯誤只在公司裝置發生時，可以依這個順序縮小範圍：

1. 比對受管理狀態：在同一台裝置的測試 profile 觀察 Chrome 是否顯示由組織管理；再用沒有企業政策的測試環境比對。個人環境成功、公司環境失敗，是政策線索，不是證明。
2. 查看目前載入的政策：在受管理的 Chrome 開啟 chrome://policy，確認 ExtensionSettings、runtime_blocked_hosts、DisableScreenshots 等欄位是否真的套用到該 extension 或目標環境。
3. 確認 extension manifest：確認 debugger permission 沒被移除，並記下 extension ID。Chrome Enterprise 的 ExtensionSettings 是依 extension ID 套用個別設定，預設 * 也可能影響未單獨指定的 extension。
4. 最後才查 target：政策錯誤排除後，再確認 tab 是否存在、是否已被另一個 debugger session attach、required protocol version 是否符合，以及 attach 前後的生命週期。
5. 保存 channel 與日期：Chrome 155 Beta 與 Stable 的 rollout 日期不同；CI 應把 channel、版本和政策快照寫進測試結果。

如果 chrome://policy 沒有顯示相關政策，但仍得到政策錯誤，不要立刻修改管理設定。先確認瀏覽器是否已重新整理政策、extension ID 是否正確，以及錯誤是否來自另一個 target 或 wrapper API。

allowlist 不能把 debugger 變成逐頁權限#

runtime_allowed_hosts 對一般 extension host access 仍有用途，但 Chrome 155 對 chrome.debugger.attach() 的政策判定是整個 attach 邊界。只要 extension 被設定非空的 runtime_blocked_hosts，官方說明是所有 target 都會被拒絕，即使個別 origin 同時出現在 allowed list。

因此管理員要先做架構決定：

• 如果 extension 確實需要 CDP，就不要替它配置會觸發這條 all-or-nothing 規則的 blocked hosts，並依組織的風險政策管理可安裝與可執行範圍。
• 如果需求只是對允許的頁面執行 script 或插入 style，評估 chrome.scripting，讓 host permissions 保持較細的範圍。
• 如果需求是宣告式攔截或修改網路請求，評估 chrome.declarativeNetRequest，不要為了取得 CDP 而承擔整個 debugger permission 的限制。
• 如果只需要 Cookie 存取，評估 chrome.cookies 與標準 host permissions。

替代 API 不是行為完全相同的 drop-in replacement。先列出實際使用的 CDP domain、需要的 target 類型與資料流，再逐項驗證替代方案；不要只把 permission 名稱換掉就宣稱遷移完成。

上線前的最小驗證矩陣#

至少保留四組結果：

這組矩陣能把 Chrome 155 的政策行為和擴充功能自身的 regression 分開。正式支援文件也應告知企業使用者：政策拒絕需要管理員處理，重新安裝 extension、清除 cache 或重開分頁不會移除組織政策。

這篇聚焦 chrome.debugger 的企業政策邊界；若你要安排 Beta、Stable 和 Extended Stable 的回歸節奏，可接著看 Chrome 改成兩週更新後，前端測試排程怎麼調整？。

參考資料：

Chrome for Developers：Stricter enterprise policy enforcement for chrome.debugger in Chrome 155

Chrome for Developers：browser.debugger API

Chrome Enterprise：Configure ExtensionSettings policy