Skip to content
Guides

OpenClaw nodes and Remote Hands

Pairing your own computer, what it may do, and the two approvals

6 min read

A node is a companion device, a Mac, an iPhone, an Android phone, a Windows or Linux machine, that connects to the Gateway and exposes commands: camera, screen, notifications, location and, on desktops, computer control. Nodes are peripherals, not gateways. Messages still land on the Gateway; a node is where the Gateway can act in the physical world you own. That is the mechanism behind what Diali calls Remote Hands, and this is how the upstream docs say it works.

Two approvals, not one

  • Device pairing: the node presents a signed identity and the Gateway creates a pairing request. Approving it admits the connection and nothing else.
  • Command surface: on reconnect the node declares the commands it offers, and that is a second request, with a different ID, that you approve separately. An unapproved surface has no effective commands.
  • Expansion: when a node adds commands, capabilities or permissions, the widened surface needs approval again; removing declarations never grants anything.

Pending pairing requests expire five minutes after the device’s last retry; pending surface requests do not expire with time. Trusted-network auto-approval covers the device only, by design, because pairing alone must never grant commands.

What a node may do

Three checks gate every command: the node must declare it, it must be in the approved surface, and the Gateway’s platform allowlist must include it. Each platform has a default allowlist: cameras, location, device info and notifications on phones; computer control on Windows, Linux and macOS. Dangerous or privacy-heavy commands, a camera photo or clip, desktop actions with consequences, need a one-time persistent opt-in even when the node declares them, and local exec approvals and the operating system’s own permissions still apply afterwards.

Nodes are peripherals, not gateways: they don’t run the gateway service, and channel messages (Telegram, WhatsApp, etc.) land on the gateway, not on nodes.

Computer use, specifically

  • The node must advertise both computer control and screen snapshots; on macOS that means Allow Computer Control plus Accessibility and Screen Recording, on Windows and Linux the bundled computer-use plugin.
  • The agent needs a vision-capable model and a tool policy that exposes the computer tool; the default coding profile does not.
  • One action per call: screenshot, clicks, drags, scroll, type, key combos, wait. Every input action returns a fresh screenshot so the model can see what it did.
  • Screenshots are model-only, never delivered to the chat, and the tool tells the model to treat everything on screen as untrusted input.

Where the docs are careful

The trust model is stated plainly: the Gateway is the authorisation chokepoint and the driver is a dumb effector. Loopback is reachability, not identity. Provider selection never falls back per action. Those sentences are the reason the two approvals exist, and why computer use sits behind tool policy as well. OpenClaw sandboxing and tool policy explains the policy side.

Remote Hands on Diali

Diali’s Remote Hands is this mechanism with the Gateway on our side: you pair a laptop, desktop or server you own, it dials out so nothing is opened inbound, you see what the assistant may do and approve it before it acts, and it uses your signed-in browser and installed apps. The private Linux desktop add-on is the other way round, a machine we run that the assistant can see and drive. Computer and Remote Hands on Diali is the page for both; Hosted OpenClaw on Diali is the assistant.

  • Pair the device, then approve what it may do.
  • Platform allowlists first, dangerous commands opt-in, operating-system permissions last.
  • Screenshots stay with the model; on-screen text is untrusted.
Get started

Stop reading about it, build one

Set up an agent, pick a channel, and have it working inside the app you already keep open.