開啟方式
啟動帶有你所需控制旗標的開發 session：你可以做什麼
extension logs 與 extension inspect 各自有專屬的參考頁面：logs 與 inspect。
共用旗標
每個會執行動作的指令都接受同樣這三個旗標：--browser選擇要作用的 session（預設chromium）。--timeout <ms>限制一次往返的時間（預設 5000）。--output <pretty|json>選擇 stdout 的輸出形式。
eval 對應 --allow-eval，其餘一律是 --allow-control。你不必猜自己漏掉了哪個限制。
哪些內容會寫到磁碟
除了即時通道之外，session 還會在dist/extension-js/<browser>/ 下寫入只追加的紀錄：logs.ndjson 保存每一筆擷取到的日誌事件，actions.ndjson（在 session 帶有 --allow-control 時寫入）稽核執行過的控制動作。兩者在 session 結束後仍可讀取。
日誌合約也保留了結構化的 dx.signal 項目，那是關於執行階段自身健康狀況的機器可讀診斷資訊，過濾方式為 extension logs --signals-only。目前尚未有任何發送端，因此這個過濾器現在不會回傳任何內容。它的結構先行記錄下來，讓消費端在第一筆 signal 出現的那天就能據此分支。
指定 context
讀取與執行動作共用同一套詞彙 — 你指定介面名稱，Extension.js 會在它正在追蹤的 session 中解析出來。範例：我的擴充功能真的改動了頁面嗎？
這個範例可以直接在預設樣板上執行。--context page 會在目前分頁的 MAIN world 中執行運算式，因此你可以檢查 content script 究竟對頁面做了什麼：
--output json，你會得到完整的信封：
console.log，同時會經由 extension logs 流出，並以序號相互關聯 — 因此你能同時看到回傳值 以及 副作用。
若要呼叫 background，請以 Firefox 或 MV2 session 為目標，那裡的 background 是一個可以正常執行運算式的頁面：
--context background 回傳的是說明性的錯誤而非值。在 Chromium MV3 上請改用 --context page 或 --context content。extension_eval MCP 工具正是基於這個原因，在 Chromium MV3 session 上預設使用 page context；在 Firefox/MV2 上其預設值仍為 background。
跨瀏覽器支援
Extension.js 透過瀏覽器內的伴隨程式進行除錯，而非 Chrome DevTools Protocol，因此核心流程能觸及你自己的介面，在 Chrome 與 Firefox 上都可運作 — 過去「Firefox 用 RDP，不支援」的那堵牆，對這些工具而言已經不存在。
（在 Chromium MV3 建置上，
eval --context background 回傳的是說明性的錯誤。MV3 的 background 是 service worker，而 Chrome 的擴充功能 CSP 在每個 MV3 建置上都會拒絕 unsafe-eval，不只是正式環境。在 Chromium MV3 上請在 page / content 中執行運算式，或改以 Firefox/MV2 建置為目標呼叫 background。extension_list_extensions 是 MCP 工具而非 CLI 動詞 — 它透過 DevTools Protocol 連線，所以僅限 Chromium。）
日誌在瀏覽器裡的位置
extension logs 會把每個 context 合併成終端機上的單一時間軸（參見 logs）。當你想改看某個 context 在瀏覽器本身的主控台時，每個 context 都藏在不同的門後：
三個能省時間的細節：
- 在 Chrome 上，service worker 連結也會喚醒閒置的 MV3 worker，所以 background 看起來像死掉時就用它。
- Content script 的日誌永遠不會出現在擴充功能自己的檢查器。在頁面 DevTools 的主控台中，context 下拉選單可以過濾到你的擴充功能的 isolated world。
- 在 Firefox 上，
about:debugging的 toolbox 涵蓋 background 與擴充功能頁面。Content script 的輸出留在頁面的 DevTools。
extension logs，依 context 標記，完全不用點開那些門。
安全性
這些限制有其用意，並非繁文縟節：- 觀察不需要任何權限。 讀取日誌與 DOM 隨時可用。
- 有界限的操作需要
--allow-control。storage、reload與open會改變狀態，因此你必須在每個 session 中明確啟用。 eval需要--allow-eval以及 每個 session 的權杖。 權杖會寫入dist/外的0600檔案，因此絕不會包含在建置產物中 — 隨機的本機程序無法悄悄操控你的 service worker。- 絕不會進入正式環境。 控制通道只在
dev/preview期間存在，且綁定在已建置產物中不存在的連接埠上。
搭配 AI agent
同樣的操作會透過@extension.dev/mcp 以 MCP 工具的形式提供（extension_logs、extension_eval、extension_storage、extension_reload、extension_open、extension_list_extensions）。限制完全相同 — 助手可以自由觀察，但只有在你為該 session 啟用後才能執行動作。
下一步
- 觸發動作與鍵盤指令 — 不需點擊也能測試處理函式，可無頭執行並用於 CI。
- Manifest 拒絕載入 — 為什麼 Chromium 會在 session 還來不及連上之前就拒絕一個擴充功能。
- 同時執行兩個 MCP server — Extension.js 控制與 Chrome DevTools MCP 並用。
- CI 範本 — 將這些整合進 PR 檢核流程。