OpenClaw exec approvals

Exec approvals are the guardrail the docs describe for letting a sandboxed agent run commands on a real host, the Gateway machine or a paired node. A command runs only when the policy, the allowlist and, optionally, a person all agree, and approvals stack on top of tool policy and elevated gating rather than replacing them. The modes run from deny through allowlist, ask and auto to full. Here is where they are enforced, the trust model and what an approval actually binds, the commands that show the effective policy, where the state lives, and the fallback when nobody is there to answer.

Commands run only when policy + allowlist + (optional) user approval all agree.

Where they apply

• Locally on the execution host: the OpenClaw process on the Gateway machine, or the node runner, which is the macOS companion app or a headless node host.
• The effective policy is the stricter of the exec tool settings and the approvals defaults; approvals can only tighten, never loosen, and a host-local ask-always keeps prompting even when a session or the config asks for prompts only on a miss.
• On macOS the node host service forwards run requests to the app over local IPC, and the app enforces the approval and executes in the user’s context.

The trust model

Gateway-authenticated callers are trusted operators for that Gateway, and paired nodes extend that capability onto the node host. Approvals reduce the risk of accidental execution; they are not a per-user auth boundary and not a read-only filesystem policy. An approved run binds its canonical context, the working directory, the exact arguments, the environment when present and a pinned executable path; every command-segment executable is bound by resolved real path, writable ones also by a content hash, and a changed resolution during the window, such as a new executable earlier on the path, denies the run. Scripts and interpreter invocations also bind one concrete file, and content that drifts between approval and execution is denied; if one file cannot be identified, OpenClaw refuses to mint an approval-backed run rather than pretend coverage.

Inspecting and storing

• The approvals command shows the requested policy, the host sources and the effective result for the Gateway or a node; the exec-policy commands show and set the local merged view; per-session overrides are inspected in the session itself.
• When the companion UI is not available, a request that would prompt is resolved by the ask fallback, deny by default; native chat approvals exist, Matrix seeds reactions for allow once, allow always and deny, and a node command waits for the decision inside the originating tool call, so a late approval cannot restart it.
• State lives in the shared SQLite database under the state directory on the execution host, with a socket beside it; state directories are independent trust scopes, and a legacy JSON file is imported once by the doctor.

OpenClaw sandboxing explained is the layer beneath this one, and OpenClaw nodes and remote hands explains what a paired machine exposes in the first place.

Why it matters

It is the answer to the question every host owner asks, whether the agent can run commands on the machine: yes, under a policy, an allowlist and an approval, with the executable and the file pinned so an approval cannot be repurposed. OpenClaw security best practices sets it beside the other controls.

On Diali

On Diali the assistant runs in its isolated instance, and a computer of yours joins as a node: its approvals are this same mechanism, the prompt reaches you, the allowlist is yours, and deny is the fallback when you are not there. Hosted OpenClaw on Diali is the assistant and Security on Diali describes the boundary.

• Policy, allowlist, approval: all three, on the host that runs the command.
• An approval binds the path, the arguments and the file.
• No one to ask means deny.