Skip to main content
Use this page when a node is visible in status but node tools fail.

​
Node goes offline after SSH logout (Linux)

On Linux, openclaw node install creates a user-level systemd service. The systemd --user instance is torn down when your last login session ends, so the node service stops the moment you log out — even though it looked healthy (enabled + running) while you were connected. Check lingering:
If it reads Linger=no, enable it (may require sudo):
Then restart the node service and verify it survives logout:
openclaw node install prints a warning with this recovery command when it detects lingering is disabled. Don’t mix a user-level service with a system-level one for the same node. The duplicate-scope guard that prevents two managers from running the same unit name is enforced for gateway units (two supervisors on the same port SIGTERM each other in a restart loop); for node services the installer does not raise this guard, so a leftover unit in the other scope can leave the node in an ambiguous state. Fully remove one before switching.

​
Command ladder

Then run node-specific checks:
Healthy signals:
  • Node is connected and paired for role node.
  • nodes describe includes the capability you’re calling.
  • Exec approvals show the expected mode/allowlist.

​
Foreground requirements

camera.* and screen.* are foreground-only on iOS/Android nodes. Quick check and fix:
If you see NODE_BACKGROUND_UNAVAILABLE, bring the node app to the foreground and retry.

​
Permissions matrix

​
Pairing versus approvals

Three separate gates control whether a node command succeeds:
  1. Device pairing: can this node connect to the gateway?
  2. Gateway node command policy: is the RPC command ID allowed by gateway.nodes.commands.allow / gateway.nodes.commands.deny and platform defaults?
  3. Exec approvals: can this node run a specific shell command locally?
Node pairing is an identity/trust gate, not a per-command approval surface. For system.run, the per-node policy lives in that node’s exec approvals file (openclaw approvals get --node ...), not in the gateway pairing record. Quick checks:
  • Pairing missing: approve the node device first.
  • nodes describe missing a command: check the gateway node command policy and whether the node actually declared that command on connect.
  • Pairing fine but system.run fails: fix exec approvals/allowlist on that node.
For approval-backed host=node runs, the gateway also binds execution to the prepared canonical systemRunPlan. If a later caller mutates the command, cwd, or session metadata before the approved run is forwarded, the gateway rejects the run as an approval mismatch instead of trusting the edited payload.

​
Common node error codes

​
Fast recovery loop

If still stuck:
  • Re-approve device pairing.
  • Re-open the node app (foreground).
  • Re-grant OS permissions.
  • Recreate/adjust the exec approval policy.
For computer control, also verify that the node-local Computer Control toggle is enabled, its pairing update is approved, a vision-capable agent exposes the computer tool, and screen.snapshot succeeds with Screen Recording permission. A gateway.nodes.commands.deny entry always overrides a platform default or gateway.nodes.commands.allow.