Chrome Bridge

Chrome Bridge

By frsorrentino · npm chrome-bridge-mcp · not affiliated with other projects named "chrome-bridge".

Claude Code drives the Chrome you are already using — signed in, with your extensions and your cookies. 69 tools: navigation, forms, DOM inspection, network mocking, visual regression, audits, performance traces and the WebMCP tools a page declares. Self-hosted, local-only, no paid plan, works on ChromeOS.

Measured against the official Claude in Chrome extension on the same tasks (paired runs, 17/10/2026, Claude Code 2.1.302, n=5 per task, medians):

15 correct answers out of 15, against 14. Method, every run and the caveats in docs/EFFICIENCY.md.

Quickstart

1. In a Claude Code session:

   /plugin install chrome-bridge --marketplace frsorrentino/chrome-bridge

From a shell, the same: claude plugin install chrome-bridge --marketplace frsorrentino/chrome-bridge.

1. Add the extension from the Chrome Web Store.
2. Restart Claude Code.

Then ask for something like *"open localhost:3000, run an accessibility audit and find the Sign Up button"*: Claude Code calls navigate, audit and find_text. Because navigate already returns element refs, click(ref="n1") follows with no discovery turn in between.

The plugin registers the MCP server from npm together with the recipes skill.

Older Claude Code, from source, Windows, one path only

Older Claude Code. Add the marketplace first: /plugin marketplace add frsorrentino/chrome-bridge, then /plugin install chrome-bridge@chrome-bridge (from a shell: claude plugin marketplace add frsorrentino/chrome-bridge, then claude plugin install chrome-bridge@chrome-bridge).

From source:

git clone https://github.com/frsorrentino/chrome-bridge.git

cd chrome-bridge && ./install.sh

Then open chrome://extensions, enable Developer mode, click Load unpacked, select the extension/ folder, and restart Claude Code. install.sh registers the MCP server with --scope user; by hand: claude mcp add --scope user chrome-bridge node /path/to/server/index.js. On ChromeOS/Crostini use the Web Store extension instead: an unpacked one is dropped on every reboot, because the container isn't mounted when Chrome starts.

Windows. install.sh does not run from PowerShell or cmd: use the plugin with the Web Store extension, or run install.sh from Git Bash. The plugin's error log hooks run in Git Bash, as Claude Code runs every hook. For launch mode see CHROME_BRIDGE_BROWSER below: Google Chrome cannot load the extension there, Microsoft Edge can.

One path only. The plugin and install.sh would register the same server twice, and so would a plugin added from the Anthropic directory on claude.ai (it reaches Claude Code as chrome-bridge@synced) next to a marketplace install. In claude.ai chat the plugin loads only the recipes skill: the tools need Claude Code, or Cowork running on your computer, where the local MCP server can start. Clients that read Agent Plugins 1.0 get the same from plugin.json + mcp.json.

Why it takes fewer turns

• Refs, not screenshots. navigate returns the page's interactive elements as short refs (n1, n2…), so the next call is the click, not a screenshot and a coordinate guess.
• One call for a whole form. fill_form fills N fields and submits in the same call.
• Filtering on the server. extract_table with where and columns returns the matching rows of a 1,500-row table, not the table.
• Debugging starts with the answer. navigate reports the first console error mapped to its source line and the failed requests with their status; get_css_styles names the rule behind a style and flags undefined CSS variables.
• Deferred loading. 22 stay in context; the rest of the 46 in the default set wait behind Claude Code's tool search (2.1.285+), and loading one mid-session does not invalidate the prompt cache. The other 23, in seven optional groups, switch on mid-session with get_status({enable: [...]}), no restart.

Your browser, your login

No blank profile, no debugging port, no cloud browser. The extension runs in your Chrome, so every site you are signed into is already open to the agent: webmail, the hosting panel, a back office, a staging site behind basic auth. Tabs the agent opens are marked as its own and closed when the session ends; your tabs stay yours. Several Claude Code sessions share the same browser: the second one becomes a relay on the first one's bridge.

WebMCP. When a page declares its own tools through WebMCP, navigate and get_interactives say so in one line, webmcp_tools lists them and webmcp_call runs one, with a timeout. Needs the WebMCP flag or origin trial in Chrome; get_status reports whether it is on.

Limits you can set. upload_file refuses keys and credentials (~/.ssh, .env*, *.pem, …) and --read-root fences it to one directory; --write-root fences every path the model writes; --no-js removes arbitrary JavaScript. The agent never types credentials: for a login, a 2FA code or a choice, handoff shows a banner in the page and waits for you.

Compared

Codex for Chrome (OpenAI, May 2026) sits in the Claude in Chrome column: an official extension with the debugger permission, macOS and Windows only, the ChatGPT app required. Claude in Chrome documents Linux desktop since September 2026; ChromeOS and WSL stay out. Competitor tool counts measured on 2026-09-01 and 2026-09-11 (docs/analisi-2026-09-11-concorrenti.md); WebMCP, recording and tracing rows checked in their documentation on 2026-10-28.

Using it

The skill in skills/chrome-bridge/SKILL.md is what makes the tools discoverable: recipes with the phrase that triggers each one ("verify the email arrives", "test the checkout with a test card", "which plugin slows the page", "what fires before consent"), the tool sequence, and the zero-token CLI commands the model would otherwise never see. install.sh copies it to ~/.claude/skills/chrome-bridge; do the same by hand for other clients.

Beyond the MCP tools, two lanes keep work away from the model entirely.

CLI — batch operations, piped through grep or jq before anything reaches the context:

chrome-bridge navigate --url https://example.com

chrome-bridge read_console --level error | head -20 chrome-bridge assert --selector "#success" --text "Done" chrome-bridge replay --file ./recordings/login.jsonl

Launch mode — a dedicated Chromium instance with an ephemeral profile, for isolated sessions or CI:

node server/index.js --launch --headless

It looks for Chromium, Microsoft Edge, Brave and last Google Chrome in their standard paths on Linux, macOS and Windows; CHROME_BRIDGE_BROWSER picks another binary. Google Chrome 137+ ignores --load-extension, so the extension never connects in it: use Chromium, Edge, Brave or Chrome for Testing.

Pair it with session_record + replay for smoke tests with no model in the loop. In launch mode execute_js falls back to new Function when the user-script toggle isn't available.

Tools

69 in total. core (46 tools: every tool used in 101 real sessions, plus the two WebMCP tools) loads by default; the other 23 sit in seven optional caps, switched on with get_status({enable: ["visual"]}) or at startup with --caps.

Every tool, with the notes that matter: docs/TOOLS.md.

How it works

![It drives the Chrome you are logged into, over a local WebSocket bridge](assets/readme/car