Most AI coding agents that interact with web browsers launch their own browser instance, with their own profile, their own cookies, and their own session state. chrome-bridge takes the opposite approach: it drives the Chrome you are already using, with your open tabs, your logged-in sessions, and your SSO. The difference matters when an agent needs to do something in a web application where you are already authenticated.

Why driving your real browser matters

Playwright and similar tools launch a separate browser with a separate profile. Every session starts logged out. You have to authenticate again, set up your preferences again, and navigate to the same applications again. For development tasks that involve checking staging environments, verifying deployments, or interacting with internal tools, that overhead is significant and repetitive.

chrome-bridge eliminates it by connecting to the Chrome you already have open. The agent sees your tabs, can interact with pages you are already viewing, and operates in the context of your existing sessions. When the agent needs to check a dashboard, verify a deployment, or read an email, it works with the browser you are looking at, not a separate instance that knows nothing about your current state.

The integration requires two things: an unpacked Chrome extension and a Node CLI with zero dependencies. The extension connects to a local WebSocket server. The CLI provides commands that any agent with shell access can call. No MCP server, no external services, no accounts.

What the agent actually does

The CLI provides a set of commands for interacting with browser tabs. The snap command produces an accessibility-tree snapshot of the page, a compact text representation with element references that the agent can act on. The click command takes a reference and performs a full pointer event sequence. The fill command sets input values. The type command handles per-character typing for autocomplete interfaces. The scroll command finds the real scroller on application-shell pages where the window does not scroll.

Every tab the agent touches displays a purple pill in the bottom-right corner that narrates what the agent is doing in real time. Taking a screenshot, reading a page, clicking a button, each action gets a live status update with elapsed time. The pill also shows a history of recent actions and reports when the bridge is offline or when commands have failed.

Driven tabs join a purple tab group, so you always know which tabs are being automated. The visual feedback is deliberate. You are handing an agent your logged-in browser, and the design assumes you want to watch it work.

How it compares to alternatives

Playwright drives a browser it launched with its own profile. Attach modes exist but are opt-in and require configuration. MCP bridges need an MCP-capable client and a configured server. Chrome DevTools MCP can attach to your real profile but requires specific Chrome versions and flags.

chrome-bridge has one mode: drive the Chrome you are already using. The client is anything that can run a shell command. The same commands work from a script, a cron job, or your own terminal. The server binds to 127.0.0.1 and rejects browser-origin requests, so a web page you visit cannot drive the bridge, though any local process can.

The extension itself is one readable file plus a manifest. There is no minified store bundle. You can read exactly what runs before you load it. The commands that do not use Chrome DevTools Protocol, snap, click, fill, eval, do not attach the debugger, so anti-bot systems are less likely to flag the session.

Setting it up

The setup is two steps for most users. Clone the repository and run the CLI to start the server. Open chrome://extensions in Chrome, enable Developer mode, click Load unpacked, and select the extension folder. The health check confirms the connection.

For agents with file access, the integration is a single line in your instructions file. For Claude Code, the skill copies into place automatically. For other agents, you add a line telling the agent to read the project's operating manual and run the CLI commands when a browser task comes up.

The server runs in the background and logs to a file. If it dies or the machine reboots, the agent's health check fails and it can restart the server itself. After a git pull, restart the server to run the latest code and reload the extension at chrome://extensions.

Multiple profiles and parallel driving

The extension can load in multiple Chrome profiles at once. Each keeps its own connection, and agents can drive them in parallel. A command routes to the only profile with a matching tab. If several profiles have a matching tab, the command is refused until the agent specifies which profile to use. This prevents the agent from accidentally acting in your personal browser when it meant the work one.

Each profile gets a stable short name that can be passed with the profile flag. The refusal on ambiguous matches is a safety net for honest CLI use. Any local process can set the profile in a command body, so it is not a security boundary. It is a convenience that prevents silent mistakes.

What this enables for agent workflows

For developers building agent workflows that need web access, chrome-bridge provides a concrete path to browser interaction without launching a separate browser, maintaining a separate profile, or configuring an MCP server. The agent calls the same CLI commands regardless of which web application it needs to interact with. The visual indicators let you see exactly what the agent is doing in real time.

The project is MIT licensed and accepts contributions. The extension is a single JavaScript file, the server has no dependencies, and the CLI is cross-platform. For teams building agents that need to work with authenticated web applications, the combination of real-browser access and zero configuration is worth evaluating.