Steven Gonsalvez

Software Engineer

← Back to Tools & Tips
Free|

dev-browser: A Sandboxed Browser Your Agents Can Actually Use

Claude Code skill that gives agents a sandboxed browser via QuickJS WASM. Persistent page state, full Playwright Page API, 30% faster and 40% cheaper than Playwright MCP.

Visit tool →

The Problem With Giving Agents a Browser

Playwright MCP works, but it's heavy. Every interaction spins up a full browser context. Screenshots get taken, parsed, acted on. It's slow and it chews through tokens like nobody's business. For a CI pipeline where you need repeatable, well-defined tests, that's fine. For an agent dev loop where you want to quickly check "did this render right" or "does this button do what I think it does," it's overkill.

dev-browser takes a different approach. It's a Claude Code skill that gives your agent a sandboxed browser running on QuickJS WASM. The agent writes JavaScript that executes in the sandbox with the full Playwright Page API. Page state persists between calls. And because it's not spinning up and tearing down browser contexts constantly, it's roughly 30% faster and 40% cheaper than the Playwright MCP route.

What Makes It Click

The persistent page state is the bit that matters. Your agent navigates to a page, does something, and the next time it interacts with the browser, everything's still there. No re-navigation. No re-rendering. The agent can build up a session incrementally, which is how you'd actually use a browser if you were sat in front of it.

The sandbox bit is important too. The agent's JS runs in QuickJS WASM, not in your actual system. So even if the agent writes something dodgy, it's contained. No accidental rm -rf, no rogue network calls from the sandbox. It's the right trade-off for giving agents browser access during development without worrying about what they might do with it.

When to Use It (and When Not To)

I use this for agent dev loops. The agent's iterating on a component, wants to check how it looks, pokes at the DOM, confirms behaviour, moves on. Quick feedback cycles where speed matters more than reproducibility.

For CI, for repeatable test suites, for anything that needs to run the same way every time across environments, use Playwright proper. dev-browser isn't trying to replace that. It's the scratchpad browser for the build phase, not the quality gate.

Getting Started

npm install -g dev-browser && dev-browser install

The skill definition slots straight into Claude Code. Once it's in, your agent has browser access without you having to configure anything else. Lightweight, fast, and properly sandboxed.

Share𝕏in

Comments & Reactions