OpenClaw elevated mode

When an OpenClaw agent runs inside a sandbox, its exec commands are confined to it. Elevated mode is the deliberate exception: it lets the agent break out of ordinary agent-configured sandboxing and run commands outside the sandbox instead, with configurable approval gates, and the docs are clear that sessions whose creator role requires sandboxing cannot use it to escape. Here are the directives, how a session gets there, the gates that must all pass, and the four things elevated does not control.

The directives

• On runs outside the sandbox on the configured host path and keeps approvals; ask is its alias.
• Full runs outside the sandbox and skips approvals only when the resolved exec mode and host approval policy are already fully permissive, security full and ask off; otherwise the normal approval policy still applies.
• Off returns to sandbox-confined execution, a short alias exists, and the bare directive shows the current level.
• Resolution order: an inline directive on a message applies to that message only, a directive-only message sets the session override, and the global default in the agent defaults comes last.

Elevated mode only changes behavior when the agent is sandboxed. For unsandboxed agents, exec already runs on the host.

The gates

Elevated must be enabled in config and the sender must be on the allowlist, which is per channel. The full list of gates: the global enable flag; the global sender allowlist; a per-agent enable flag that can only further restrict, so both must be true; a per-agent allowlist the sender must also match; and a channel-provided fallback allowlist that no bundled channel currently implements, so in practice every provider needs an explicit entry today. All gates must pass, otherwise elevated is treated as unavailable. Allowlist entries can be a bare sender id, phone number or from field, or prefixed by name, username, tag, or the explicit identity prefixes. With elevated active, exec calls leave the sandbox and the effective host is the Gateway by default, or a node when the configured or session exec target is already a node.

What it does not control

• Tool policy: if exec is denied by tool policy, elevated cannot override it. Required role sandboxing: if the session creator’s operator role required a sandbox, elevated cannot run commands on the Gateway or a node.
• Host selection: elevated does not turn an automatic host choice into a free cross-host override; it follows the configured or session exec target rules. And it is separate from the exec directive, which adjusts per-session exec defaults for authorized senders without needing elevated at all.
• The bash chat command, the exclamation-mark prefix, is a separate gate that requires elevated to be enabled in addition to its own flag, so disabling elevated locks shell commands from chat out as well.

OpenClaw sandboxing explained is the boundary elevated steps over, and OpenClaw exec approvals the approval system that stays in force in on and ask modes.

How the three gates compose

The docs keep a separate page on how sandbox, tool policy and elevated compose during a tool call, and the short version is in the list above: policy decides whether exec exists, the sandbox decides where it runs, and elevated moves it out only when every gate agrees. OpenClaw permission modes covers the session-wide exec policy that the exec directive sets, and OpenClaw slash commands the command surface the elevated directive belongs to.

On Diali

On Diali every assistant is sandboxed and there is no host to break out to: the isolated instance is the boundary, and the approvals stay where you see them, in the dashboard. Hosted OpenClaw on Diali is the assistant and Diali security describes the boundary.

• On keeps approvals; full skips them only when policy already allows.
• Global flag, global allowlist, per-agent flag, per-agent allowlist: all must pass.
• Tool policy and required-role sandboxing win over elevated.