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
- stealth(plugins): stop overwriting real native navigator.plugins in headed
mode (the JS fake had a non-native item(), broken uint32 wrap → incolumitas
overflowTest FAIL, and an anachronistic Native Client plugin). Leave native
plugins untouched when present; modernize the headless-escape fallback to the
real 5 PDF-viewer set with masked-native item()/namedItem().
- connect: auto_connect_cdp() now prefers the dialog-free ab-connect relay over
the raw :9222 CDP port, so Chrome 136+'s "Allow remote debugging?" consent
modal no longer fires when the extension relay is live. Gated by a bare-TCP
relay_is_live() probe (+3 unit tests).
- extension: rename ab-connect to "agent-browser-stealth" + new stealth icon set
(16/32/48/128).
- docs(README): hero/shield/fingerprint images, expanded detector results
(CreepJS 0% stealth, incolumitas all-OK, BrowserScan CDP-clean), and a
"Verify it yourself" section. .gitignore: allow assets/ + extension icons.
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.
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
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.
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.
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.
leeguooooo