The OpenClaw exec tool

Exec is the tool that makes an agent operational and the one that deserves the most care. It is a shell, it writes files, and where it runs is a resolution question rather than a fixed answer. Here is the parameter surface, the placement rules, the five policy modes with the reviewer that sits inside one of them, and the session commands that can tighten but never loosen.

Parameters and placement

• The command is the only required parameter; a working directory, environment overrides, a yield delay before backgrounding, an immediate background flag, a per-call timeout in seconds, a pseudo-terminal flag for terminal-only programs, an ask mode, a node selector and an elevated flag complete the surface, and a timeout of zero disables the process timeout for that call.
• The host parameter takes only auto, sandbox, gateway or node and is not a hostname selector; auto inherits the configured host including agent and session overrides, and when that is also auto it resolves to the sandbox when a sandbox runtime is active and the gateway otherwise, while a session that requires a sandbox stays sandboxed regardless.
• While a sandbox runtime is active, auto keeps exec in the sandbox and rejects per-call gateway or node overrides, so forcing either means setting the configured host explicitly; running on a node needs a paired connected node supporting the run command, and with several eligible nodes connected a target must be selected in config or per session.
• Host execution rejects path and loader environment overrides to prevent binary hijacking, normalises a pager override to an empty value rather than passing an executable name, sets a marker variable so shell profiles can detect exec context, and on the gateway merges the login-shell path while sourcing a captured startup snapshot that excludes secret-looking variables.

exec is a mutating shell surface: commands can create, edit, or delete files wherever the selected host or sandbox filesystem permits.

The five modes and the reviewer

The mode key is the canonical policy knob and everything else derives from it. Deny blocks exec outright. Allowlist runs only allowlisted or safe-bin commands and asks nothing. Ask runs allowlist matches directly and sends everything else to a human. Auto runs the matches directly and hands eligible misses to a native reviewer that returns allow, deny or ask, where allow runs a low or medium risk command once, deny returns a reason the agent must respect rather than work around, and three consecutive denials in a session escalate the third command to a human. Full runs without ordinary policy prompts, and no-approval host exec is the default for gateway and node because of host-policy defaults rather than the auto host. On the gateway, commands must pass mutable-file binding checks before review: the whole dispatch chain is bound at review time and rechecked before launch, protected executables by resolved real path and writable ones also by content hash, so a new executable earlier on the search path denies the approved run. Shell command wrappers, environment assignments and other unbindable chains skip the reviewer and take the one-shot human path instead.

Inline eval, paths and sessions

• Strict inline eval is a separate opt-in, off by default: when ordinary host approval evaluation runs, it requires reviewer or explicit approval for recognised inline interpreter forms even when the policy allows full and off, covering the eval flags of the common interpreters and carriers, and inline-eval forms never become durable allow rules.
• Path handling differs per host: the gateway merges the login-shell path and securely prepends configured directories right before execution, the sandbox runs a login shell inside the container so the profile may reset the path and configured entries are prepended after profile sourcing, and node hosts ignore path overrides entirely, so extra entries belong in the node service environment.
• A session command sets placement defaults per session while security and ask apply to the current message only; it is honored only for authorized senders, external senders may persist placement defaults while internal clients need administrative scope, and when a session has a permission mode the per-turn override can only tighten it, never loosen it.

OpenClaw exec approvals is the approval flow these modes feed and OpenClaw advanced exec approvals the safe-bin and binding rules behind them.

Two things people get wrong

The first is assuming the file tools are the write surface: disabling them does not make exec read-only, because the shell writes wherever the selected host permits. The second is assuming sandboxing is on: it is off by default, so an implicit auto host resolves to the gateway, while an explicit sandbox request fails closed rather than silently running on the host. The structured patch subtool is worth knowing for the same reason, since allowing the write tool implicitly allows it while denying write does not deny it. Hard-disabling exec is a tool-policy decision, and outside a full-access session the host approval floors still apply. OpenClaw sandboxing explained explains the isolation and OpenClaw skills the instruction files that usually drive these commands.

On Diali

On Diali each assistant runs in its own runtime with the configuration generated from the dashboard and replaced at each release, so the shell an agent reaches is that customer's runtime and nothing else. Hosted OpenClaw on Diali describes the hosted assistant and Diali security the boundary around it.

• Disabling the file tools does not make the shell read-only.
• Sandboxing is off by default; auto then means the gateway.
• Per-turn overrides tighten policy, never loosen it.