`extension connect` rewrote argv to ["connect", <relay-url>] but the connect path
reads flags.cdp — parsed earlier from the original argv ("extension connect" →
None). So the relay URL was dropped and the daemon ran AUTO-CONNECT, grabbing
whatever Chrome it could discover: a stale remote-debugging Chrome on :9222
(indefinite hang), or triggering Chrome's "Allow remote debugging?" prompt on
machines without one. This is the EAGAIN/hang hermes hit on --session connect.
Fix: set flags.cdp = Some(relay_url) (+ disable auto_connect) in the
extension-connect branch so the daemon connects to the live relay endpoint.
Diagnosed via local repro (trace showed connect_cdp resolving ws://...:9222/
devtools/browser/... instead of the relay's ws://...:<port>/<guid>).
The nm-host fanned extension→client messages over a broadcast channel and
forwarded commands under the client's own id, so two sessions connected to one
relay collided: command replies went to every client and ids overlapped → the
2nd session's connect hung (EAGAIN after 30s×5) and responses cross-talked.
Now the relay demultiplexes:
- each forwarded command is re-keyed to a relay-global id mapped to (client,
original_id); the extension's reply routes back to ONLY that client with its
original id restored (relay.rs: pending map + ClientId)
- CDP events fan out to all clients (they ignore unknown sessions)
- nm-host keeps a client_id -> sender registry instead of a broadcast; clients
are unregistered + their pending dropped on disconnect
Unblocks concurrent multi-agent on one shared Chrome (each --session its own tab
group from fork.20). relay.rs: 9 unit tests incl. cross-client id isolation.
Shared browser, separate tab groups: when an agent drives the user's real Chrome
via ab-connect, every tab it opens lands in a Chrome tab group named after its
--session (stable color per name). Each agent's tabs stay visually separated from
other agents' and from the user's own (ungrouped) tabs. Visibility is NOT
restricted — all agents still see all tabs (per design).
- CreateTargetParams gains an optional non-CDP `agentGroup` hint (skip-if-none),
so a strict real-Chrome endpoint never receives it
- BrowserManager.agent_group(): Some(session) only when ws_url == the live
ab-connect relay URL (never on launched/direct CDP); DAEMON_SESSION set at
daemon start supplies the name; emitted at all createTarget sites (transient
storage target stays None)
- ab-connect: +tabGroups permission; Target.createTarget reads agentGroup and
groups the new tab (create/reuse by title, deterministic color), best-effort
- extension 0.3.0 -> 0.4.0; re-signed crx + zip (id unchanged)
Needs the v0.4.0 extension reloaded + a build with this change to take effect.
Release binaries / Build macOS ARM64 (push) Has been cancelled
Release binaries / Build macOS x64 (push) Has been cancelled
Release binaries / Build Linux ARM64 (push) Has been cancelled
Release binaries / Build Linux musl ARM64 (push) Has been cancelled
Release binaries / Build Linux musl x64 (push) Has been cancelled
Release binaries / Build Linux x64 (push) Has been cancelled
Release binaries / Build Windows x64 (push) Has been cancelled
Release binaries / Attach binaries to GitHub Release (push) Has been cancelled
Transport (native messaging + extension connect) works today via Load unpacked.
Silent force-install is pending the Chrome Web Store listing going live (off-store
force-install is [BLOCKED] on unmanaged Chrome 149).
Verified on Chrome 149 (unmanaged macOS): a force-install policy pointing at a
SELF-HOSTED crx is tagged [BLOCKED] in chrome://policy ("Error, Warning") — Chrome
refuses off-Web-Store force-installs on non-cloud-managed browsers. So the
self-hosted-crx approach cannot work on consumer Chrome; the extension must ship
via the Chrome Web Store (same reason codex/claude do).
- UPDATE_URL -> Chrome Web Store update endpoint; add STORE_URL (one-click Add to
Chrome) as the guaranteed path + headless fallback
- install instructions now offer: A) one-click store link, B) silent profile
force-install (works once published), with Load-unpacked as the pre-publish stopgap
- build extensions/ab-connect.zip (CWS upload package; manifest "key" kept so the
published id stays ciiljdlhdpfckdcfkphgmfalanpdejep)
- extensions/store/{SUBMISSION.html,privacy.html}: full listing copy, permission
justifications (debugger is the review-sensitive one), privacy policy
- drop dead self-hosted extensions/updates.xml; pack-extension.sh now builds the zip
Not released yet — force-install only works after the store listing is Published.
Chrome 149 killed every GUI-free way to load an *unpacked* extension into the
real profile: --load-extension removed in Chrome 142 (incl. the
--disable-features workaround), local-.crx external install blocked on macOS
since Chrome 44, remote-debugging-port killed in Chrome 136. So agents were
stuck automating the chrome://extensions Load-unpacked native file dialog —
unworkable.
`extension install` now writes a macOS configuration profile that force-installs
the signed .crx from a hosted update_url (ExtensionInstallForcelist policy). One
approval in System Settings (a single fixed Install button — cua-driver-friendly,
unlike a file dialog) → Chrome force-installs + auto-updates the extension on next
launch. No token, no per-use confirmation, and binary-install users no longer
need the extensions/ folder (crx is fetched from the URL).
- pin a stable signing key; new extension id ciiljdlhdpfckdcfkphgmfalanpdejep
- ship signed extensions/ab-connect.crx + extensions/updates.xml (raw GH host)
- scripts/pack-extension.sh re-signs with the stable key; .secrets/*.pem ignored
- uninstall removes the profile file + prints `profiles remove` hint
So an agent can operate the zero-confirmation real-Chrome feature itself:
- SKILL.md: tool matrix gains "the user's own already-open, logged-in window →
extension connect", plus a short section pointing at the flow.
- commands.md: the one-time "Load unpacked" is a privileged GUI step the CLI
can't do — call it out that the agent can perform it with a computer-use /
GUI-automation tool (cua-driver), with the live gotchas (synthetic-keystroke
tools like peekaboo don't reach Chrome; cua-driver does; the native file
dialog may need the user to pick the folder).
Completes the zero-confirmation real-Chrome feature.
- Drive the user's EXISTING logged-in tabs (not just newly-created ones):
extension attachTab now treats "already attached" (a lingering chrome.debugger
binding after a service-worker restart) as success and announces the tab
anyway, instead of skipping it. The nm-host also sends {method:"attachAll"}
when an agent-browser CDP client connects, so the daemon doesn't race an empty
target list.
- `agent-browser extension connect` auto-discovers the relay's CDP url
(~/.agent-browser/relay-cdp-url) and attaches — no copying a ws URL. Rewrites
into the normal `connect <url>` flow; `extension install/status/uninstall`
unchanged.
- Skill docs: a "drive your real, logged-in Chrome (extension)" section.
Verified end-to-end: `extension connect` listed the user's real tabs (Lark,
LINUX DO, Rakuten, Discord) and read a logged-in Lark doc's title — zero token,
zero confirmation. Full suite 768 passed.
The __nm-host now exposes a Chrome-compatible CDP WebSocket endpoint and bridges
it to the extension over native messaging via the relay translation core
(relay.rs): incoming raw CDP commands are answered locally for browser-level
Target discovery or forwarded to the extension as forwardCDPCommand; the
extension's forwardCDPEvent/results are relayed back as raw CDP.
Security without a token or user interaction: the ws URL carries an unguessable
guid and is written to ~/.agent-browser/relay-cdp-url (perms 600), so only this
user's agent-browser can drive the browser — mirroring how Chrome guards its own
remote-debugging URL.
Verified end-to-end on real Chrome: `agent-browser connect <relay-url>` then an
eval navigated a tab and read back "Example Domain | https://example.com/" —
abs → CDP → relay → native messaging → extension → chrome.debugger → real tab,
zero token, zero confirmation. Adds the tokio io-std feature for the host's
stdio.
Remaining polish: re-attach the user's EXISTING tabs after a service-worker
restart (currently attaches new tabs cleanly; existing ones need detach+reattach
since chrome.debugger may still be bound), and an `open --extension` UX that
reads relay-cdp-url so the URL isn't passed by hand.
Optimal architecture (chosen over the WS+token copy): the ab-connect extension
talks to a local agent-browser native-messaging host. No localhost port, no
token — Chrome authenticates the extension to the host by id. This is the
codex/claude-style "install once, no per-use confirmation" model.
- extensions/ab-connect: rewritten transport WebSocket+token → native messaging
(chrome.runtime.connectNative). Pinned the extension id via a manifest `key`
(→ bdoiejojpjogcjojeladhioioijhgade) so the host manifest can authorize it.
Kept the proven chrome.debugger attach + Target.attachedToTarget emulation;
dropped WS/token/options. Rebranded to "agent-browser connect".
- cli connect.rs: `agent-browser extension install` writes the native-messaging
host manifest (Chrome/Chromium/Edge/Brave) + a launcher; hidden `__nm-host`
speaks the 4-byte-length native-messaging framing.
Validated end-to-end on real Chrome: Chrome spawned the host (origin matched the
pinned id) and the extension attached the user's real logged-in tabs, streaming
Target.attachedToTarget over native messaging — zero token, zero port.
Next: bridge the host to the daemon relay (relay.rs) + CdpClient so
`agent-browser click/eval/...` drives those tabs.
Pure, unit-tested core of the daemon-side relay that bridges the ab-connect
extension to the existing CdpClient. The extension exposes per-tab
chrome.debugger + synthesized Target events; CdpClient expects a browser-level
endpoint. So RelayState:
- answers Target.getTargets / attachToTarget / setDiscoverTargets LOCALLY from
targets learned via the extension's forwardCDPEvent(Target.attachedToTarget),
returning the extension's cb-tab-N sessionId (consumes those synth events
rather than double-forwarding them);
- forwards every other command as a forwardCDPCommand envelope (carrying
method/params/sessionId);
- maps forwardCDPCommand responses and forwardCDPEvent events back to raw CDP;
- validates the connect-handshake token; emits challenge/ping.
Keeps CdpClient and browser.rs unchanged. 8 unit tests; clippy clean. Still
inert — the tokio WS server + `connect` command wire it next.
First step toward zero-confirmation direct connect to the user's real Chrome:
Chrome 136 killed --remote-debugging-port on the default profile, so the only
sanctioned way to drive the user's live logged-in window is an extension using
chrome.debugger (same approach as Codex/Claude, whose extensions are closed).
Vendors the MIT-licensed openclaw-browser-relay extension into
extensions/ab-connect/, rebranded to "agent-browser connect" (NOTICE.md keeps
attribution). It already handles the hard parts: chrome.debugger auto-attach all
tabs, new-tab auto-attach, MV3 service-worker keepalive (alarms) + reconnect,
sessionId↔tab mapping, token auth, and a CDP-over-WebSocket envelope
(connect handshake / forwardCDPCommand / forwardCDPEvent / ping-pong).
Inert for now — not wired. Next: an abs-daemon relay that speaks this envelope
and bridges it to the existing CdpClient (raw CDP), then a `connect` command.
Borrow web-access's site-experience persistence as an agent-workflow convention
(no CLI code): keep one markdown file per domain under
~/.agent-browser/site-patterns/<domain>.md. Read it before working a domain
(hints, not guarantees); update it after learning something durable — working
selectors, required hidden fields, anti-bot traps, login needs. Makes repeat
visits fast instead of re-solving the same page every run.
Borrow web-access's find-url: locate an internal system or a previously-saved
page that public search can't reach, without opening a browser.
- `agent-browser find-url <keywords> [--browser chrome|edge] [--profile X]
[--limit N] [--json]` — local command, no daemon. All keywords must match a
bookmark's name or url; results are most-recently-added first.
- Cross-platform Bookmarks JSON paths (macOS / Linux / Windows), zero new deps
(serde_json). Skips javascript:/data: bookmarklets.
- Skill docs: "pick the cheapest tool" matrix now points at find-url, plus a
commands.md section.
Bookmarks only for now — visited-history is a locked SQLite DB and would need a
SQLite dependency (deferred to avoid C-dep cross-compile risk in the release
pipeline).
Real dogfooding showed the skill pushed agents straight into the fragile
snapshot/@ref path. Reframe the core guidance toward how a developer actually
drives a real browser:
- "Pick the cheapest tool" matrix: WebSearch / WebFetch+curl for static, reach
for agent-browser only when you need a real logged-in / interactive / dynamic
browser. Plus: don't hand-build deep URLs — use links found by interacting.
- "Two ways to drive a page": structured (@ref/find) is convenient but lossy &
fragile; eval-first (`eval "<js>"`) is the real DOM — read hidden inputs,
Shadow DOM, form.elements/.validity, or el.click() directly. Drop to eval the
moment the structured path fights you, instead of retrying it.
- Escalation ladder rewritten (refs → find → CSS → eval) and a note to retry a
no-op click with AGENT_BROWSER_CLICK_MODE=dom.
Doc-only; closes the biggest part of the "abs feels worse than web-access" gap.
Real-world dogfooding surfaced clicks that resolve a valid @ref but still miss:
- Scroll the target into view before computing click coordinates
(scrollIntoViewIfNeeded). Without it, an element below the fold — or revealed
after a scroll/popup — yields off-viewport coordinates and the click lands on
whatever occupies that screen point.
- Fall back to a DOM-dispatched `.click()` when the coordinate path fails (a
persistent floating layer failing the occlusion guard, or coordinates that
won't resolve). The DOM dispatch targets the intended element directly instead
of a screen point, so an overlay or portal can't divert it.
- AGENT_BROWSER_CLICK_MODE: "" (default: scroll + coordinate + DOM fallback),
"coord" (strict coordinate, hard-fail on occlusion), "dom" (always
element.click() — best for autocomplete/menu <li> that close on input blur).
Fallback is limited to left single-clicks (DOM .click() can't express
right/middle/double). Non-left/multi and "coord" mode keep the original error.
Docs: README knob table + skill commands.md gain CLICK_MODE, a click-reliability
note, and a "debug forms/hidden inputs with eval" section (snapshot doesn't show
hidden inputs — the fast path to bugs like a hidden point_choice=none).
6 click/interaction e2e green; full suite 760 passed.
console/errors capture is off by default in this fork (Runtime.enable is a
detectable CDP signal). Update the agent-facing skill docs so agents don't
treat empty console output as a bug:
- commands.md: new "Stealth / anti-detection knobs" env-var block
(CAPTURE_CONSOLE, TIMEZONE, BLOCK_WEBRTC, HIDE_CANVAS, ADAPTIVE_REF) plus a
heads-up note; annotate the console/errors lines.
- dogfood/slack SKILL.md: note that console/errors need
AGENT_BROWSER_CAPTURE_CONSOLE=1.
- snapshot: make collect_fingerprints private (TreeNode is private, so a
pub(super) fn leaked a more-private type)
- adaptive: if-let instead of single-arm match in attr_score
- stealth: move timezone test module to end of file (items-after-test-module)
No behavior change. Pre-release cleanup.
Borrow Scrapling's adaptive element finding, adapted to this project's
in-session AX-ref model. When a saved @ref's node is gone (or its identity
no longer matches) and the role/name/nth re-query also fails, score the
current page's candidate elements against an AX fingerprint captured at
snapshot time and relocate to the best match.
- New `adaptive` module: pure, browser-free scoring (role, accessible name
via Levenshtein, AX properties, ancestor-role LCS, parent/sibling) plus
pick_best with a high absolute threshold (0.70) AND a clear margin (0.15)
over the runner-up — so ambiguous twins are refused rather than mis-clicked,
matching the existing "fail loudly over wrong click" posture.
- Fingerprint captured during the existing AX-tree snapshot walk — no extra
CDP round-trips. TreeNode is AX-only (no DOM tag/attrs), so we use AX role
as the type and a few discriminating AX properties (value/url/level/checked);
DOM id/class would have cost an N×describeNode storm per snapshot.
- Wired into both resolve_element_center and resolve_element_object_id: on a
verify-identity mismatch or a stale-node fallback miss, relocation is tried
before erroring. A confident match overrides the identity guard; otherwise
the original error is surfaced. Opt out with AGENT_BROWSER_ADAPTIVE_REF=0.
README documents the new tuning knobs. Adds 9 unit tests; full suite 760 passed.
Borrow anti-detection hardening from Scrapling/patchright, preferring native
CDP/Chrome overrides over JS lies:
- Runtime.enable is now opt-in via AGENT_BROWSER_CAPTURE_CONSOLE (default off).
It was called on every session INCLUDING CdpAttach (the user's real Chrome),
leaking the patchright/rebrowser "runtime" CDP signal and undermining the
"real browser, no lies" guarantee. Runtime.evaluate/callFunctionOn and
runIfWaitingForDebugger work without it; only console/error capture needs it.
The console/errors commands now return a hint when capture is disabled.
- Timezone alignment via native Emulation.setTimezoneOverride, opt-in with
AGENT_BROWSER_TIMEZONE=<IANA>|auto (FullLaunch only). Intl and Date both
follow with no JS artifact.
- WebRTC IP-leak handling via the --force-webrtc-ip-handling-policy Chrome
flag: auto disable_non_proxied_udp when a proxy is set (so the real IP can't
leak past the proxy); AGENT_BROWSER_BLOCK_WEBRTC=1 hides the local IP when
there is no proxy; =0 opts out.
- Opt-in canvas/audio fingerprint noise via AGENT_BROWSER_HIDE_CANVAS=1
(FullLaunch only). Session-stable seed so reads stay consistent within a
session while differing from the headless-stable hash.
Adds 5 unit tests; full suite 751 passed, 0 failed.
install.sh created `agent-browser` + `abs` but not `agent-browser-stealth`, so
users who invoke `agent-browser-stealth` (the fork's package name) weren't
getting it updated on curl-install/upgrade. Now all three names — agent-browser,
agent-browser-stealth, abs — symlink to the same binary, so an upgrade refreshes
whichever name you actually run.
Release binaries / Build macOS ARM64 (push) Has been cancelled
Release binaries / Build macOS x64 (push) Has been cancelled
Release binaries / Build Linux ARM64 (push) Has been cancelled
Release binaries / Build Linux musl ARM64 (push) Has been cancelled
Release binaries / Build Linux musl x64 (push) Has been cancelled
Release binaries / Build Linux x64 (push) Has been cancelled
Release binaries / Build Windows x64 (push) Has been cancelled
Release binaries / Attach binaries to GitHub Release (push) Has been cancelled
`agent-browser-stealth upgrade` no longer installs the wrong upstream npm
package; it re-runs the GitHub-Release install.sh in place. CI actions bumped
off Node 20.
`agent-browser-stealth upgrade` (inherited from upstream) queried
registry.npmjs.org/agent-browser and ran `npm/pnpm install -g
agent-browser@latest` — installing the UNRELATED upstream `agent-browser`
package and clobbering the user's stealth install (reported in testing).
The stealth fork ships via GitHub Releases, so `upgrade` now just re-runs
install.sh into the same directory as the current binary — identical to the
install path, always tracking the freshest Release. (Windows prints manual
download instructions.)
Also bump CI actions off the deprecated Node 20 runtime (GitHub forces Node 24
on 2026-06-16): checkout v4->v6, upload-artifact v4->v7, download-artifact
v4->v8, action-gh-release v2->v3.
Release binaries / Build macOS ARM64 (push) Has been cancelled
Release binaries / Build macOS x64 (push) Has been cancelled
Release binaries / Build Linux ARM64 (push) Has been cancelled
Release binaries / Build Linux musl ARM64 (push) Has been cancelled
Release binaries / Build Linux musl x64 (push) Has been cancelled
Release binaries / Build Linux x64 (push) Has been cancelled
Release binaries / Build Windows x64 (push) Has been cancelled
Release binaries / Attach binaries to GitHub Release (push) Has been cancelled
Stops agents from silently launching a temporary empty profile (no login).
Adds --profile auto, warns on bare --launch, and recommends --profile auto in
connect-failure errors. Addresses issue #1 follow-up.
Addresses the footgun raised in issue #1 follow-up: plain `--launch` silently
uses a temporary EMPTY profile (no cookies/login), and the connect-failure
error even recommended it — trapping agents into thinking they reused the
logged-in browser when they didn't.
- `--profile auto`: resolves to the Chrome profile last used (from Local State
`profile.last_used`), falling back to "Default", then the first profile. So
`--launch --profile auto open <url>` reuses real login state without naming
the profile. (--profile <name>/Default already worked.)
- connect-failure error now recommends `--launch --profile auto` and states
plainly that bare `--launch` is a temporary EMPTY profile — no cookies/login.
- bare `--launch` (no --profile, not CI) now prints a warning to that effect.
- README: fix Setup (relaunch with --remote-debugging-port, not chrome://inspect)
and split Standalone mode into throwaway vs. keep-your-login (`--profile auto`).
Tests: resolve_chrome_profile("auto") prefers last_used, falls back to Default.
Addresses issue #1. The "Setup (one time)" section told users to toggle
chrome://inspect, which only enables target discovery and is NOT enough to
attach — the most-reported first-run failure. Replace with the correct model:
relaunch Chrome with --remote-debugging-port (a startup flag), expect the
Chrome 136+ "Allow remote debugging?" consent dialog, and use --launch as a
zero-setup fallback. Add a "Command names" note that agent-browser /
agent-browser-stealth / abs are the same binary (stealth is runtime behavior,
not a separate executable).
Release binaries / Build macOS ARM64 (push) Has been cancelled
Release binaries / Build macOS x64 (push) Has been cancelled
Release binaries / Build Linux ARM64 (push) Has been cancelled
Release binaries / Build Linux musl ARM64 (push) Has been cancelled
Release binaries / Build Linux musl x64 (push) Has been cancelled
Release binaries / Build Linux x64 (push) Has been cancelled
Release binaries / Build Windows x64 (push) Has been cancelled
Release binaries / Attach binaries to GitHub Release (push) Has been cancelled
`abs skills get core` now works on GitHub-Release/install.sh installs (skill
content is embedded in the binary and extracted to a cache dir on first use).
First release via the automated tag-push -> release-binaries CI flow.
`skills get core` (the first step the agent-browser skill stub tells agents to
run) failed with "Skills directory not found" on a GitHub-Release / install.sh
install: only the binary is shipped, with no adjacent skills/ or skill-data/
the way an npm install bundles them, so find_package_root() returned nothing.
Embed skills/ and skill-data/ into the binary via include_dir (168K) and, when
no on-disk skill dirs are found, extract them once to a per-version cache dir
($CACHE/agent-browser/skills-<version>/) and serve from there. npm/dev installs
still use the on-disk dirs unchanged.
Verified: from an isolated dir (no skills/ nearby), `skills list` shows all 6
skills and `skills get core` serves content.
install.sh resolved the latest tag through api.github.com/.../releases/latest,
which rate-limits unauthenticated callers to 60/hr and returned 403 in testing.
Use the github.com/<repo>/releases/latest 302 redirect instead (web host, not
rate-limited) and parse the tag from the resolved /releases/tag/<TAG> URL.
Verified: `curl … install.sh | sh` resolves v0.27.0-fork.11, downloads the
darwin-arm64 asset, verifies the .sha256, installs agent-browser + abs.
Distribute the prebuilt binary through GitHub Releases instead of the npm
registry — zero auth for the publisher (CI's GITHUB_TOKEN) and zero auth for
consumers (no npm token / 2FA / OTP, no GitHub Packages .npmrc).
- install.sh: detects OS/arch (incl. linux musl), downloads the matching
agent-browser-<platform>.tar.gz from the GitHub Release, verifies .sha256,
installs `agent-browser` + `abs` to /usr/local/bin or ~/.local/bin.
Override via AGENT_BROWSER_VERSION / AGENT_BROWSER_BIN_DIR.
- .github/workflows/release-binaries.yml: on tag push (v*), build all 7
platform variants (reusing the zigbuild cross-compile matrix), package each
as .tar.gz + .sha256, attach to the tag's GitHub Release. No npm, no token.
- remove .github/workflows/release.yml: it published to npm (--provenance) and
built the (removed) dashboard, so it broke on every main push.
- README install now leads with `curl … install.sh | sh`; npm demoted to a
legacy alternative.
- skill stub self-heals: if `agent-browser` is missing, run install.sh (don't
fall back to other browser tools).
Fixes the longstanding FullLaunch (--launch) stealth gap: handle_launch's
fresh-launch path now calls apply_stealth_to_browser, so the 32 JS fingerprint
patches and the HeadlessChrome→Chrome UA strip run on launched browsers (they
never did before — only the launch flags applied).
Verified FullLaunch headless: navigator.webdriver=false,
navigator.userAgent=Chrome/<v> (no HeadlessChrome), new tabs + initial page
clean, bot.sannysoft.com 0 failed / 31 passed.
handle_launch's fresh-launch path (the path `--launch open <url>` takes) never
called apply_stealth_to_browser — only the launch FLAGS were applied (e.g.
--disable-blink-features=AutomationControlled, which is why navigator.webdriver
was already false). As a result the 32 JS fingerprint patches and the
Emulation.setUserAgentOverride HeadlessChrome→Chrome UA strip NEVER ran on a
launched browser: navigator.userAgent kept the HeadlessChrome marker (a
longstanding bug — identical on the prior prebuilt binary).
Add the apply_stealth_to_browser call after launch (the auto_launch path
already had it; only the explicit-launch path was missing it).
Verified, FullLaunch headless:
- navigator.webdriver === false, navigator.userAgent => Chrome/<v> (no Headless)
- new tabs and the initial page both clean
- bot.sannysoft.com: 0 failed / 31 passed
Fixes since fork.9 (UX audit batch):
- stealth: per-session coverage so new tabs (tab new) and cross-origin iframe
sessions get patched (were unpatched/detectable)
- stealth: navigator.webdriver = false (boolean), not undefined — never delete
the property (undefined is itself a detection tell)
- hygiene: sweep orphaned temp Chrome profiles on daemon startup (only dirs no
live process references) — fixes the kill -9 temp-dir disk leak
- ux: success-with-no-data prints "Done" instead of a silent exit 0
- ux: top-level aliases for `get` reads (url, cdp-url, title, html, text, ...)
- ux: clearer connect errors (consent dialog, "startup flag" guidance, and
--cdp on Chrome 136+ points to auto-connect)
Known follow-up (not in this release): FullLaunch (--launch) browsers don't get
the JS patches / UA-strip applied (navigator.userAgent still shows
HeadlessChrome); secondary to the primary CdpAttach mode. Tracked for a
dedicated fix.
The webdriver patch deleted navigator.webdriver, leaving it `undefined`. Real
Chrome reports `false`, so `undefined` is itself a detection tell, and deleting
it also removes the native `false` that Emulation.setAutomationOverride sets.
Now we rely on setAutomationOverride for a native (undetectable) `false` and
only force `false` via a getter as a fallback when webdriver is still `true`
(older Chrome without that override) — never delete it. Verified: FullLaunch
headless now reports navigator.webdriver === false (boolean), consistently.
- output: a success response with no data payload now prints "Done" instead of
nothing (a silent exit 0 looked like a no-op).
- commands: add top-level aliases for `get` status reads — `url`, `cdp-url`
(and `cdp_url`), `title`, `html`, `text`, `value`, `count`, `box`, `styles`,
`attr` — so `agent-browser url` no longer errors "Unknown command".
- connect errors now explain the Chrome 136+ realities:
- connect-failure mentions the "Allow remote debugging?" consent dialog and
that remote debugging is a startup flag, not a setting.
- no-Chrome error tells the user to relaunch Chrome with
--remote-debugging-port (auto-connect then works).
- --cdp discovery failure explains Chrome 136+ dropped the HTTP discovery
endpoints and to use the default auto-connect instead.
Stealth coverage (the fork's core value was leaking on secondary surfaces):
- stealth scripts are registered per CDP session, so new tabs (`tab new`) and
cross-origin iframe sessions created after the initial page had NO patches.
Extract apply_stealth_via_mgr/apply_stealth_to_session and re-apply on
tab_new and on iframe attach. Fixes automation markers (and FullLaunch UA)
leaking in new tabs / cross-origin frames.
Resource hygiene (temp profiles filled the disk):
- ChromeProcess::drop already cleans the temp user-data-dir on normal exit, but
a hard kill (kill -9 / version-mismatch restart / crash) skips Drop and leaks
~50MB per session. Add cleanup_orphaned_chrome_profiles() on daemon startup
that sweeps agent-browser-chrome-* temp dirs NOT referenced by any live
process (so an in-use profile is never deleted).
Upstream cherry-picks (onto v0.27.0 base):
- security: same-origin stream command relay (#1355)
- feat: hide scrollbars in headless screenshots (#1396)
- chore: pnpm minimum release age + node pinning (#1377, fork-adapted)
Fork fixes:
- fix(connect): stop remote-debugging consent storm — is_connection_alive no
longer tears down an externally-attached browser on a transient liveness
timeout (was an endless prompt loop / browser freeze)
- fix(connect): single consenting WebSocket — drop the throwaway verify probe
so the user's one "Allow remote debugging?" click sticks to the real
connection
auto-connect resolved the DevToolsActivePort URL by first opening a
verification WebSocket (verify_ws_endpoint: connect, Browser.getVersion,
close) and only then opening the real connection. On Chrome 136+ the
"Allow remote debugging?" consent is granted per-connection, so the user's
single Allow click was consumed by the throwaway probe and the real
connection (opened afterwards) asked again — surfacing as repeated prompts
or a hung command after the user had already clicked Allow.
resolve_cdp_from_active_port now gates the direct DevToolsActivePort URL on
a consent-free TCP liveness check (tcp_port_alive) instead of a WebSocket
probe, so the real connection is the single WebSocket the user consents to.
A bare TCP connect does not trigger the consent flow (that fires on the CDP
upgrade), and the real connect_async has no client-side timeout, so it waits
for the user to click Allow at their own pace. verify_ws_endpoint removed;
discovery-order tests updated, plus a guard test that resolution opens no
WebSocket.
Verified live: single prompt on a real Chrome attach, then open + eval +
scroll x2 + eval with zero re-prompts and no freeze.
The daemon re-validates the CDP connection before every browsing command via
is_connection_alive() (Browser.getVersion, 3s timeout). It treated any
timeout-or-error as "dead" and tore the connection down + reconnected.
For an externally-attached browser (the stealth fork's default — the user's
real Chrome), a timed-out probe is almost always Chrome being briefly busy or
showing the Chrome 136+ "Allow remote debugging?" consent modal, which blocks
CDP responses until the user clicks Allow. Tearing the already-consented
connection down forces a reconnect that re-pops the consent prompt — repeated
on every command this becomes an endless prompt loop, and the close +
multiple new /devtools/browser WS probes storm Chrome into a freeze.
Fix: distinguish the probe outcome.
- Responded -> alive
- TransportError -> dead (WS closed/reset; user closing Chrome lands here too,
so zombie-socket detection is preserved)
- TimedOut -> alive for an external attach (don't tear down a consented
connection on transient slowness); dead for a browser we
launched ourselves (a real hang worth reconnecting, and no
consent modal in play).
Extracted the verdict into a pure connection_alive_from_probe() with unit
tests covering all outcomes. No behavior change for locally-launched browsers.
Cherry-picks upstream agent-browser #1396. Adds a configurable
--hide-scrollbars flag (AGENT_BROWSER_HIDE_SCROLLBARS env, hideScrollbars
config key, default true) that appends Chrome's --hide-scrollbars launch arg
for headless (non-extension) launches so native scrollbars aren't painted into
screenshots. Plumbed through flags.rs, connection.rs, main.rs, native/actions.rs
and native/cdp/chrome.rs; help text in output.rs + skill-data.
Fork adaptation:
- the arg lands in the headless && !has_extensions block, separate from the
stealth base args — no interaction with anti-detection.
- dropped upstream docs/, agent-browser.schema.json and README hunks (removed
or rewritten in this fork).
Verified: cargo check --tests passes.
leeguooooo