WebOperator — AI browser agent and MCP server for Chrome automation

Tell Chrome what you want done, in plain English, and let the agent do it.

Most browser agents bring their own browser. WebOperator works the one you are already in: the tab in front of you, with your sessions and logins intact — no separate profile, no re-login, no copying cookies around. The model behind it can be local, served by Ollama or MLX, so the pages you look at never have to leave the machine. And it works in both directions: the local bridge exposes that same live tab over MCP, so Hermes, OpenClaw, or any other agent client can borrow your browser as a tool.

git clone https://github.com/KazKozDev/WebOperator.git
npm --prefix WebOperator/core ci
npm --prefix WebOperator/core run build

Your goal, typed once · The agent plans, acts, verifies · Every step visible

Quick start

Two ways in. If you would rather not touch Node, grab the weboperator-1.5.0-chrome.zip archive from the latest release and unzip it — that folder is the built extension.

If you ran the commands above instead, the build lands in core/dist and finishes in well under a second:

vite v8.0.11 building client environment for production...
✓ 101 modules transformed.
✓ built in 189ms

Either way, open chrome://extensions, enable Developer mode, click Load unpacked, and point it at the folder you just got. Press Cmd+Shift+K (Ctrl+Shift+K on Linux) to open the side panel, pick a provider under Settings, and type a goal.

Out of the box the agent talks to Ollama at http://127.0.0.1:11434, so have a tool-capable local model running before your first task — or paste an API key and use a remote provider instead.

Automate a multi-step task across your open Chrome tabs

WebOperator works the tab you are looking at in a plan → act → verify loop: it writes out a plan you can read, calls one browser tool at a time, and checks each result against a fresh snapshot of the page before moving on.

Summarize the current page

It can navigate, click, type, press keys, scroll, switch tabs, screenshot, and pull out structured text — so the same loop still works when the answer is scattered across half a dozen open tabs.

Compare info across tabs

The side panel streams the plan, every action, and the final answer, and keeps the full trace; history, checkpoints, and scheduled runs each get their own tab. The flip side: the agent only knows what it can actually see in the browser, so anything hidden, paywalled, or geo-blocked simply will not show up in the answer.

• Agent engineering — a plan, act and verify loop, 29 browser tools, 6 loop guards
• LLM security — the prompt-injection attack rate down from 44.4% to 0.0% across 9 adversarial fixtures
• LLM evaluation — AssistantBench and 24 fixtures in a deterministic harness, see docs/evals.md
• MCP — the browser exposed as an MCP server with 10 tools for any agent client

Schedule recurring browser automation in Chrome

Some tasks you want done whether or not you are at the keyboard. Give a schedule a start URL, a goal, and a cadence — once, hourly, daily, or weekly — and Chrome alarms wake the agent on time, even with the side panel closed.

Task name:  Morning release check
Start URL:  https://github.com/KazKozDev/WebOperator/releases
Repeat:     daily
Goal:       Tell me if a new version was published since yesterday

Every run lands in History with its trace, so you can go back afterwards and see exactly what it did. If a run hits something only you can clear — a login wall, a verification challenge — it stops and marks itself needs_user rather than failing quietly.

Connect Hermes, OpenClaw, or another MCP agent

Your live browser can be somebody else's tool. The local bridge speaks MCP over stdio and exposes ten of them: browser_snapshot, browser_navigate, browser_click, browser_type, browser_press, browser_scroll, browser_screenshot, browser_extract, browser_solve_captcha, and weboperator_execute_goal.

cd weboperator-bridge
./install.sh
node mcp-server.js

install.sh registers the Native Messaging host that wires those calls to your active Chrome or Brave tab. Drop-in configs for Hermes and OpenClaw are already in weboperator-bridge/.

How it works

A goal arrives from the side panel or from an external MCP agent. From there the service worker runs the show — model calls, task state, retries, verification, schedules, storage. The content script does the hands-on part: it turns the page into an accessibility snapshot with stable element refs, then performs DOM actions against those refs. Whatever the page says is treated as data, never as instructions to follow. Twelve built-in skills sit on top as domain playbooks and kick in when the agent recognizes a matching site or task.

goal → page snapshot → model tool call → verified action → trace

Contributing