dev-browser: Give Claude a Playwright-backed browser without handing it your filesystem

If you have ever wished Claude could just open a browser and check whether the thing it just built actually works, dev-browser is the closest thing to that right now. It is a Claude Code skill: install it once, tell Claude about it, and your agent can drive a full Playwright session without you writing a single line of automation code.

What it actually does

Under the hood it is a thin wrapper around Playwright, but the key design decision is the sandbox: automation scripts run inside a QuickJS WASM runtime rather than straight Node.js. The browser code your agent generates can't reach your filesystem, can't make arbitrary outbound calls, and can't require() your project's dependencies. Less power, more safety — which is exactly the tradeoff you want when your agent is writing its own automation.

The API surface is genuine Playwright: goto, click, fill, locator, evaluate, screenshots. Plus one extra: page.snapshotForAI(), which serializes the page into a compact, structured representation a model can parse without burning tokens on raw HTML.

npm install -g dev-browser
dev-browser install    # pulls Playwright + Chromium (~300MB)

# Tell Claude about it by adding to .claude/settings.json:
# "permissions": { "allow": ["Bash(dev-browser *)"] }

Where it earns its keep

The obvious use case: you ship a component, ask Claude to open it in the browser and verify that the button works, the form submits, the layout does not collapse on mobile. Claude writes the automation inline, dev-browser executes it in the sandbox, and you get a screenshot back. No test-suite setup, no Playwright project config, no separate CI step to wire up.

It is also genuinely useful for "does this page look broken?" spot-checks mid-session. snapshotForAI() gives the model enough structured context to describe what is on screen without you having to paste raw HTML into the prompt — which, if you have ever tried that, you know how fast it goes sideways.

The catch (there is always one)

QuickJS is not Node.js. If you were hoping to pull in a utility library or your own helper functions inside the automation scripts, that will not work — you are limited to browser-compatible JavaScript and the built-in Playwright API. File I/O inside scripts is locked to ~/.dev-browser/tmp/, so you cannot read your project source files from within an automation run.

It also downloads its own Chromium (~300MB) rather than using your system browser, and auto-connecting to an existing Chrome session requires enabling remote debugging, which is not on by default. For deterministic CI regression suites with parameterized inputs, plain Playwright is still the right tool. dev-browser earns its place in ad-hoc, agent-driven verification — not as a test harness replacement.

Built by Sawyer Hood — repo at github.com/SawyerHood/dev-browser. At 6.4k stars with a handful of active forks (including one specifically for persistent page state), it has the kind of quiet adoption that usually means people are actually using it.