启用
启动一个开发会话时带上你需要的控制开关：你可以做什么
extension logs 与 extension inspect 各自有独立的参考页：logs 与 inspect。
共享 flag
每个执行操作的命令都接受同样这三个 flag：--browser选择要指向的会话（默认chromium）。--timeout <ms>限定一次往返的时长（默认 5000）。--output <pretty|json>选择 stdout 的输出方言。
eval 对应 --allow-eval，其余全部对应 --allow-control。你不用去猜自己漏了哪个门控。
哪些内容会落到磁盘上
除了实时通道之外，会话还会在dist/extension-js/<browser>/ 下写入只追加的记录：logs.ndjson 保存捕获到的每一条日志事件，actions.ndjson（在会话带 --allow-control 时写入）审计已执行的控制操作。两者在会话结束后仍可读取。
日志契约还预留了结构化的 dx.signal 条目，它们是关于运行时自身健康状况的机器可读诊断信息，过滤方式为 extension logs --signals-only。目前还没有任何发射端，因此这个过滤器现在什么也不会返回。它的结构已经先行文档化，这样等第一条 signal 落地时，消费方就可以据此分支。
指定上下文
读取和执行操作共享同一套词汇——你只需说明界面名称，Extension.js 会根据它正在跟踪的会话进行解析。示例：我的扩展真的改动了页面吗？
这个例子在默认模板上可以直接运行。--context page 在当前标签页的 MAIN 世界中求值，因此你可以检查 content script 到底对页面做了什么：
--output json，你会得到完整的信封：
console.log 都会同时通过 extension logs 输出，并按序号相关联——这样你能同时看到返回值和副作用。
如果要调用后台，请针对 Firefox 或 MV2 会话，那里的后台是一个可以正常求值的页面：
--context background 返回的是一条解释性错误而不是值。在 Chromium MV3 上请改用 --context page 或 --context content。extension_eval MCP 工具正是出于这个原因，在 Chromium MV3 会话上默认使用 page 上下文；在 Firefox/MV2 上它的默认值仍然是 background。
跨浏览器支持
Extension.js 通过浏览器内伴侣进程进行调试，而不是 Chrome DevTools Protocol，因此核心循环可以在 Chrome 与 Firefox 上都到达你自己的界面——曾经那堵“Firefox 用 RDP，所以不支持”的墙在这些工具上已经不存在了。
（在 Chromium MV3 构建上，
eval --context background 返回的是一条解释性错误。MV3 的后台是 service worker，而 Chrome 的扩展 CSP 在每个 MV3 构建上都拒绝 unsafe-eval，不只是生产环境。在 Chromium MV3 上请在 page / content 中求值，或者针对 Firefox/MV2 构建调用后台。extension_list_extensions 是 MCP 工具而不是 CLI 子命令——它通过 DevTools Protocol 连接，因此仅支持 Chromium。）
日志在浏览器里的位置
extension logs 把每个上下文合并进同一条终端时间线(见 logs)。当你想看某个上下文在浏览器自己的控制台里的输出时，每个上下文都在不同的门后面：
三个细节能帮你省时间：
- 在 Chrome 上，service worker 链接还能唤醒一个空闲的 MV3 worker，当后台看起来没反应时用它。
- Content script 的日志永远不会出现在扩展自己的检查器里。在页面 DevTools 的控制台中，上下文下拉框可以过滤到你的扩展的隔离世界。
- 在 Firefox 上，
about:debugging工具箱覆盖后台和扩展页面。Content script 的输出留在页面的 DevTools 里。
extension logs，按上下文打标签，不需要点开任何一扇门。
安全性
这些门控是有意为之，而不是官僚式的限制：- 观察无需任何开关。 读取日志和 DOM 始终可用。
- 有边界的操作需要
--allow-control。storage、reload与open会改变状态，因此你需要按会话主动开启。 eval需要--allow-eval以及一个按会话生成的 token。 该 token 写入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）。门控完全一致——助手可以自由地观察，但只有在你为本次会话启用后才能执行操作。
下一步
- 触发动作和键盘命令——无需点击即可测试处理器，无头并可在 CI 中运行。
- Manifest 拒绝——为什么 Chromium 会在会话还来不及连接之前就拒绝一个扩展。
- 同时运行两个 MCP 服务器——Extension.js 控制能力与 Chrome DevTools MCP 并存。
- CI 模板——将这些能力接入 pull request 的检查。