Turn it on
Start a dev session with the control flags you need:What you can do
Address a context
Reading and acting share one vocabulary — you name the surface, Extension.js resolves it against the session it’s already tracking.Example: did my background handler actually run?
console.log your expression triggers flows out through extension logs at the same time, correlated by sequence — so you see the return value and the side effects.
Cross-browser support
Extension.js debugs through an in-browser companion, not the Chrome DevTools Protocol, so the core loop reaches your own surfaces on both Chrome and Firefox — the old “Firefox uses RDP, not supported” wall is gone for these tools.
(
extension_list_extensions is an MCP tool rather than a CLI verb — it connects over the DevTools Protocol, so it’s Chromium-only.)
Safety
The gates are intentional, not bureaucratic:- Observation needs nothing. Reading logs and DOM is always available.
- Bounded operations need
--allow-control.storage,reload, andopenchange state, so you opt in per session. evalneeds--allow-evaland a per-session token. The token is written to a0600file outsidedist/so it never ships in a build — a random local process can’t quietly drive your service worker.- Nothing reaches production. The control channel exists only during
dev/preview; it’s gated on a port that isn’t present in a built bundle.
With an AI agent
The same operations are exposed as MCP tools through@extension.dev/mcp (extension_logs, extension_eval, extension_storage, extension_reload, extension_open, extension_list_extensions). The gates are identical — an assistant observes freely but only acts when you’ve enabled it for the session.
Next steps
- Trigger actions and keyboard commands — test handlers without clicking, headless and in CI.
- Run both MCP servers — Extension.js control alongside Chrome DevTools MCP.
- CI templates — wire these into a pull-request gate.

