Problem

opencli browser <profile> eval <js> internally calls chrome.debugger.attach() (CDP).
Some sites detect debugger attachment the moment it happens and immediately redirect the tab
(e.g. to about:blank), making eval impossible on those sites even when the user is browsing
them normally in Chrome.

Concrete case: BOSS直聘 (zhipin.com) detects the debugger attach and redirects within ~100ms.
The page data is fully loaded and readable to the human user, but any opencli eval attempt
lands on a blank page.

Technical Root Cause

CDP's chrome.debugger.attach() is observable by page JS — sites can hook
window.chrome.debugger, watch for the Runtime.enable event exposure, or use timing
fingerprints to detect it. There is no way to suppress this with existing opencli flags.

Proposed Feature

Add a --no-debugger (or --via-extension) flag to browser eval that routes the JS
execution through the Browser Bridge extension's native scripting API instead of CDP:

opencli browser work eval "document.title" --no-debugger

The Browser Bridge extension background can call chrome.scripting.executeScript() to run
JS in a target tab — this does not attach a debugger and is invisible to page-level
anti-bot code.

Implementation sketch:

1. CLI sends eval request to daemon as usual
2. Daemon forwards to Browser Bridge extension via its existing WebSocket channel
3. Extension background calls chrome.scripting.executeScript({ target: { tabId }, func })
4. Result is returned through the same channel

Environment

• OpenCLI v1.8.0, Browser Bridge v1.0.15
• Windows 11, Node.js v22.22.2, PowerShell
• Profile: work (Chrome with zhipin.com logged in)

Workaround Explored

We verified the page data is accessible via the Chrome Extension scripting API from a
separate extension (boss-helper, which reads el.__vue__.jobList as a content script).
The data is there — only the CDP attach step blocks access.