WSL2 CDP connection to Windows Brave — firewall blocking | Friends of the Crustacean 🦞🤝 | Page 1

fringe yarrow Apr 13, 2026, 7:48 AM

#

Hi, I'm trying to connect OpenClaw (running in WSL2) to Brave browser on Windows via CDP on port 9222. Brave is running with --remote-debugging-port=9222 and netstat on Windows confirms it's listening on 127.0.0.1:9222. But from inside WSL2, curl http://172.22.240.1:9222/json/version just hangs. Tried adding a firewall rule via PowerShell but getting "Access is denied" even running as administrator. What's the correct way to expose port 9222 from Windows to WSL2?

violet quiverBOT Apr 13, 2026, 7:48 AM

#

quartz spearBOT Apr 13, 2026, 7:48 AM

#

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

violet quiverBOT Apr 13, 2026, 7:48 AM

#

somber sluiceBOT Apr 13, 2026, 7:51 AM

#

Let me verify the current docs and the exact WSL/CDP bits before I tell them the wrong thing.

#

I found an OpenClaw doc page specifically for this exact WSL2 + Windows CDP setup, and I want to pull the concrete fix path from there instead of hand-waving.

#

Yep, the hang makes sense.

172.22.240.1 from WSL2 is not Windows loopback. It’s a host IP hop, so if Brave is only listening on 127.0.0.1:9222, WSL cannot reach it there.

Correct setup for WSL2 → Windows Brave CDP:

First try localhost from WSL
- If you use WSL mirrored networking, this may just work:
```
curl http://127.0.0.1:9222/json/version
```
If that works, use cdpUrl: "http://127.0.0.1:9222".
If you’re on default WSL NAT mode
- Get the Windows host IP from WSL:

#

   ip route show | awk '/default/ {print $3}'

Then make Brave reachable on that IP, either by:
- Preferred: start Brave with:
```
brave.exe --remote-debugging-address=0.0.0.0 --remote-debugging-port=9222
```
  then allow TCP 9222 in Windows Firewall, or
- Alternative: keep Brave on 127.0.0.1:9222 and add a portproxy on a different port, for example 9223 -> 127.0.0.1:9222.

Verify from WSL

curl http://<windows-host-ip>:9222/json/version

or :9223 if you used portproxy.

#

Point OpenClaw at that exact URL

{
  browser: {
    enabled: true,
    defaultProfile: "remote",
    profiles: {
      remote: {
        cdpUrl: "http://<windows-host-ip>:9222",
        attachOnly: true
      }
    }
  }
}

A couple gotchas:

#

For WSL2 Gateway + Windows browser, use raw remote CDP, not existing-session / user.
Open the Control UI on http://127.0.0.1:18789/, not a LAN IP.
If curl works but OpenClaw still rejects it, check browser SSRF/private-network config.

If New-NetFirewallRule says Access is denied even in an elevated shell, that’s usually a Windows policy/UAC issue, not OpenClaw itself.

Docs:

If you want, paste these and I’ll tell you exactly which layer is failing:

openclaw --version
openclaw status
ip route show | grep default
curl http://127.0.0.1:9222/json/version from WSL
curl http://<windows-host-ip>:9222/json/version from WSL

fringe yarrow Apr 13, 2026, 7:58 AM

#

Following your advice, tried both approaches. --remote-debugging-address=0.0.0.0 flag is being ignored by Brave — netstat still shows it binding to 127.0.0.1:9222 only. Then tried the portproxy approach but getting "The requested operation requires elevation" even in PowerShell running as Administrator. Is there a way to run this without needing elevated permissions, or another approach entirely?

somber sluiceBOT Apr 13, 2026, 7:59 AM

#

I’m checking if there’s a cleaner OpenClaw-native fallback here, because fighting Windows admin policy on portproxy is miserable.

#

Short answer, not reliably in default WSL2 NAT mode.

If Brave stays on 127.0.0.1:9222, then exposing that to WSL via a host IP needs one of these:

Brave binding off-loopback, or
Windows portproxy + firewall changes

Both are effectively admin-controlled. So if Brave ignores --remote-debugging-address and Windows blocks elevation, I would stop fighting raw CDP across the WSL boundary.

Best no-admin alternative

Use a Windows node host instead of exposing CDP.

That’s the OpenClaw-native path for “gateway here, browser there”:

Keep the Gateway in WSL.
Install/run the OpenClaw CLI on Windows.

#

On Windows, run:

openclaw node run --host 127.0.0.1 --port 18789

In WSL, approve the node:

openclaw devices list
openclaw devices approve <requestId>

Let browser actions route through that Windows node.

That avoids 9222, portproxy, and Windows firewall weirdness entirely.

If you need your real Brave session

On the Windows node, use an existing-session browser profile for Brave, instead of remote CDP. That is host-local, so it doesn’t need WSL-to-Windows CDP exposure.

#

One other admin-free thing to try

If your Windows/WSL build supports mirrored networking, WSL can often reach Windows services on 127.0.0.1 directly. Then from WSL:

curl http://127.0.0.1:9222/json/version

If that works, you can use localhost and skip portproxy. If it doesn’t, I’d go straight to the node-host route.

Docs:

If you want, I can give you the exact Windows node host + Brave existing-session config next.

fringe yarrow Apr 13, 2026, 8:06 AM

#

Running the Windows CLI installer, got to setup mode. Options are: "Local gateway (this machine) - No gateway detected" or "Remote gateway (info-only)". Which do I pick for the node host setup?

somber sluiceBOT Apr 13, 2026, 8:07 AM

#

I’m checking the native Windows docs so I don’t send them down the wrong installer path and accidentally have them install a second gateway.

#

Pick Remote gateway (info-only).

Why:

you do not want to install a second Windows gateway
your real gateway is the one already running in WSL
the Windows side is just going to be a node/browser host

So for the Windows setup:

Choose Remote gateway (info-only)
Point it at the WSL gateway, usually:
- ws://127.0.0.1:18789
Use the same gateway token/password your WSL gateway uses
Then run the node host on Windows:

#

   openclaw node run --host 127.0.0.1 --port 18789

In WSL, approve the node:

openclaw devices list
openclaw devices approve <requestId>

That “No gateway detected” message under Local gateway is expected, it’s looking for a Windows-native gateway, not the one inside WSL.

One small gotcha from the docs, if onboarding complains about plaintext private-network ws://, you may need to run onboarding with:

$env:OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1
openclaw onboard

#

Docs:

If you want, next I can give you the exact Windows Brave existing-session profile to add after the node pairs.

fringe yarrow Apr 13, 2026, 8:24 AM

#

The Windows node is paired and showing browser.proxy in caps. But when I create an existing-session profile for Brave, the gateway tries to find the Windows path inside WSL2 instead of routing through the node. How do I tell the gateway to route browser actions through the Windows node? Do I need gateway.nodes.browser.mode set?

somber sluiceBOT Apr 13, 2026, 8:25 AM

#

I’m pulling the exact routing knob from the docs/source, because this is the kind of config key that’s easy to misremember and I don’t want to invent one.

#

Yep, that’s the missing piece.

Do not put the Brave existing-session profile in the WSL gateway config.
If you do, the gateway will try to resolve that Windows path inside WSL, which is exactly what you’re seeing.

For node-browser routing:

1) Put the Brave profile on the Windows node

In the Windows node’s openclaw.json, define the profile there, for example:

{
  browser: {
    enabled: true,
    profiles: {
      brave: {

#

        driver: "existing-session",
        attachOnly: true,
        userDataDir: "C:\\Users\\<you>\\AppData\\Local\\BraveSoftware\\Brave-Browser\\User Data"
      }
    }
  }
}

The docs are explicit here: profiles come from the node’s own browser.profiles config.

2) On the WSL gateway, enable node browser routing

Yes, this is where gateway.nodes.browser.mode matters.

If you have one browser-capable node, use:

#

{
  gateway: {
    nodes: {
      browser: {
        mode: "auto"
      }
    }
  }
}

If you want to pin it to your Windows node:

#

  gateway: {
    nodes: {
      browser: {
        mode: "auto",
        node: "<your-windows-node-name-or-id>"
      }
    }
  }
}

From the schema:

auto = pick a single connected browser node
manual = require explicit node targeting
off = disable node browser routing

#

3) Then use the node’s profile name

From the gateway side, use profile="brave".

The gateway should route the browser action to the Windows node, and the Windows node will resolve the Brave path locally.

Important gotcha

Don’t try to create persistent browser profiles through the proxy from WSL. Define them on the Windows node directly.

Also, if you set nodeHost.browserProxy.allowProfiles on the Windows node, make sure "brave" is included, or just leave that list empty for now.

Docs:

If you want, paste your Windows node browser config and WSL gateway node-browser config, and I’ll sanity-check them.

fringe yarrow Apr 13, 2026, 9:00 AM

#

Using existing-session driver for Brave on the Windows node. Getting: Could not connect to Chrome - ENOENT: DevToolsActivePort not found. Brave is open normally but doesn't have --remote-debugging-port flag. We can't launch Brave with that flag reliably, and we can't do portproxy without admin rights. How is existing-session supposed to attach to Brave without CDP/remote debugging enabled?

somber sluiceBOT Apr 13, 2026, 9:00 AM

#

It isn’t supposed to attach without browser-side remote debugging enabled.

existing-session is host-local, but it still uses Chrome DevTools MCP, which needs Brave/Chrome’s debugging attach path turned on. It does not magically attach to a normal browser with zero debugging enabled.

From the docs, for Brave:

Open:
brave://inspect/#remote-debugging
Enable remote debugging there
Keep Brave running
Approve the attach prompt when OpenClaw connects

So the key distinction is:

raw remote CDP = you point OpenClaw at a CDP URL/port
existing-session = OpenClaw/node host does the local attach flow for you, but the browser still must allow debugging attach

#

That DevToolsActivePort not found error usually means one of:

remote debugging is not enabled in Brave
wrong userDataDir
Brave version is too old for this path
attach consent prompt never appeared / wasn’t accepted

Also make sure userDataDir is the User Data root, not the Default profile folder, for example:

userDataDir: "C:\\Users\\<you>\\AppData\\Local\\BraveSoftware\\Brave-Browser\\User Data"

If you cannot enable debugging in Brave at all

Then existing-session is basically blocked.

Your fallback is:

#

use the managed openclaw browser on the Windows node, or
use a separate remote CDP/browser service

So yes, the tough truth here is: existing-session still needs debugging enabled, just locally on the Windows node instead of through the WSL network boundary.

Docs:

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

If you want, I can give you:

the exact Brave existing-session checklist, or
the simpler managed browser on the Windows node setup, which avoids this whole Brave attach mess.

fringe yarrow Apr 13, 2026, 9:05 AM

#

that worked thank you, wil makr as resoluved now

somber sluiceBOT Apr 13, 2026, 9:05 AM

#

Nice, glad we got it working 🎉

And thank you. If Discord is being weird, it’s right-click the solution message → Apps → ✅ Mark Solution.

That helps Answer Overflow index it for the next person.

#WSL2 CDP connection to Windows Brave — firewall blocking

Best no-admin alternative

If you need your real Brave session

One other admin-free thing to try

1) Put the Brave profile on the Windows node

2) On the WSL gateway, enable node browser routing

3) Then use the node’s profile name

Important gotcha

If you cannot enable debugging in Brave at all