sawyerhood/dev-browser
Summary
dev-browser is a CLI tool that lets AI agents (primarily Claude Code) control a web browser by executing sandboxed JavaScript scripts against a full Playwright API. It works by running a Node.js daemon that manages persistent browser pages, with user scripts executing inside a QuickJS WASM sandbox — so arbitrary scripts can't touch the host filesystem or network directly. The Rust CLI binary embeds the daemon bundle at compile time via include_str! and spawns it as needed.
Great for
building or extending AI-driven browser automation tools, especially those that need sandboxed script execution or want to give LLM agents safe web interaction without full host access
Easy wins
- +Add more Vitest test cases for browser-manager edge cases — browser-manager-pages.test.ts and browser-manager-title-timeout.test.ts exist but likely have thin coverage given the small contributor count
- +Improve error messages surfaced to users when the QuickJS sandbox throws — currently these likely bubble up raw from quickjs-emscripten with no user-friendly wrapping
- +Document the daemon↔CLI IPC protocol (protocol.ts exists but has no inline docs), which would unblock contributors who want to extend the script API
- +Add Windows CI coverage — the README has explicit Windows notes and a separate exe asset, but CI (ci.yml) is unknown; Windows path handling in temp-files.ts restricted to ~/.dev-browser/tmp/ could have edge cases
Red flags
- !daemon/src/sandbox/forked-client/ contains thousands of lines of vendored Playwright internals (Apache 2.0, Microsoft copyright) with @ts-nocheck suppressing all type checking — this is a maintenance and licensing complexity that isn't called out in the README
- !Only 1 contributor in practice (commit_count: 1, contributor_count: 1 despite listing 4) — the 4947 stars and 307 forks are almost certainly from viral launch, not sustained community
- !The build requires running `pnpm bundle` before `cargo build` or changes silently don't apply — this is documented only in CLAUDE.md, which is AI-agent-facing, not in CONTRIBUTING.md where human contributors would look
- !postinstall.js downloads a platform-specific binary (dev-browser-windows-x64.exe) from GitHub releases during npm install — supply chain risk if the release pipeline is compromised
- !commit_frequency_30d: 1 suggests this may be a launch-and-abandon project despite high star count
Code quality
The daemon TypeScript is strict-mode with noUncheckedIndexedAccess and noImplicitOverride enabled, which is a good sign. The forked Playwright client files (daemon/src/sandbox/forked-client/) are all marked @ts-nocheck and are clearly vendored Microsoft source with Apache 2.0 headers — these are essentially a copied internal Playwright build, not original code, which makes that directory a maintenance liability when Playwright updates. The original daemon code (browser-manager.ts, local-endpoint.ts, lock.ts) appears clean and tested. The build pipeline dependency (bundle before cargo build) is a real footgun for new contributors and is only documented in CLAUDE.md, not CONTRIBUTING.md.
What makes it unique
The core differentiator is running user scripts inside QuickJS WASM rather than directly in Node.js, which is genuinely novel for AI browser automation tools. Playwright MCP and similar tools give agents direct Playwright calls; this tool lets agents write multi-step scripts that run atomically in a sandbox. The benchmark table in the README shows real methodology with a linked eval repo, which is more honest than most tools. However, the 'forked Playwright client' approach means they're maintaining a patched copy of Playwright internals rather than using the public API, which is a significant long-term bet against Playwright's stability.