Feature idea: opt-in CDP Runtime instrumentation for browsing vs debugging

[amxv]

Motivation: browsing and web-app debugging have different CDP needs

First, I saw the decisions in #120 and #506 to keep general anti-detection/stealth features outside core, and I agree this is a sensible boundary. This is a narrower request about controlling a specific CDP domain, rather than asking agent-browser to incorporate fingerprint spoofing or a universal stealth mode.

There are two common workflows with agent-browser:

1. Developing and testing our own web apps, where continuously collecting console messages and uncaught exceptions is genuinely useful.
2. Browsing/researching third-party websites, where we mostly need navigation, DOM/a11y snapshots, interactions and eval. The continuous CDP Runtime event stream is usually unnecessary, yet its instrumentation can itself cause false-positive automation detections.

In v0.41.1, agent-browser enables Runtime.enable when preparing page and auto-attached sessions (including paths in cli/src/native/browser.rs, actions.rs, and state.rs). Rebrowser's runtimeEnableLeak and DeviceAndBrowserInfo's isAutomatedWithCDP can identify that instrumentation even after ordinary Chrome startup flags have removed navigator.webdriver and the headless user-agent mismatch.

What we tested

On Apple Silicon macOS, agent-browser 0.41.1, Chrome 156, November 3, 2026:

Setup	Rebrowser	DeviceAndBrowserInfo	ScrapingCourse's Cloudflare test page
Default headed/headless	runtimeEnableLeak red	Detected as bot, roughly 3–4/22 signals	Stuck on verification
Chrome startup flags only (AutomationControlled disabled; matching native headless UA)	Runtime leak still red	CDP automation remained the last positive signal in the best run	Passed with both flags
Browsing build with Runtime disabled after initialization	Zero red findings, runtimeEnableLeak green	0/22 bot signals, isAutomatedWithCDP: false	Reached the challenge test content

The patched build retained open, snapshot, and eval in smoke tests. SannySoft also reported no failed checks; NowSecure loaded. Rebrowser still had four yellow warnings, and G2 still returned a DataDome CAPTCHA. These are single-machine, small-sample test observations, not claims of universally bypassing protections.

Proposed opt-in capability

Would you consider exposing a Runtime-domain / console-observability opt-out for browsing sessions, while keeping the existing developer behavior as the default? For example (illustrative API):

agent-browser --runtime-events off open https://example.com
# Or AGENT_BROWSER_RUNTIME_EVENTS=off for the session's lifetime

The essential effect is to avoid leaving Runtime.enable active in the relevant CDP sessions. It should preserve normal navigation, snapshots, interactions and JS evaluation; console/page-error streams may be unavailable in this mode and should be documented accordingly. A lazy or pluggable CDP-domain lifecycle would also be useful if it fits the architecture better.

Importantly, the existing --args and launch.mutate plugin APIs can modify Chrome launch flags/init scripts, but cannot stop agent-browser's own Runtime.enable calls. That is the gap motivating this request. No change to default behavior or generic stealth implementation would be needed.

Reproducible implementation and results

We've maintained an unofficial, release-tracking Apple Silicon browsing variant so we can preserve the full official CLI for debugging:

• Source patch and GitHub Actions build: https://github.com/amxv/agent-browser-browse
• Exact experimental results (including limitations): https://github.com/amxv/agent-browser-browse#detection-test-results
• Published v0.41.1 binary: https://github.com/amxv/agent-browser-browse/releases/tag/v0.41.1
• Patch implementation: https://github.com/amxv/agent-browser-browse/blob/main/scripts/patch_upstream.py

The current patch sends Runtime.disable immediately after the four relevant Runtime.enable commands and bakes in tested Chrome defaults. We'd be happy if the maintainers prefer this to remain an external patch, but a small opt-in hook at the CDP domain layer would let users implement such browsing profiles without permanently maintaining a fork.