Feature request: support extension page and service-worker visibility when attaching to existing Chrome

[luisnomad]

Context

This issue was originally filed as a bug report because the attached-browser path does not pass categoryExtensions through the same way as the launched-browser path. After maintainer feedback, I understand that the current behavior is intentional: full extension debugging is currently supported only over piped connection, and enabling the full extension category over WebSocket-based attach flows would expose tools that are known to fail.

I am keeping that original context here so the existing thread and linked PR discussion still make sense.

Feature request

Support a narrower extension-debugging capability when attaching to an already-running Chrome instance via:

• --browserUrl
• --wsEndpoint
• --autoConnect

Specifically, the request is to expose extension pages and extension service workers for observability in attach mode, without implying that the full extension-management toolset is supported there.

Requested scope

When connected to an existing Chrome instance, allow list_pages to include:

• extension pages
• extension service workers

This would support workflows where the MCP server attaches to a real Chrome profile that already has authenticated state, tab layout, and active extension contexts, and the user needs visibility into those extension targets.

Non-goals

This request is not asking to enable the full extension-management toolset over WebSocket-based attach flows. In particular, tools such as these may remain unavailable or explicitly unsupported in connected-browser mode:

• install_extension
• uninstall_extension
• reload_extension
• list_extensions
• trigger_extension_action

Why this narrower feature would still help

Even without full extension-management support, page/service-worker visibility in attach mode would still be valuable for:

• attaching to a real browser profile with existing auth/session state
• inspecting extension contexts in that same running browser
• debugging workflows that depend on extension pages or extension service workers being visible to the MCP server

Existing prototype

There is a prototype PR here: #1171

That PR currently assumes the attached-browser behavior should match launch-mode behavior more directly. If the narrower feature direction described above is acceptable, the implementation can be reworked around that supported subset instead.

[nroscino]

Hey luisnomad! Thank you for filing this!

Currently, our extension implementation is supported only over piped connection. While some basics functionalities (like listing pages and service workers) will work over WebSockets, many tools for the extension debugging such as:
install_extension, uninstall_extension, reload_extension, list_extensions and trigger_extension_action, will fail due to browser-level security restrictions (The CDP methods will return a Method not allowed when called using WebSockets).
Therefore, enabling the --categoryExtension with --autoConnect, as of now, would break most of the extension debugging tools.

We can mark this as a feature request to enable full debugging extension capabilities through WebSockets, but as of now this is the intended behaviour.

[luisnomad]

Thanks, that makes sense. I agree the current --category-extensions behavior implies a broader extension toolset, and many of those tools would fail over WebSocket-based attach flows.

I do have a prototype PR here: #1171, but I understand that it is not sufficient as-is if enabling the category would expose unsupported extension-management tools.

Would maintainers be open to treating this as a narrower feature request instead: enabling attach-mode visibility for extension pages/service workers in list_pages, while keeping tools such as install_extension, uninstall_extension, reload_extension, list_extensions, and trigger_extension_action unavailable or explicitly unsupported in connected-browser mode?

If that direction is acceptable, I can rework the PR around that supported subset instead of treating it as a bug fix.

[luisnomad]

Additional context that seems relevant to the narrower feature framing here: the Chrome team recently published "Let your Coding Agent debug your browser session with Chrome DevTools MCP".

That post describes attach-mode support as a way for coding agents to re-use an existing browser session, access active debugging sessions in DevTools, and investigate currently selected requests/elements in a live browser session.

To me, that seems aligned with the narrower request in this issue: improving attach-mode observability for existing browser contexts, without necessarily implying that the full extension-management toolset should work over WebSocket-based attach flows.

In other words, I think extension page/service-worker visibility in attached-browser mode would fit the same general direction of making live browser sessions more inspectable to agents.

[pirate]

Related discussion here too:

• Feature Request: Support for browser extension development and debugging #96