An open, self-hosted browser-control layer for AI agents.
A Manifest V3 extension that drives your real, logged-in browser over CDP,
exposed as one open protocol any backend — and any LLM — can drive. Navigate, click,
type, screenshot, read pages, fill forms, run JavaScript, and inspect console/network.
MIT licensed. Bring your own model.
by Cereon Labs
Use with MCP · How it compares · Use cases · Protocol · FAQ
Browser Operator is a Manifest V3 Chrome/Chromium extension that turns your
browser into a CDP (Chrome DevTools Protocol) automation agent. Your software
pushes { id, tool, args } commands and receives { commandId, result } back —
that's the entire contract (PROTOCOL.md).
It is the browser-control layer — the "hands," not the "brain." It doesn't ship an LLM and doesn't decide what to do on its own. You point your own backend at it — fastest path is the bundled MCP server, so any MCP client (Claude Desktop, Cursor, Cline, Claude Code) drives your browser with no custom code. Or wire it to your own loop calling Claude, GPT, Gemini, or a local model (Ollama / LM Studio), in any language. No vendor lock-in, no cloud dependency, no per-seat subscription — self-hosted AI browser automation that you own end to end.
- MCP-native — the bundled
mcp-server/exposes every tool to any MCP client; add one line to your config. - Pluggable transport — SSE+HTTP (remote) or WebSocket (local), chosen in settings.
- Token auth — paste a token your backend (or the MCP server) issues. No accounts, no consent flow.
- 14 tools (plus 4 reserved) — tabs, navigate, the multi-action
computer(13 actions), accessibility tree, find, form input, JavaScript, console/network capture, and more (catalog). - Configured at runtime — one build, point it anywhere; nothing about a backend is compiled in.
- Safe by design — the extension only acts inside a dedicated automation tab group; your normal tabs are off-limits.
Your backend ──commands──► Browser Operator ──CDP──► the page
Your backend ◄──results─── Browser Operator
(SSE+HTTP or one WebSocket; see PROTOCOL.md)
Browser Operator is the hands — something has to connect to it. Two audiences, one short guide → docs/usage.md:
- You use a product that supports it (e.g. Cereon CRM) — install the extension, click Connect in the product, approve in the popup. No tokens, no config. → End-user guide
- You're a developer — drive it yourself or embed it in your product: (A) add the bundled MCP server and pair in one click; (B) embed it in your platform with one-click pairing (how Cereon CRM does it); or (C) script your own backend. → Developer guide
The ready-made backends below get you driving the browser the fastest.
The fastest path — no custom backend. The bundled MCP server lets Claude Desktop, Cursor, Cline, or Claude Code drive your real browser.
# One pnpm install at the repo root sets up the extension AND the MCP server
# (single workspace, single lockfile — no per-directory installs).
pnpm install
pnpm build # then load ./dist in chrome://extensionsAdd it to your MCP client config (claude_desktop_config.json / .mcp.json):
{
"mcpServers": {
"browser-operator": {
"command": "node",
"args": ["/abs/path/to/cereon-browser-operator/mcp-server/server.mjs"],
"env": { "OPERATOR_TOKEN": "dev-token" }
}
}
}Once the MCP server is published to npm you can skip the local path and use
"command": "npx", "args": ["-y", "cereon-browser-operator-mcp"] instead.
Then connect the extension — one click: open http://localhost:8787/pair,
click the toolbar icon, and press Connect (or set it manually in
Configure…: WebSocket, ws://localhost:8787, token dev-token). Now ask your
AI client: "open example.com and screenshot it." Full setup:
mcp-server/.
The tools Browser Operator actually competes with are Playwright MCP (Microsoft) and Chrome DevTools MCP (Google) — both are mature, well-resourced ways to drive a browser from an agent. For most "let an agent drive a browser" jobs, reach for one of those first. Browser Operator is the better fit in a narrower band:
| Browser Operator | Playwright MCP / Chrome DevTools MCP | |
|---|---|---|
| What it is | MV3 extension + open protocol | MCP server driving a managed/attached browser |
| Acts in your browser | Yes, by default — your real, open, logged-in session | Possible via a flag (persistent profile / connect-over-CDP) |
| Embed & white-label | Yes — re-skin in one file, ship in your product | Not a goal — consumed as a third-party MCP server |
| Driven over | An open protocol you point at your own backend | MCP |
| Maturity | New (2026), small surface | Mature / official, broad ecosystem |
| Cross-browser / depth | Any Chromium; tab-group safety boundary | Playwright: cross-browser · CDP MCP: perf traces, network |
So pick Browser Operator when you specifically want an extension that acts in the user's real, logged-in browser, embedded and branded inside your own product, over a protocol you control. Otherwise Playwright MCP / Chrome DevTools MCP are the pragmatic default.
Full breakdown — including the bundled agent products (Claude for Chrome, Nanobrowser, Browser Use, BrowserOS) — in docs/comparison.md.
- Open & MIT — read every line, audit it, fork it, ship it. No black box.
- Model- and framework-agnostic — one open protocol; wire up any LLM or no LLM. You're never locked to a vendor's model or roadmap.
- Self-hosted & private — runs on your machine; your pages and data don't go to anyone's cloud unless your backend sends them.
- One build, point anywhere — backends are runtime configuration, not compile-time. Switch from a localhost script to production without rebuilding.
- Forkable & white-label — re-skin the whole extension from one file and ship it inside your own product (BRANDING.md).
- Safe by construction — only tabs inside the automation tab group accept commands, so an agent can't reach into your everyday browsing.
Browser Operator is the automation surface for agentic web workflows, QA, scraping, and RPA:
- AI web agents — let an LLM read a page (accessibility tree + text), pick a tool, act, and loop. Wire any model in ~30 lines →
- Build-test-verify for coding agents — pair with Claude Code: build in the terminal, then drive the browser to test and read console errors, network requests, and DOM state.
- Data extraction / scraping —
read_page/get_page_text/findto pull structured data from rendered pages. - Form automation & RPA —
form_input+computerto fill and submit repetitive workflows. - Embed in your own product — point the extension at your own server; anything that speaks the protocol can drive it.
Full recipes (incl. the LLM agent loop) in docs/use-cases.md.
Prefer to drive it yourself instead of via MCP? Try it end-to-end with the bundled reference backend:
# 1. build + load the extension (the root install also covers examples/)
pnpm install && pnpm build # then load ./dist in chrome://extensions
# 2. run the bundled reference server
OPERATOR_TOKEN=dev-token node examples/reference-server.mjsIn the extension popup → Configure…: transport WebSocket, auth Token,
server URL ws://localhost:8787, token dev-token. Save, then Connect.
Drive it:
node examples/cli-driver.mjs tabs_context_mcp '{"createIfEmpty":true}' # note the tabId
node examples/cli-driver.mjs navigate '{"url":"example.com","tabId":123}'
node examples/cli-driver.mjs computer '{"action":"screenshot","tabId":123}'See examples/ for details, and PROTOCOL.md to build
your own backend.
TypeScript, bundled with esbuild into self-contained scripts. Source in src/,
static assets in static/, build output in dist/.
src/
├── shared/ # protocol types, brand config, errors, logger, constants, utils
├── config/ # ConnectionConfig + ConfigStore (runtime backend settings)
├── background/
│ ├── transport/ # Transport interface + SSE/HTTP + WebSocket + factory
│ ├── auth/ # AuthProvider + TokenAuth
│ ├── cdp/ input/ screenshot/ tabs/ content-bridge/ # the automation engine
│ └── tools/ # one class per tool (computer/ = action strategies)
├── content/ # in-page DOM introspection (a11y tree, find, forms)
├── options/ # settings page
└── popup/ # status + connect/disconnect
mcp-server/ # MCP server bridge (drive the browser from any MCP client)
examples/ # reference backend + CLI driver (implements PROTOCOL.md)
Requires Node.js 22+ and pnpm, plus any Chromium browser. This is a single
pnpm workspace — one pnpm install at the root wires up the extension, the
MCP server, and the reference backend.
pnpm install
pnpm build # bundles src/ -> dist/Load unpacked: chrome://extensions → enable Developer mode → Load unpacked
→ select dist/. Each install gets its own extension id — exactly what an
independent, token-authenticated tool wants.
pnpm watch # rebuild on change
pnpm typecheck # tsc --noEmit (strict)
pnpm test # Vitest unit suite
pnpm lint # eslint
pnpm format # prettier --write (format:check is the CI gate)
pnpm check # format:check + lint + typecheck + test + build (the full CI gate)Open Configure… from the popup and set:
- Transport —
SSE + HTTP(remote server) orWebSocket(local). - Server URL + (for SSE/HTTP) command/result paths, optional
target. - Token — the bearer token your backend (or the MCP server) issues.
Then Connect from the popup. Implement the matching backend per PROTOCOL.md, or use the bundled MCP server / reference server.
Re-skin in one file (src/shared/brand.ts) plus the manifest name and icons —
ship your own branded browser operator inside your product. See
BRANDING.md.
Those are mature, well-resourced MCP servers that drive a browser for an agent — for most jobs they're the pragmatic default. Browser Operator's difference is that it's a Manifest V3 extension acting in the user's own, already-logged-in browser by default, driven over an open protocol you can embed and white-label inside your own product (the bundled MCP server is just one backend). It's also an open, self-hosted alternative to closed first-party agents like Claude for Chrome — you own the model, the data path, and the brand. See the comparison for when to pick which.
The extension is free and MIT licensed. It needs no API key itself. If your backend uses a hosted LLM, you bring (and pay for) that model's key — or run a local model and pay nothing.
Any of them, because the model lives in your backend, not the extension. Claude, GPT, Gemini, Llama, local Ollama/LM Studio — or no LLM at all if you're scripting deterministic automation. See docs/use-cases.md.
It runs entirely on your machine and talks only to the backend URL you configure. Your pages and data never leave your stack unless your backend chooses to send them. There is no Browser-Operator cloud.
Any browser-using AI agent carries prompt-injection risk — malicious instructions hidden in a page can try to hijack the agent. Browser Operator narrows the blast radius: it only acts inside a dedicated automation tab group (your everyday tabs are untouched), and you control the model, the system prompt, and the allowed tools. Treat untrusted pages with the same caution you would any agent, and keep a human in the loop for sensitive actions.
Any Chromium-based browser that supports Manifest V3 and the debugger API — Chrome, Edge, Brave, Arc, and others. (Claude for Chrome is Chrome-only.)
Those bundle the agent loop and LLM calls inside the tool. Browser Operator is the control layer: it exposes the browser over an open protocol and lets your backend run the loop, in any language or framework. More flexible if you're building your own agent; see docs/comparison.md.
No. Use the bundled MCP server for any MCP client, the reference server for scripting, or implement the protocol in your own software. Nothing about any one backend is compiled in.
Yes — that's a first-class path. A product can connect your browser with one click (no token to paste) and drive it from its own backend, using the vendor-neutral pairing handoff. Cereon CRM is the reference example — Settings → MCP → Browser Operator → Connect. If you're building such a product, see docs/usage.md → For developers.
Open foundation, built in the open. Roughly what's next — and where help is most welcome (each is a self-contained contribution; see CONTRIBUTING.md):
- Publish the MCP server to npm so
npx -y cereon-browser-operator-mcpjust works — the release pipeline is wired, pending the first tagged release. - A recorded demo GIF + screenshots for the README and a social-preview image (see docs/assets/).
- Implement the reserved tools —
gif_creator(in-browser recording),shortcuts_list/shortcuts_execute,switch_browser(currently honest stubs; see PROTOCOL.md). - More reference backends in other languages (Python first) to sit alongside the Node example.
- Broader example agent loops — additional model providers wired in docs/use-cases.md.
- An end-to-end smoke test that loads the unpacked extension into a headed Chrome in CI and drives a real navigate + screenshot — today's suite unit-tests the pure logic (parsers, transports, config); the CDP engine itself isn't yet exercised against a live browser.
- Wider browser/CI coverage — exercise the matrix against more Chromium builds.
Have an idea that isn't here? Open an issue or a discussion — the protocol is designed to be extended.
Browser Operator is community-driven and vendor-neutral — contributions welcome.
See CONTRIBUTING.md. All PRs must pass
pnpm check (format · lint · typecheck · test · build) — the same gate CI runs.
If it helps you,
star the repo and
open an issue with
ideas or bugs.
If Browser Operator is useful to you, a ⭐ helps others find it.
MIT — built by Cereon Labs. Use it, fork it, ship it.