Discovery & transports
OpenClaw has two distinct problems that look similar on the surface:- Operator remote control: the macOS menu bar app controlling a gateway running elsewhere.
- Node pairing: iOS/Android (and future nodes) finding a gateway and pairing securely.
openclaw gateway) and keep clients (mac app, iOS) as consumers.
Terms
- Gateway: a single long-running gateway process that owns state (sessions, pairing, node registry) and runs channels. Most setups use one per host; isolated multi-gateway setups are possible.
- Gateway WS (control plane): the WebSocket endpoint on
127.0.0.1:18789by default; can be bound to LAN/tailnet viagateway.bind. - Direct WS transport: a LAN/tailnet-facing Gateway WS endpoint (no SSH).
- SSH transport (fallback): remote control by forwarding
127.0.0.1:18789over SSH. - Legacy TCP bridge (removed): older node transport (see Bridge protocol); no longer advertised for discovery and no longer part of current builds.
Why we keep both “direct” and SSH
- Direct WS is the best UX on the same network and within a tailnet:
- auto-discovery on LAN via Bonjour
- pairing tokens + ACLs owned by the gateway
- no shell access required; protocol surface can stay tight and auditable
- SSH remains the universal fallback:
- works anywhere you have SSH access (even across unrelated networks)
- survives multicast/mDNS issues
- requires no new inbound ports besides SSH
Discovery inputs (how clients learn where the gateway is)
1) Bonjour / DNS-SD discovery
Multicast Bonjour is best-effort and does not cross networks. OpenClaw can also browse the same gateway beacon via a configured wide-area DNS-SD domain, so discovery can cover:local.on the same LAN- a configured unicast DNS-SD domain for cross-network discovery
- The gateway advertises its WS endpoint via Bonjour.
- Clients browse and show a “pick a gateway” list, then store the chosen endpoint.
Service beacon details
- Service types:
_openclaw-gw._tcp(gateway transport beacon)
- TXT keys (non-secret):
role=gatewaytransport=gatewaydisplayName=<friendly name>(operator-configured display name)lanHost=<hostname>.localgatewayPort=18789(Gateway WS + HTTP)gatewayTls=1(only when TLS is enabled)gatewayTlsSha256=<sha256>(only when TLS is enabled and fingerprint is available)canvasPort=<port>(canvas host port; currently the same asgatewayPortwhen the canvas host is enabled)tailnetDns=<magicdns>(optional hint; auto-detected when Tailscale is available)sshPort=<port>(mDNS full mode only; wide-area DNS-SD may omit it, in which case SSH defaults stay at22)cliPath=<path>(mDNS full mode only; wide-area DNS-SD still writes it as a remote-install hint)
- Bonjour/mDNS TXT records are unauthenticated. Clients must treat TXT values as UX hints only.
- Routing (host/port) should prefer the resolved service endpoint (SRV + A/AAAA) over TXT-provided
lanHost,tailnetDns, orgatewayPort. - TLS pinning must never allow an advertised
gatewayTlsSha256to override a previously stored pin. - iOS/Android nodes should require an explicit “trust this fingerprint” confirmation before storing a first-time pin (out-of-band verification) whenever the chosen route is secure/TLS-based.
OPENCLAW_DISABLE_BONJOUR=1disables advertising.gateway.bindin~/.openclaw/openclaw.jsoncontrols the Gateway bind mode.OPENCLAW_SSH_PORToverrides the SSH port advertised whensshPortis emitted.OPENCLAW_TAILNET_DNSpublishes atailnetDnshint (MagicDNS).OPENCLAW_CLI_PATHoverrides the advertised CLI path.
2) Tailnet (cross-network)
For London/Vienna style setups, Bonjour won’t help. The recommended “direct” target is:- Tailscale MagicDNS name (preferred) or a stable tailnet IP.
tailnetDns as an optional hint for clients (including wide-area beacons).
The macOS app now prefers MagicDNS names over raw Tailscale IPs for gateway discovery. This improves reliability when tailnet IPs change (for example after node restarts or CGNAT reassignment), because MagicDNS names resolve to the current IP automatically.
For mobile node pairing, discovery hints do not relax transport security on tailnet/public routes:
- iOS/Android still require a secure first-time tailnet/public connect path (
wss://or Tailscale Serve/Funnel). - A discovered raw tailnet IP is a routing hint, not permission to use plaintext remote
ws://. - Private LAN direct-connect
ws://remains supported. - If you want the simplest Tailscale path for mobile nodes, use Tailscale Serve so discovery and the setup code both resolve to the same secure MagicDNS endpoint.
3) Manual / SSH target
When there is no direct route (or direct is disabled), clients can always connect via SSH by forwarding the loopback gateway port. See Remote access.Transport selection (client policy)
Recommended client behavior:- If a paired direct endpoint is configured and reachable, use it.
- Else, if discovery finds a gateway on
local.or the configured wide-area domain, offer a one-tap “Use this gateway” choice and save it as the direct endpoint. - Else, if a tailnet DNS/IP is configured, try direct.
For mobile nodes on tailnet/public routes, direct means a secure endpoint, not plaintext remote
ws://. - Else, fall back to SSH.
Pairing + auth (direct transport)
The gateway is the source of truth for node/client admission.- Pairing requests are created/approved/rejected in the gateway (see Gateway pairing).
- The gateway enforces:
- auth (token / keypair)
- scopes/ACLs (the gateway is not a raw proxy to every method)
- rate limits
Responsibilities by component
- Gateway: advertises discovery beacons, owns pairing decisions, and hosts the WS endpoint.
- macOS app: helps you pick a gateway, shows pairing prompts, and uses SSH only as a fallback.
- iOS/Android nodes: browse Bonjour as a convenience and connect to the paired Gateway WS.