feat(browser): add --via-extension flag to bypass debugger detection on anti-bot sites

[BruceLoveDecimal]

Closes #1757

Problem

opencli browser <profile> eval <js> currently routes all JS execution through chrome.debugger.attach() (CDP). Sites like BOSS直聘 (zhipin.com) detect debugger attachment within ~100ms and immediately redirect the tab to about:blank, making eval impossible even when the user is browsing the page normally.

CDP attachment is detectable via multiple signals:

• The "Browser Bridge started debugging…" infobar causes a visualViewport reflow
• debugger; statements actually pause execution once a debugger is attached (timing-detectable)
• Runtime.enable has observable side effects on console / Function.prototype / microtask timing
• First-attach cold-start latency fingerprint

Solution

Add a --via-extension flag that routes eval through chrome.scripting.executeScript() (MAIN world) instead of CDP. This is the same mechanism used by ad-blockers and password managers — page JS cannot detect it without breaking itself for all normal extension users.

# default: CDP path — full features, detectable by anti-bot sites
opencli browser work eval "document.title"

# --via-extension: scripting API path — invisible to anti-bot, limited return types
opencli browser work eval "document.title" --via-extension

Changes

File	Change
extension/manifest.json	Add "scripting" permission
extension/src/protocol.ts	Add noDebugger?: boolean to Command interface
extension/src/cdp.ts	Add evaluateViaScripting() — uses chrome.scripting.executeScript with world: 'MAIN' and an async indirect-eval wrapper
extension/src/background.ts	Branch in handleExec: noDebugger routes to evaluateViaScripting; --via-extension + --frame returns a clear error
src/browser/daemon-client.ts	Add noDebugger?: boolean to DaemonCommand
src/browser/page.ts	Add evaluateNoDebugger() method
src/types.ts	Declare evaluateNoDebugger? on IPage
src/cli.ts	Add --via-extension option to browser eval

Known Limitations (intentional for v1)

--via-extension is not a drop-in replacement for the default CDP path:

• Return values must be structured-cloneable — no DOM nodes, functions, or circular references
• No remote object handles — CDP returns objectId references you can re-use; scripting API returns plain values only
• Weaker error reporting — errors come back stringified, full stack traces are lost
• --frame is unsupported — combining --via-extension with --frame returns a clear error message; frame support can be added later via chrome.webNavigation.getAllFrames
• No console interception — the CDP path can observe page console output; this path cannot

Execution World

The implementation uses world: 'MAIN' so that eval can access page-side JS state (Vue/React instances, window.xxx, etc.). This is required for the primary use case (reading el.__vue__.jobList on zhipin.com). world: 'ISOLATED' support can be added as a follow-up flag if needed.

Manifest Permission Note

Adding "scripting" to manifest.json will prompt users to re-approve the Browser Bridge extension on next update. Worth calling out in release notes.

E2E Test Results

Tested locally against zhipin.com:

--via-extension (4 consecutive evals — page never redirected):

eval 1: document.title  → "BOSS直聘-找工作BOSS直聘直接谈！招聘求职找工作！"  ✅
eval 2: location.href   → "https://www.zhipin.com/hangzhou/?seoRefer=index"  ✅
eval 3: location.href   → "https://www.zhipin.com/hangzhou/?seoRefer=index"  ✅  (page intact)
eval 4: DOM query       → undefined (correct — selector absent on homepage)  ✅

CDP path (reproduced the issue):

eval 1: document.title  → "BOSS直聘-..."  ✅  (before redirect)
eval 2: location.href   → "about:blank"  ❌  (redirected within ~100ms of attach)
eval 3: location.href   → "about:blank"  ❌

🤖 Generated with Claude Code