
Agent Webbridge
io.github.jeet-dhandhav1.3.1Updated Oct 9, 2026
Drive your real, logged-in Chrome (many profiles, parallel tabs) from any MCP client. Local only.
Overview
Lets an AI assistant drive your real, already signed-in Chrome through local MCP tools for navigation, clicking, filling, screenshots and JavaScript evaluation.
- What it does
- Runs a local MCP server that controls your actual Chrome browser, using your existing login sessions rather than a headless or cloud browser. Tools include navigate, find_tab, snapshot, click, trusted_click, fill, upload, evaluate, screenshot, save_as_pdf, network, list_tabs, close_tab and close_session. Calls can target a named Chrome profile and a session, so several profiles and many tabs can run in parallel. Everything is routed over the loopback interface.
- When to use it
- Useful when an assistant must work in pages that require your existing logins, passkeys or two-factor authentication, or that block headless and cloud browsers. Also suited to tasks needing several accounts or many tabs at once, such as reading pages, filling forms or capturing screenshots. Not intended for unattended automation of accounts or sites you are not entitled to automate.
- Requirements
- macOS or Windows with Google Chrome and Node.js 18 or newer; the package is run locally with npx. A one-time setup installs a daemon and a Chrome extension, and each Chrome profile must be brought up and connected. No accounts, API keys or environment variables are declared, though AWB_CHROME_BIN and AWB_CHROME_DIR can be set for non-standard Chrome installs. Linux paths exist but are untested.
Installation
In SourceWeft
- Open Agent Webbridge in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
agent-webbridge
[npm] [Chrome Web Store] [license] [node]
Let Claude Code, Cursor and any MCP client drive your real, logged-in Chrome — many profiles, many tabs, in parallel. No headless re-login, no bot detection, no cloud. Nothing leaves
127.0.0.1.
Add it to your agent (30 seconds)
Then add the MCP server to Claude Desktop, Claude Code, Cursor or Windsurf:
Claude Code: claude mcp add chrome -- npx -y agent-webbridge mcp
Or install it as an agent skill (Claude Code, Cursor, Codex and others): npx skills add jeet-dhandha/agent-webbridge
Your agent now has browser_navigate, browser_snapshot, browser_click, browser_fill, browser_evaluate, browser_screenshot and more — all running in your Chrome, with your sessions. Pass profile to choose an account and tabId to run tabs in parallel. If a call fails, browser_status tells the agent which profile isn't connected.
Why not Playwright or a cloud browser?
It automates a browser you are already signed in to — use it only on accounts and sites you are entitled to automate, and respect each site's terms.
agent-webbridge is a tiny Node daemon (one runtime dependency: ws) plus a clean-room MV3 Chrome extension. An agent POSTs a command to a local router → the router fans it out to the right profile's daemon → the extension attaches the Chrome DevTools Protocol per tab.
See it work
Real runs, not mock-ups: a script sends MCP calls to npx agent-webbridge mcp, which drives a real, signed-in Chrome profile. The screenshots are the browser's own and the timings are measured. Public pages only; nothing is submitted to any account.
Timings come from one MacBook on home broadband; yours will differ.
Overview
- Drive your real browser — your actual Chrome, your actual login sessions. No headless re-login, no scraping around auth.
- Run tabs in parallel — the extension attaches
chrome.debuggerper tab, so N tabs in one profile run concurrently. 10 tabs finish as fast as 1 (~2 s, flat). - Span multiple profiles — one daemon per profile. Total concurrency = profiles × tabs, all from one endpoint.
- Stay private — own daemon, own MV3 extension, no closed-source dependency, no account. Everything is local.
Install
awb setup opens the Agent WebBridge listing in your chosen profile and polls while you click Add to Chrome. As soon as it detects the install, it wires the profile to its daemon and brings the fleet up.
Requirements: macOS or Windows · Google Chrome · Node.js ≥ 18.
Quickstart
Every call is a POST /command on 127.0.0.1:10086. Wrap payloads in single quotes ('...') to prevent shell quote-escaping issues. "session" groups a task's tabs into one Chrome tab group; "profile" picks which Chrome profile to drive. Pass {"action":"screenshot","args":{"path":"/path/to/img.png"}} to save screenshots directly to disk.
Tools
How it works
The router proxies each command to the per-profile daemon on its deterministic hashed port; the daemon relays over WebSocket to that profile's extension; the extension keeps a Map of chrome.debugger attachments — one per tab — and issues CDP calls. That per-tab map is the whole trick: bridges that funnel everything through a single "current tab" can only drive one tab per profile; this drives N.
CLI
<profile> is anything that resolves uniquely — the profile name ("Work"), an email, or the Chrome directory ("Profile 2").
Use it from an AI agent
Ship it as a Claude Code skill / plugin — the bundled agent-webbridge skill teaches an agent the full flow (install via awb check --json, then drive over POST /command). To hack on the extension itself, awb install-dev Load-unpacks the in-repo build (chrome://extensions → Developer mode → Load unpacked → agent-webbridge-extension/); it ships its own key, so the dev id is stable across reloads.
Platform
Set AWB_CHROME_BIN / AWB_CHROME_DIR if Chrome or its data directory is somewhere non-standard (Chrome Beta, portable installs). Linux paths are wired up but untested.
On Windows, run commands from PowerShell or cmd (the curl examples below use bash quoting; in PowerShell use curl.exe and a here-string, or just use the MCP server). The daemon and the Windows code paths are covered by CI on windows-latest; the Chrome-launching steps (awb setup / awb up) are the least-tested part — please open an issue if one misbehaves.
Security
- Everything listens on
127.0.0.1only. As of 1.3.1 the router and daemons also refuse requests that carry a webOriginor a non-loopbackHost, so a website you visit cannot drive the bridge (see the changelog). Upgrade from earlier versions and restart the fleet withawb down && awb up. - It acts as you, in your signed-in browser. Any local program that can reach
127.0.0.1:10086can do the same, so only run it on a machine and account you trust, and keep irreversible actions (posting, paying, deleting) behind a human confirmation in your agent. - Report vulnerabilities privately through GitHub's "Report a vulnerability" on the Security tab.
License
MIT © jeet-dhandha
Source: README.md at commit bfd8cf7
Tools
0Version history
1- v1.3.1LatestOct 9, 2026

