Breaking out of the sandbox on purpose

Sandboxing an agent is easy to decide and harder to live with, because the moment a genuine task needs something outside the box you need a way to let it out that is deliberate rather than accidental. Elevated mode is the OpenClaw answer to that. It changes nothing for an agent that was never sandboxed, and for one that is, it opens a narrow and gated path to the host. The gates are worth reading closely, because several of them have to line up before a single command moves.

What elevated mode does

• Elevated mode lets a sandboxed agent break out of ordinary agent configured sandboxing and run commands outside the sandbox instead, with approval gates that stay configurable.
• It only changes behaviour when the agent is sandboxed, because an unsandboxed agent already runs its shell commands on the host.
• The effective host is the Gateway by default and becomes the node only when the configured or session exec target is already a node, so elevation is not a cross host override.
• Four directives are available per session, with an on level that keeps approvals, an ask level that is an alias of it, a full level that can skip approvals, and an off level that returns to sandbox confined execution.

Sessions whose creator role requires sandboxing cannot use elevated mode to escape.

The gates that must align

Availability is a conjunction, not a switch. The global gate has to be on, and the sender has to appear on the allowlist for their channel, which is kept as per channel lists of identifiers. A per agent gate can only further restrict things, so both the global and the per agent gate must be on for an agent to qualify. The per agent allowlist works the same way, and a sender has to match both the global and the per agent list. Channel plugins may supply a fallback allowlist through an SDK adapter hook, but no bundled channel implements that hook today, so in practice every provider needs its own explicit allowlist entry. If any gate fails, elevated is treated as unavailable rather than partially granted. Entries themselves can be plain identifiers, which match a sender ID, an E.164 number or a From field, or they can carry a prefix that targets a display name, a username or a tag, with explicit identity prefixes available when you need to be unambiguous. There is one quieter dependency as well, since the bash chat command sits behind its own flag and additionally requires elevated to be enabled, so turning elevated off locks those shell messages out too.

Levels and precedence

• A directive only message sets the session default, while the same directive used inline in front of a request applies to that message alone.
• Resolution runs from the inline directive first, then the session override, then the global default set in configuration.
• In full mode approvals are skipped only when the resolved exec mode and host approval policy is already fully permissive, and in the on and ask levels the configured approval rules always apply.

Elevated mode assumes you already have a Gateway sandboxing worth leaving, and it assumes you have decided what a command is allowed to do once it lands, which is the job of Exec approvals. Neither of those is something elevation replaces.

Why the limits hold

The design treats elevation as a lever on one axis only, and refuses to let it become a general override. If tool policy denies Exec tool outright, elevation cannot bring it back, because the two answer different questions and the more restrictive one wins. If the authenticated session creator's operator role required a sandbox, elevation cannot run commands on the Gateway or a node at all, which keeps an operator decision above a chat directive. Host selection is treated the same way, so an automatic target is not converted into a free choice of machine. Keeping these gates separate is what makes the composition predictable, and the documentation has a page on how the three of them interact at the moment of a tool call, which is worth reading once in full (How the three gates compose). The related exec directive is a different lever again, adjusting per session exec defaults for authorised senders without requiring elevation at all. Taken together, the rules mean that turning elevation on widens exactly one thing and leaves every other boundary where it was.

On Diali

On Diali each customer runs their own assistant, and the runtime configuration for Hosted OpenClaw on Diali is generated from the dashboard and replaced at each release. If you want to see where the boundaries sit before you widen any of them, start with our Diali security page.

• Elevated changes nothing unless the agent is actually sandboxed.
• Every gate must pass: global, per agent, and the allowlist for that channel.
• Only the full level skips approvals, and only when policy is already permissive.