2026-07-20

OpenClaw Approvals: Design a Safer Command Boundary

Choose OpenClaw exec approval modes, inspect effective host policy, scope durable allowlists, bind one-shot decisions, and test no-UI failure behavior.

The riskiest OpenClaw approval is often granted to the wrong machine. An operator reviews a harmless-looking command in chat, chooses allow-always, and assumes the decision applies to one workflow. The durable entry actually belongs to an execution host and an agent scope. If that host carries repositories, credentials, or production access, the small convenience becomes a standing capability.

OpenClaw approvals sit after the decision to expose exec. They do not decide whether the tool exists; they decide whether a specific host command may cross from an agent runtime onto the gateway or a node. That makes approvals a command boundary, not a generic permission screen. The useful question is not “How do I stop prompts?” It is “Which command shape can this agent repeat on this host without a person looking again?”

Decision rule: make the cheapest wrong decision allow-once. A permanent grant should require a stable executable, constrained arguments, a known host, and a consequence you are willing to accept tomorrow without seeing the prompt.

Choose a mode from the cost of a wrong grant

OpenClaw exposes five normalized exec modes. They are not a maturity ladder. Moving toward full trades review for throughput, while moving toward deny trades capability for containment. The correct setting depends on the host and task, not on how trustworthy the prompt sounds.

Mode	What happens	Reasonable use	Bad fit
`deny`	Host execution is blocked.	Research, support, or review agents that need no shell on a real host.	A build worker whose core job requires host commands.
`allowlist`	Only deterministic matches run; misses fail.	Unattended jobs with a small, stable command vocabulary.	Exploratory debugging with changing tools and arguments.
`ask`	Allowlist matches run; misses request approval.	Interactive engineering where unfamiliar commands deserve review.	A headless cron whose operator will not be present.
`auto`	Deterministic matches run; misses go through the native reviewer before human fallback.	Bounded low-risk automation with enforceable command plans.	Opaque commands, sensitive hosts, or calls whose effect cannot be inspected.
`full`	Host commands run without approval prompts.	Disposable or tightly isolated hosts where another boundary owns the risk.	A shared gateway with valuable credentials or writable production state.

The host approvals file and requested tools.exec policy are intersected. The stricter result wins. A permissive session request therefore cannot loosen a host file that still says deny or ask: always. The reverse matters too: setting a host file to full does not resurrect an exec tool removed by agent policy. The adjacent OpenClaw tool policy guide covers that earlier capability boundary; this memo starts after exec is already callable.

Cinematic surreal scene of five illuminated doors leading from an agent workspace toward execution hosts, with progressively fewer review barriers — Approval modes trade operator attention for standing command capability; they are choices, not upgrade levels.

Inspect both owners before changing either

There are two views because there are two owners. openclaw exec-policy show explains the local requested configuration together with the local approvals file. openclaw approvals get reads the approvals policy for a target host and reports the merged result. Add --gateway for the Gateway host or --node <id|name|ip> for a node. With no target flag, the command addresses the local machine.

openclaw exec-policy show --json
openclaw approvals get --json
openclaw approvals get --gateway --json
openclaw approvals get --node "Build Node" --json

On OpenClaw 2026.7.1, a local read-only inspection reported requested security: full and ask: off resolving to effective full, with askFallback: deny. The two inspectors agreed on the decision while describing ownership differently. That distinction is operationally useful: a configuration review tells you what the Gateway requests; the host view tells you what the machine will enforce.

Per-session /exec overrides are deliberately absent from these CLI summaries. Inspect the relevant session when diagnosing a prompt that appears inconsistent with the files. Also verify routing. host=auto chooses the sandbox when one exists and otherwise the Gateway; it is not another approval level.

Read before write. Capture the target, requested mode, host mode, effective mode, agent scope, and fallback. An approvals change without that snapshot is difficult to review and harder to roll back.

A durable grant is an executable contract

allow-always is not “trust this message forever.” It can create a reusable allowlist entry. OpenClaw allowlists are per agent and normally match a resolved executable path or a bare command name invoked through PATH. Bare rg may match the resolved rg binary; it does not imply trust in ./rg or an unrelated binary placed under /tmp.

Path-only trust is still broad. If the workflow needs one script shape, add an argPattern so the parsed arguments must match as well. OpenClaw applies ECMAScript regular-expression semantics to the argument string without argv[0]:

{
  version: 1,
  agents: {
    report_worker: {
      security: "allowlist",
      ask: "on-miss",
      askFallback: "deny",
      allowlist: [{
        pattern: "python3",
        argPattern: "^/srv/reports/render\\.py --date [0-9]{4}-[0-9]{2}-[0-9]{2}$"
      }]
    }
  }
}

That rule does not make Python safe. It trusts one parsed invocation shape. A second path-only Python entry would reopen every unmatched argument, so do not combine a narrow rule with a broad fallback for the same binary.

Interpreters and shell composition deserve extra suspicion. python -c, node -e, find -exec, xargs, and similar inline forms can carry an entire program in arguments. Enabling tools.exec.strictInlineEval forces those forms through approval even when the interpreter binary is allowlisted. It also prevents allow-always from quietly turning an inline program into a durable entry.

Surreal cinematic close-up of a brass key aligned with an exact mechanical lock while malformed keys are rejected into shadow — A useful durable approval binds a narrow executable and argument shape; trusting only an interpreter name leaves most of the program unspecified.

What allow-once actually buys

One-shot approval is valuable because the approved request is bound to execution context. For node-host runs, OpenClaw prepares a canonical plan containing the command, working directory, agent, session, environment binding when present, and pinned executable path where applicable. If the caller changes that context after review, the Gateway rejects the forwarded run.

For direct scripts and interpreter file invocations, OpenClaw also attempts to bind one concrete local file operand. A file changed between approval and execution causes denial. The documentation is careful about the limit: this is best-effort protection, not a complete model of every loader. If OpenClaw cannot identify exactly one concrete file, it refuses to mint an approval-backed run rather than pretend the plan is stable.

Pending records expire. List them with openclaw approvals pending --json, review the full request rather than the shortened table row, then resolve the exact ID:

openclaw approvals pending --json
openclaw approvals resolve <id> allow-once
openclaw approvals resolve <id> allow-always
openclaw approvals resolve <id> deny --reason "Unexpected during maintenance"

Resolution is idempotent only for the same recorded decision. Repeating allow-once for an already allowed request succeeds; trying to change that record to deny fails. This protects automation from duplicate delivery without allowing a later caller to rewrite the decision.

Troubleshooting an absent reviewer

askFallback decides what happens when a prompt is required but no approval surface is reachable or the request times out. The default is deny. Keep it there for most production systems. A headless workflow that cannot tolerate a prompt should be designed around deterministic allowlist matches, not a fallback of full.

Interactive workstation

ask or auto, a reachable review surface, askFallback: deny, and narrow durable entries.

Unattended worker

allowlist, no expected prompts, askFallback: deny, and an alert on every miss.

Disposable runner

full can be defensible only when filesystem, credentials, network, and lifetime already contain the consequence.

Production gateway

Prefer deny or ask; move repetitive commands to a narrower worker instead of normalizing permanent grants.

The built-in yolo preset aligns local requested policy and the local approvals file to full/off. It is intentionally explicit because opening only one layer can leave a misleading partial state. Do not use it as a prompt-removal shortcut on a valuable host. It changes authorization behavior; it does not add isolation.

Checklist: one success and one safe rejection

An approvals change is complete when one intended command succeeds and one near miss fails. Test a harmless variant: the same binary with a disallowed argument, the same script from a different path, or the same node request with a changed working directory. Record the effective policy before and after, the exact agent scope, and the terminal decision.

Review durable entries later using their last-used metadata. Remove rules that no longer serve an active workflow. For node-specific mechanics, OpenClaw nodes covers pairing and host capabilities. For the surrounding containment layers, use the OpenClaw security audit. Approvals reduce accidental host execution; they are not per-user authorization, a read-only filesystem, credential scoping, or network policy.

The good default is slightly inconvenient

A command boundary should interrupt unusual work and disappear for stable, narrow work. Start with ask on an interactive host or allowlist on an unattended one. Grant once until the command shape proves repetitive. Persist only the executable and arguments you can explain without the original conversation. If the result feels frictionless on day one, it probably trusts more than the workflow has earned.

GolemWorkers runs persistent hosted agents with runtime operations handled for you, but consequential tool access still deserves an explicit owner and test. The platform can remove server maintenance; it cannot make a broad command grant narrow.

Sources

OpenClaw approvals CLI — host targeting, pending records, resolution decisions, replacement semantics, allowlist helpers, and local policy presets.
OpenClaw exec approvals — effective policy, modes, host trust, strict inline evaluation, durable entries, plan binding, and fallback behavior.
OpenClaw exec approvals documentation source — current upstream behavior contract.