Skip to content
Guides

The OpenClaw Chrome extension

Driving your signed-in browser, pairing, and what it can and cannot see

6 min read

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.
Get started

Stop reading about it, build one

Set up an agent, pick a channel, and have it working inside the app you already keep open.