BrowserAttach

BrowserAttach

English · 简体中文

Drive the Chrome / Edge tabs you already have open and already signed in from an MCP client. BrowserAttach connects to the browser through a locally paired extension, keeps your existing sign-in state, and needs neither a remote debugging port nor a separate automation browser.

npm · Usage guide · Architecture · Agent integration · Test report · Issues · Contributing

What it does

• Discover multiple browser profiles, pick one precisely, claim a tab exclusively, and release it when done.
• Control existing ordinary file:// tabs after enabling BrowserAttach's Allow access to file URLs setting in the browser's extension details; use the same discovery, claim, observation and input tools.
• Read the accessibility tree, query names/values/nearby field context, inspect field values and supported editor models; click, fill and type through refs or strict CSS/XPath, HTML label, placeholder and AX role/name locators. Type can also target the currently focused field explicitly.
• Native pointer hover, stepped drags and conditional waits; select HTML options without opening a native popup.
• Navigate and go back/forward, open or close tabs, handle JavaScript dialogs, upload local files, and capture the whole page or a single element.
• Evaluate JavaScript expressions in the main page; read console, page-error, network and navigation logs captured after claiming, with bounded available stacks and request initiators; opt in to bounded, redacted request/response details when XHR/fetch needs verification.
• Read one HTTP(S) URL in a temporary background tab with the profile's sign-in, returning rendered text, current DOM, or complete JSON with the main-document HTTP status when observed.
• Standard stdio MCP with 24 tools. The Hub listens on loopback only and pairs with the extension through a random key.

Requirements

• Node.js 22 or newer, plus npm.
• Chrome / Edge 125 or newer with permission to load unpacked extensions. Latest stable is recommended.
• An MCP client that speaks stdio MCP and can find Node/npm on PATH.

Quick start

1. Install and pair

npm install --global @evan_zhong/browser-attach

browser-attach setup

setup prints a stable extension directory and starts the local Hub. The directory is usually:

• Windows: %USERPROFILE%\.browser-attach\extension
• macOS / Linux: ~/.local/share/browser-attach/extension

Open chrome://extensions or edge://extensions, enable developer mode, choose "Load unpacked" and load that directory. Load it once for every browser profile you want to expose; the extension options page lets you set a recognizable profile name.

Or without a global install:

npx --yes --package=@evan_zhong/browser-attach@latest browser-attach setup

2. Configure the MCP client

Merge the following into your client's MCP configuration, or see mcp-config.json:

{

"mcpServers": { "browser_attach": { "command": "npx", "args": ["--yes", "--package=@evan_zhong/browser-attach@latest", "browser-attach", "mcp"] } } }

On Windows clients that require a full command extension, use npx.cmd. With a global install you can also configure "command": "browser-attach", "args": ["mcp"]. Restart the MCP client to discover the tools.

@latest selects the package at launch; upgrading an existing pair is coordinated at startup. The first extension load, and pairs still on an older protocol, need one manual extension reload — see local data and upgrades.

Host entry points are collected in agent integration, and the connection parameters, JSON/TOML examples and verification steps are in the setup reference; other clients use the stdio entry above.

The npm package includes an optional browser-attach skill with setup, recovery and cross-site recipes. Copy the whole skills/browser-attach directory to your host's skill location if desired; npm installation does not register it with the host.

3. Start driving

1. browser_discover(kind="browsers") → browser_discover(kind="tabs") to confirm the browser, tab title and URL.
2. browser_claim_tab with the tab_id from discover(kind="tabs") (optional expected_url / expected_title exact guards) to take control and receive this connection's tab_handle.
3. browser_snapshot to get element refs, then click, fill or run other actions.
4. Observe when the next decision needs new state, and finish with browser_tab_control(action="release"). Use snapshot(diff_since="latest") or action observe:{diff_since:"latest"} for page changes; inspect mode/reset_reason and finish pagination. A full-page refresh is not required after every action.

When titles change often, omit expected_title and check the identity returned by claim instead. Elements may be addressed by ref or by a selector re-resolved on every call; design trade-offs: architecture notes.

Claiming and ordinary input never activate a tab or window; call browser_tab_control(action="activate") explicitly when foreground rendering is needed. When an outcome is unknown, observe again first and avoid duplicate submissions. Full parameters, pagination, uploads and input semantics: usage guide.

Tools

Local data and upgrades

Override it explicitly with the absolute path BROWSER_ATTACH_HOME. The Windows default avoids AppData, which packaged hosts may virtualize; no other host's private cache is searched or merged automatically. The directory holds the pairing configuration, Hub logs and the stable extension copy, and depends on neither the clone location, the client working directory nor the npm cache. If you already use a custom directory, keep using the same environment variable or --config instead of accidentally creating a second pairing under the new default.

A host assembly step that writes the client entry pins the absolute paths of the current Node, CLI and the actual pairing file and sets BROWSER_ATTACH_HOME; it works together with a custom --config. When the MCP launches the Hub it passes the same absolute pairing path and directory, so different launch environments cannot derive a second configuration. See agent integration.

To upgrade, install again with the command from step 1 and reconnect the MCP client. With @latest and a pair on 0.17 or newer the restart is enough; a pair still on an older protocol needs browser-attach stop, a restart and one manual extension reload. Custom pairing paths, ports and extension directories are retained, closed browser profiles update when they next connect, and an older MCP package cannot downgrade a newer Hub or installed extension.

An upgrade waits for extension cleanup and confirms the new version after reload; cleanup or reload failures are reported instead of replaying page actions. Manual reload remains available on the extension options page for recovery, and Hub and extension versions must match for page control. The default port is 47831; choose another port with setup --port when creating a pairing.

Architecture and boundaries

MCP client → Node.js stdio MCP → 127.0.0.1 Hub

↕ local pairing Chrome / Edge MV3 extension ↓ chrome.debugger / CDP existing HTTP(S) / authorized file:// tabs

Each MCP connection holds its own control and handles cannot be used across connections. Disconnecting or stopping debugging releases control. The client endpoint requires a Bearer key and rejects web page Origins; the extension verifies a fixed Origin, key and version. browser_evaluate can read and write data with the page's existing sign-in state; a timeout or error may already have had an effect and must not be replayed automatically. No generic CDP tool is exposed.

Logs are collected from claim time, survive navigation and are cleared on release, with bounded buffers that report data_loss on eviction. Buffered reads use the existing claim without requiring a supported or responsive current page; capture changes still require page access. Network logs store lifecycle metadata and available initiators by default; an explicit capture reads bounded, redacted headers/bodies of subsequent XHR/fetch requests without changing caches or intercepting traffic. Navigation requests and commits remain separate obser