Skip to main content
The actionbook browser command lets AI agents automate any Chromium-based browser. Three modes are available depending on the use case:
Normal usage: run actionbook setup once, then use actionbook browser ... commands only.

Modes

All three modes are designed for AI agents:
  • Local gives agents a clean, reproducible environment.
  • Cloud offloads the browser to a remote provider, suited for production workloads, parallel execution at scale, or IP geolocation control.
  • Extension lets agents operate inside the user’s real browser when the task requires existing authentication (e.g., “book my flight”, “reply to that email”).

Local Mode

Works out of the box with no setup. The CLI launches a temporary Chrome process with a dedicated profile and connects via CDP.
When done, close the browser:

Cloud Providers

Cloud mode lets you run browser sessions on a remote provider instead of launching a local Chrome. Use the -p (or --provider) flag with browser start:

Supported Providers

Quick Start

1

Export your provider API key

2

Start a cloud browser session

The CLI creates a remote browser session and returns the session_id and tab_id for subsequent commands.
3

Use browser commands as usual

All browser commands work the same way. The session runs on the cloud provider transparently.
4

Close when done

This terminates the remote browser session and releases provider resources.

How It Works

  • -p <name> automatically implies --mode cloud, so you don’t need to set both
  • -p is mutually exclusive with --cdp-endpoint and --mode local/extension
  • The CLI forwards provider env vars from your current shell to the daemon at start time (the daemon’s own env is frozen at spawn)
  • browser restart --session <id> mints a fresh remote session while preserving the same session_id, so you can reset state without losing your addressing handle
For raw CDP connections without a managed provider, use --mode cloud --cdp-endpoint wss://... instead of -p.

Extension Mode Setup

Extension mode is under active development. For most use cases, Local or Cloud mode is recommended.
If you’ve configured mode = "extension" in your config file, you only need to perform this one-time setup.
1

Install from Chrome Web Store (recommended)

  1. Open Actionbook on Chrome Web Store
  2. Click Add to Chrome
  3. Confirm Add extension
2

Verify with any browser command

The extension bridge (part of the actionbook daemon) auto-starts in the background and the extension auto-connects within a few seconds.
3

Fallback: local debug install (only if Web Store install fails)

  1. Install the fallback package:
  1. Open chrome://extensions
  2. Enable Developer mode
  3. Click Load unpacked
  4. Select the local folder printed by:

Extension Commands

The actionbook extension commands manage the Chrome extension and its connection to the actionbook daemon. The recommended install method is the Chrome Web Store (current version: 0.4.0). actionbook extension install is a local fallback — after running it, you must manually load the unpacked extension in Chrome via chrome://extensions > Developer mode > Load unpacked, using the path from actionbook extension path.
The extension bridge runs inside the actionbook daemon (auto-started by browser commands). extension status shows whether the bridge is listening and the extension is connected. extension ping tests connectivity by connecting to the bridge WebSocket at ws://127.0.0.1:19222.
Extension 0.4.0: Tabs opened by Actionbook are automatically grouped into a Chrome “Actionbook” tab group (toggleable via extension popup). list-tabs in extension mode now returns only Actionbook-managed tabs — other user tabs are hidden. Extensions below 0.4.0 are rejected at handshake.

Configuration

The recommended way to set your preferred browser mode is via actionbook setup. It writes your choice to ~/.actionbook/config.toml, so you can run browser commands without extra flags.

Set Default Mode

Create or edit ~/.actionbook/config.toml:
Once configured, all browser commands will automatically use your chosen mode:

Browser Commands

Most commands work in all modes. All per-tab commands require --session and --tab flags to address a specific tab.

Session Lifecycle

Both --session and --set-session-id are get-or-create: they reuse a Running session with the given ID, or create one if not found.
When reusing a session, if --profile is passed and does not match the session’s bound profile, the command fails with SESSION_PROFILE_MISMATCH. Omit --profile or pass the matching value to reuse.

Tab Management

For running parallel tasks across multiple tabs, use Multi-Session with the --session flag instead of manual tab switching.

Page Interaction

Use @eN refs from snapshot output directly as selectors (e.g., actionbook browser click @e5 --session s1 --tab t1).

Wait Conditions

wait network-idle is edge-triggered: it only tracks fetch/XHR requests started after the command begins. Pre-existing background connections (SSE, WebSocket, analytics pings) are ignored and do not block. This is an agent-friendly settle signal, not a guarantee of global network silence.

Observation & Export

har start accepts --max-entries N to set the ring-buffer cap (default: 10000).
When har stop detects dropped entries, the envelope includes meta.truncated = true and a HAR_TRUNCATED warning in meta.warnings with the drop count and configured cap. Read data.dropped and data.max_entries to decide whether to raise --max-entries or stop recording sooner.

File Upload

Multi-Session (Parallel Tabs)

Available since v0.11.0. Requires local mode (default).
Multi-session lets you run multiple independent tabs in a single browser instance. Each named session is bound to its own tab, so commands sent to one session never affect another.

Basic Usage

Use the --session flag to name a session:
Without --session, commands use a default session.

Session Management

Common Mistakes

Don’t create multiple profiles or ports for parallel tabs. Use --session instead.
Combine action manuals with browser automation for the best results:

Shutdown

browser close is idempotent — closing an unknown or already-closed session returns ok: true with a warning in meta.warnings, not an error. Safe to call unconditionally during cleanup without checking session existence first. Read meta.warnings to distinguish a fresh close from an already-gone session.

Extension Security

Extension mode connects via a local WebSocket bridge with the following guarantees:
  • The bridge only listens on 127.0.0.1 (loopback), no external network access
  • No token or pairing is required; local origin is sufficient for authentication
  • The extension identifies itself via a WebSocket handshake with role and version fields
  • The bridge validates the connection source (origin + extension ID) before accepting commands

Eval Error Handling

browser eval accepts the expression from three mutually-exclusive sources: a positional argument, --file <path>, or stdin (-). browser eval returns structured error codes on failure. Branch on error.code instead of parsing the message string: Runtime errors (after browser execution): CLI-layer errors (before any browser interaction):
For EVAL_RESPONSE_NOT_OK and EVAL_RESPONSE_NOT_JSON, inspect error.details.body_head (first ≤256 chars of the response body) to decide whether to retry — a 403 challenge page is not worth retrying blindly.

CDP Error Handling

Browser commands that interact with elements, navigate, or communicate via CDP return structured CDP_* error codes. Branch on error.code: When error.code is a CDP_* code, error.details includes reason (raw CDP message) and cdp_code (upstream numeric code) when available. CDP_NAV_TIMEOUT also includes timeout_ms.
CDP_NAV_TIMEOUT and CDP_TARGET_CLOSED set error.retryable = true in the JSON envelope — orchestrators can auto-retry these. All other CDP codes require caller intervention (e.g. refreshing snapshot refs, scrolling elements into view).
Some interaction paths (cookies, screenshots, PDF, etc.) still emit the legacy CDP_ERROR code. These are being migrated to the structured CDP_* taxonomy (ACT-999).

Troubleshooting

  • Run any browser command once: actionbook browser open <url> (this auto-starts the bridge)
  • Keep Chrome open and confirm the Actionbook extension is enabled in chrome://extensions
  • First startup can take a few seconds while the bridge starts and the extension reconnects
  • This usually means the WebSocket handshake did not complete
  • Update CLI: npm update -g @actionbookdev/cli
  • Reinstall from Chrome Web Store
  • If needed, use fallback install: actionbook extension install --force, then reload it in chrome://extensions
  • Click Connect in the extension popup to retry
  • Re-run actionbook setup and choose your preferred browser mode
  • Check effective config with actionbook config show
  • Environment variables (for example ACTIONBOOK_BROWSER_MODE) can override config
  • Make sure Chrome has at least one visible, active tab
  • Run actionbook browser open <url> first to attach a tab
  • Avoid chrome:// pages; the debugger cannot attach to them
  • Browser mode currently uses a fixed bridge address: ws://127.0.0.1:19222
  • Stop the conflicting process on that port (macOS/Linux: lsof -i :19222)
  • Then retry your browser command; the bridge will auto-start again
  • Retry Web Store install: Actionbook on Chrome Web Store
  • Use local debug fallback: actionbook extension install
  • Load it manually from chrome://extensions with Load unpacked
  • If GitHub API is rate-limited during fallback, wait and retry or download from GitHub Releases