Browser | Friends of the Crustacean 🦞🤝 | Page 1

olive mirage Apr 21, 2026, 6:32 PM

#

@grizzled niche my claw dosent seem to be able to attach to chrome using cdp. The remote desktop service just says starting on its inspection page. Ive tried different ports but to no success. I want him to use my existing chrome profile

grizzled nicheBOT Apr 21, 2026, 6:34 PM

#

Let me verify the docs path and the browser attach bits so I don’t guess.

#

First, what does openclaw --version say?

Also, if your goal is to use your already signed-in Chrome profile, don’t keep fighting random CDP ports unless Chrome and the gateway are on different machines.

The supported path is usually the built-in user profile / existing-session attach:

openclaw browser --browser-profile user start
openclaw browser --browser-profile user status
openclaw browser --browser-profile user tabs

What should be true for that to work:

Chrome is 144+
chrome://inspect/#remote-debugging has remote debugging enabled
Chrome stays open
you approve the attach prompt when OpenClaw connects

#

Good result:

driver: existing-session
transport: chrome-mcp
your current tabs show up

Two common gotchas:

Gateway and Chrome are not on the same machine
If OpenClaw is in Docker, WSL, a VPS, etc., the user profile usually won’t attach to your local desktop Chrome. Then you need either:
- a node host on the browser machine, or
- raw remote CDP with a profile like:
```
{
  browser: {
    profiles: {
      remote: {
```

#

           cdpUrl: "http://HOST:9222",
           attachOnly: true,
         },
       },
     },
   }

And from the gateway machine, this must work first:

curl http://HOST:9222/json/version

You want a non-default Chrome/Brave/Edge profile
Then make a custom existing-session profile with userDataDir, instead of just user.

If strict SSRF mode is on and you’re using localhost CDP, you may also need both:

#

browser.ssrfPolicy.allowedHostnames
browser.ssrfPolicy.hostnameAllowlist

with 127.0.0.1 and localhost.

Docs:

If you paste these 3 things, I can narrow it down fast:

openclaw --version
whether Chrome and the gateway are on the same machine
openclaw browser --browser-profile user status

olive mirage Apr 21, 2026, 6:36 PM

#

@grizzled niche im on default chrome and the latest version of claw. And chrome remote debugging just says status is starting... I want him to be able to access it without needing approval everytime aswell. Its set to user profile but he says he cant use it

grizzled nicheBOT Apr 21, 2026, 6:37 PM

#

I’m checking whether the Chrome consent prompt can be made persistent, because that part matters here.

#

Yeah, I think the key thing is this:

user is not raw CDP. It uses Chrome MCP existing-session attach.
So changing CDP ports usually won’t help for the built-in user profile.

If chrome://inspect/#remote-debugging itself is stuck on “starting”, that’s usually the Chrome-side remote debugging service not coming up yet, so OpenClaw has nothing to attach to.

A couple important bits from the docs:

user / existing-session is the right mode for your signed-in default Chrome
you should approve the first attach consent prompt
docs still frame this mode as something to use when you’re at the computer
if you want a truly unattended/reliable always-on browser, the managed openclaw profile is the safer path

So I’d try this exact smoke test:

#

openclaw doctor
openclaw browser --browser-profile user start
openclaw browser --browser-profile user status
openclaw browser --browser-profile user tabs

Also make sure:

Chrome is 144+
Chrome is fully open
you have at least one normal tab open
remote debugging is enabled in chrome://inspect/#remote-debugging

One subtle point: the docs say approve the first attach consent prompt, not “no prompt forever”. So if your main requirement is no approval every time, user may not be the best fit for what you want.

If you paste the exact output of:

openclaw doctor

#Browser