Chrome error

[hollow raven]

On macOS with OpenClaw 2026.4.11, I’m hitting two browser issues that seem related but distinct.

First issue:

• managed browser profile fails
• openclaw browser start
• error: Chrome CDP websocket for profile "openclaw" is not reachable after start

Second issue:

• I switched away from the managed profile because of the above
• configured an explicit remote CDP Chrome on 127.0.0.1:9222
• browser config is now:

"browser": {
"enabled": true,
"defaultProfile": "openclaw-remote",
"ssrfPolicy": {
"dangerouslyAllowPrivateNetwork": true,
"allowedHostnames": ["x.com", "www.x.com"],
"hostnameAllowlist": ["*.x.com"]
},
"profiles": {
"openclaw-remote": {
"cdpUrl": "http://127.0.0.1:9222",
"color": "#FF4500"
},
"user": {
"driver": "existing-session",
"attachOnly": true,
"color": "#00AA00"
}
}
}

Repro:
1.

killall "Google Chrome"
open -na "Google Chrome" --args --remote-debugging-port=9222

2. restart gateway
3. test:

openclaw browser status
openclaw browser open https://x.com/home

Observed:

• openclaw browser status shows:
• profile: openclaw-remote
• cdpUrl: http://127.0.0.1:9222
• but navigation still fails with:
• GatewayClientRequestError: browser navigation blocked by policy

Related logs:

• before remote CDP fallback:
• Could not find DevToolsActivePort for chrome at ~/Library/Application Support/Google/Chrome/DevToolsActivePort
• after remote CDP fallback:
• browser.request ... errorCode=INVALID_REQUEST errorMessage=browser navigation blocked by policy

Question:

• is there another SSRF/config key required for remote CDP navigation in 2026.4.10/2026.4.11 beyond allowedHostnames, hostnameAllowlist, and dangerouslyAllowPrivateNetwork?
• or is this a regression where remote CDP browser open https://x.com/home is still denied even when hostname/private-network settings should allow it?

[remote goblet]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[sage igloo]

I found one subtle source-level wrinkle that matters here: a cdpUrl on 127.0.0.1 is treated as loopback/local, not as a true “remote-cdp” profile internally. I’m checking whether that changes the answer or just the workaround.

I found a likely regression candidate in the git history: d015986265 fix: preserve browser cdp ssrf policy. I’m opening that patch now, because it sounds uncomfortably close to what you’re seeing.

Short version, no extra hidden SSRF key.

What I found from docs/source:

• The relevant keys in 2026.4.10 / 2026.4.11 are:
  • browser.ssrfPolicy.dangerouslyAllowPrivateNetwork
  • browser.ssrfPolicy.allowedHostnames
  • browser.ssrfPolicy.hostnameAllowlist
  • legacy alias: browser.ssrfPolicy.allowPrivateNetwork
• In strict mode, OpenClaw also SSRF-checks the CDP endpoint itself, including /json/version discovery on profiles.*.cdpUrl. That is documented in docs/tools/browser.md and docs/gateway/configuration-reference.md, not a separate key.
• For an externally managed Chrome, attachOnly: true is the right profile shape. Not an SSRF key, just a good fix for this setup.

So with your exact config, openclaw browser open https://x.com/home should not be blocked. In extensions/browser/src/browser/navigation-guard.ts, the hostname strict-mode block only fires when dangerouslyAllowPrivateNetwork is false. Since yours is true, x.com should pass.

That makes this look more like a regression or config-load mismatch than “you missed another SSRF knob”.

Two nuances worth calling out:

1. Chrome CDP discovery can bounce between 127.0.0.1 and localhost
   If Chrome returns a webSocketDebuggerUrl on localhost, strict setups may need both 127.0.0.1 and localhost allowed. With dangerouslyAllowPrivateNetwork: true that should not matter, but it is still a good belt-and-suspenders tweak.

2. http://127.0.0.1:9222 is treated as loopback/local internally
   It is not treated like true non-loopback remote-cdp in profile-capabilities.ts. So I would still set:

   "openclaw-remote": {
     "cdpUrl": "http://127.0.0.1:9222",
     "attachOnly": true,
     "color": "#FF4500"
   }
   

On the first issue, the managed-profile failure is separate.
Chrome CDP websocket for profile "openclaw" is not reachable after start plus:

• Could not find DevToolsActivePort for chrome at ~/Library/Application Support/Google/Chrome/DevToolsActivePort

means Chrome never brought up its DevTools endpoint after launch. That comes from the launch/readiness path in server-context.availability.ts, so that is a browser startup problem on macOS, not SSRF.

If you want, I’d reply to them with this recommendation:

"browser": {
  "enabled": true,
  "defaultProfile": "openclaw-remote",
  "ssrfPolicy": {
    "dangerouslyAllowPrivateNetwork": true,
    "allowedHostnames": ["x.com", "www.x.com", "127.0.0.1", "localhost"],
    "hostnameAllowlist": ["*.x.com"]
  },
  "profiles": {
    "openclaw-remote": {
      "cdpUrl": "http://127.0.0.1:9222",

      "attachOnly": true,
      "color": "#FF4500"
    }
  }
}

And docs to link:

• https://docs.openclaw.ai/tools/browser
• https://docs.openclaw.ai/gateway/configuration-reference
• https://docs.openclaw.ai/gateway/troubleshooting

If they can paste the exact gateway log line around the rejected browser.request, I can help pin down whether 2026.4.11 is ignoring the loaded ssrfPolicy or blocking on a redirect/final URL.

[hollow raven]

Send this follow-up:

Tried the suggested refinement too, still reproduces.

Updated config now:

"browser": {
"enabled": true,
"defaultProfile": "openclaw-remote",
"ssrfPolicy": {
"dangerouslyAllowPrivateNetwork": true,
"allowedHostnames": ["x.com", "www.x.com", "127.0.0.1", "localhost"],
"hostnameAllowlist": ["*.x.com"]
},
"profiles": {
"openclaw-remote": {
"cdpUrl": "http://127.0.0.1:9222",
"attachOnly": true,
"color": "#FF4500"
}
}
}

Then:
1.

killall "Google Chrome"
open -na "Google Chrome" --args --remote-debugging-port=9222

2. restart gateway
3. test:

openclaw browser status
openclaw browser tabs
openclaw browser open https://x.com/home

Observed after restart:

• profile: openclaw-remote
• cdpUrl: http://127.0.0.1:9222
• openclaw browser tabs → No tabs (browser closed or no targets).
• openclaw browser open https://x.com/home still fails with:
• GatewayClientRequestError: browser navigation blocked by policy

So even with:

• dangerouslyAllowPrivateNetwork: true
• explicit allowlist for x.com, www.x.com, 127.0.0.1, localhost
• loopback CDP URL
• attachOnly: true

navigation is still denied.

At this point it looks like either:

• 2026.4.11 is ignoring loaded browser.ssrfPolicy for this loopback-CDP path, or
• there’s another internal policy check/regression on browser open that isn’t documented.

If helpful, the exact final state from openclaw browser status is:

• profile: openclaw-remote
• enabled: true
• running: false
• transport: cdp
• cdpPort: 9222
• cdpUrl: http://127.0.0.1:9222
• browser: unknown
• detectedBrowser: chrome

[sage igloo]

Thanks, that narrows it down a lot.

Given that it still reproduces with:

• dangerouslyAllowPrivateNetwork: true
• explicit allowlist for x.com, www.x.com, 127.0.0.1, localhost
• loopback cdpUrl
• attachOnly: true

I do not think there’s another undocumented SSRF/config key here.

At this point it really looks like either:

• a regression in 2026.4.11, or
• the loopback CDP path is not honoring the loaded browser.ssrfPolicy during browser open.

The docs/source only expose those SSRF knobs, and extensions/browser/src/browser/navigation-guard.ts only applies the hostname strict-mode block when dangerouslyAllowPrivateNetwork is false, so open https://x.com/home should not be denied with your config.

Also, the managed-browser failure still looks like a separate issue:

• Chrome CDP websocket for profile "openclaw" is not reachable after start
• Could not find DevToolsActivePort ...

That points to Chrome startup / CDP readiness on macOS, not SSRF.

Your final status output is useful too:

• enabled: true
• transport: cdp
• cdpUrl: http://127.0.0.1:9222
• running: false
• detectedBrowser: chrome

So OpenClaw is clearly seeing the profile config, but browser open is still failing with browser navigation blocked by policy.

This feels bug-worthy now. I’d file a GitHub issue with the exact config, repro, status output, and both error strings:

https://github.com/openclaw/openclaw/issues

If you do, include these exact commands too:

killall "Google Chrome"
open -na "Google Chrome" --args --remote-debugging-port=9222
openclaw browser status
openclaw browser tabs
openclaw browser open https://x.com/home

[hollow raven]

openclaw browser open "https://x.com/home"
→ Navigation blocked: strict browser SSRF policy requires an IP-literal URL because browser DNS rebinding protections are unavailable for hostname-based navigation

[sage igloo]

That exact error string is actually very helpful. I’m checking one thing before I answer, so I don’t invent a config command that doesn’t exist.

Oh, that’s the smoking gun.

That exact message:

Navigation blocked: strict browser SSRF policy requires an IP-literal URL because browser DNS rebinding protections are unavailable for hostname-based navigation

comes straight from extensions/browser/src/browser/navigation-guard.ts, and it only fires when OpenClaw believes it is still in strict mode for that request.

So this pretty strongly means:

• there is not another hidden SSRF key, and
• the live gateway is behaving as if browser.ssrfPolicy.dangerouslyAllowPrivateNetwork is false / unset, or the allowedHostnames / hostnameAllowlist you set are not what the request path is actually seeing.

In other words, this is no longer “maybe another browser flag”, it’s now either:

1. a config-load mismatch, stale gateway, wrong config file, etc., or
2. a real bug/regression in how the loopback CDP browser open path is reading browser.ssrfPolicy.