CDP browser not working. again. | Friends of the Crustacean 🦞🤝 | Page 1

limber holly Apr 15, 2026, 6:19 AM

#

14:14:54 [tools] browser failed: Error: Chrome CDP websocket for profile "openclaw" is not reachable after start. raw_params={"action":"start","profile":"openclaw"}
14:14:58 [ws] ⇄ res ✓ sessions.list 259ms conn=22d4c3c6…5fbe id=60caea56…a5f9
14:14:58 [tools] browser failed: Browser attachOnly is enabled and profile "scraper" is not running. raw_params={"action":"start"}
14:15:02 [ws] ⇄ res ✓ sessions.list 247ms conn=22d4c3c6…5fbe id=2e5a1e55…5bed
14:15:09 [ws] ⇄ res ✓ sessions.list 275ms conn=22d4c3c6…5fbe id=4cd6f90f…cc7a
14:15:09 [tools] browser failed: Navigation blocked: strict browser SSRF policy requires an IP-literal URL because browser DNS rebinding protections are unavailable for hostname-based navigation raw_params={"action":"open","profile":"scraper","url":"https://hk.jobsdb.com"}

tawny rivetBOT Apr 15, 2026, 6:21 AM

#

I’m checking the browser docs against the current version so I don’t make up config keys.

#

These are 3 different failures, not one:

profile="openclaw"
Chrome CDP websocket ... not reachable after start
-> managed browser launch/attach is failing.
profile="scraper"
attachOnly is enabled
-> OpenClaw will not launch that profile. The external browser for scraper must already be running at its cdpUrl, or attachOnly: true needs to go.
https://hk.jobsdb.com
strict browser SSRF policy requires an IP-literal URL...
-> this is a navigation policy block, separate from CDP startup. In strict mode, hostname URLs need an explicit allow.

A few likely fixes:

If this is Linux, managed openclaw often fails when it picks snap Chromium. Prefer Chrome/Brave via browser.executablePath, or use attach-only with a manually started browser. Docs: https://docs.openclaw.ai/tools/browser-linux-troubleshooting

#

If scraper is remote/externally managed, keep attachOnly: true but make sure that browser is already running and profiles.scraper.cdpUrl is reachable from the gateway host.
For the SSRF block, add exact/pattern host exceptions, for example:
- browser.ssrfPolicy.allowedHostnames: ["hk.jobsdb.com", "127.0.0.1", "localhost"]
- or browser.ssrfPolicy.hostnameAllowlist: ["*.jobsdb.com"]

Also, open can fail its SSRF check before startup succeeds, so that last error does not prove scraper is actually running.

Can you paste these next:

openclaw --version
openclaw status --all
openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile scraper status

and the redacted browser: section from ~/.openclaw/openclaw.json?

#

Relevant docs:

FAQ: https://docs.openclaw.ai/help/faq
Browser: https://docs.openclaw.ai/tools/browser
WSL2/remote CDP if relevant: https://docs.openclaw.ai/tools/browser-wsl2-windows-remote-cdp-troubleshooting

limber holly Apr 15, 2026, 6:22 AM

#

"browser": {
"enabled": true,
"defaultProfile": "scraper",
"profiles": {
"scraper": {
"cdpUrl": "http://127.0.0.1:18810",
"attachOnly": true,
"color": "#FF4500"
},
"linkedin": {
"driver": "existing-session",
"attachOnly": true,
"userDataDir": "C:\Users\glysh\AppData\Local\BraveSoftware\Brave-Browser\User Data",
"color": "#FF4500"
}
}
},

why do i need to keep the ssrf block?
i have removed it because it was affecting my scraping performance, it was being blocked thats why i had to get rid of it

tawny rivetBOT Apr 15, 2026, 6:23 AM

#

You do not have to keep the explicit strict SSRF block if it’s hurting your scraping flow.

The important distinction is:

Remove the explicit strict setting
Good middle ground for public scraping.
Set dangerouslyAllowPrivateNetwork: true
Much broader, this allows private/internal targets too.

So if you just removed:

browser: {
  ssrfPolicy: {
    dangerouslyAllowPrivateNetwork: false
  }

#

that’s actually reasonable for your use case. I would not turn it all the way to true unless you intentionally want the browser tool to be able to hit localhost/LAN/private stuff too.

For your current config, the bigger issue is this:

"scraper": {
  "cdpUrl": "http://127.0.0.1:18810",
  "attachOnly": true
}

That means OpenClaw expects a browser/CDP endpoint to already be running on 127.0.0.1:18810.
If nothing is serving CDP there, start will fail, because attach-only profiles are not launched by OpenClaw.

#

So I’d debug it like this:

Make sure your external browser is actually running with remote debugging on 18810

Verify this works on the same machine:

curl http://127.0.0.1:18810/json/version

If that fails, OpenClaw is not the problem yet, the CDP target is just not up
If it succeeds, scraper should be usable

Also, this log:

profile "openclaw"

is separate. Since you didn’t define openclaw, OpenClaw auto-creates a managed openclaw profile. So something is still explicitly trying to use profile="openclaw" instead of scraper.

#

My recommendation:

For scraping public sites: leave ssrfPolicy unset
Keep scraper.attachOnly: true if you want to manage the browser yourself
Make sure something is actually listening on 127.0.0.1:18810
Make sure your tool call/profile selection is really scraper, not openclaw

If you want, paste:

curl http://127.0.0.1:18810/json/version
openclaw --version

and I can tell you pretty quickly which layer is still broken.

Docs:

https://docs.openclaw.ai/tools/browser

#

https://docs.openclaw.ai/gateway/security

limber holly Apr 15, 2026, 8:39 AM

#

PS C:\Windows\system32> curl http://127.0.0.1:18810/json/version

openclaw --version
curl : Unable to connect to the remote server
At line:1 char:1

curl http://127.0.0.1:18810/json/version

  + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
 eption
  + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

OpenClaw 2026.4.12 (1c0672b)

tawny rivetBOT Apr 15, 2026, 8:40 AM

#

Nice, that isolates it.

curl http://127.0.0.1:18810/json/version failing means nothing is listening on 127.0.0.1:18810, so this part is not an OpenClaw bug yet, it’s just your scraper CDP target not being up.

Because your profile is:

"scraper": {
  "cdpUrl": "http://127.0.0.1:18810",
  "attachOnly": true
}

OpenClaw is doing exactly what it should: attach to an already-running browser. It will not launch one for that profile.

Next step

#

Start a Chromium browser manually with remote debugging on 18810.

Example with Brave on Windows:

& "$env:ProgramFiles\BraveSoftware\Brave-Browser\Application\brave.exe" `
  --remote-debugging-port=18810 `
  --user-data-dir="$env:LOCALAPPDATA\OpenClaw\scraper-browser" `
  about:blank

Then retry:

curl http://127.0.0.1:18810/json/version

#

If that returns JSON, scraper should be attachable.

Two other important bits

Restart the gateway after browser config changes
Browser config changes need a restart:
```
openclaw gateway restart
```
Why are you still seeing profile="openclaw"?
That means something is still explicitly targeting openclaw, or the gateway is still using old config. Since your default is scraper, I’d strongly suspect stale config until restart.

Recommendation

If you want to manage the browser yourself, keep scraper.attachOnly: true
If you want OpenClaw to launch it, don’t use attach-only for that profile

#

Leave ssrfPolicy unset unless you specifically want the stricter hostname blocking mode

If you want, send the output of:

openclaw gateway restart
curl http://127.0.0.1:18810/json/version
openclaw browser --browser-profile scraper status

and we can finish the last mile.

limber holly Apr 15, 2026, 9:45 AM

#

PS C:\Windows\system32> curl http://127.0.0.1:18810/json/version

StatusCode : 200
StatusDescription : OK
Content : {
"Browser": "Chrome/147.0.7727.56",
"Protocol-Version": "1.3",
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/147.0.0.0 Safari/537....
RawContent : HTTP/1.1 200 OK
Content-Security-Policy: frame-ancestors 'none'
Content-Length: 422
Content-Type: application/json; charset=UTF-8

                {
                   "Browser": "Chrome/147.0.7727.56",
                   "Protocol-Version":...

Forms : {}
Headers : {[Content-Security-Policy, frame-ancestors 'none'], [Content-Length, 422], [Content-Type,
application/json; charset=UTF-8]}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : mshtml.HTMLDocumentClass
RawContentLength : 422

PS C:\Windows\system32> openclaw browser --browser-profile scraper status

🦞 OpenClaw 2026.4.12 (1c0672b) — Making 'I'll automate that later' happen now.

|
o
profile: scraper
enabled: true
running: false
transport: cdp
cdpPort: 18810
cdpUrl: http://127.0.0.1:18810
browser: unknown
detectedBrowser: brave
detectedPath: C:\Program Files\BraveSoftware\Brave-Browser\Application\brave.exe
profileColor: #FF4500

tawny rivetBOT Apr 15, 2026, 9:47 AM

#

That’s progress. 👍

You’ve now proven the HTTP CDP endpoint is up on 127.0.0.1:18810.

So the problem is narrower now:

/json/version works
but OpenClaw still does not think the CDP WebSocket is reachable yet

status showing running: false here means “HTTP answered, but WS wasn’t confirmed”.

Next 2 commands

openclaw browser --browser-profile scraper start
openclaw browser --browser-profile scraper tabs

#

If those work, you’re good.

If start still fails, then I want the raw /json/version body, not the formatted PowerShell summary:

(iwr http://127.0.0.1:18810/json/version).Content

Paste that, especially the webSocketDebuggerUrl.

Two likely causes if it still fails

Gateway still has stale browser config
- if you changed browser.ssrfPolicy or default profile, restart the gateway:
```
openclaw gateway restart
```

#

The WS URL returned by /json/version is what’s failing
- for example, if it comes back as ws://localhost:18810/... and you still have strict SSRF anywhere, that can still bite you
- if you keep strict mode, allow both 127.0.0.1 and localhost
- if you don’t need strict mode, leaving ssrfPolicy unset is simpler

Also, the old profile="openclaw" error still looks like either:

stale gateway config, or
some tool call explicitly requesting openclaw

So I’d do:

openclaw gateway restart
openclaw browser --browser-profile scraper start
openclaw browser --browser-profile scraper tabs
(iwr http://127.0.0.1:18810/json/version).Content

#

Paste the failing line if any, and we can pin it down fast.

limber holly Apr 15, 2026, 9:51 AM

#

PS C:\Windows\system32> openclaw browser --browser-profile scraper start

openclaw browser --browser-profile scraper tabs

🦞 OpenClaw 2026.4.12 (1c0672b) — I don't have opinions about tabs vs spaces. I have opinions about everything else.

|
do
GatewayClientRequestError: Browser attachOnly is enabled and profile "scraper" is not running.

🦞 OpenClaw 2026.4.12 (1c0672b) — I autocomplete your thoughts—just slower and with more API calls.

|
dado
No tabs (browser closed or no targets).
PS C:\Windows\system32> (iwr http://127.0.0.1:18810/json/version).Content
{
"Browser": "Chrome/147.0.7727.56",
"Protocol-Version": "1.3",
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36",
"V8-Version": "14.7.173.16",
"WebKit-Version": "537.36 (@d491a927d068805831350ec9d7e5afda454e83c)",
"webSocketDebuggerUrl": "ws://127.0.0.1:18810/devtools/browser/e8e4a3c6-ae53-4d95-b79a-55728709dc42"
}

tawny rivetBOT Apr 15, 2026, 9:52 AM

#

Aha, this is the key clue.

Your /json/version output is healthy. It includes a valid:

webSocketDebuggerUrl: ws://127.0.0.1:18810/devtools/browser/...

So the CDP endpoint itself is fine.

But OpenClaw is still throwing:

Browser attachOnly is enabled and profile "scraper" is not running.

That specific error means the gateway could not even reach the HTTP CDP endpoint.

#

So the likely problem now is:

OpenClaw is not probing the same `127.0.0.1` that your PowerShell is

That usually happens when the gateway is running in a different network context, for example:

WSL2
Docker
VM
remote node host

If that’s true, then this config is wrong for the gateway side:

"cdpUrl": "http://127.0.0.1:18810"

#

because 127.0.0.1 means “this host”, not “your Windows browser host”.

So the big question:

Is your gateway actually running on native Windows, or is it running in WSL2 / Docker / another host?

If it’s WSL2 or another host, change scraper.cdpUrl to the Windows host address reachable from the gateway, not Windows localhost.

Docs for exactly this case:
https://docs.openclaw.ai/tools/browser-wsl2-windows-remote-cdp-troubleshooting

Why I’m pretty confident

Because if OpenClaw could hit /json/version but not the socket, you’d usually get the websocket not reachable variant.
You’re getting the profile not running variant, which points to the gateway not seeing that HTTP endpoint at all.

If you want, send:

#

openclaw gateway status
openclaw status --all

and tell me whether the gateway is Windows-native or WSL2. That should pin it down fast.

limber holly Apr 15, 2026, 9:58 AM

#

it is windows-native. i have ran the 2 commands, but the output is too long, which part did you want?

tawny rivetBOT Apr 15, 2026, 9:59 AM

#

Perfect, if it’s Windows-native then I only need the bits that tell us what config the gateway actually loaded and what it thinks the browser state is.

Please paste just these:

1) Full `openclaw gateway status`

That one is usually short enough.

2) From `openclaw status --all`, only the lines/section mentioning:

browser
scraper
18810
cdp
config path / target URL

If PowerShell helps, you can filter it:

#

openclaw status --all | Select-String "browser|Browser|scraper|18810|cdp|CDP|config|target"

3) Best signal: gateway logs right after reproducing it

In one terminal:

openclaw logs --follow

Then in another:

openclaw browser --browser-profile scraper start

#

Paste the browser-related log lines right after that, especially anything mentioning:

scraper
18810
cdp
ssrf
attachOnly

That should be enough. No need to dump the whole wall of text.

limber holly Apr 15, 2026, 10:03 AM

#

Service: Scheduled Task (registered)
File logs: ~\AppData\Local\Temp\openclaw\openclaw-2026-04-15.log
Command: C:\Program Files\nodejs\node.exe F:\npm-global\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: F:\openclaw-state\gateway.cmd
Service env: OPENCLAW_STATE_DIR=F:\openclaw-state OPENCLAW_CONFIG_PATH=F:\openclaw-state\openclaw.json OPENCLAW_GATEWAY_PORT=18789

Config (cli): F:\openclaw-state\openclaw.json
Config (service): F:\openclaw-state\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (last run 267009, last run time 4/15/2026 5:25:38 PM)
RPC probe: ok

Listening: 127.0.0.1:18789

tawny rivetBOT Apr 15, 2026, 10:03 AM

#

Nice, that rules out a bunch of annoying stuff:

gateway is definitely Windows-native
CLI + service are using the same config file
gateway itself is healthy

So now I’m pretty suspicious this is a gateway-side browser probe bug or some weird service-context loopback issue.

The missing piece is still the browser log lines right when scraper start fails.

Please paste this:

Get-Content "$env:LOCALAPPDATA\Temp\openclaw\openclaw-2026-04-15.log" -Tail 200 |
  Select-String "browser|scraper|18810|cdp|attachOnly|ssrf"

#

If that doesn’t catch the failure, do this live:

Get-Content "$env:LOCALAPPDATA\Temp\openclaw\openclaw-2026-04-15.log" -Wait |
  Select-String "browser|scraper|18810|cdp|attachOnly|ssrf"

then in another terminal run:

openclaw browser --browser-profile scraper start

and paste the new matching lines.

One quick sanity check too, just so we don’t chase ghosts:
did you restart the gateway after changing the browser config / removing the strict SSRF block?

#

If not:

openclaw gateway restart

then retry once.

If the log still shows the gateway insisting scraper is not running while /json/version is clearly alive, I’d call that bug territory.

limber holly Apr 15, 2026, 10:07 AM

#

F:/npm-global/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:159","me
thod":"console.log"}},"time":"2026-04-15T17:50:01.997+08:00"}
{"0":"{"subsystem":"gateway/ws"}","1":"\u001b[93mâ‡„\u001b[39m \u001b[1mres\u001b[22m \u001b[91mâœ—\u001b[39m
\u001b[1mbrowser.request\u001b[22m \u001b[2m2ms\u001b[22m \u001b[2merrorCode\u001b[22m=INVALID_REQUEST
\u001b[2merrorMessage\u001b[22m=Browser attachOnly is enabled and profile "scraper" is not running.
\u001b[2mconn\u001b[22m=\u001b[90mc3c829bcâ€¦8ff9\u001b[39m \u001b[2mid\u001b[22m=\u001b[90m3ca71e55â€¦08fc\u001b[39m",
"_meta":{"runtime":"node","runtimeVersion":"24.13.1","hostname":"LPA","name":"{"subsystem":"gateway/ws"}","parentNa
mes":["openclaw"],"date":"2026-04-15T10:06:50.880Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:/
//F:/npm-global/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:330:14","fileName":"subsystem-CSBs8ZPt.js","fileNameWi
thLine":"subsystem-CSBs8ZPt.js:330","fileColumn":"14","fileLine":"330","filePath":"/F:/npm-global/node_modules/openclaw
/dist/subsystem-CSBs8ZPt.js","filePathWithLine":"/F:/npm-global/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:330","
method":"logToFile"}},"time":"2026-04-15T18:06:50.883+08:00"}
{"0":"\u001b[38;2;226;61;45mGatewayClientRequestError: Browser attachOnly is enabled and profile "scraper" is not run
ning.\u001b[39m","_meta":{"runtime":"node","runtimeVersion":"24.13.1","hostname":"LPA","name":"openclaw","date":"2026-0
4-15T10:06:50.888Z","logLevelId":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///F:/npm-global/node_modules/op
enclaw/dist/subsystem-CSBs8ZPt.js:161:68","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:
161","fileColumn":"68","fileLine":"161","filePath":"/F:/npm-global/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","f
ilePathWithLine":"/F:/npm-global/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:161","method":"console.error"}},"time
":"2026-04-15T18:06:50.891+08:00"}

tawny rivetBOT Apr 15, 2026, 10:08 AM

#

Yep, I think we’ve crossed into real bug / bad edge case territory.

You now have all the evidence for it:

Windows-native gateway
same config file for CLI + service
/json/version works
valid webSocketDebuggerUrl comes back
but OpenClaw still says attach-only profile is “not running”

That is not what I’d expect.

Best temporary workaround

Try using the direct WebSocket URL instead of the HTTP CDP base URL.

So for scraper, temporarily change:

#

"scraper": {
  "cdpUrl": "ws://127.0.0.1:18810/devtools/browser/e8e4a3c6-ae53-4d95-b79a-55728709dc42",
  "attachOnly": true,
  "color": "#FF4500"
}

then restart the gateway:

openclaw gateway restart

and retry:

#

openclaw browser --browser-profile scraper start
openclaw browser --browser-profile scraper tabs

Important catch

That webSocketDebuggerUrl is ephemeral. If the browser restarts, it will change, so this is a workaround, not a real fix.

What this would prove

If the direct ws://... URL works, then the broken part is very likely the HTTP discovery / reachability path for attach-only CDP on your setup.

I’d file this as a bug

Please open a GitHub issue with:

your browser config snippet
openclaw --version
the openclaw gateway status output

#

the /json/version output showing webSocketDebuggerUrl
the exact error:
- Browser attachOnly is enabled and profile "scraper" is not running.

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

If you test the direct ws://... workaround, send the result here, that’ll make the bug report much stronger.

limber holly Apr 15, 2026, 10:09 AM

#

where do i change that for 'scraper'? in config or do i just put it in powershell?

tawny rivetBOT Apr 15, 2026, 10:09 AM

#

In the config file, not PowerShell directly.

For your setup, edit:

F:\openclaw-state\openclaw.json

Change the scraper profile from:

"scraper": {
  "cdpUrl": "http://127.0.0.1:18810",
  "attachOnly": true,
  "color": "#FF4500"
}

#

to:

"scraper": {
  "cdpUrl": "ws://127.0.0.1:18810/devtools/browser/e8e4a3c6-ae53-4d95-b79a-55728709dc42",
  "attachOnly": true,
  "color": "#FF4500"
}

Then restart the gateway:

openclaw gateway restart

and retry:

#

openclaw browser --browser-profile scraper start
openclaw browser --browser-profile scraper tabs

Important: that ws://.../devtools/browser/... value is temporary. If Chrome/Brave restarts, it will change, so you’d need to update it again.

So yes, this is just a workaround to confirm the bug, not the permanent fix.

limber holly Apr 15, 2026, 10:20 AM

#

openclaw browser --browser-profile scraper tabs
|
o
Error: gateway timeout after 45000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopbackuest
Config: F:\openclaw-state\openclaw.json
Bind: loopback

tawny rivetBOT Apr 15, 2026, 10:20 AM

#

Oof, yeah, that’s bug territory.

If the direct ws://... URL also ends up hanging the gateway for 45s, then this is no longer just the HTTP discovery path. The attach path itself looks broken on your setup.

What I’d do now

Revert scraper.cdpUrl back to the original HTTP form:
```
"cdpUrl": "http://127.0.0.1:18810"
```
File a GitHub issue with the full repro. This is the right next step now:
https://github.com/openclaw/openclaw/issues

Include these exact points

Windows-native gateway

#

OpenClaw version:
```
OpenClaw 2026.4.12 (1c0672b)
```

attach-only CDP profile:

"scraper": {
  "cdpUrl": "http://127.0.0.1:18810",
  "attachOnly": true
}

curl http://127.0.0.1:18810/json/version works
/json/version returns a valid webSocketDebuggerUrl
but:
- openclaw browser --browser-profile scraper start
  says Browser attachOnly is enabled and profile "scraper" is not running
- and using the direct ws://.../devtools/browser/... URL causes:

#

gateway timeout after 45000ms

That’s a pretty solid repro already.

If you need to keep moving right now

Use one of these instead:

a managed openclaw profile if external attach is not required
your linkedin existing-session profile if what you really need is the live Brave session rather than raw CDP attach

I’m sorry, this one really does look like the kind of thing maintainers need to fix.

limber holly Apr 16, 2026, 11:20 AM

#

just now my openclaw won't launch and i am seeing the below error in openclaw doctor:

Config invalid; doctor will run with best-effort config.

Multiple state directories detected. This can split session history. |
| - ~.openclaw |
| Active state dir: F:\openclaw-state |
| - Found 2 agent directories on disk without a matching agents.list entry. |
| These agents can still have sessions/auth state on disk, but config-driven routing, |
| identity, and model selection will ignore them. |
| Examples: anthropic, minimax |
| Restore the missing agents.list entries or remove stale dirs after confirming they are |
| no longer needed: F:\openclaw-state\agents |
| - 1/5 recent sessions are missing transcripts. |
| Verify sessions in store: openclaw sessions --store |
| "F:\openclaw-state\agents\main\sessions\sessions.json" |
| Preview cleanup impact: openclaw sessions cleanup --store |
| "F:\openclaw-state\agents\main\sessions\sessions.json" --dry-run |
| Prune missing entries: openclaw sessions cleanup --store |
| "F:\openclaw-state\agents\main\sessions\sessions.json" --enforce --fix-missing

tawny rivetBOT Apr 16, 2026, 11:21 AM

#

I’m checking the doctor/state-dir docs so I can separate harmless warnings from the thing actually blocking launch.

#

That doctor output looks scary, but most of it is warning-level cleanup stuff, not “won’t launch” stuff.

The important split is:

Probably not the blocker

multiple state dirs detected
stale agent dirs on disk
missing session transcripts

Those can make history/state messy, but they usually do not stop OpenClaw from starting.

The part that might block startup

Config invalid; doctor will run with best-effort config.

That usually means there’s a real config problem somewhere, and doctor is falling back enough to keep checking other things.

So I would not delete/cleanup anything yet

#

Don’t run the session cleanup / remove agent dirs / nuke ~\.openclaw yet.
Let’s get the actual startup error first.

Please paste these 2 things

1) `openclaw gateway status`

2) the latest startup errors from logs

Since your log path is in temp, something like:

Get-Content "$env:LOCALAPPDATA\Temp\openclaw\openclaw-2026-04-16.log" -Tail 120

or if today’s filename differs, the newest one from that folder.

If you want to keep it shorter, filter for likely useful lines:

#

Get-Content "$env:LOCALAPPDATA\Temp\openclaw\openclaw-2026-04-16.log" -Tail 200 |
  Select-String "error|invalid|config|browser|gateway|failed|exception"

My current guess

The duplicate state dir warning is probably not why launch failed.
The invalid config line is the thing I’d chase first.

Docs:

limber holly Apr 16, 2026, 11:25 AM

#

i wasn't even done pasting everything
but here is the rest:

Chrome MCP existing-session is configured for profile(s): linkedin. |
| - These profiles use an explicit Chromium user data directory instead of Chrome's |
| default auto-connect path. |
| - Verify the matching Chromium-based browser is version 144+ on the same host as the |
| Gateway or node. |
| - Enable remote debugging in that browser's inspect page |
| (chrome://inspect/#remote-debugging, brave://inspect/#remote-debugging, |
| edge://inspect/#remote-debugging). |
| - Keep the browser running and accept the attach consent prompt the first time OpenClaw |
| connects.
Runtime: stopped (state Ready, last run 1, last run time 4/16/2026 7:09:25 PM, Task Last |
| Run Result=1; treating as not running.) |
| Service is loaded but not running (likely exited immediately). |
| File logs: C:\Users\glysh\AppData\Local\Temp\openclaw\openclaw-2026-04-16.log |
| Logs: schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST

tawny rivetBOT Apr 16, 2026, 11:25 AM

#

Yep, this is the useful part.

The Chrome MCP / linkedin section is just advisory.
The real problem is here:

Runtime: stopped
Task Last Run Result=1
Service is loaded but not running (likely exited immediately)

So the gateway is crashing on startup.

Next thing I need

The last ~100 lines of:

C:\Users\glysh\AppData\Local\Temp\openclaw\openclaw-2026-04-16.log

#

Please paste this:

Get-Content "C:\Users\glysh\AppData\Local\Temp\openclaw\openclaw-2026-04-16.log" -Tail 120

If you want a shorter paste, filter it:

Get-Content "C:\Users\glysh\AppData\Local\Temp\openclaw\openclaw-2026-04-16.log" -Tail 200 |
  Select-String "error|failed|exception|invalid|config|schema|EADDR|browser|gateway"

Short version

At this point, don’t focus on:

multiple state dirs

#

missing transcripts
the linkedin readiness note

Those are not the main blocker right now.

The blocker is: the gateway starts, exits immediately, and we need the log line that says why.

limber holly Apr 16, 2026, 11:27 AM

#

browser.profiles.openclaw: Unrecognized key: "executablePath"\u001b[39m","_meta":{"ru
ntime":"node","runtimeVersion":"24.13.1","hostname":"LPA","name":"openclaw","date":"2026-04-16T11:14:05.848Z","logLevel
Id":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///F:/npm-global/node_modules/openclaw/dist/subsystem-CSBs8ZP
t.js:161:68","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:161","fileColumn":"68","fileL
ine":"161","filePath":"/F:/npm-global/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","filePathWithLine":"/F:/npm-glo
bal/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:161","method":"console.error"}},"time":"2026-04-16T19:14:05.849+08
:00"}
{"0":"","_meta":{"runtime":"node","runtimeVersion":"24.13.1","hostname":"LPA","name":"openclaw","date":"2026-04-16T11:1
4:05.850Z","logLevelId":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///F:/npm-global/node_modules/openclaw/di
st/subsystem-CSBs8ZPt.js:161:68","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:161","fil
eColumn":"68","fileLine":"161","filePath":"/F:/npm-global/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","filePathWi
thLine":"/F:/npm-global/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:161","method":"console.error"}},"time":"2026-0
4-16T19:14:05.851+08:00"}
{"0":"\u001b[38;2;139;127;119mRun:\u001b[39m \u001b[38;2;255;122;61mopenclaw doctor --fix\u001b[39m","_meta":{"runtime"
:"node","runtimeVersion":"24.13.1","hostname":"LPA","name":"openclaw","date":"2026-04-16T11:14:05.852Z","logLevelId":5,
"logLevelName":"ERROR","path":{"fullFilePath":"file:///F:/npm-global/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js:1
61:68","fileName":"subsystem-CSBs8ZPt.js","fileNameWithLine":"subsystem-CSBs8ZPt.js:161","fileColumn":"68","fileLine":"
161","filePath":"/F:/npm-global/node_modules/openclaw/dist/subsystem-CSBs8ZPt.js","filePathWithLine":"/F:/npm-global/no
de_modules/openclaw/dist/subsystem-CSBs8ZPt.js:161","method":"console.error"}},

tawny rivetBOT Apr 16, 2026, 11:28 AM

#

Yep, that’s the blocker. Nice catch.

The launch failure is not the state-dir warnings. It’s this:

browser.profiles.openclaw: Unrecognized key: "executablePath"

What’s wrong

executablePath is a top-level browser key, not a per-profile key.

So this is wrong:

browser: {

#

  profiles: {
    openclaw: {
      executablePath: "C:\\Program Files\\BraveSoftware\\Brave-Browser\\Application\\brave.exe"
    }
  }
}

Fix

Move it up to browser.executablePath:

browser: {
  executablePath: "C:\\Program Files\\BraveSoftware\\Brave-Browser\\Application\\brave.exe",

#

  profiles: {
    openclaw: {
      color: "#FF4500"
    }
  }
}

Or, if your openclaw profile only existed to hold executablePath, you can simplify even more:

browser: {
  executablePath: "C:\\Program Files\\BraveSoftware\\Brave-Browser\\Application\\brave.exe"
}

#

OpenClaw auto-creates the default openclaw profile if missing.

Then do this

Edit F:\openclaw-state\openclaw.json
Remove browser.profiles.openclaw.executablePath
Put that path under browser.executablePath
Save
Run:

openclaw doctor --fix
openclaw gateway restart

That should get it launching again.

#

Browser config reference:
https://docs.openclaw.ai/tools/browser

Glad we finally found the real blocker 😅

limber holly Apr 16, 2026, 11:34 AM

#

still not working:
| - Chrome MCP existing-session is configured for profile(s): linkedin. |
| - These profiles use an explicit Chromium user data directory instead of Chrome's |
| default auto-connect path. |
| - Verify the matching Chromium-based browser is version 144+ on the same host as the |
| Gateway or node. |
| - Enable remote debugging in that browser's inspect page |
| (chrome://inspect/#remote-debugging, brave://inspect/#remote-debugging, |
| edge://inspect/#remote-debugging). |
| - Keep the browser running and accept the attach consent prompt the first time OpenClaw |
| connects.
o Gateway ----------------------------------------------------------------------------------+
| |
| Runtime: stopped (state Ready, last run 1, last run time 4/16/2026 7:13:42 PM, Task Last |
| Run Result=1; treating as not running.) |
| Service is loaded but not running (likely exited immediately). |
| File logs: C:\Users\glysh\AppData\Local\Temp\openclaw\openclaw-2026-04-16.log |
| Logs: schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST
Restarted Scheduled Task: OpenClaw Gateway
Invalid config:

browser.profiles.openclaw: Profile userDataDir is only supported with driver="existing-session"

tawny rivetBOT Apr 16, 2026, 11:35 AM

#

You’re very close, it’s just tripping over the next invalid browser key now.

This new blocker is:

browser.profiles.openclaw: Profile userDataDir is only supported with driver="existing-session"

What that means

userDataDir is only valid on profiles like this:

driver: "existing-session"

So it belongs on something like your linkedin profile, not on a normal managed openclaw profile.

#

Fix

Remove this from browser.profiles.openclaw:

userDataDir: "..."

If openclaw is meant to be the normal managed browser, it should be more like:

openclaw: {
  color: "#FF4500"
}

or you can remove the openclaw profile block entirely and let OpenClaw create the default one automatically.

#

Valid shape, based on what you showed before

Something like this should be fine:

browser: {
  enabled: true,
  executablePath: "C:\\Program Files\\BraveSoftware\\Brave-Browser\\Application\\brave.exe",
  defaultProfile: "scraper",
  profiles: {
    scraper: {
      cdpUrl: "http://127.0.0.1:18810",
      attachOnly: true,
      color: "#FF4500"
    },
    linkedin: {

#

      driver: "existing-session",
      attachOnly: true,
      userDataDir: "C:\\Users\\glysh\\AppData\\Local\\BraveSoftware\\Brave-Browser\\User Data",
      color: "#FF4500"
    }
  }
}

Then run

openclaw doctor --fix
openclaw gateway restart

#

If it still complains after that, paste the entire browser section from F:\openclaw-state\openclaw.json and I’ll clean it up into a valid config for you in one go. That’ll be faster than whack-a-mole-ing one key at a time.

limber holly Apr 16, 2026, 12:14 PM

#

this is actually my current browser block, have a look and let me know what needs to be changed:

"browser": {
"executablePath": "C:\Program Files\BraveSoftware\Brave-Browser\Application\brave.exe",
"enabled": true,
"defaultProfile": "openclaw",
"profiles": {
"openclaw": {
"attachOnly": true,
"cdpPort": 18810,
"userDataDir": "C:\Users\glysh\AppData\Local\BraveSoftware\Brave-Browser\User Data",
"color": "#FF4500"
},
"linkedin": {
"driver": "existing-session",
"attachOnly": true,
"userDataDir": "C:\Users\glysh\AppData\Local\BraveSoftware\Brave-Browser\User Data",
"color": "#FF4500"
}
}
}

tawny rivetBOT Apr 16, 2026, 12:15 PM

#

Yep, I see the problem.

Right now your openclaw profile is mixing two different browser modes:

managed profile (openclaw, raw CDP / launched by OpenClaw)
existing-session profile (userDataDir, real Brave profile)

That combo is invalid.

What to change

In `openclaw`, remove:

userDataDir
attachOnly (unless you intentionally want a manual raw-CDP profile, but then it still should not use userDataDir)

Keep `linkedin` as the existing-session profile

That one is the correct place for:

#

driver: "existing-session"
attachOnly: true
userDataDir: ...

Clean corrected version

If you want:

openclaw = normal managed browser
linkedin = real Brave existing-session attach

use this:

#

"browser": {
  "executablePath": "C:\\Program Files\\BraveSoftware\\Brave-Browser\\Application\\brave.exe",
  "enabled": true,
  "defaultProfile": "openclaw",
  "profiles": {
    "openclaw": {
      "cdpPort": 18810,
      "color": "#FF4500"
    },
    "linkedin": {
      "driver": "existing-session",
      "attachOnly": true,
      "userDataDir": "C:\\Users\\glysh\\AppData\\Local\\BraveSoftware\\Brave-Browser\\User Data",
      "color": "#FF4500"
    }

#

}
}

If you still want a separate manual scraper profile

Then add a third profile, like this:

"scraper": {
  "cdpUrl": "http://127.0.0.1:18810",
  "attachOnly": true,
  "color": "#FF4500"

#

Important: a raw CDP scraper profile should use cdpUrl, not userDataDir.

So the mental model is:

openclaw → managed browser
linkedin → existing-session via Brave profile
scraper → raw CDP attach to an already-running browser

#CDP browser not working. again.