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

Command ladder

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

Foreground requirements

canvas.*, 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

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 gateway.nodes.allowCommands / denyCommands and platform defaults?
  3. Exec approvals: can this node run a specific shell command locally?
Quick checks:
If pairing is missing, approve the node device first. If nodes describe 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 system.run fails, fix exec approvals/allowlist on that node. 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 (fluffbuzz approvals get --node ...), not in the gateway pairing record. For approval-backed host=node runs, the gateway also binds execution to the prepared canonical systemRunPlan. 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

  • NODE_BACKGROUND_UNAVAILABLE → app is backgrounded; bring it foreground.
  • CAMERA_DISABLED → camera toggle disabled in node settings.
  • *_PERMISSION_REQUIRED → OS permission missing/denied.
  • LOCATION_DISABLED → location mode is off.
  • LOCATION_PERMISSION_REQUIRED → requested location mode not granted.
  • LOCATION_BACKGROUND_UNAVAILABLE → app is backgrounded but only While Using permission exists.
  • SYSTEM_RUN_DENIED: approval required → exec request needs explicit approval.
  • SYSTEM_RUN_DENIED: allowlist miss → command blocked by allowlist mode. On Windows node hosts, shell-wrapper forms like cmd.exe /c ... are treated as allowlist misses in allowlist mode unless approved via ask flow.

Fast recovery loop

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