OpenClaw Approvals & Exec Policy CLI

`openclaw approvals`

Approvals for the local host, gateway host, or a node host can be managed here. When no target flag is supplied, commands operate on the local approvals document stored in shared SQLite state. Point to the gateway with --gateway, or use --node <id|name|ip> to select a particular node.

Alias: openclaw exec-approvals

`openclaw exec-policy`

openclaw exec-policy serves as the local-only helper that synchronizes requested tools.exec.* configuration with the local host approvals document in a single operation:

openclaw exec-policy show
openclaw exec-policy show --json

openclaw exec-policy preset yolo
openclaw exec-policy preset cautious --json

openclaw exec-policy set --host gateway --security full --ask off --ask-fallback full --json

Both show, preset, and set take --json and deliver the same requested, host, and effective policy details as one JSON object.

Scope:

The local config file and local approvals document are updated together; policy is not pushed to the gateway or a node host.
--host node gets rejected: node exec approvals are retrieved from the node at runtime, so local exec-policy cannot synchronize them. Turn to openclaw approvals set --node <id|name|ip> instead.
exec-policy show designates host=node scopes as node-managed at runtime, rather than deriving an effective policy from the local approvals document.

For remote host approvals, go directly to openclaw approvals set --gateway or openclaw approvals set --node <id|name|ip>.

Common commands

openclaw approvals get
openclaw approvals get --node <id|name|ip>
openclaw approvals get --gateway
openclaw approvals pending
openclaw approvals resolve <id> <allow-once|allow-always|deny>

The effective exec policy for the target is displayed by get: the requested tools.exec policy, the host approvals-file policy, and the merged effective result. Nodes carrying a host-native policy, like the Windows companion, show that policy directly, skipping OpenClaw approvals-file policy calculations.

For file-backed nodes, the merged view depends on a host-resolved policy snapshot. Older nodes report the effective policy as unavailable, rather than assuming the Gateway's requested policy also holds on the host.

Note

Per-session /exec overrides stay out of this view. Run /exec inside the relevant session to check its current defaults.

Precedence:

The host approvals document stands as the enforceable source of truth.
Requested tools.exec policy may narrow or broaden intent, yet the effective result comes from host rules.
--node merges the node host approvals document with gateway tools.exec policy (both apply at runtime).
If gateway config is missing, the CLI falls back to the node approvals snapshot and flags that the final runtime policy could not be determined.

Pending approvals

Pending exec, plugin, and OpenClaw system-agent approvals from the Gateway are listed here:

openclaw approvals pending
openclaw approvals pending --json

Full enumeration and the matching operator-wide resolve flow rely on operator.admin, since approval records otherwise keep requester/reviewer filtering. Resolution also asks for the dedicated operator.approvals scope. The standard CLI operator grant covers both scopes; a restricted third-party client should not request admin just to mimic this command.

Human output presents the approval kind, agent/session attribution, request age, time until expiry, a shortened command or summary, and a shell-neutral id64_<base64url> id token. A Full request text block always trails the compact table with every complete token and a losslessly escaped request, so terminal-width shortening cannot conceal a suffix or the token needed for resolution. Copy the complete token into resolve. Unsafe terminal characters in other fields appear as visible Unicode escapes. JSON output returns normalized entries under approvals, keeping the original raw id, summary, createdAtMs, and expiresAtMs for scripts; raw ids remain accepted by resolve unless they use the reserved id64_ display-token prefix.

When a supplied id64_ value matches both a literal raw id and the decoded display token for another approval, the CLI rejects it as ambiguous, avoiding resolution of the wrong request.

Resolve one approval by its full id:

openclaw approvals resolve <id> allow-once
openclaw approvals resolve <id> allow-always
openclaw approvals resolve <id> deny --reason "Not expected during maintenance"

For exec requests, allow-always means always allow here: the generated grant is bound to the command's exact arguments and current working directory. The same command from another directory demands a separate approval.

For approvals that come from an automation (cron) run, allow-always creates a scoped standing grant rather than a JSON allowlist entry, as described in Standing grants for automations. Unless revoked, the grant remains active by default; --expires-in-days <n> sets an explicit duration instead of relying on the configured tools.exec.grantExpiryDays default:

openclaw approvals resolve <id> allow-always --expires-in-days 30

Standing grants

Standing grants produced by allow-always on automation approvals are managed through the same command group, where they can be listed and revoked:

openclaw approvals grants list
openclaw approvals grants list --json
openclaw approvals grants revoke <grant-id>

The listing shows the owning automation, the precise command, the usage count, and each grant's status (until revoked, expires in N days, expired, or revoked). Revoking is idempotent and applies at the next occurrence's spawn boundary, at which point that occurrence prompts again. Modifying or deleting the automation invalidates its grants without requiring an explicit revoke.

To determine the kind, the CLI reads the unified approval record, compares the requested decision against the allowed decisions in that record, and then invokes the unified resolver. A first successful decision causes 0 to exit. Repeating the recorded decision also exits 0 and outputs already resolved (same decision). A conflicting decision, a missing or expired approval, or a decision that is unavailable for that approval kind prints a clear error and exits with a non-zero code.

--reason appends a local note to the CLI confirmation. Since the current Gateway approval record lacks a free-text resolution-reason field, this note is neither persisted nor forwarded to other approval surfaces.

Replace approvals from a file

openclaw approvals set --file ./exec-approvals.json
openclaw approvals set --stdin <<'EOF'
{ version: 1, defaults: { security: "full", ask: "off", askFallback: "full" } }
EOF
openclaw approvals set --node <id|name|ip> --file ./exec-approvals.json
openclaw approvals set --gateway --file ./exec-approvals.json

set accepts JSON5, not just strict JSON. Use either --file or --stdin, but never both.

Host-native Windows nodes follow a distinct policy shape:

openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
{
  defaultAction: "deny",
  rules: [{ pattern: "hostname", action: "allow" }]
}
EOF

The CLI reads the node's current hash first and includes it with the update, so concurrent local edits are rejected rather than overwritten. rules is mandatory because this operation replaces the node's entire rule list; defaultAction is optional. A node reporting its native policy as disabled cannot be configured remotely; enable or configure the policy on that host first. The allowlist add|remove helpers are not available for host-native policies.

"Never prompt" / YOLO example

For a host that should never stop on exec approvals, set the host approvals defaults to full + off:

openclaw approvals set --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

For nodes exposing an OpenClaw approvals document, apply the same body with openclaw approvals set --node <id|name|ip> --stdin. Host-native nodes require the owner-specific shape shown above.

This modifies only the host approvals document. To keep the requested OpenClaw policy in sync, also set:

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.mode full

tools.exec.host=gateway is specified here because host=auto still means "sandbox when available, otherwise gateway": YOLO concerns approvals, not routing. Use gateway (or /exec host=gateway) when host exec is desired even with a sandbox configured.

When askFallback is omitted, it defaults to deny. Set askFallback: "full" explicitly when upgrading a no-UI host that should retain never-prompt behavior.

Local shortcut for the same intent, applying only to the local machine:

openclaw exec-policy preset yolo

Allowlist helpers

openclaw approvals allowlist add "~/Projects/**/bin/rg"
openclaw approvals allowlist add --agent main --node <id|name|ip> "/usr/bin/uptime"
openclaw approvals allowlist add --agent "*" "/usr/bin/uname"

openclaw approvals allowlist remove "~/Projects/**/bin/rg"

Common options

get, set, and allowlist add|remove each support:

--node <id|name|ip> (resolves id, name, IP, or id prefix; uses the same resolver as openclaw nodes)
--gateway
shared node RPC options: --url, --token, --timeout, --json

With no target flag, the local approvals row in the shared state database is used.

allowlist add|remove also supports --agent <id> (defaults to "*", applying to all agents).

pending and resolve always use the Gateway because pending requests are live Gateway state. They support the shared Gateway connection options --url, --token, and --timeout; pending also supports --json.

Notes

The node host is required to advertise system.execApprovals.get/set (macOS app, headless node host, or Windows companion).
When upgrading from an argv-only generated-grant version, execute openclaw doctor --fix if the update hasn't already handled it. Doctor only clears inactive generated grants; manual allowlist entries remain untouched. Re-run affected workflows to get them approved in the intended directory.
Per host, approvals live in $OPENCLAW_STATE_DIR/state/openclaw.sqlite#exec_approvals_config, or ~/.openclaw/state/openclaw.sqlite#exec_approvals_config when the variable is unset. The suffix points to the singleton SQLite row.