OpenClaw permission modes

Permission modes decide how much authority an agent has before it runs host commands, writes files or asks a backend harness for more access. The docs put it in one setting, the exec mode, with five values, and are careful to say it is separate from the setting that chooses where a command runs. Here is what each mode resolves to, why the docs recommend auto for coding agents, how the mode maps onto native Codex approvals, the separate permissions of the ACP harness, and the two commands that show what is really in force.

The five modes

• Deny: block host exec entirely; security deny, ask off.
• Allowlist: run only allowlisted commands and silently deny misses.
• Ask: run allowlist matches and ask a human on every miss.
• Auto: run allowlist matches and review eligible misses with an automatic reviewer that answers allow, deny or ask; the docs’ recommended default for coding agents that need useful host access without a prompt for every miss.
• Full: run host exec without ordinary policy prompts, for a trusted host only.

Permission mode is separate from tools.exec.host=auto.

How auto reviews

Ask and auto share the same allowlist and ask settings; auto adds the native reviewer. An allow verdict permits one low- or medium-risk execution, a deny verdict returns a reason so the agent can pick a safer alternative or ask, and an ask verdict, like a review failure, requests human approval; on the Gateway, three consecutive reviewer denials escalate to a human. Binding still applies: every command-segment executable is bound before review and re-checked before launch, login and interactive shell wrappers skip the reviewer and require a human, and the strict inline-eval setting, off by default, makes recognised inline programs need review even under full. A full-permission Gateway session with effective full and ask off skips the host approval path altogether; tightening ask restores it.

Codex and the ACP harness

• For native Codex sessions, auto drives Guardian-reviewed approvals: on-request approval policy, an automatic reviewer and a workspace-write sandbox, forcing that policy over unsafe legacy combinations; deny and allowlist block Codex local execution entirely, and full is the intentional no-approval posture.
• ACP harness sessions have no terminal for prompts and use their own settings: a permission mode of approve reads, approve all or deny all, and a rule for non-interactive prompts, fail or deny; approve all is the break-glass equivalent of a no-prompt session.
• The layers do not loosen each other: host exec uses the stricter of the config and the host-local approvals file, harness permissions do not loosen host approvals, and host approvals do not loosen harness prompts.

OpenClaw exec approvals is the guardrail layer this mode configures, and OpenClaw sandboxing explained the containment beneath it.

Seeing what is in force

Two commands: the approvals command prints the requested policy, the host policy sources behind it and the effective result, and the exec-policy command shows the local merged view; the docs say to run both when a command still prompts or fails after a mode change. OpenClaw and Claude Code is where the same idea appears on the Claude side, with hooks and permissions the migration keeps archive-only.

On Diali

On Diali the assistant’s instance runs with the modes set for it, and a computer of yours joins as a node with its own approvals; the toggle between ask and auto is a dashboard decision rather than a config edit. Hosted OpenClaw on Diali is the assistant.

• Five modes, each a security and ask pair.
• Auto reviews misses; three denials bring in a human.
• Layers only tighten; two commands show the result.