fix: enable extensions when connecting to existing Chrome

[luisnomad]

Summary

• pass enableExtensions through the connected-browser path for --browserUrl, --wsEndpoint, and --autoConnect
• extract browser resolution into a small helper so the attach-vs-launch wiring is testable
• document that --category-extensions applies when connecting to an existing Chrome instance

Testing

• npm run build
• node scripts/test.mjs tests/index.test.ts tests/resolveBrowser.test.ts

[zyzyzyryxy]

Thank you for your contribution.

Please submit an issue describing your use case before we can act on your PR. Specifically let us know if you think you are addressing a bug or implementing a new feature.

[luisnomad]

Thanks. I believe this PR is fixing a bug rather than adding a new feature. Extension-related behavior already exists in the server, and ensureBrowserConnected() already accepts enableExtensions, but the connected-browser path in createMcpServer() was not passing categoryExtensions through.

The result is that extension pages/service workers are not exposed consistently when attaching to an existing Chrome instance via --browserUrl, --wsEndpoint, or --autoConnect, even though the launched-browser path already supports that mode.

I think #1072 is the closest existing issue for this area. My use case is attaching to an already-running Chrome profile and inspecting extension contexts there, rather than launching a separate isolated browser. If you’d prefer a dedicated bug issue for this narrower case, I can open one and link it here.

[luisnomad]

Follow-up: I think #1072 is only adjacent context and not the exact issue this PR addresses. I opened #1173 to track the specific bug here: --category-extensions is not applied on the connected-browser path even though launch-mode already supports it and ensureBrowserConnected() already accepts enableExtensions.

I think #1173 is the better issue to associate with this PR.

[luisnomad]

Follow-up: I updated #1173 to reflect the maintainer guidance that the current behavior is intentional and that this should be discussed as a feature request rather than a bug.

With that framing, this PR should be read as a prototype for a narrower feature: exposing extension pages/service workers in attached-browser mode, not enabling the full extension-management toolset over WebSocket-based attach flows. If that narrower direction is acceptable, I can rework the PR around that supported subset.

[OrKoN]

Thanks for the PR but we already have extension implementation in progress. Stay tuned!