OpenClaw Exec Approval Policy Guide

Teams evaluating OpenClaw for coding or ops work need to know when the agent can run commands and when a human approval should interrupt the flow. This search usually appears after the first OpenClaw demo feels promising but the rollout still feels risky. The question is no longer whether an agent can answer a message. The question is whether it can run a real operating lane with memory, permissions, routing, verification, and a clean handoff back to people.

30-second answer

Inspect the effective exec policy, keep risky or destructive actions approval-gated, and separate local host trust from Gateway or node trust. OpenClaw approvals are not friction for its own sake; they are the point where humans keep agency over real systems.

When this is worth doing

This is worth doing before an agent touches repositories, servers, package managers, or deployment commands. A fast agent with unclear shell power is not a productivity win; it is an incident waiting to happen.

Official docs to keep open

This guide stays inside the documented OpenClaw surface. The most relevant docs are tools/exec-approvals.md; tools/elevated.md; gateway/sandbox-vs-tool-policy-vs-elevated.md; gateway/operator-scopes.md; gateway/sandboxing.md. The building blocks to evaluate are openclaw approvals get; openclaw exec-policy show; local and Gateway policy sources; operator scopes; sandbox boundaries. If a workflow would need a hidden feature, a private API, or an assumed limit that the docs do not describe, keep it out of the first rollout.

Buyer-intent runbook

1. Inspect the current policy with the documented approval and exec-policy commands. Do not guess whether the agent is in deny, allowlist, or full mode.
2. Decide which commands are routine and which require a human. Build, test, read-only diagnostics, and safe formatting may be different from deploy, delete, migrate, or credential work.
3. Account for where the command runs. The docs distinguish local-machine policy, Gateway host behavior, node execution, sandboxing, and elevated actions.
4. Use sandboxing to reduce blast radius, but do not treat it as a substitute for approvals. Sandboxing and approval policy solve different parts of the risk model.
5. Review failed approval requests. They are useful signals about missing allowlists, unclear prompts, or risky workflows that should be redesigned.

Proof before rollout

The proof is an effective policy printout, a low-risk command that runs without surprise, and a risky command that correctly asks for approval or is blocked. If both commands behave the same, the policy probably needs work.

Common mistakes

• Do not set full command access globally because one workflow was annoying.
• Do not approve a chained command without reading the whole script.
• Do not confuse elevated permissions with sandbox safety.
• Do not let agents change their own safety policy as a routine task.

Rollout note

Start strict and loosen narrow paths after observing real work. The best policy is boring: it lets safe repetition move fast and forces humans to see irreversible steps.

Where the Playbook helps

The Playbook helps classify commands by risk and map them to approval rules, sandbox choices, and escalation language humans can understand. The OpenClaw Playbook turns that decision into a repeatable operating system: which files to keep, which jobs to schedule, which approvals to require, and how to report proof without flooding the team. If you are moving from experiment to revenue or client operations, use the Playbook before the agent becomes another unmanaged tool.

The practical rule is to start with one lane, one owner, one channel, and one verification habit. Approval policy is a buying criterion for teams because it determines whether OpenClaw can be trusted near real infrastructure. That keeps the first deployment measurable. It also gives the team a simple before-and-after comparison: how long the workflow took manually, what the agent handled, what still needed judgment, and which check proved the result. Once the lane is stable, duplicate the pattern for adjacent work instead of designing a giant automation program on day one.