chrome-bridge

Chrome Bridge is an open-source project developed by frsorrentino that provides your real, already-logged-in Chrome browser as an MCP server for use with Claude Code. It uses a browser extension and a local WebSocket bridge to let an AI agent borrow the Chrome tab you are currently using—already logged in, with your extensions and cookies—work within it, and return it when done. Operations that only a human can complete (login, 2FA codes, CAPTCHA, making choices) are handed back to you through a handoff mechanism: a banner appears in the page, and after you act, the agent continues.

Main capabilities

• About 60 tools for web development, covering navigation, DOM inspection, visual regression, auditing, network simulation, and more.
• Compact element refs: navigate directly returns element refs, so you can immediately click(ref="n1") without an extra discovery round.
• fill_form fills multiple fields in one call; table filtering on large pages is done server-side, reducing transfer payload.
• Provides accessibility, SEO, and security audits, as well as visual regression and network simulation capabilities.
• Supports headless instances, usable in CI.
• Provides a CLI channel for batch operations, which can be filtered via grep or jq pipes before entering context.
• Provides launch mode: a standalone Chromium instance using a temporary profile, for isolated sessions or CI.
• Total tool count is 67: core (44 tools, loaded by default) plus 23 tools across 7 optional capability packs, which the agent can enable during a session via get_status({enable: ["visual"]}) without restarting.

How to use

• Requires Node.js 18+ and Chrome 135+.
• Install the extension: open chrome://extensions, enable Developer mode, click "Load unpacked", and select the extension/ folder.
• Restart Claude Code.
• Then you can make requests such as "open localhost:3000, run an accessibility audit, and find the Sign Up button": Claude Code will call navigate, audit, and find_text.
• On ChromeOS/Crostini, install from the Chrome Web Store, because unpacked extensions are discarded after every restart (the container is not yet mounted when Chrome starts).
• On Windows, install.sh cannot be run from PowerShell or cmd; you can use the plugin path (claude plugin marketplace add frsorrentino/chrome-bridge, then claude plugin install chrome-bridge@chrome-bridge) with the Web Store extension, or run install.sh from Git Bash.
• install.sh registers the MCP server with --scope user; to register manually: claude mcp add --scope user chrome-bridge node /path/to/server/index.js.
• For execute_js, you need to enable Allow user scripts in chrome://extensions → Chrome Bridge → Details (on Chrome 135-137, enable Developer mode instead).
• Install as a plugin (no cloning required): in a Claude Code session, run /plugin install chrome-bridge --marketplace frsorrentino/chrome-bridge (Claude Code 2.1.275+); for older versions, first /plugin marketplace add frsorrentino/chrome-bridge, then /plugin install chrome-bridge@chrome-bridge. Running claude plugin install from the shell does not have a --marketplace option: first claude plugin marketplace add frsorrentino/chrome-bridge, then claude plugin install chrome-bridge@chrome-bridge.
• Note: the plugin and install.sh will register the same server twice; plugins added from the Anthropic directory (chrome-bridge@synced) and marketplace installs will also duplicate. In claude.ai chat, the plugin only loads the recipes skill; tools require Claude Code or Cowork running on your computer.

Use cases

• Perform automated operations on websites you are already logged into (webmail, hosting panels, customer backends, staging sites behind basic auth).
• Web development debugging: form filling, finding rows in large tables, debugging broken pages, accessibility/SEO/security audits, visual regression, network simulation.
• Headless instances and launch mode in CI, combined with session_record + replay for smoke tests.
• Flows requiring human intervention: login, 2FA, CAPTCHA, selecting elements, etc., handing control back via the handoff banner.

Limitations and security

• Page content reaches the model unfiltered; text from hostile pages is untrusted input.
• get_storage, session_fixture, HAR export, and screenshots are not redacted and may carry cookies, tokens, or personal data.
• Do not point automation at pages containing secrets you would not want pasted into chat.
• The bridge binds to the loopback address and only accepts extension connections from the chrome-extension:// origin; once a token is set, both handshakes require the token. When no token is set, any local process could act as a relay and reach execute_js.
• Launch mode opens the DevTools port on 127.0.0.1 (chosen by the system); CDP has no authentication, so any local process can drive that dedicated browser while it is running; its profile is temporary and does not contain your data; your own Chrome will not open a port.
• The debugger bar is the signal: click / press_key use trusted, emulate_media uses via: "debugger", perf_trace and screencast will temporarily attach chrome.debugger to a tab, during which Chrome shows the "Debugging this browser has started" bar; canceling ends it.
• The real risk is prompt injection: a page can ask the agent to run JavaSscript, send requests with your cookies, submit forms, or upload files. Treat every automated page as untrusted input.
• Reduce the attack surface: --caps core (default) exposes the minimal set; --no-js removes arbitrary JavaScript; --write-root restricts every path the model writes to; upload_file rejects keys and credentials, and --read-root restricts it to one directory. For important sessions, automate in a separate Chrome profile.
• --no-js is not a sandbox: inject_css remains, and a CSS attribute selector with url() can leak attribute values to a remote host.
• chrome-bridge itself has no telemetry; error logs stay local unless you approve sending them.

Local error log

• When its own tools fail, chrome-bridge appends a line in the claude-observe format to the local file ${XDG_STATE_HOME:-~/.local/state}/claude-observe/chrome-bridge.jsonl (permissions 0600, inside a 0700 folder).
• Retained: tool name, redacted error text (home directory becomes ~; emails, URL queries, secrets, and input values are removed), parameter names and text value lengths, chrome-bridge version, operating system, working folder name, and Claude Code configuration folder name. When using the plugin, it also retains the Claude Code and model versions, session ID, and the tool names of the last three calls.
• Never retained: parameter values—no URLs, selectors, input text, or page content.
• It will not leave your computer unless you agree. When using the plugin, after errors accumulate it will prompt at the end of the turn, and Claude may propose sending it as a GitHub issue: first show the anonymized text, then ask with buttons (send from your GitHub, or not yet), and send only what you choose. /chrome-bridge:observe send can do this on demand; list, mark, and add are used to read and classify logs. The server alone will not send or propose anything.
• Security observations (out-of-bounds reads/writes, secret exposure, unexpected code execution, data leaving the computer) never go into public issues: /chrome-bridge:observe send --security prepares a private vulnerability report, see SECURITY.md.
• Turn off: set {"enabled": false} in ~/.config/claude-observe/config.json (for all plugins using claude-observe), or set CHROME_BRIDGE_OBSERVE=off for the server. Keep logs but stop proposing: {"propose": false}.

Related projects

• agent-webbridge — drives multiple Chrome profiles at the same time, supporting parallel tabs.
• awb-recipes — community-maintained, per-site date-annotated recipes for automating logged-in websites.