How to Set Up OpenClaw with Chrome CDP - Or Use the Version We Already Set Up for You

One of the most common reactions we see from people exploring OpenClaw is:

"This looks great, but how do I actually give it a real browser?"

The short answer is that you need more than just a Chrome binary.

If you want OpenClaw to browse reliably in the cloud, you need a complete browser path:

• a running Chrome instance with CDP enabled
• a tool the agent can call, like chrome-cdp
• a skill that tells the runtime when and how to use that tool
• a browser UI or endpoint you can open yourself when you want to inspect it
• routing that makes all of those pieces reachable in the tenant

We learned this by building it the hard way.

So this post has two messages:

1. yes, you can set this up yourself
2. if you use OpenClaw Box, we already set it up for you

What people usually try first - and why it is not enough

The first instinct is often something like:

• install Chromium
• install Puppeteer or Playwright
• tell the agent to use a browser

That sounds reasonable, but in practice it leaves a lot unsolved.

We found that real browser capability breaks down unless you answer all of these questions:

• where is Chrome actually running?
• what CDP endpoint does the tool connect to?
• what should the agent use by default for browsing tasks?
• how does the user open the browser surface manually?
• what happens in path-mode routing or reverse-proxy deployments?

That is why our setup became a full stack, not a one-package install.

The setup pattern that actually works

The working model we landed on is simple conceptually:

1. Run Chrome as a dedicated sidecar or service

In our tenant runtime, Chrome does not run inside the main gateway process.

We run a dedicated browserless/chrome sidecar with remote debugging enabled on port 9222.

That separation matters because it gives OpenClaw a stable browser target instead of trying to bootstrap a fresh desktop-style browser process inside every agent task.

2. Give the runtime a deterministic browser tool

We install a chrome-cdp binary into the tenant workspace tool path.

That gives the agent a direct, explicit browser automation primitive it can call for:

• loading pages
• waiting for selectors or text
• extracting DOM content
• reading titles, links, or structured page data

In our deployment, the skill examples look like this:

chrome-cdp --url "https://example.com" --wait-for-text "Example Domain" --eval "document.title"
chrome-cdp --url "https://example.com" --wait-for-selector "h1" --eval "document.querySelector('h1').innerText"

That is much more dependable than vaguely telling the agent to "browse the web somehow."

3. Install a skill that makes chrome-cdp the default path

This part is easy to underestimate.

Even if the tool exists, the runtime still needs to know:

• use chrome-cdp for browsing
• do not use the built-in browser tool in this deployment
• do not ask the user to attach tabs, install extensions, or open relay tabs
• try cloud browsing first, then explain limitations only if the target site really blocks access

That policy is what turns browser access from "available in theory" into "used correctly in practice."

Without the skill, the agent often falls back to the wrong mental model.

4. Expose a browser UI so the user can inspect the environment too

We also expose a browser UI on /browser/.

This is important because users do not just want to hope the browser exists. They want to open it, verify it, and understand what the runtime is using.

5. Hand the user the right URL from /status

The final product fix was simple but important: /status now shows both:

• Control Panel
• Browser

That means the user does not need to guess where the browser lives. The handoff is already in the runtime interface.

If you want to do this yourself

If you are self-hosting OpenClaw and want to recreate this stack, here is the practical checklist.

The minimum viable browser-enabled OpenClaw setup

1. Run OpenClaw normally.
2. Start a Chrome or browserless Chrome process with CDP enabled.
3. Make sure your runtime can reach that CDP endpoint.
4. Install the chrome-cdp tool into the runtime tool path.
5. Add a chrome skill that tells the agent to use chrome-cdp for browsing tasks.
6. Make the browser surface reachable to the user, ideally through a dedicated browser UI.
7. If you are behind path-mode routing or a gateway, ensure the browser URL carries the correct websocket routing information.

The last point is especially important.

One of the practical problems we hit was that browser links in path-mode deployments need the correct gatewayUrl websocket context. If that value is missing, the browser UI can connect incorrectly and the experience degrades into random disconnects.

So yes, you can wire this up yourself.

But it is one of those setups where each missing piece makes the whole thing feel flaky.

If you use OpenClaw Box, we already did the setup work

This is the simpler path.

Every OpenClaw Box tenant already ships with the browser stack prewired:

• a dedicated browserless Chrome sidecar
• a browser UI exposed on /browser/
• a preinstalled chrome-cdp binary in the workspace tools path
• a bundled chrome skill
• seeded workspace instructions that tell the runtime to use chrome-cdp first
• a /status response that gives you the Browser URL directly

So the message to the user is:

you can set up OpenClaw + Chrome CDP yourself, but if you use OpenClaw Box, you can skip the plumbing and start from a working setup.

That is exactly the kind of product work we want to do - remove the fragile integration layer and leave users with the useful part.

Why we think this matters

Giving OpenClaw a browser is not a vanity feature.

It changes the category of work the runtime can do.

Once browsing is reliable, OpenClaw becomes much more useful for:

• research tasks
• dashboards and admin panels
• documentation lookup
• web-native operator workflows
• tasks that require both chat and a real page context

And when the setup is already done, the user gets that capability without becoming a part-time infrastructure engineer.

That is the real promise here.

You should absolutely be able to build this stack yourself.

But if your real goal is to use OpenClaw with a cloud browser instead of spending half a day wiring Chrome, CDP, skills, and routing together, we already built that path for you.