Repo of the day: dev-browser, the browser that lets the agent verify its own work

🔍 What dev-browser is

dev-browser is, verbatim, «a Claude Skill to give your agent the ability to use a web browser». In practice it's a small command-line runtime: the agent writes a JavaScript script that drives a page with Playwright's API — go to a URL, click, fill, evaluate, take a screenshot — and dev-browser runs it. What sets it apart from a plain Playwright script is three design choices: execution is sandboxed, pages are persistent, and the connection to the browser is automatic.

Sandboxed means the script doesn't run in Node.js but inside a QuickJS sandbox compiled to WebAssembly, with no access to the host's filesystem or network: it can drive the browser, not your computer. Persistent means a page opened in one script stays alive for the next, so the agent navigates once and then interacts over several steps without restarting each time. Automatic means it attaches to the Chrome you already have open — handy for working on your session, with your logins — or launches a clean headless Chromium when a fresh environment is needed.

repo       SawyerHood/dev-browser
what       a browser the agent drives via Playwright scripts
sandbox    QuickJS in WebAssembly, no host disk or network access
pages      persistent: navigate once, interact across scripts
connect    to your running Chrome (--connect) or a fresh Chromium
license    MIT · TypeScript + Rust · backed by the company Do Browser

⚙️ How to install it and the first script

Installation is that of a global npm package: you install dev-browser and then run the command that downloads Playwright and Chromium. From there the simplest use is to pipe a script on standard input: open a page, go to an address, read the title. Anyone who wants to work on their own session — cookies and logins included — enables Chrome's remote debugging and launches in connect mode, so the agent uses the browser the person is already using.

The recommended way to hand it to an agent is disarming: after installing, you just tell it to run the help command. The output isn't the usual list of flags but a usage guide written for an LLM, with examples and an API reference — so the agent learns how to use it on its own, with no plugin or skill to install. The classic route is still available, as a Claude Code plugin or a skill copied into Amp's or Codex's folder, for those who prefer it.

# Global install + browser
npm install -g dev-browser
dev-browser install     # downloads Playwright + Chromium

# A first script: open a page and read the title
dev-browser --headless <<'EOF'
const page = await browser.getPage("main");
await page.goto("https://example.com", { waitUntil: "domcontentloaded" });
console.log(await page.title());
EOF

# Or attach to the Chrome you already have open
dev-browser --connect

🧩 How an agent uses it: the sandboxed API

Inside the script the agent has a few clear globals. There's a browser object to get a page by name, create a temporary one, list open tabs or close one. There's a small set of functions to save a screenshot or read and write files, but confined to a dedicated temporary folder: the sandbox again, protecting the rest of your disk. And every page is a full Playwright Page object, with all the methods you'd expect.

The part built specifically for agents is the two «tiers» of control each page exposes, plus a snapshot made for LLMs. The pixel tier takes a screenshot whose points map one-to-one onto the page's coordinates and lets the agent click, drag, scroll and type at those coordinates — the «vision» way of operating. The DOM-id tier instead produces a list of the visible interactive elements each with an identifier, and the agent acts by citing the id: more robust when the page is structured. Having both means the agent picks the right approach for the situation, instead of being forced into one.

// Browser control
browser.getPage(name)      // page by name, or connect to a tab
browser.newPage()          // temporary page, cleaned up after the script
browser.listPages()        // list of tabs: id, url, title, name

// Every page is a full Playwright Page
await page.goto(url); await page.click(sel); await page.fill(sel, val);
await page.snapshotForAI();   // page snapshot, formatted for an LLM

// Two action tiers built for agents
page.cua.*      // pixel: screenshot + click/scroll/type at coordinates
page.domCua.*   // DOM id: numbered visible elements, act by id

📊 Why it's fast: the author's numbers

The obvious question is: why not use Playwright MCP directly, or Claude's browser extension? The author published a small benchmark, with the methodology in a dedicated repo, comparing four ways of giving a browser to the agent on the same task. dev-browser closes it in about four minutes, with 29 turns and under a dollar of cost, at 100% success. Playwright MCP also reaches 100%, but with 51 turns and nearly double the cost; the Playwright skill and the Chrome extension are slower and, in the skill's case, less reliable.

The underlying reason is the architecture: a Playwright server that stays running keeps pages alive, and agentic scripts do more per turn instead of a slow «observe–think–act» loop at every micro-step. Fewer turns mean fewer tokens spent and less time lost, which on an agent you pay by usage is exactly what matters. Read them for what they are — the author's measurements on one task, not an independent benchmark — but the direction is consistent with the design.

🏢 Why it matters, for developers and SMBs

For developers, dev-browser closes a loop that usually stays open: the agent that writes interfaces can finally try them. It builds a screen, opens it, clicks the button, fills the form, checks the right message appears — and if it doesn't, it notices, not me the next day. It's the same spirit as hooks used as a quality gate, or the «think, act, prove» discipline I've written about elsewhere: move verification inside the agent's loop, not after it. It's also a decent end-to-end tester driven by natural language, useful during development.

For an SMB the value is indirect but concrete: it raises trust in what the AI produces. Software built with the help of an agent that verified itself on a real browser is more credible than one merely «declared working». And the sandbox choice matters for governance: scripts don't touch the host's disk or network, so the operational risk is contained and scoped to the browser. There's still a caveat — an agent with a browser can navigate and act on real sites — but it's a manageable risk, and far more legible than full system access.

⚠️ Limits and caveats before adopting it

It's worth being honest. dev-browser is a young, evolving project: the latest release as I write is still a 0.2.x, so the API may change between versions. It has real traction — several thousand stars and adoption in the Claude Code community — but it's pre-1.0, with the stability implications that follow. Behind it is a company, Do Browser: the code is open source under the MIT license, but it's fair to know that when framing the project.

On the practical side, the sandbox protects the host, not the web: the script doesn't touch your files, but the browser can navigate and act on real pages and services, with your logins if you connect to the open Chrome. Pre-approving the command in Claude Code removes the confirmation prompts but also removes a human check, so it's wise to understand what the agent can do before making it automatic. Finally, the benchmarks are the author's own: indicative, not third-party verification.

• Pre-1.0: still 0.2.x releases, the API may change between versions.
• Sandbox = host protected, not the web: the browser acts on real sites, with your logins if you connect.
• Backed by a company (Do Browser): open MIT project, but good to know.
• Pre-approving the command drops the prompts: convenient, but removes a human check.
• Author's benchmarks: indicative numbers on one task, not an independent test.

✅ Where to start

The path I'd suggest is low-risk. First install it and run a minimal script in headless mode, just to see the loop: open a page, read a title, take a screenshot. Then ask the agent to run the help command and let it read the guide on its own, so it learns the API without you explaining it. At that point the most instructive test is to give it a small page to build and explicitly ask it to open it and verify the behavior with dev-browser before declaring it done.

Zooming out, the interesting signal isn't the single tool but the direction: giving agents the same tools we use — a browser, a terminal, an editor — inside clear boundaries. dev-browser does this well on a piece that was missing, visual verification, and with a care for safety that's the part to imitate. For anyone putting AI inside real processes, the lesson is the usual one, made a bit more concrete: an agent is worth as much as its ability to check its own work.

More articles from the blog