observe/snapshot/navigate fail with "Cannot access a chrome-extension:// URL of different extension" when Agent Window tab is born on an extension options page

[nextonebug]

Bug: observe/snapshot/navigate fail with "Cannot access a chrome-extension:// URL of different extension" when the Agent Window's initial tab is born on ANY chrome-extension:// page

Environment

• OS: Windows 11
• Browsers: Edge 151 AND Chrome 151 (both reproduce; Chrome extension build from Web Store)
• bsk CLI: 0.1.10, daemon protocol 1.0
• BrowserSkill extension: 0.1.6
• Trigger: the Agent Window's initial tab is born on a chrome-extension:// page (e.g. an extension that opens its options page on startup — identified as "Save In" v4.1.0 in our case; on Edge a new-tab hijacker). Reproduces on both Edge and Chrome.

What happened

1. bsk session start succeeds (Agent Window opens).
2. Any CDP-backed operation against the session's tab fails with:

   Cannot access a chrome-extension:// URL of different extension
   

   Affected: observe, snapshot, navigate (all wait-until phases incl. commit/load), press, and presumably click/fill.
3. Evidence that navigation itself SUCCEEDED: tab list shows the tab loaded at the target URL with the right title (e.g. https://news.ycombinator.com, "Hacker News", active=true). Only the CDP attachment / completion-signal path is broken.
4. Once the error starts, it STICKS: even brand-new tabs created with tab create --url <normal-url> (which show the correct URL and title in tab list) keep failing. The DevTools target pointer appears poisoned for the whole session/window.
5. Also reproduced: navigate --wait-until load times out after 30s with "tool RPC timed out" even though the page fully loaded (same root cause — completion signal lost).

Workarounds found

• bsk daemon stop; bsk daemon start clears the stuck state completely (extension reconnects in ~2s). After a daemon restart, the FIRST observe on a freshly created tab succeeded once (@vom 1 / RootWebArea), then the error returned on subsequent calls.
• Creating tabs born directly on a normal URL (tab create --url ...) instead of letting them start at the (hijacked) new-tab page reduces the chance of hitting it.
• screenshot uses a different channel and works reliably even while observe/snapshot fail.

Hypothesis

When the Agent Window's initial tab is born on a chrome-extension:// page owned by ANOTHER extension (because that extension hijacked the Edge new-tab page), the CDP session attaches to that protected target, and every subsequent operation keeps trying to use that poisoned target instead of re-attaching to the current, normal page. CDP cannot access other extensions' pages by design — but bsk should detect this and re-attach to the actual active tab.

Repro

1. Edge with a new-tab-hijacking extension installed (many popular Chinese extensions do this).
2. bsk session start → bsk navigate https://example.com → fails with the error above.
3. bsk daemon stop && bsk daemon start → first observe may work → error returns.

Thanks for the great tool — the Agent Window + real-login-session model is exactly what we needed.

[nextonebug]

Follow-up: controlled reproduction + root-cause refinement (original reporter)

We ran a controlled experiment that refines the root cause significantly — the initial "tab born on an extension options page" hypothesis was wrong.

Controlled trial (same daemon, same extension version 0.1.6, same sequence)

Trial	Variable	Result
Baseline	all extensions enabled	❌ poisoned
1	+ Listen 1 (MV2 persistent scripts) disabled	❌ still poisoned
2	+ AdGuard (MV2 persistent page) disabled	❌ still poisoned
3	+ uBlock Origin (MV2 persistent page) disabled — all MV2 extensions now off	❌ still poisoned
Control	Chrome (16 extensions incl. MV2, same machine, same daemon)	✅ fully healthy (5/5 stress: navigate+snapshot cycles, tab churn)

All MV2 extensions are ruled out. The failure is browser-specific: Edge 151 vs Chrome 151, identical everything else.

Refined failure signature

The first CDP-backed call on a fresh session fails with Detached while handling command — NOT the extension error. The Cannot access a chrome-extension:// URL error only appears on subsequent calls. Sequence: fresh session → snap1 "Detached" → snap2+ "chrome-extension:// different extension".

Daemon log evidence

Edge:   11 connects / 3 disconnects (ws read error: 10054 远程主机强迫关闭了一个现有的连接)
Chrome:  6 connects / 1 disconnect
handshake first-frame timeouts: 6 (all on the Edge side)

The Edge extension's WebSocket to the daemon gets force-closed mid-operation (os error 10054), and on reconnect/retry the CDP session attaches to a wrong (protected extension) target instead of the real tab.

Hypothesis v2

Edge applies different lifetime/throttling behavior to extension background connections than Chrome (Edge "sleeping tabs"/efficiency mode family?). The extension's service worker or its DevTools relay gets suspended mid-command; bsk's retry path then enumerates targets and grabs a protected chrome-extension:// target without re-validating it belongs to the session's tab.

Practical notes for other users

• Workaround: use Chrome for bsk sessions (fully healthy in our tests).
• A stuck plugin-side session counter ("session limit reached (5 concurrent sessions)" while bsk session list shows 0 after an Edge restart) clears by restarting the harness process that hosts the plugin.

Happy to run any further diagnostics you need — both browsers are still set up for it.