fix: route remote mac browser through node host

This commit is contained in:
Peter Steinberger
2026-04-26 05:25:13 +01:00
parent b8aef04ccd
commit ae45eebef1
10 changed files with 175 additions and 10 deletions

View File

@@ -104,6 +104,7 @@ Manage the service:
```bash
openclaw node status
openclaw node start
openclaw node stop
openclaw node restart
openclaw node uninstall

View File

@@ -12,7 +12,11 @@ A **node** is a companion device (macOS/iOS/Android/headless) that connects to t
Legacy transport: [Bridge protocol](/gateway/bridge-protocol) (TCP JSONL;
historical only for current nodes).
macOS can also run in **node mode**: the menubar app connects to the Gateways WS server and exposes its local canvas/camera commands as a node (so `openclaw nodes …` works against this Mac).
macOS can also run in **node mode**: the menubar app connects to the Gateways
WS server and exposes its local canvas/camera commands as a node (so
`openclaw nodes …` works against this Mac). In remote gateway mode, browser
automation is handled by the CLI node host (`openclaw node run` or the
installed node service), not by the native app node.
Notes:
@@ -112,6 +116,7 @@ Notes:
```bash
openclaw node install --host <gateway-host> --port 18789 --display-name "Build Node"
openclaw node start
openclaw node restart
```

View File

@@ -25,7 +25,14 @@ Remote mode supports two transports:
In SSH tunnel mode, discovered LAN/tailnet hostnames are saved as
`gateway.remote.sshTarget`. The app keeps `gateway.remote.url` on the local
tunnel endpoint, for example `ws://127.0.0.1:18789`, so CLI, Web Chat, and
browser automation all use the same safe loopback transport.
the local node-host service all use the same safe loopback transport.
Browser automation in remote mode is owned by the CLI node host, not by the
native macOS app node. The app starts the installed node host service when
possible; if you need browser control from that Mac, install/start it with
`openclaw node install ...` and `openclaw node start` (or run
`openclaw node run ...` in the foreground), then target that browser-capable
node.
## Prereqs on the remote host