byob (Bring Your Own Browser)
Let your AI coding assistant drive the Chrome you're already logged into — no headless browser required.
- Source repo
- wxtsky/byob
- Stars
- ★ 145
- Last updated
- 1mo ago
- License
- MIT
- Primary language
- JavaScript
- FA score
- 48/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free, no paid service needed
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A developer asks Claude Code to read their logged-in GitHub or Gmail tab and report unread counts before continuing to code
- Not a fit if
- Teams running browsers on headless servers or in containers
- Anyone unwilling to grant a tool access to logged-in personal accounts
- Users expecting zero manual Chrome setup and restarts
- Source review
- 48/100 · Major gaps 1 safety controls not found
What does this agent do, and when should you use it?
byob is a local MCP server that connects AI coding tools (Claude Code, Cursor, Cline, Windsurf, Codex CLI and other MCP clients) to your everyday Chrome. It is built from three pieces: the stdio MCP server byob-mcp, a local byob-bridge process reached over a Unix socket, and an MV3 Chrome extension that talks to the bridge via Native Messaging and drives tabs through the Chrome DevTools Protocol. Version 0.5 ships 25 tools spanning snapshots, finding, clicking, typing, key presses, scrolling, drag-and-drop, file upload, content extraction, screenshots/PDF, tab management, console and network capture, cookies and storage, dialogs, device emulation, clipboard and batched steps. Because it uses your real logged-in browser, it can see authenticated pages and usually passes bot detection, at the cost of a local extension install, a manual unpacked load and a full Chrome restart. All traffic stays on the machine, and page scripts run in an isolated world so sites never see byob globals or data attributes.
The AI client calls byob-mcp over stdio; the request goes to byob-bridge, across Native Messaging into the Chrome extension, which executes it in your tab via the Chrome DevTools Protocol. Elements are targeted by snapshot refs such as [ref=e12], CSS selectors, or x/y coordinates. browser_snapshot returns an accessibility outline with refs (interactive-only, diff, scoped, iframes inlined), and browser_find locates by role+name, text, label, placeholder or testId and can click, fill or check in the same call. browser_click, browser_type, browser_press_key, browser_hover, browser_select, browser_scroll, browser_drag and browser_upload_file emit real mouse and keyboard events and auto-wait for elements to be attached, visible, stable, enabled and on top, then report navigation, new tabs and JS dialogs. browser_read emits text, markdown reader mode, html, links or tables; browser_screenshot returns viewport, full page, element or clipped images to the model and can produce PDFs. browser_network records traffic (summary, JSON, HAR) or blocks, mocks and modifies requests; browser_storage gets, sets and clears cookies and local/session storage; browser_emulate switches device, dark mode, geolocation, timezone, locale, offline and headers. browser_evaluate runs page JavaScript only when BYOB_ALLOW_EVAL=1 is set, and every call is audit-logged. browser_batch bundles many steps into one round trip.
- A developer asks Claude Code to read their logged-in GitHub or Gmail tab and report unread counts before continuing to code
- Authenticated data gathering: have the agent read a Twitter/X timeline and summarize the top posts, or search, click the first result and read the page
- Front-end debugging on a real session: export a HAR with browser_network, check errors with browser_console, inspect box model and Web Vitals with browser_inspect
- Filling and submitting a multi-field form via browser_batch, then screenshotting the result to confirm
- Producing deliverables like a full-page screenshot or PDF of a site for a report
- Reusing an existing session cookie for script verification, as in the README example of grabbing a GitHub session cookie to curl with
How do you install or deploy this agent?
Prerequisites: Node.js ≥ 20, bun, Chrome/Edge/Brave, and any MCP-compatible AI tool. On Windows, run the one-liner from Git Bash or MSYS2.
The recommended install script checks prerequisites, clones the repo, builds everything and walks through MCP registration interactively (it offers to install bun with the native installer if missing). Set BYOB_INSTALL_DIR to change the install location (default ~/byob).
curl -fsSL https://raw.githubusercontent.com/wxtsky/byob/main/install.sh | bashManual install instead:
git clone https://github.com/wxtsky/byob
cd byob
bun install
bun run setupsetup asks for output language (English / 中文), generates a unique extension key, builds the extension, writes the config that lets Chrome talk to byob, and lets you multi-select your AI tools (Claude Code gets the bundled plugin; others get MCP config). Three manual steps remain. First, open chrome://extensions, enable Developer mode, click Load unpacked and pick the printed folder, e.g. /your/path/to/byob/packages/extension/output/chrome-mv3. Second, quit Chrome completely (⌘Q on macOS) and reopen it, since Chrome reads Native Messaging config only at startup. Third, wait for setup to print ✓ bridge online, or check later:
bun run doctorIf you skipped the registration prompt, register MCP manually, for example with Claude Code:
claude mcp add byob -s user -- /path/to/tsx /path/to/byob-mcp.tsOr install the Claude Code plugin:
claude plugin marketplace add wxtsky/byob
claude plugin install byob@byob --scope userHow do you use this agent?
Once the bridge is online, start a new session in your AI tool and ask in natural language, e.g. "use byob to read my Twitter timeline and summarize the top 5 posts".
Set per-site policy yourself (the agent cannot change it):
bun run policy --deny "**.chase.com" "mail.proton.me"
bun run policy --allow "**.github.com"
bun run policy --clear-allow --clear-deny
bun run policy --allow-file onTo let the agent run page JavaScript, opt in explicitly:
claude mcp add byob -s user -e BYOB_ALLOW_EVAL=1 -- /path/to/tsx /path/to/byob-mcp.ts{
"mcpServers": {
"byob": {
"command": "/path/to/tsx",
"args": ["/path/to/byob-mcp.ts"],
"env": { "BYOB_ALLOW_EVAL": "1" }
}
}
}Everyday maintenance commands, run from the repo root:
bun run doctor # diagnose which step failed
bun run bridges # list running bridge processes
bun run logs # tail the bridge log
bun run unsetup # remove everythingCommon errors: No live bridge (Chrome not running or extension disabled), cdp_attach_failed (DevTools open on that tab), url_forbidden (blocked by your site policy), stale_ref (page navigated; snapshot again), element_covered (a banner or modal is on top; close it or use force:true).
What are this agent's strengths and limitations?
- Uses the Chrome you are already signed into, so no cookie copying or re-login, and actions come from a real human browser that usually passes bot detection
- Uses an extension plus Native Messaging instead of an open remote-debugging port, so there is no "Allow remote debugging?" prompt and other local programs cannot hijack the logged-in browser through that port
- Concrete security defaults: browser_evaluate is off and audit-logged, password/OTP/card/email field values come back as [redacted], chrome:// and file:// plus Google/Microsoft/Apple login pages are blocked, socket files are 0600 and dirs 0700, and there is zero outbound traffic
- Actions auto-wait for elements to be visible, stable and clickable and report navigation, new tabs and dialogs back, so the agent need not poll; Ctrl+C cancels end to end and sleep/wake recovery resets debug sessions
- Broad tool coverage: ref-based accessibility snapshots, HAR export, request interception, device emulation, screenshots/PDF, console and storage access in one MCP server
- The install path is long: Node.js ≥ 20 and bun are required, the extension must be built and loaded unpacked from chrome://extensions, and Chrome must be fully quit and restarted; Claude Code plugin users must avoid registering a second byob MCP server
- Chrome shows a "byob is debugging this browser" banner on active tabs while in use; the README states this is a Chrome security feature that cannot be suppressed
- A tab with DevTools open cannot be attached (cdp_attach_failed), and refs become stale after navigation and must be re-snapshotted
- Upgrading is breaking: tool names changed between 0.4 and 0.5, so existing prompts and scripts need updating
- The project is at v0.5 and grants broad access to your browser; the README limits it to machines and accounts you own, and there is no third-party security audit or hosted option
How does this agent compare with similar options?
The README benchmarks byob against three real alternatives. WebFetch cannot see logged-in pages and fails bot detection. Headless Puppeteer needs manual cookie copying, takes hours to set up and may cost cloud money. Tools that attach over Chrome's remote-debugging port — DevTools MCP, agent-browser, Playwright with --cdp — require opening a debugging port, trigger an "Allow remote debugging?" prompt on every connection, and leave the logged-in browser open to hijacking by other local programs. byob avoids the port entirely by being an extension, at the cost of loading it manually and restarting Chrome.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| byob (Bring Your Own Browser) This agent | 48 · Major gaps | MCP serverFree | ★ 145 | 1mo ago | JavaScript | Codex · Claude Code |
| BrowserTools MCP | 81 · Good | — | ★ 7.3k | 9d ago | TypeScript | Claude Code |
| Interceptor | 57 · Major gaps | CLIFree | ★ 603 | today | TypeScript | Codex · Claude Code · Claude.ai |
| OpenTabs | 49 · Major gaps | CLIFree + model costs | ★ 1k | 3mo ago | TypeScript | Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
The README gives substantive least-privilege and sensitive-data evidence: browser_evaluate off by default, chrome:// and login pages blocked, user-set per-site allow/deny, redaction of password/OTP/card/email fields, 0600 sockets, and zero outbound traffic. Deductions are concrete: the recommended install is curl | bash executing remote code as the default high-privilege path; the toolset includes browser_storage (cookie read), browser_clipboard, browser_upload_file and browser_network interception/rewrite, and the README itself concedes 'broad access to your browser'; there is no per-action user confirmation gate, so user_confirmation is only 1. Dependency security scores 0: only a root package.json (sharp 0.34.5 devDependency) is present, with no lockfile, audit or SBOM evidence. External effects (form submit, clicks, downloads) have no dry-run or impact preview, and rollback is limited to unsetup and policy reset with no per-action undo, both 1. Source attribution is a single 'wxt' copyright line with an unverified publisher, 1.
The README describes auto-waiting, action effect reporting, non-hanging dialogs, end-to-end cancellation and sleep/wake recovery in specific terms consistent with the tool table, so self_consistency is 2. Failure messages are strong: a troubleshooting table plus doctor command and named error codes (stale_ref, element_covered, url_forbidden), so failure_messages is 2. Dependency availability is thin: Node >=20 and bun are required, the installer may install bun itself, no lockfile pins versions, and cross-platform support is asserted only in a table, so dependency_availability is 1.
Per-client configuration examples are given for Claude Code, Cursor, Cline, Windsurf and Codex, with scenarios covering reading, clicking, screenshots and form filling, so audience_and_scenarios is 2. Capability boundaries are stated clearly (eval off by default, site policy, login-page blocking, unsuppressable Chrome debug banner), so capability_boundaries is 2. Trigger precision is weak: tools are selected by the model from natural language with no explicit confirmation threshold or risk tiering, so trigger_precision is 1. Environment fit covers macOS/Windows/Linux and Chrome/Edge/Brave, but Windows requires Git Bash/MSYS2, so environment_fit is 2.
The README is well structured with install, tool table, architecture diagram, commands, security, troubleshooting and platform notes, so information_architecture and install_notes are 2 (install is stepwise with a manual path). examples_and_faq gets 2 for example prompts and the troubleshooting table. license is 2 for the full MIT text. Naming stability is deducted: the README states tool names changed from 0.4 to 0.5, so 1. known_limitations is only scattered mentions (debug banner, full Chrome restart) with no consolidated list, 1. versioning_changelog is a badge and link to CHANGELOG.md that is not in the evidence, 1. maintenance_responsibility is a single author with no governance, security disclosure channel or maintenance commitment, 1.
Output usability is good: refs in snapshots, screenshots returned to the model, markdown/table reading, so output_usability is 2. The comparison table against WebFetch and headless Puppeteer articulates marginal value (reuse of an already logged-in real browser, no debug port), so marginal_value is 2. Cost-benefit is deducted: bun is required, an unpacked extension must be loaded, Chrome must be fully restarted, and Chrome shows a debug banner, making real setup and upkeep costlier than the claimed '~5 min', with the risk cost of broad permissions unquantified, so cost_benefit is 1.
claim_traceability is partial: tool schemas point to shared/src/tools.ts, which is not in the evidence, and most performance and security claims are README self-assertions, so 1. cross_source_corroboration rests on only README, LICENSE and package.json; package.json corroborates version 0.5.0 and the scripts, but no tests or code corroborate the security claims, so 1. fact_inference_separation is weak because the README interleaves conclusions such as 'tested end to end' with design intent without marking which is verified, so 1.
- Not found in source: dependency securityPin versions and run a dependency audit (npm audit, pip-audit) before installing; prefer running it in a container.
- The recommended install is curl | bash executing a remote script, a high-privilege default path; review install.sh first or use the manual git clone route.
- The toolset includes cookie/storage reads, clipboard read/write, file upload and network interception/rewrite; the README concedes broad browser access, so use only on machines and accounts you own.
- There is no per-action user confirmation gate; the model can submit forms, click and download autonomously. Tighten scope with the per-site allow/deny policy.
- No lockfile or dependency audit evidence is present, so dependency security cannot be confirmed statically.
- Publisher identity is unverified and maintenance responsibility and security disclosure channels are unclear.