fix: allow --categoryExtensions when connecting to an existing browser

[paviad]

Fixes #2989.

Split at the reviewer's request: the target-filter fix that makes extension pages visible when attached is now #3047. This PR only lifts the startup rejection and updates the related text.

#2753 added ['categoryExtensions', 'autoConnect'] and ['categoryExtensions', 'browserUrl', 'wsEndpoint'] to CONFLICTING_ARGS, so main exits at startup with "mutually exclusive" for these combinations. 1.10.1 accepts them. The help text still said attach modes were unsupported only "until 149", and Chrome 149 has shipped. In #2852, @OrKoN noted that recent Chrome doesn't need a pipe connection, and said the rejection should be fixed.

Changes

• src/config/mcp-options.ts: remove the two categoryExtensions conflict groups. --viaCli keeps its existing default (extensions off when attaching unless requested explicitly).
• --categoryExtensions help text (category-options.ts, regenerated docs/configuration.md) and skills/troubleshooting/SKILL.md: replace the "pipe only / until 149" note with "requires Chrome 149 or later" for attach modes.
• tests/cli.test.ts: the conflict tests now assert the combinations are accepted.

#3047 should land first or together with this one. Otherwise attaching with --categoryExtensions is accepted but extension pages stay hidden from list_pages.

Testing

• npm run gen (only docs/configuration.md changed) and npm run check-format: clean.
• node scripts/test.js tests/cli.test.ts tests/browser.test.ts: all pass.
• Manual, on Windows with Chrome 154.0.8037.98, with this change and fix: pass categoryExtensions to the target filter when connecting #3047 together: started with --browserUrl http://127.0.0.1:<port> --categoryExtensions=true, and list_pages lists the extension tab under ## Extension Pages. --autoConnect and --wsEndpoint were covered only by the unit tests.

Not tested: Chrome 149 through 153, and anything before 149. The "Chrome 149 or later" requirement in the help text keeps the boundary from the original note in #1922 rather than one I measured. Following the existing convention (--autoConnect "Chrome 144+", --allowedUrlPattern "Chrome 149+"), it's documented, not checked at runtime. I'm happy to add a runtime check in a follow-up if you'd prefer one.

🤖 Generated with Claude Code

[Lightning00Blade]

@paviad Can I ask you to split the changes in two it would be much easier to review and merged the changes.

[paviad]

@paviad Can I ask you to split the changes in two it would be much easier to review and merged the changes.

What should be contained in each part?

[Lightning00Blade]

Its the two things you listed. One related to argument and the other related to the internal handling of things.

[paviad]

Ok will split - I will find the issue relating to the rejected startup (part 1) - I should create one if one doesn't exist, correct?

[paviad]

@Lightning00Blade Done, split in two:

• fix: pass categoryExtensions to the target filter when connecting #3047: the target-filter fix in BrowserManager#connect(), so extension pages and service workers show up when attached (issue Extension pages and service workers are hidden when attaching with --browserUrl, --wsEndpoint or --autoConnect #3046). Small, and safe to land on its own.
• This PR (fix: allow --categoryExtensions when connecting to an existing browser #3041): only lifts the categoryExtensions conflict with autoConnect/browserUrl/wsEndpoint and updates the help text, docs and skill (main rejects --categoryExtensions with --browserUrl, --wsEndpoint or --autoConnect, which work in 1.10.1 and the docs promise for Chrome 149+ #2989).

Both are rebased on current main. Landing #3047 first avoids a window where attaching is allowed but extension pages are hidden.