#Allow Node to access [x]

1 messages · Page 1 of 1 (latest)

lethal timber
#

Is there a way to always allow this so i dont have to keep going back to my machine to ensure my agent stays autonomous? Someone must've figured out an answer

tribal bearBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

candid jolt
#

True

meager egretBOT
#

Yes — that prompt is the exec approvals safety gate for system.run on your node. You’ve got a few options depending on how “autonomous” you want it:

Option A (recommended): allowlist + “Always allow”

When the prompt pops up, choose “Always allow”. That permanently adds the resolved binary path to the node’s allowlist, so you won’t be asked again for that command.

You can also pre-seed the allowlist from the CLI:

openclaw approvals allowlist add --node <id|name|ip> "/usr/bin/uptime"
openclaw approvals allowlist add --node <id|name|ip> "/opt/homebrew/bin/rg"

Docs: https://docs.openclaw.ai/tools/exec-approvals • https://docs.openclaw.ai/nodes

Option B: fully autonomous (risky): set security to full

In Control UI → Nodes → Exec approvals (select your node), set Security = full (and optionally Ask = off). That stops prompts entirely — but it also means the agent can run any command on that machine.

#

Option C: don’t walk to the machine — approve from chat

You can forward approval prompts to Discord/Telegram/etc and approve with /approve <id> …, so you can stay remote without making it “full auto”.

Docs section: “Approval forwarding to chat channels” (same exec-approvals doc above).

If you paste the exact text of the prompt you’re seeing (or a screenshot), I can tell you which of these you’re hitting (node exec approvals vs device pairing, etc.).

#

Yep.

If the thing you’re bumping into is the exec approval prompt for system.run on your node, the two “set and forget” ways are:

1) Allowlist (best balance)

Approve once with Always allow (adds it to the node allowlist), or add entries proactively:

openclaw nodes status                       # find the node name/id
openclaw approvals allowlist add --node <node> "/usr/bin/uptime"
openclaw approvals allowlist add --node <node> "/opt/homebrew/bin/rg"

If it’s still prompting even for allowlisted commands, check the node’s approvals policy:

# 
openclaw approvals get --node <node>

(You want security: "allowlist" + ask: "on-miss" typically.)

2) Full auto (no prompts, highest risk)

Set the node’s exec approvals Security = full (and optionally Ask = off) in Control UI → Nodes → Exec approvals for that node.

Docs: https://docs.openclaw.ai/tools/exec-approvals (and https://docs.openclaw.ai/nodes)

If you tell me what node you’re using (macOS app vs headless node host) + what command it keeps asking for, I can suggest the exact allowlist pattern to add.

lethal timber
#

Exec approvals
Allowlist and approval policy for exec host=gateway/node.
Target
Gateway edits local approvals; node edits the selected node.
No nodes advertise exec approvals yet.
Scope
Defaults
main
outreach (outreach)
x (x)
Security
Default security mode.
Ask
Default prompt policy.
Ask fallback
Applied when the Ul prompt is unavailable.
Auto-allow skill CLIs
Allow skill executables listed by the Gateway.
Save
Node
Select node
Host
く
Node
く
Mode
Full
Mode
Off
Fallback
Full
Enabled
口

Exec approvals
Allowlist and approval policy for exec host=gateway/node.
Target
Gateway edits local approvals; node edits the selected node.
Scope
Defaults
main
outreach (outreach)
x (x)
Security
Default security mode.
Ask
Default prompt policy.
Ask fallback
Applied when the Ul prompt is unavailable.
Auto-allow skill CLIs
Allow skill executables listed by the Gateway.
Gateway
Full
Off
Full
Save
Host
Mode
Mode
く
Fallback
Enabled

configs are diffferent to what u described. i want full yolo autonomy

meager egretBOT
#

What you’re seeing in that UI is consistent with this split:

  • “Target: Gateway” = you’re editing exec approvals on the gateway host.
  • “Target: Node” = only works if the node advertises system.execApprovals.get/set.
    Your UI literally says “No nodes advertise exec approvals yet”, so the dashboard can’t push “full yolo” settings to the node remotely.

So: you can’t make a node go full-autonomy from the Control UI unless that node supports remote approvals editing.

If you want true “full yolo autonomy” on the node

You need to set it on the node machine (one-time):

  1. On the node host, edit (or create) this file:

~/.openclaw/exec-approvals.json

  1. Set defaults to full:
# 
{
  "version": 1,
  "defaults": {
    "security": "full",
    "ask": "off",
    "askFallback": "full",
    "autoAllowSkills": true
  }
}

After that, exec host=node won’t prompt anymore.

Docs: https://docs.openclaw.ai/tools/exec-approvals (see “Settings and storage” + policy knobs)

Why you can’t do it “without ever touching the machine”

#

Because the approval gate is enforced locally on the execution host (the node). If the node doesn’t expose approvals controls to the gateway yet, there’s no remote lever by design.

Next step (so we don’t guess)

Can you paste:

  • openclaw --version (on the node machine), and
  • openclaw nodes describe --node <your-node> (from the gateway)

If the node is just on an older build, upgrading it is usually what makes it start advertising exec approvals so the Control UI can manage it.

lethal timber
#

this is what it looked like already. isnt this already full yolo?

  "version": 1,
  "socket": {
    "path": "~/.openclaw/exec-approvals.sock",
    "token": "[redacted]"
  },
  "defaults": {
    "security": "full",
    "ask": "off",
    "askFallback": "full"
  },
  "agents": {
    "main": {
      "askFallback": "full",
      "allowlist": [
        {
          "id": "[redacted]",
          "pattern": "/bin/ls",
          "lastUsedAt": 1773371252300,
          "lastUsedCommand": "ls -la /private/tmp/[redacted]",
          "lastResolvedPath": "/bin/ls"
        },
        {
          "id": "[redacted]",
          "pattern": "/usr/bin/head",
          "lastUsedAt": 1773331170489,
          "lastUsedCommand": "ls -1t ~/.openclaw/cron/runs/*.jsonl | head -20",
          "lastResolvedPath": "/bin/ls"
        }
      ]
    }
  }
}```
meager egretBOT
#

Yeah — that JSON is already “full yolo” for exec approvals on whatever machine that file lives on:

  • defaults.security: "full"
  • defaults.ask: "off"
  • defaults.askFallback: "full"

In that state, the allowlist section is basically irrelevant (it only matters when security: "allowlist").

So if you’re still getting blocked / prompted, it’s almost always one of these:

1) You edited the wrong host’s file (gateway vs node)

Exec approvals are enforced on the execution host:

  • If your runs are host=gateway → the file must be on the gateway machine.
  • If your runs are host=node → the file must be on the node machine.

Your Control UI screenshot saying “No nodes advertise exec approvals yet” strongly suggests you’re not actually editing the node via UI — so double-check the file you pasted is from the node you’re executing on.

#

Quick sanity checks:

  • openclaw nodes status (on gateway) → which node is actually connected/used?
  • In chat: /exec → does it show host=node and which node=...?

2) Tool policy is still stricter than approvals

OpenClaw applies the stricter of tools.exec.* and approvals. So if your gateway config has (for example) tools.exec.security: "allowlist" or tools.exec.ask: "always", you can still end up with prompts/denies even though approvals are “full”.

To be truly no-prompts, make sure the session/tool settings are also full, e.g.:

  • in chat: /exec host=node security=full ask=off node=<your-node>

Paste these 2 things and I’ll tell you exactly where the mismatch is

  1. Output of /exec in the chat where it’s failing
  2. openclaw config get tools.exec (on the gateway)

That’ll immediately show whether you’re (a) on the wrong host or (b) being clamped by tool policy.

lethal timber
# 
┌───────────────────────────────┬──────────────────────────────────────────────────────────────────┬──────────┬───────────────────────────────────┬───────────────────────┬────────────────────────────┐
│ Node                          │ ID                                                               │ IP       │ Detail                            │ Status                │ Caps                       │
├───────────────────────────────┼──────────────────────────────────────────────────────────────────┼──────────┼───────────────────────────────────┼───────────────────────┼────────────────────────────┤
│ MacBook Pro                   │ [redacted] │          │                                   │ paired · disconnected │                            │
└───────────────────────────────┴──────────────────────────────────────────────────────────────────┴──────────┴───────────────────────────────────┴───────────────────────┴─────────────────────────```

 Current exec defaults: host=gateway, security=full, ask=off, node=(unset).                                                             
 Options: host=sandbox|gateway|node, security=deny|allowlist|full, ask=off|on-miss|always, node=<id>

```{
  "host": "gateway",
  "security": "full",
  "ask": "off",
  "pathPrepend": [
    "/opt/homebrew/bin",
    "/usr/local/bin",
    "/usr/bin",
    "/bin"
  ],
  "safeBinTrustedDirs": [
    "/bin",
    "/usr/bin"
  ]
}
meager egretBOT
#

That output explains it: your node isn’t connected.

  • Known: 1 · Paired: 1 · Connected: 0
  • paired · disconnected

So right now you don’t have a live node to run anything on, regardless of approvals / “full yolo”. Approvals only matter after the node is actually online.

Also, your current exec defaults are:

  • host=gateway, security=full, ask=off

So even when things work, exec is currently running on the gateway, not the MacBook.

What you need for “always autonomous”

A) Keep the node connected 24/7 (the real blocker)

On the MacBook (one-time), run a node host as a service so it auto-starts after reboots:

# 
openclaw node install --host <gateway-host> --port 18789 --display-name "MacBook Pro"
openclaw node restart

Then make sure the MacBook doesn’t sleep (sleep = node disconnect). For true autonomy, a MacBook is a pain; a Mac mini / always-on box is way better.

Docs: https://docs.openclaw.ai/nodes (see “Start a node host (service)” + the SSH tunnel note if your gateway binds loopback)

B) Actually route exec to the node (once it’s connected)

In chat (or config), set:

/exec host=node security=full ask=off node=<node-id-or-name>

Quick question so I can give the exact connection fix

#

Where is your gateway running (same Mac vs VPS/Linux)? If it’s remote and bound to loopback, the node needs an SSH tunnel or tailnet bind to stay connected.

lethal timber
#

what do i replace in <gateway-host>?

#

im on my personal mbp

meager egretBOT
#

<gateway-host> should be the hostname/IP of the machine that’s running your Gateway, as seen from the MacBook (node machine).

Common cases:

1) Gateway is on the same MacBook

Use loopback:

openclaw node install --host 127.0.0.1 --port 18789 --display-name "MacBook Pro"

2) Gateway is on a VPS / other machine

Use that server’s reachable address, ideally a stable DNS name:

  • Public DNS/IP (if you exposed it): my-vps.example.com or 1.2.3.4
  • Tailscale MagicDNS (recommended): my-vps.tailnet-xxxx.ts.net
#

Example:

openclaw node install --host my-vps.tailnet-xxxx.ts.net --port 18789 --display-name "MacBook Pro"

3) Gateway binds to loopback on the server (common) → use an SSH tunnel

If your gateway is only listening on 127.0.0.1:18789 on the server, the node can’t reach it directly. Do this on the MacBook:

ssh -N -L 18790:127.0.0.1:18789 user@my-vps
openclaw node run --host 127.0.0.1 --port 18790 --display-name "MacBook Pro"

(Then you can convert to a service once that works.)

If you tell me where your Gateway is running (same MacBook vs VPS, and whether you’re using Tailscale/Serve/SSH), I’ll give you the exact one-liner.

#

Got it — but the missing piece is still: where is your Gateway running? (same MBP vs a VPS/other machine)

If the Gateway is running on this same MBP

Then <gateway-host> is just:

  • 127.0.0.1 (or localhost)

…and honestly you don’t need a node at all for exec — your exec is already host=gateway security=full ask=off, so it’ll run locally on the MBP.

If the Gateway is running somewhere else (VPS / home server)

Then <gateway-host> is the address of that server (e.g. a Tailscale MagicDNS name like my-vps.tailnet-xxxx.ts.net), and you install the node host service on the MBP:

openclaw node install --host <your-gateway-host> --port 18789 --display-name "MacBook Pro"
openclaw node restart
#

Why your node shows “paired · disconnected”

That usually means the MBP isn’t currently connected/running the node host (or it slept / network dropped). If you want “always autonomous”, the MBP has to stay awake + online (or switch to an always‑on machine like a Mac mini).

If you run this on the MBP and paste the output, I can tell you instantly which case you’re in:

openclaw gateway status
lethal timber
#

ok i ran openclaw node install --host 127.0.0.1 --port 18789 --display-name "MacBook Pro"

now what?

meager egretBOT
#

Next steps are basically: start it, pair it (if needed), then actually route exec to it.

1) Start/restart the node service

(On the MBP)

openclaw node restart
openclaw node status

2) Approve the node pairing request (first time only)

The first connection usually creates a pending device pairing request on the Gateway.

On the Gateway (if it’s the same MBP, just run it there too):

# 
openclaw devices list
openclaw devices approve <requestId>

3) Confirm it’s connected

openclaw nodes status

You want to see Connected: 1 and your node not “disconnected”.

4) (Optional) Actually use the node for exec

Right now your exec defaults are host=gateway. If you want commands to go through the node path:

In chat:

# 
/exec host=node security=full ask=off node=MacBook\ Pro

(or use the node ID from openclaw nodes status)

One important note: installing a node host on the same MBP as the gateway doesn’t magically make it “always autonomous” if the MBP sleeps. If your real goal is 24/7 autonomy, you’ll need the gateway/node on an always-on machine (or disable sleep).

lethal timber
#

Macbook\ Pro? or Macbook Pro? would that make a difference?

#

re: sleeping, is caffeinate enough? i havent had problems thus far

meager egretBOT
#

It can make a difference, because /exec … node=… is parsed as space‑separated tokens. So:

  • node=Macbook Pro will usually get parsed as node=Macbook + stray Pro (bad)
  • node=Macbook\ Pro might work if the parser understands backslash escapes, but it’s not the most reliable.

Do this instead (recommended): use the node ID from openclaw nodes status. No spaces, no ambiguity.

Example:

/exec host=node security=full ask=off node=<THE_NODE_ID>

(Once the node is actually connected — right now yours was “paired · disconnected”, so the node value won’t matter until it’s online.)

#

caffeinate is usually enough to stop idle sleep (which is the main thing that makes nodes disconnect), as long as:

  • the Mac stays powered on (not rebooted),
  • the process is still running,
  • you don’t close the lid in a way that forces sleep.

A pretty standard “keep it awake” command is:

caffeinate -dimsu

Notes / gotchas:

  • If the MBP reboots/logs out, caffeinate stops (so it’s not truly “set and forget” unless you also auto-start it).
  • If you close the lid, macOS often sleeps anyway unless you’re in clamshell mode (power + external display/keyboard) — caffeinate won’t reliably override that.
  • For real 24/7 autonomy, the most reliable setup is still: always-on machine (Mac mini / server) + disable sleep in macOS power settings.
#

If you haven’t had problems so far, you’re probably already in the “plugged in + lid open” sweet spot. The moment you start seeing paired · disconnected again, it’s almost always sleep/lid/power-saving kicking in.

lethal timber
#

so node > gateway?

meager egretBOT
#

Not really “node > gateway” — they’re different jobs:

  • Gateway = the required always-on control plane (runs the agent, owns sessions, talks to Discord/Telegram, calls tools).
  • Node = an optional peripheral that lets the gateway run certain tools on another device (your MBP, phone, etc.).

So the right choice depends on what you’re optimizing for:

If your Gateway is on your MBP

Use host=gateway for exec. A node on the same machine is mostly redundant (extra moving parts).

If your Gateway is on a VPS / always-on server

Then node is how the agent can touch your MBP (run commands, local browser proxy, etc.). But it will only work while the MBP is awake/online.

For “always autonomous”

The most reliable pattern is:

  • Gateway on always-on host (VPS/Mac mini)
  • Node on MBP only when you need MBP-local stuff
#

Gateway is the “brain”; node is “hands on a device.”

lethal timber
#

how to perform full health doctor deep security audit redacted so i can share w u. gimme the command

meager egretBOT
#

Run this bundle and paste the output here:

openclaw --version && \
echo "\n===== openclaw status --all (safe to share; tokens redacted) =====\n" && \
openclaw status --all && \
echo "\n===== openclaw doctor --deep =====\n" && \
openclaw doctor --deep && \
echo "\n===== openclaw security audit --deep =====\n" && \
openclaw security audit --deep

Notes:

  • openclaw status --all is the one that’s explicitly designed to be pasteable (tokens redacted).
  • Still do a quick skim before posting in case you see personal identifiers you don’t want public (phone numbers, hostnames, etc.).
lethal timber
#

openclaw 2026.3.11 on macos arm64. discord connected, gateway running locally on 127.0.0.1:18789, but logs show repeated ws 1008 closes with “connect failed” and “pairing required” during operator->node role upgrade. also hitting ACPX non-interactive write/exec denial, exec allowlist/host-denied errors, and sandbox path/ENOENT failures for SKILL.md reads. seems mainly like pairing/trust + ACP permission config, with secondary sandbox skill path issues.

#

Repair legacy cron jobs now?
│ ○ Yes / ● No
?? will this fuck up my crons?

meager egretBOT
#

That summary lines up with 3 separate buckets. Here’s the shortest path to get you unblocked on each:

1) 1008 … pairing required / “operator→node role upgrade”

That error means a client is connecting but doesn’t have an approved device token for the role/scope it’s requesting.

On the gateway host (you said that’s the MBP):

openclaw devices list
openclaw devices approve --latest

Then retry the thing that’s failing (Control UI reconnect / node reconnect).

If it keeps happening and there’s no pending request to approve, you likely have stale device state. Nuke + re-pair the specific device:

# 
openclaw devices list
openclaw devices remove <deviceId>
# then reconnect the client so it generates a new request
openclaw devices approve --latest

CLI docs: https://docs.openclaw.ai/cli/devices
FAQ note (same symptom): https://docs.openclaw.ai/help/faq#what-does-invalid-handshake-code-1008-mean

2) ACPX “non-interactive write/exec denial”

That’s the acpx harness permission mode. If you want it to just work (YOLO), set:

openclaw config set plugins.entries.acpx.config.permissionMode approve-all
openclaw gateway restart
#

Docs: https://docs.openclaw.ai/tools/acp-agents#permission-configuration

3) Sandbox SKILL.md ENOENT / skill path issues

That usually means you’re running a session inside Docker sandbox, but the file path you’re trying to read isn’t available/mounted there.

Two quick fixes:

  • Disable sandboxing for that agent/session while debugging, or
  • Move/override the skill into the workspace (so it exists in the sandbox mount), not some host-only path.

Docs: https://docs.openclaw.ai/gateway/sandboxing

If you paste the output of openclaw devices list --json (redact ids if you want), I can tell you exactly which device request/role/scope is causing the 1008 loop.