Node troubleshooting

Use this page when a node is visible in status but node tools fail.

Command ladder

bash
Copy
openclaw status
openclaw gateway status
openclaw logs --follow
openclaw doctor
openclaw channels status --probe

Then run node specific checks:

bash
Copy
openclaw nodes status
openclaw nodes describe --node <idOrNameOrIp>
openclaw approvals get --node <idOrNameOrIp>

Healthy signals:

• Node is connected and paired for role
  text

  Copy

  node
  .
• text

  Copy

  nodes describe
  includes the capability you are calling.
• Exec approvals show expected mode/allowlist.

Foreground requirements

, , and are foreground only on iOS/Android nodes.

Quick check and fix:

bash
Copy
openclaw nodes describe --node <idOrNameOrIp>
openclaw nodes canvas snapshot --node <idOrNameOrIp>
openclaw logs --follow

If you see

, bring the node app to the foreground and retry.

Permissions matrix

Pairing versus approvals

These are different gates:

1. Device pairing: can this node connect to the gateway?
2. Gateway node command policy: is the RPC command ID allowed by
   text

   Copy

   gateway.nodes.allowCommands
   /
   text

   Copy

   denyCommands
   and platform defaults?
3. Exec approvals: can this node run a specific shell command locally?

Quick checks:

bash
Copy
openclaw devices list
openclaw nodes status
openclaw approvals get --node <idOrNameOrIp>
openclaw approvals allowlist add --node <idOrNameOrIp> "/usr/bin/uname"

If pairing is missing, approve the node device first. If

is missing a command, check the gateway node command policy and whether the node actually declared that command on connect. If pairing is fine but fails, fix exec approvals/allowlist on that node.

Node pairing is an identity/trust gate, not a per-command approval surface. For

, the per-node policy lives in that node's exec approvals file (), not in the gateway pairing record.

For approval-backed

runs, the gateway also binds execution to the prepared canonical . If a later caller mutates 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

• text

  Copy

  NODE_BACKGROUND_UNAVAILABLE
  → app is backgrounded; bring it foreground.
• text

  Copy

  CAMERA_DISABLED
  → camera toggle disabled in node settings.
• text

  Copy

  *_PERMISSION_REQUIRED
  → OS permission missing/denied.
• text

  Copy

  LOCATION_DISABLED
  → location mode is off.
• text

  Copy

  LOCATION_PERMISSION_REQUIRED
  → requested location mode not granted.
• text

  Copy

  LOCATION_BACKGROUND_UNAVAILABLE
  → app is backgrounded but only While Using permission exists.
• text

  Copy

  SYSTEM_RUN_DENIED: approval required
  → exec request needs explicit approval.
• text

  Copy

  SYSTEM_RUN_DENIED: allowlist miss
  → command blocked by allowlist mode. On Windows node hosts, shell-wrapper forms like
  text

  Copy

  cmd.exe /c ...
  are treated as allowlist misses in allowlist mode unless approved via ask flow.

Fast recovery loop

bash
Copy
openclaw nodes status
openclaw nodes describe --node <idOrNameOrIp>
openclaw approvals get --node <idOrNameOrIp>
openclaw logs --follow

If still stuck:

• Re-approve device pairing.
• Re-open node app (foreground).
• Re-grant OS permissions.
• Recreate/adjust exec approval policy.

Related:

• /nodes/index
• /nodes/camera
• /nodes/location-command
• /tools/exec-approvals
• /gateway/pairing

Related

• Nodes overview
• Gateway troubleshooting
• Channel troubleshooting