The OpenClaw Chrome extension
Driving your signed-in browser, pairing, and what it can and cannot see
The OpenClaw Chrome extension lets the browser tool automate eligible tabs in your signed-in Chrome profile, using Chrome’s debugger interface so there is no remote-debugging consent prompt. It is infrastructure, not a copilot: no chat, no prompt box, no page sharing. Its popup shows the connection state, the access mode, a pause-or-allow action for the current tab and a settings link. People search for it as the browser relay, which is the loopback relay it talks through. Here is how it is installed, paired and limited.
Requirements and install
- Chrome, Chrome for Testing or Chromium, launched at least once so the user-data directory exists.
- OpenClaw on the same machine, or an OpenClaw browser node on that machine.
- macOS or Linux for automatic native bootstrap; Windows keeps manual pairing.
- One install command that registers the native host and asks Chrome to install the Store extension; you approve it in Chrome, per profile, and OpenClaw never restarts Chrome or clicks the prompt for you.
How it connects
Select the built-in chrome browser profile or make it the default. Fresh automatic pairings use all tabs; existing pairings are never overwritten and keep their access mode. The first authenticated connection wakes the browser-control service and starts the profile’s loopback relay, which OpenClaw and local clients then use; keep the Gateway running and nothing else needs prewarming. On macOS and Linux a standalone relay can run without a local Gateway, on the exact IPv4 loopback address, rate-limited to one wake-up a minute.
It does not request activeTab, contextMenus, scripting, or sidePanel.
What it can see
- Permissions: the debugger, tabs and tab groups, storage for pairing and access mode, alarms to wake the worker, and native messaging for the bootstrap.
- The access mode decides which tabs are eligible; a pause action stops automation on the current tab.
- The native host handles one bootstrap request at a time and validates the response; a removed profile or a stale port fails closed.
Why this and not a headless browser
Because the point is your logged-in sessions: the extension drives the Chrome you already use, cookies and all, which is exactly why the prompt-injection page lists the browser among the high-risk tools to keep off tool-enabled agents unless needed. Prompt injection and OpenClaw has that argument; OpenClaw nodes and Remote Hands covers the other way to reach your machine, a paired node with computer use.
On Diali
On Diali the assistant has a browser of its own inside its sandbox on every plan, and Remote Hands is how it reaches your signed-in browser and installed apps on a machine you pair, with approval before it acts. Computer and Remote Hands on Diali is the page; Hosted OpenClaw on Diali the assistant.
- Your Chrome, your logins, driven over the debugger interface.
- One install command, one approval in Chrome, one relay on loopback.
- Powerful and risky for the same reason; treat it as a tool to gate.
Stop reading about it, build one
Set up an agent, pick a channel, and have it working inside the app you already keep open.
