OpenClaw "exec denied: allowlist miss"

Why it happens

Exec allowlists are per agent and match the resolved real path of every top-level command segment. One error string covers several different failures, and the log redacts the command, so the message alone does not tell you which one you hit (issue #158341).

1. The binary is genuinely not on the agent's allowlist. Allowlist entries belong to one agent id, so an entry added for one agent does not cover another.
2. The program name does not resolve at all: it is missing from the gateway process's PATH, or it is a relative path from a different working directory. This reads like a permission problem but is a PATH problem (issue #158341; a clearer denial message is proposed in PR #167761).
3. The path you allowlisted is a symlink and the matcher compares the resolved target. On Ubuntu 25.10 and 26.04, /usr/bin/date and other coreutils point to /usr/lib/cargo/bin/coreutils/, so an entry for /usr/bin/date never matches (issue #140921).
4. The command is a shell chain or wrapper. Every top-level segment must pass, so VAR=x; curl ... or cmd1 && cmd2 is denied even when curl itself is allowlisted (issue #59235).
5. Isolated cron runs. An agentTurn cron job with sessionTarget isolated can be denied even when openclaw approvals get shows the entry (issue #136386, open).

The fix

1. 1 See which policy applies to the agent: openclaw exec-policy show --agent main. If security is allowlist, the denial is policy working as configured.
2. 2 Find the real path the gateway resolves: run readlink -f "$(command -v curl)" on the gateway host, as the gateway's user. Allowlist that resolved path, not the symlink.
3. 3 Add it to the right agent: openclaw approvals allowlist add --agent main "/usr/bin/curl". Without --agent the entry goes to "*" (all agents). Confirm with openclaw approvals get.
4. 4 If the agent ran a chained or wrapped command, have it call the binary directly, one command per exec call, so each segment can be matched.
5. 5 To restrict arguments too, add an argPattern to the entry (for example pattern python3 with argPattern ^safe\.py$) instead of allowlisting the interpreter outright.
6. 6 Rerun and watch openclaw logs --follow. If the absolute path works but the bare name fails, it is a PATH lookup problem, not a missing grant.

Why the allowlist exists, and why allow-all is the wrong fix

Exec lets the model run commands on a real host, and the model reads untrusted text all day: web pages, emails, chat messages, skill files. If that text persuades it to run something, the allowlist limits the damage to binaries you chose. Matching on the resolved path means a new binary placed earlier on PATH cannot impersonate an approved one.

Setting full with ask off (the YOLO preset) removes the error by removing the check for every command and every future prompt. Full is already the default on gateway and node hosts, so this error means someone chose allowlist mode on purpose. A narrower option is ask on-miss: allowlisted commands run, anything else waits for human approval.

openclaw exec-policy set --security allowlist --ask on-miss --ask-fallback deny

With ask on-miss you need an approval surface the agent can reach (Control UI, the companion app, or a chat approval channel). If none is reachable, askFallback decides, and its default is deny.

Still failing?

• Run openclaw approvals get --json and check the entry sits under the agent id that is actually running, not a different agent or only under "*".
• Check whether the host approvals file is stricter than tools.exec in openclaw.json, because the stricter of the two always wins.
• If it only fails from cron, compare a sessionTarget main run with the isolated run and follow issue #136386.

Related errors

• OpenClaw "tool read/write/exec does not exist"
• OpenClaw "access not configured" pairing reply