The whole browser surface
More than clicks: tabs, groups, forms, files, console, network, responsive testing, downloads, artifacts and human hand-off — exposed as MCP and HTTP.
brw
open source by Revitt
brw gives any agent fast, inspectable control of real Chrome and Chromium. Stable refs replace pixel hunting, every action reports what changed, and deterministic recipes turn proven browser work into a two-call run.
Latest release v0.13.5 · macOS · Linux · Windows
More than clicks: tabs, groups, forms, files, console, network, responsive testing, downloads, artifacts and human hand-off — exposed as MCP and HTTP.
Stable refs, action observations, batched plans, bounded reads and on-demand tool disclosure remove repeat screenshots and unnecessary round-trips.
Turn stable browser work into immutable recipes with exact origins, declared risk and durable postconditions — then search and run in two calls.
Bridges to the installed, signed-in browser you already use — Chrome, Chromium, Edge, Brave, Vivaldi, Opera or Arc. The sites you're logged into, brw is too, and cookies and sessions stay on your machine.
Bind profiles to workspaces with MCPlexer →Snapshot the actionable frontier or find one control by role, name, text or test id. brw returns stable refs like e17, not brittle selectors.
Click, type, fill, select, drag, upload or commit. The action returns URL, focus and changed elements, so the agent does not spend another turn asking whether it worked.
Trace or draft the successful mechanics, validate the semantic targets and install an immutable recipe. Next time: search, pin and run.
known workflowtwo calls
01 / searchbrw_recipe_search { query, origin }
Returns id, version, digest, risk and score — never the private steps.
02 / runbrw_recipe_run { id, version, digest, inputs }
Returns status, attempts, timings and artifact handles.
The fast everyday surface, built around stable refs and small observations.
Collapse browser work into fewer calls while preserving explicit checks.
Move proven workflows out of prompts and into a private, reviewable runtime.
The real browser stays visible, organised and under the operator's control.
See what the page, browser and server actually did.
Large or sensitive evidence stays beside the browser until explicitly read.
Need the smallest possible prompt? Use --mcp-tools auto, core or minimal. Every tool remains discoverable and directly callable.
Pre-armed semantic waits versus arming after a synchronous DOM reaction.
A bounded browser-host read instead of hauling the full payload across HTTP.
A compact artifact handle instead of inline base64 for a 1.31 MB capture.
The default auto profile at startup versus advertising all 62 tools every turn.
Reproducible Apple M4 Max samples from September 2026. These are brw engineering probes, not Claude measurements. Methods and caveats →
brw vs Claude in Chrome
Claude in Chrome is polished and capable. brw wins when you need an open, agent-agnostic control layer, deterministic execution or an API you own. Here is the fair comparison.
| Capability | brw | Claude in Chrome |
|---|---|---|
| What it is | Open browser-control infrastructure for agents and automation systems. | Anthropic's end-user browser agent inside Claude products. |
| Who can drive it | Any MCP client or HTTP client — Claude, Codex, Cursor, pi, your own service. | Claude Code, Claude Cowork and the Claude side panel. |
| Browser support | Chrome and Chromium, plus Edge, Brave, Vivaldi, Opera and Arc — any Chromium build, named with one flag. Local, or a remote browser host over SSH. | Google Chrome; other Chromium browsers are not supported. |
| Signed-in browser | Yes — bridge into an installed profile, or use a dedicated direct-CDP profile. | Yes — works alongside the user's signed-in Chrome session. |
| Control contract | Stable semantic refs, bounded reads, observations after actions, assertions, batch, plan, cancel and trace. | Reads, clicks, types, navigates and fills forms; also exposes screenshots, console, network and DOM context. |
| Efficiency evidence | Public local probes: 2.31× faster event settling, 51.9× less proxy transfer, 6,332× smaller capture results and 69.9% less initial tool context. | No equivalent low-level benchmark is published in Anthropic's feature guide; private brw runs were directionally faster, not a numeric public claim. |
| Reusable work | Private schema-validated recipes pinned by id, version and digest, with origin/risk/postcondition gates. | Recorded workflows in the classic side panel, reusable shortcuts and scheduled tasks. |
| Large outputs | Browser-host artifacts for text, JSON, images, PDFs, downloads and video, read back in bounded windows. | No comparable public artifact-handle API is documented. |
| Ownership | Self-hosted, AGPL-3.0 source, local data path, optional commercial licence. | Proprietary Anthropic service; available on paid Claude plans. |
Compared from public documentation checked 10 September 2026. Read Anthropic's current feature guide. Claude is an Anthropic product; brw is independent and is not affiliated with or endorsed by Anthropic.
start heremacOS and Linux
$ curl -fsSL https://brw.donworks.co.uk/install.sh | shThat command runs a shell script fetched over the network, so read it first. install.sh is served from this site as plain text, with no caching, and is the same file the command executes.
~/Library/Application Support/brw on macOS or ~/.local/share/brw on Linux, and symlinks brwd, brwctl, brwcheck and brw-devtools-mcp into ~/.local/bin. No sudo, nothing outside your home directory.brwctl setup.It reads no input, which is what makes the pipe safe. BRW_VERSION, BRW_INSTALL_DIR, BRW_BIN_DIR, BRW_BASE_URL, BRW_NO_SETUP and BRW_SKIP_ATTESTATION change what it does.
homebrewmacOS and Linux
brew install don-works/tap/brw installs the same tree into the formula prefix, which is then the app directory: brwctl doctor --app-dir "$(brew --prefix brw)". Run brwctl setup afterwards. The tap is bumped by the release workflow, so brew upgrade tracks releases.
macOS pkgAdmin and MDM installs
A universal .pkg that installs machine-wide under /usr/local. Take this route when you are deploying to someone else's machine, or when policy requires a package your MDM can ship. It needs administrator rights; the one-line installer does not.
linux.deb and .rpm
brw_<version>_linux_amd64.deb and the arm64 and .rpm equivalents, for systems that expect packages to come from the package manager. Installs to /usr/share/brw/.
windows.msi
brw_<version>_windows_amd64.msi and an arm64 build. Puts the brw commands on PATH and the extension, tests and licence under C:\Program Files\brw\share\.
setupWhat brwctl setup does
Inside the pipe it is non-interactive: it prints the plan, performs it and exits. On a terminal it asks first. brwctl setup --dry-run lists every action without performing one. Nothing it writes is outside your home directory and no step uses sudo.
~/Library/Application Support/brw/browser-profiles.json on macOS and ~/.config/brw/browser-profiles.json on Linux, merging into an existing one rather than replacing it.127.0.0.1:17310 for control and 127.0.0.1:17311 for the bridge. If a service already drives that profile or holds those ports, it reports what it found and writes nothing.claude mcp add. --mcp-client codex or both covers Codex; --mcp-client none prints the mcpServers block for you to paste.~/.claude/skills/brw, ~/.agents/skills/brw and ~/.codex/skills/brw.thenConnect a browser
Loading the extension is the one step brwctl setup cannot do for you. The bridge drives a browser you are already signed into, so that browser needs the brw extension. One permanent extension id, trusted by the daemon with no configuration:
amocjcgddnoakjijfggdpnefdnboilpe
/etc/chromium/policies/managed/. macOS uses a configuration profile, Windows a .reg file or the matching GPO.chrome://extensions → Developer mode → Load unpacked → the extension/ folder. A Chrome Web Store build is being prepared for review. No listing exists yet, so load-unpacked is the Chrome path until one does.# setup prints this line with your workspace filled in
$ brwctl doctor --workspace brw-chrome-profile
# before the extension is loaded and the browser restarted,
# doctor reports it missing and exits non-zero. That is expected.# then check it end to end
$ curl -s 127.0.0.1:17310/api/browser/open \
-H 'content-type: application/json' \
-d '{"url":"https://example.com"}'
# a visible tab opened; read its controls
$ curl -s 127.0.0.1:17310/api/page/snapshot | jq# build from source instead
$ git clone https://github.com/Don-Works/brw.git
$ cd brw
$ make build
$ ./bin/brwd --mcp --http offRemote browsers, multi-profile policies and SSH-first setups are in the install docs.
| Capability | Extension bridge | Direct CDP |
|---|---|---|
| The browser it drives | The Chrome, Chromium, Edge, Brave, Vivaldi, Opera or Arc you already have open and signed in. | A separate Chromium browser that brw launches, on a profile brw owns. |
| Where the logins come from | Sessions, cookies and passkeys that are already in that profile. | Sign in once with brwd --login; the profile keeps the session for later headless runs. |
| Chrome tab groups | Yes — chrome.tabGroups keeps the agent's tabs in one labelled group. | No. chrome.tabGroups is an extension API with no DevTools Protocol equivalent. |
| Incognito contexts | No. | Yes — brw_open_incognito opens an isolated context, brw_close_context disposes it. |
| Cookie tools | No. The extension refuses every cookie CDP method, HttpOnly included, to protect the signed-in profile. | Yes — brw_cookies lists, sets and deletes, HttpOnly cookies included. |
| Downloads | Files land in the browser's own download folder. Capturing the bytes as an artifact can need macOS Files & Folders consent; the metadata-only event does not. | Deterministic — files are staged in brw's private cache, no Downloads access needed. |
| Headless | No. --headless with --bridge is refused rather than ignored. | Yes, once the profile has been signed into. |
| How it starts | brwd --bridge, plus the extension loaded in that browser. | brwd --mcp --http off. No extension involved. |
brw_identity reports which transport a namespace is on, so an agent can check before it assumes a capability. Read the auth model.
Daemon, CLI and extension are in one public repository under one licence.
A checksum proves a file matches the release. An attestation proves which workflow and which commit built it.
No release artifact carries a platform code-signing signature today, on any operating system.
A release builds only after the gate in the public workflow file.
The daemon trusts that id with no configuration.
These refusals are implemented in the extension's service worker.
# the file matches the release
$ shasum -a 256 -c SHA256SUMS.txt
# the release came from this repository's workflow
$ gh attestation verify brw_<version>_macos_universal.pkg \
--repo Don-Works/brwBoth checks run against artifacts from the releases page. The workflow that produces and attests them is in the repository.
safety
brw uses a normal visible browser and a persistent user profile. It does not add stealth code, CAPTCHA bypass, MFA bypass, fraud-check bypass or consent bypass. The installed-profile extension refuses HttpOnly cookie and bulk storage access; explicit cookie tools exist only for dedicated direct-CDP profiles, and the extension privacy policy lists every refusal. Browser-control HTTP binds to loopback by default, recipes declare their risk, and mutating requests are guarded. For remote use, prefer stdio MCP over SSH so the profile stays on the machine that owns it. Released under AGPL-3.0 — free to use, change and build on, with improvements shared back. If that doesn't fit your business, talk to Revitt about a commercial licence.