browserlane packages WebDriver BiDi into one local Rust binary. Humans use the CLI; agents use MCP or learn the CLI through a Skill. Every specification capability is tracked in public.
{ "name": "browser_click", "arguments": { "selector": "@e2" } } → clicked · 96 ms
Built on the W3C-standard bidirectional protocol. Every specification capability — module, command, event — belongs in the engine parity model.
A single Rust binary for macOS, Linux, and Windows. Browser, sessions, data, and artifacts stay on your machine — no cloud.
CLI for humans and scripts. MCP for agents. A Skill that teaches agents the CLI, token-efficiently. One engine underneath.
Modules, commands, events, implementation status, and Chrome verification — tracked openly, gaps included.
Architecture
Humans and scripts take the CLI. Agents connect over MCP, or learn the CLI through a Skill. All three routes end at the bl engine, which speaks WebDriver BiDi to Chrome.
CLI, MCP, and Skill are curated doors into the same bl engine — the same sessions and the same capabilities underneath, whichever way you come in.
MCP exposes structured tools for useful user intentions. It deliberately does not mirror every BiDi primitive 1:1 — that would bloat an agent’s tool catalog without adding capability.
The Skill is one file that teaches an agent token-efficient CLI workflows. It reuses the composable CLI surface and implements no separate browser capability.
Protocol internals can stay internal — implemented and tested in the engine — without earning a dedicated command or tool. Engine parity and surface exposure are tracked separately.
Every WebDriver BiDi capability must be reachable through the engine. Only capabilities representing a useful user intention should receive dedicated CLI commands or MCP tools.
WebDriver BiDi parity
We track every WebDriver BiDi module, command, and event against the bl engine, its user intention, CLI exposure, MCP exposure, Skill workflow, and Chrome support — in public, gaps included.
Spec capabilities
89
65 commands · 24 events, from the W3C Working Draft
Engine coverage
100%
89 covered · 0 gaps — the goal is complete specification parity
How it's covered
89 native
0 covered another way — shimmed, consumed events, or lifecycle alternatives
Verification baseline
82 integrated
82 verified on Chrome · 0 awaiting runtime verification · 0 not integrated · 7 other
nativecovered another waygap
5 native · 0 covered another way · 0 gaps
7 native · 0 covered another way · 0 gaps
29 native · 0 covered another way · 0 gaps
11 native · 0 covered another way · 0 gaps
18 native · 0 covered another way · 0 gaps
9 native · 0 covered another way · 0 gaps
3 native · 0 covered another way · 0 gaps
1 native · 0 covered another way · 0 gaps
4 native · 0 covered another way · 0 gaps
2 native · 0 covered another way · 0 gaps
Engine parity is measured at the protocol, not at the command line. Capabilities can be covered by the engine while staying internal, and one CLI command or MCP tool can serve several capabilities — so a missing dedicated command is not an engine gap, and surface counts are not a parity score.
tracking W3C Working Draft 2026-06-29 · last verified 2026-07-16
Three surfaces
The same engine answers to a human at a shell, to an agent over MCP, and to an agent that has been taught the CLI through a Skill. Each surface is intentionally curated for its user; all three route into the same engine and session model.
CLI · humans & scripts
Composable commands with structured JSON where it helps and real exit codes everywhere — for interactive use, scripts, and CI.
MCP · AI agents
Tools that represent useful intentions — not one tool per BiDi primitive — over stdio JSON-RPC. Same engine, same sessions as the CLI.
$ bl add-mcp claudeMCP reference →Skill · token-efficient agents
One skill file teaches an agent token-efficient CLI workflows — no large tool catalog in context, and no separate browser capability to maintain.
$ bl add-skillSkill reference →The Skill is not another protocol implementation — it teaches an agent the CLI, so agents with shell access get the whole engine at a fraction of the context cost. Every route ends at the same bl engine.
The browser stack
Browser, sessions, tabs, pages, elements — then state, signals, environment, evidence. browserlane gives agents and developers a handle at every layer — not just a screenshot of the top one.
01 · Browser shell
One command launches a visible Chrome over WebDriver BiDi. Navigate, wait, reload, capture. Every run is a real render of your real app, not a DOM emulation.
02 · Parallel sessions
Give each workflow its own named session — separate cookies, storage, and tabs — and drive them in parallel from one warm daemon. Log in as several users at once with no state crossing between them. Add --isolated and a session gets its own browser process, so a crash stays contained.
03 · Tabs & contexts
Within a session, tabs are enumerable and addressable — open, list, and switch by index or URL. A warm daemon keeps the session alive between commands, so multi-tab flows stay scriptable.
04 · Page & frames
Each tab shows a page, and every page — frames included — is readable: query by CSS, role, label, text, or XPath, and read the accessibility tree the way assistive tech does.
05 · Elements & input
Map every interactive element to a stable @ref an agent can act on, then drive it with real pointer and keyboard events — actionability checks built in: click, type, fill, drag, press. If a human can do it in the page, an agent can script it.
06 · State & auth
Snapshot cookies, localStorage, and sessionStorage as a named state; restore it in the next run. Log in once, then test authenticated flows on every run after — no scripted logins.
07 · Console & network
Recordings capture console output and network activity alongside snapshots — the failed POST and the stack trace behind it travel with the run, not just the final pixels.
08 · Emulation
Resize to any device, override geolocation, and force CSS media features like dark mode or reduced motion — per session, without touching app code.
09 · Observability & reporting
Assertions with real exit codes, structured diffs between steps, annotated screenshots, replayable recordings — all captured locally. When a run fails, you open the evidence — you don’t reproduce the failure.
Observability & reporting
Most browser tools tell an agent what the page looks like. browserlane also tells it what happened — assertions with exit codes, structured diffs, and recordings that carry console and network context. A failing run becomes evidence to read, not behavior to guess at. It all stays on your machine.
Assertions · real exit codes
State diffs · between steps
Recordings · replayable runs
Screenshots · annotated evidence
Quickstart
One line to install, one command to fetch Chrome for Testing, and you’re driving a real browser — from your shell or your agent.
1 · Install — macOS / Linux
Windows (PowerShell)
2 · Fetch Chrome for Testing
3 · First commands
For agents · MCP server or CLI skill