Im running an openclaw agent using gpt 5.4 mini thru a custom provider on a raspberry. It works, unstable, but works. Now, as my raspberry is headless, i want to connect openclaw to my windows machine, for it to be able to open a chromium session in there and control it, while i talk to the agent in cli on the raspberry. So, is that possible?
#How to connect openclaw agent to a browser on a remote host
1 messages · Page 1 of 1 (latest)
Yes — that setup is possible, and the cleanest path is: Raspberry Pi runs the Gateway/agent, Windows runs an OpenClaw node host with browser proxy.
Shape:
- Pi: Gateway + CLI chat + model calls
- Windows: Chrome/Brave/Edge/Chromium +
openclaw node run/install - Gateway proxies browser tool calls to the Windows node, so the browser opens visibly on Windows while you talk to the agent on the Pi.
High-level setup:
-
Make the Pi Gateway reachable from Windows — ideally over Tailscale/tailnet, or an SSH tunnel. Keep it private; don’t expose the Gateway publicly.
-
On Windows, install OpenClaw CLI, then run the node host:
$env:OPENCLAW_GATEWAY_TOKEN="<gateway-token>"
openclaw node run --host <raspberry-host-or-tailnet-ip> --port 18789 --display-name "Windows Browser"
For background/service mode:
$env:OPENCLAW_GATEWAY_TOKEN="<gateway-token>"
openclaw node install --host <raspberry-host-or-tailnet-ip> --port 18789 --display-name "Windows Browser"
openclaw node restart
- On the Pi, approve the node:
openclaw devices list
openclaw devices approve <requestId>
openclaw nodes status
- Test browser routing from the Pi:
openclaw browser open https://example.com
openclaw browser tabs
If you have multiple nodes, pin the browser node with gateway.nodes.browser.node.
There’s also a second option: run Chrome on Windows with remote debugging (--remote-debugging-port=9222) and configure a remote CDP browser profile on the Pi. That works too, but I’d try the node-host browser proxy first — less brittle, more OpenClaw-native.
Docs:
https://docs.openclaw.ai/nodes
https://docs.openclaw.ai/cli/node
https://docs.openclaw.ai/tools/browser
https://docs.openclaw.ai/gateway/remote
If it gets weird, first thing to paste is openclaw --version plus whether the Pi and Windows are on LAN, Tailscale, or SSH tunnel.
raspberry and windows are on some host. so, lets go step by step. what do i do? i have openclaw installed on my windows, whats the next step?
Good — next step is to make the Windows machine connect to the Raspberry Pi Gateway as a node.
First, quick sanity check on both machines:
openclaw --version
If the versions are very different, update first; mismatches can cause weird pairing/tool issues.
Then on the Raspberry Pi, check the Gateway is running and get/confirm auth:
openclaw status
openclaw gateway status
You need the Pi Gateway host/IP and token. If you don’t already have a token, generate one on the Pi:
openclaw doctor --generate-gateway-token
Then check your config/token source. Usually:
openclaw config get gateway.auth.token
Now on Windows PowerShell, set the token for this shell and start the node host:
$env:OPENCLAW_GATEWAY_TOKEN="PASTE_TOKEN_HERE"
openclaw node run --host RASPBERRY_PI_IP_OR_HOSTNAME --port 18789 --display-name "Windows Browser"
Leave that PowerShell window open. It should try to connect and create a pairing request.
Then go back to the Pi and approve it:
openclaw devices list
openclaw devices approve <requestId>
openclaw nodes status
Start there. Paste the output from the Windows openclaw node run ... if it errors, and paste openclaw --version from both machines too.
im a bit confused. my raspberry is running on 192.168.1.104, my windows is on 192.168.1.120. i generated gateway token, whats next?
Got it — same LAN, so use the Pi’s LAN IP directly. The missing piece is usually that the Gateway only listens on 127.0.0.1 by default, so Windows can’t reach it until you bind it to LAN.
Do this on the Raspberry Pi first:
openclaw --version
openclaw config set gateway.bind lan
openclaw gateway restart
openclaw gateway status
Then from Windows PowerShell, test that the Pi port is reachable:
Test-NetConnection 192.168.1.104 -Port 18789
You want TcpTestSucceeded : True.
Then still on Windows PowerShell, start the Windows node:
$env:OPENCLAW_GATEWAY_TOKEN="PASTE_YOUR_GATEWAY_TOKEN_HERE"
openclaw node run --host 192.168.1.104 --port 18789 --display-name "Windows Browser"
Leave that PowerShell window open.
Now back on the Raspberry Pi, approve the Windows node:
openclaw devices list
openclaw devices approve <requestId>
openclaw nodes status
After that, test browser control from the Pi:
openclaw browser open https://example.com
openclaw browser tabs
If Test-NetConnection fails, Windows can’t reach the Pi Gateway yet — likely Pi firewall, wrong bind, gateway not restarted, or port mismatch. If node run says pairing required / pending, that’s good: approve it on the Pi.
do i need to install any skill or mcp or something or tool to use browser? im no expert and i dont know whtas the diff between tools and skills etc and if i need any prerequisitse for openclaw to be able to use the browser
No extra skill needed. Browser control is a built-in tool/plugin in OpenClaw.
Quick mental model:
- Tool = something the agent can actually do, like
browser,exec,message,web_search. - Skill = instructions/recipe for how to use tools well. It doesn’t add browser capability by itself.
- MCP = another way to connect external tools/services. You don’t need MCP for this setup.
For your case, prerequisites are just:
- OpenClaw installed on Windows âś… you already have this
- A Chromium browser on Windows: Chrome, Edge, Brave, or Chromium
- Browser plugin enabled — usually already enabled by default
- Windows node host connected to the Pi Gateway using
openclaw node run ... - Your model must reliably call tools — this is the one warning: custom-provider GPT mini may work, but browser automation can be flaky if the model is weak at tool calling.
You can check browser support on Windows with:
openclaw browser status
openclaw browser profiles
If that says browser is disabled or missing, then check your config. Common fix is:
openclaw config set browser.enabled true
And if you use a plugins.allow list in config, it must include browser. If you never touched plugins.allow, don’t worry about it.
So the next practical thing is still this on Windows:
$env:OPENCLAW_GATEWAY_TOKEN="PASTE_TOKEN_HERE"
openclaw node run --host 192.168.1.104 --port 18789 --display-name "Windows Browser"
Then approve it on the Pi. Once paired, the Pi agent should be able to route browser actions to Windows.
Docs if you want the deeper version:
https://docs.openclaw.ai/tools/browser
https://docs.openclaw.ai/cli/node
PS C:\WINDOWS\system32> openclaw node run --host 192.168.1.104 --port 18789 --display-name "Windows Browser"
🦞 OpenClaw 2026.5.7 (eeef486) — I autocomplete your thoughts—just slower and with more API calls.
node host gateway connect failed: SECURITY ERROR: Cannot connect to "192.168.1.104" over plaintext ws://. Both credentials and chat data would be exposed to network interception. Use wss:// for remote URLs. Safe defaults: keep gateway.bind=loopback and connect via SSH tunnel (ssh -N -L 18789:127.0.0.1:18789 user@gateway-host), or use Tailscale Serve/Funnel. Break-glass (trusted private networks only): set OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1. Run openclaw doctor --fix for guidance.
Warning: Detected unsettled top-level await at file:///C:/Users/petra/AppData/Roaming/npm/node_modules/openclaw/openclaw.mjs:393
if (await tryImport("./dist/entry.js")) {
Yep, that error is OpenClaw protecting you: it refuses plain ws://192.168... because that sends token/chat data over the LAN unencrypted.
Use an SSH tunnel. This is the safest/simple path.
On the Pi, you can put the Gateway back to loopback-only:
openclaw config set gateway.bind loopback
openclaw gateway restart
On Windows, open PowerShell window #1 and create a tunnel to the Pi. Replace pi with your Raspberry Pi username if different:
ssh -N -L 18790:127.0.0.1:18789 pi@192.168.1.104
Leave that window open. If it asks for the Pi password, enter it. No output is normal.
Then open PowerShell window #2 and run the node through the tunnel:
$env:OPENCLAW_GATEWAY_TOKEN="PASTE_YOUR_GATEWAY_TOKEN_HERE"
openclaw node run --host 127.0.0.1 --port 18790 --display-name "Windows Browser"
Then on the Pi, approve it:
openclaw devices list
openclaw devices approve <requestId>
openclaw nodes status
Why port 18790? It avoids colliding with any local OpenClaw stuff on Windows. The tunnel forwards Windows 127.0.0.1:18790 → Pi 127.0.0.1:18789.
There is a break-glass env var for trusted LANs, but I’d avoid it unless you really know you want plaintext LAN traffic. SSH tunnel is cleaner. The “unsettled top-level await” warning is just fallout after the failed connection; ignore it for now.
from where do i get the request id tho?
You get it on the Raspberry Pi, after the Windows node tries to connect.
Flow:
- Keep the Windows node command running:
$env:OPENCLAW_GATEWAY_TOKEN="PASTE_TOKEN_HERE"
openclaw node run --host 127.0.0.1 --port 18790 --display-name "Windows Browser"
- On the Pi, run:
openclaw devices list
That should show a pending device request, something like:
requestId: abc123...
role: node
name: Windows Browser
- Copy that request id and approve it:
openclaw devices approve abc123...
Then check:
openclaw nodes status
If openclaw devices list shows nothing, the Windows node has not reached the Pi yet — usually the SSH tunnel isn’t running, wrong port, token missing/wrong, or the Pi gateway isn’t running on 127.0.0.1:18789.
windows browser paired automatically. i think i didnt need to approve it. node status gives paired and connecte with caps browser file system
Nice — that means the hard part is done 🎉
Now test browser routing from the Pi:
openclaw browser profiles
openclaw browser open https://example.com
openclaw browser tabs
openclaw browser screenshot
You should see Chromium/Chrome/Edge open on the Windows machine.
If you have more than one node later, pin this one as the browser node on the Pi:
openclaw config set gateway.nodes.browser.node "Windows Browser"
openclaw gateway restart
Then in your agent chat, ask something simple like:
open example.com in the browser and tell me the page title
If that works, you’re fully connected: Pi agent → Windows node → Windows browser.
browser works nice! ok. now do i just tell my agent to use the browser or what?
Yep — now you just ask normally, as long as that agent/session has the browser tool available.
Try simple prompts first:
Open
https://example.comin the browser and tell me the title.
or:
Use the browser to search for OpenClaw docs and summarize the browser setup page.
If the agent is tool-aware, it should decide to call browser on its own. You don’t usually need magic wording, but saying “use the browser” helps.
A few useful checks on the Pi:
openclaw browser open https://example.com
openclaw browser snapshot
If those work, the browser plumbing is good.
If your agent says it “can’t use browser” or never calls it, check tool policy/config. Common things:
browser.enabledshould be true- if you use
plugins.allow, it must includebrowser - if you use a tools allowlist, it must include
browseror a group that contains it - your custom GPT mini provider has to support tool calling well enough
For browser-heavy tasks, be explicit:
Use the browser tool. Open the site, inspect the page, click through if needed, and report what you find.
And keep the Windows node + SSH tunnel running while you want browser access.
agent says it has no browser tool. how do i grant it access to it
That usually means the browser plugin works at CLI level, but the agent tool allowlist doesn’t include browser.
On the Pi, run:
openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.deny
openclaw config get plugins.allow
Most likely your tools.profile is coding. That profile includes web/search/file/exec stuff, but not browser. Add browser explicitly:
openclaw config set tools.allow '["group:fs","group:runtime","group:web","group:sessions","group:memory","browser","image","image_generate"]' --strict-json
openclaw gateway restart
If you want the broader UI group instead of only browser:
openclaw config set tools.allow '["group:fs","group:runtime","group:web","group:sessions","group:memory","group:ui","image","image_generate"]' --strict-json
openclaw gateway restart
Also check these two gotchas:
-
If
tools.denycontainsbrowserorgroup:ui, remove that deny, because deny wins. -
If
plugins.allowis set, it must includebrowser, otherwise the browser plugin won’t be available to agents:
openclaw config set plugins.allow '["browser"]' --strict-json --merge
openclaw gateway restart
But only do that if plugins.allow exists already — don’t narrow it accidentally.
After restart, start a new agent session if the old one still says it has no browser. Tool lists are often captured at session start.
its coding for profile and not found for each other key youve given me. what do i do?
That’s actually good/normal. not found just means those optional config keys aren’t set.
Since your profile is coding, add browser as an extra allowed tool on top of coding.
Run this on the Raspberry Pi:
openclaw config set tools.alsoAllow '["browser"]' --strict-json
openclaw gateway restart
Then verify:
openclaw config get tools.profile
openclaw config get tools.alsoAllow
You want:
tools.profile = coding
tools.alsoAllow = ["browser"]
Then start a new agent session / restart your CLI chat. Existing sessions may have captured the old tool list.
After that, ask:
Use the browser tool to open example.com and tell me the title.
Because openclaw browser ... already works, you don’t need to mess with plugins.allow right now. The browser plugin is loaded; your agent just wasn’t being shown the tool.
what about the allow command youve given previously? i only did config get, now i want to add the browser capabilities. i also need it to be able to hold memory, and be smart overall and be useful in the browser. no stupidness
Good catch. Don’t use the big tools.allow ... command I gave earlier unless you want to replace the whole allowlist manually. Since you already have tools.profile = coding, the cleaner move is add browser on top.
Run this on the Pi:
openclaw config set tools.alsoAllow '["browser"]' --strict-json
openclaw gateway restart
That keeps the coding profile, which already gives you useful core stuff like:
- filesystem tools
- exec/process tools
- web search/fetch
- session tools
- memory tools
…and then adds browser.
If you want browser + canvas UI tools, use this instead:
openclaw config set tools.alsoAllow '["group:ui"]' --strict-json
openclaw gateway restart
For “hold memory”: with coding, memory tools should already be included via group:memory. But memory also depends on the agent actually using it and your workspace memory files/config being present. The tool access side is already covered.
After restart, start a fresh CLI agent session. Old sessions may still have the old tool list.
Then test with:
Use the browser tool to open https://example.com, inspect the page, and tell me the title. Remember that my browser is on the Windows node.
For “no stupidness”: the honest answer is tool access helps, but model quality still matters. A small/custom GPT mini can browse, but it may be less reliable at multi-step browser tasks. Give it explicit instructions like “use browser, take a snapshot after navigation, don’t guess, report if blocked” and it’ll behave better.
whats canvas ui? i think it will also need screenshots or smth to understand what happens in the browser, is that included?
Canvas UI is separate from browser control. You probably don’t need it for this.
For browser understanding, the browser tool already includes the important stuff:
snapshot— structured page view: buttons, links, text fields, headings, refs to click/typescreenshot— visual image capture of the pageclick,type,navigate,open,tabs, etc.
So if you add only:
openclaw config set tools.alsoAllow '["browser"]' --strict-json
openclaw gateway restart
that should be enough for normal browser automation.
canvas is more like an OpenClaw-controlled webview/surface for node apps and visual UI presentation. Useful in some node/device workflows, but not required for “open Chromium on Windows and control it.”
If you want to be generous, group:ui gives both browser and canvas:
openclaw config set tools.alsoAllow '["group:ui"]' --strict-json
openclaw gateway restart
But my recommendation: start with just browser. Smaller permission surface, less confusion.
After restart, new CLI session, ask:
Use the browser tool. Open example.com, take a snapshot or screenshot if needed, and tell me what you see.
The agent should be able to inspect the page without you adding canvas.
ok my agent says that he sees no node Windows Browser but its there. maybe it has no permissions?
Maybe, but for browser use the agent does not need to “see” the node directly. It only needs the browser tool; the Gateway routes browser calls to the Windows node.
Do this on the Pi to pin browser routing to that node:
openclaw config set gateway.nodes.browser.mode auto
openclaw config set gateway.nodes.browser.node "Windows Browser"
openclaw gateway restart
Then verify from the Pi, outside the agent:
openclaw nodes status
openclaw browser open https://example.com
openclaw browser tabs
If those work, start a fresh CLI agent session and tell it:
Use the browser tool to open example.com and tell me the page title.
Important: if the agent says “I don’t see node Windows Browser”, it may be trying to use/list node tools, not browser tools. With only:
openclaw config set tools.alsoAllow '["browser"]' --strict-json
it can use browser, but it may not have permission to inspect nodes.
If you also want it to be able to list/invoke nodes, add nodes too:
openclaw config set tools.alsoAllow '["browser","group:nodes"]' --strict-json
openclaw gateway restart
But my recommendation: first pin gateway.nodes.browser.node, then use only the browser tool. Cleaner and safer. Docs: https://docs.openclaw.ai/tools/browser
before creating a fresh session how do i tell my agent to remember the instructions i gave? i told him to write it and he said he wrote it out to memory/2026-05-14.md, is that the intended behaviour?
Yes — writing to memory/2026-05-14.md is intended behavior, but with one important nuance:
memory/YYYY-MM-DD.md= daily/short-term notes. Good for “what we did today”, setup details, temporary context.MEMORY.md= curated long-term memory. Better for stable preferences/instructions you want loaded reliably.AGENTS.md= standing instructions / operating rules. Best place for “always behave this way” instructions.
Daily memory files are usually recalled through memory search, not always injected into every fresh session. So before starting a new session, I’d ask your agent to write a short durable note into MEMORY.md or AGENTS.md, not only the daily file.
Something like:
Please save this durable setup note to MEMORY.md: My OpenClaw Gateway runs on Raspberry Pi 192.168.1.104. My Windows browser node is named "Windows Browser" and is reached through browser tool routing. When I ask for browsing, use the browser tool directly; do not look for the node unless needed.
And for behavior/instructions:
Please add to AGENTS.md: For browser tasks, use the browser tool, inspect with snapshot/screenshot, don’t guess, and report blockers clearly.
Then start a fresh session and say:
Check memory for my browser/node setup, then use the browser tool to open example.com.
Docs: https://docs.openclaw.ai/concepts/memory and https://docs.openclaw.ai/concepts/system-prompt
i asked it for available nodes and it says it has no nodes in this mode
That’s expected if you only granted browser.
There are two different permissions:
browsertool = can open/control the Windows browser. This is what you need.nodestool /group:nodes= can list or inspect OpenClaw nodes. You did not grant that yet.
So if you ask “what nodes are available?”, the agent may say it has no node access. But it can still use the browser if the Gateway is routing browser calls to Windows Browser.
If you want it to also inspect nodes, run this on the Pi:
openclaw config set tools.alsoAllow '["browser","group:nodes"]' --strict-json
openclaw gateway restart
Then start a fresh CLI session.
But for browser tasks, you don’t need node access. Better prompt:
Use the browser tool to open example.com and tell me the title. Do not try to list nodes; browser routing is already configured by the Gateway.
Also make sure you pinned routing on the Pi:
openclaw config set gateway.nodes.browser.mode auto
openclaw config set gateway.nodes.browser.node "Windows Browser"
openclaw gateway restart
If openclaw browser open https://example.com works from the Pi, then the browser path is good even if the agent can’t list nodes.
well when i ask it for browser it says the raspberry has no browser installed. even tho i did whatever you told me to configure. browser open works fine from pi. gonna allow nodes, ask it for nodes, try and ask it to use the browser tool again.
That “Raspberry has no browser installed” answer is the model using the wrong mental path — probably trying to reason from the Pi filesystem instead of calling the browser tool.
If openclaw browser open ... works from the Pi, the browser system is fine.
Do this checklist:
- On the Pi, allow browser + optionally nodes:
openclaw config set tools.alsoAllow '["browser","group:nodes"]' --strict-json
openclaw config set gateway.nodes.browser.mode auto
openclaw config set gateway.nodes.browser.node "Windows Browser"
openclaw gateway restart
- Start a fresh session. In chat/CLI, run:
/tools verbose
Look for browser in the tool list. If browser is not listed, the agent still doesn’t have tool access and we need to inspect per-agent config.
- Prompt it very explicitly:
Use the browser tool, not exec and not local Chrome. Browser routing is configured by the Gateway to the Windows node. Open https://example.com, take a snapshot, and tell me the title. Do not say the Raspberry has no browser installed; call the browser tool.
If /tools verbose shows no browser, check if this custom agent has its own override:
openclaw config get agents.list
If the agent entry has tools.allow set, that can override/restrict things. In that case you’d add browser at the agent level with agents.list[].tools.alsoAllow or remove the restrictive agent-specific allowlist.
Allowing nodes is okay for debugging, but it shouldn’t be required for browsing. The key proof is: /tools verbose must show browser.
"I can’t list nodes from here because this runtime is in local embedded mode and the node/session management tools aren’t available in this session."
Aha — that message says you’re probably using the local embedded CLI (openclaw chat / openclaw tui --local), not a Gateway-backed session.
Local embedded mode is running directly in the CLI process, so Gateway-only stuff like node/session management may not be available. Your Windows browser proxy lives behind the Gateway, so use the Gateway-backed TUI instead.
On the Pi, start the chat like this:
openclaw tui
not:
openclaw chat
If you need to be explicit:
openclaw tui --url ws://127.0.0.1:18789 --token YOUR_GATEWAY_TOKEN