When OpenClaw elevated execution is justified, and what to record

Published June 13, 2026 · OpenClawBlog Team. Sources checked September 13, 2026.

A sandboxed OpenClaw agent eventually reaches a task it cannot finish inside its current boundary. The missing piece may be a host service, a paired node, a system-level file, or a command that exists only outside the sandbox. The tempting answer is /elevated on or an exec request with elevated: true. The harder question is whether the exception is necessary, and whether anybody can later explain exactly what it allowed.

The current OpenClaw security model separates sandbox location, tool policy, and elevated execution. That distinction gives operators a useful starting point. Elevated mode changes the execution path for exec; it does not create a new class of safe tools or turn a shared Gateway into a tenant boundary.

The behavior described here comes from OpenClaw documentation checked on September 13, 2026. The review rubric, record template, and acceptance checks are editorial proposals. No command in this article was run against a live Gateway.

The short answer

Elevated execution is justified when all of the following are true:

The task cannot be completed inside the current sandbox with the required workspace and tools.
The host or node that must run the command is known before approval.
The command, working directory, relevant inputs, and expected side effects can be stated precisely.
A trusted operator can review the request and approve one bounded execution.
The action has a rollback or containment plan that is proportionate to what it can change.

If one of those answers is missing, treat the request as incomplete. A request that says “run this on the host because the sandbox is annoying” is not a security decision. It is a request to widen authority without describing the new boundary.

I would also add a sixth condition for shared deployments: the people who can reach the Gateway must already belong to the same trust cell. OpenClaw's trust model says approvals reduce accidental execution risk, but they are not per-user authentication or a read-only filesystem policy. For mutually adversarial users, the documented answer is a separate Gateway and, preferably, a separate operating-system user or host.

What changes when elevated exec is used

OpenClaw uses three related controls, and each answers a different question:

Control	Question it answers	What it does not answer
Sandbox	Where does the tool run, and which workspace boundary does it see?	Whether the agent may call a tool at all.
Tool policy	Which tools are available or denied to this agent and provider?	Whether an allowed `exec` command is harmless.
Elevated mode	May the `exec` call leave the ordinary sandbox?	Whether other tools become available or whether a denied `exec` tool becomes allowed.

The sandbox and tool-policy reference describes elevated as an exec-only escape path. It uses the configured Gateway path by default, or a node when the exec target is configured for a node. A creator role that requires a sandbox cannot be bypassed through elevated mode, and elevated mode does not override a tool allow or deny rule.

The configuration gates are also separate. OpenClaw documents tools.elevated.enabled and provider-specific tools.elevated.allowFrom. A per-agent override can restrict those settings further. Session directives such as /elevated on, /elevated off, /elevated ask, and /elevated full change session state or the current request; they do not replace the underlying tool policy. The tool-policy configuration reference shows these gates and their relationship.

There is a second source of confusion: host: auto is a routing choice, not a promise that the command will stay inside a sandbox. The exec documentation says that auto resolves to a sandbox when a sandbox runtime is active and to the Gateway otherwise. If the session is already running directly on a host, elevated mode may be effectively a no-op, although ordinary approval rules can still apply.

Finally, exec remains a mutating shell surface. Denying OpenClaw's separate write, edit, or apply_patch tools does not make an allowed shell command read-only. A command can still create, edit, or delete files wherever the selected host or sandbox permissions allow it.

Decide whether elevation is the right fix

Start with the smallest boundary that can complete the job. The following is a decision guide, not a replacement for inspecting the effective configuration.

Observed need	First choice	Reason to stop and review again
The task reads or writes files already inside the permitted workspace.	Keep the agent sandboxed and adjust only the workspace access if necessary.	The requested path is outside the workspace or contains credentials.
A command or library is missing from the sandbox image.	Update the image, install the dependency in the sandbox, or use a dedicated build environment.	The proposed fix requires access to a host package manager, system directory, or shared daemon.
The task must reach a host-only service or a paired device.	Consider one elevated exec request with an explicit target and approval.	The host, node, OS account, or service owner is not known.
The task sends a message, publishes data, or changes an external account.	Put an approval gate around that side effect as well.	The plan assumes host exec approval will automatically cover a first-class plugin or messaging tool.
Untrusted or mixed-trust people can trigger the workflow.	Separate the trust boundary before adding host authority.	The design depends on a shared Gateway, shared credentials, or labels to provide isolation.

The third row is the usual case for justified elevation: the task genuinely needs a host capability. Even there, elevation should be a narrow exception, not a permanent operating mode. If the same host operation happens every day, redesign the operation as a small, reviewable service or allowlisted command rather than asking a general-purpose agent to run with broad host authority forever.

Inspect the effective state before approval

Do not review only the file that someone remembers editing. OpenClaw's documented inspection commands expose different layers of state:

openclaw sandbox explain --json
openclaw approvals get --gateway --json
openclaw exec-policy show

openclaw sandbox explain --json can show the effective sandbox mode, scope, workspace access, tool allow and deny results, and elevated gates. openclaw approvals get shows requested policy, host policy sources, and the effective result for the selected execution host. openclaw exec-policy show gives the local merged view. The exec approvals documentation warns that per-session /exec overrides are not included in the local policy view, so inspect the relevant session separately.

For a node, identify the node explicitly and inspect its policy on that execution host. A paired node is not just another label in the Gateway UI. It is an additional host where the command may run. The record should name the node, its owner, and the reason that node is the intended target.

Keep the inspection output in the review bundle after removing secrets. Record the command, timestamp, selected agent, selected host, and exit result. A redacted field should be marked as redacted, not silently treated as empty. If a value was not checked, write “not checked.”

Build the review record before the prompt

Native approvals provide useful execution evidence, but they do not automatically capture the business reason for an exception or the rollback decision. I would create a short record before approving any elevated request. It can live beside the change ticket, incident note, or task artifact. Do not put tokens, cookies, private keys, or full secret-bearing environment values in it.

Request identity. Give the request a unique ID and record the time, agent, session, channel, sender, and intended approver. The record should make it possible to connect the human decision to the command that later ran.
Reason for elevation. Describe the task in one sentence. Add the failed or insufficient sandbox condition, such as a host-only socket or a device operation that the sandbox cannot reach. Record the safer alternatives considered and why they were not enough.
Effective boundary. Capture the OpenClaw version or source revision, config and state profile, sandbox explanation, effective tool policy, elevated enablement, sender allowlist, execution host, node identity, OS account, and working directory.
Command plan. Preserve the exact command or argument vector shown to the approver. Include the executable path, arguments, working directory, relevant file operands, requested environment names, and expected network destinations. Store secret values elsewhere under the normal secret-management process.
Expected effect. Say what may change, what must not change, whether data leaves the host, and which accounts or services are touched. “Maintenance” is too vague if the command can delete a directory or restart a production service.
Approval decision. Record allow once, deny, or a deliberately scoped standing grant; the approver identity; the approval ID; the time; and the expiry or revocation condition. If the reviewer or UI changes the command, start a new record.
Recovery and acceptance. Name the backup, rollback command or owner, stop condition, expected exit result, post-run checks, and evidence location. The action is not complete because the process returned zero.

Here is a compact template. Its paths and command are placeholders, not a live test:

request_id: EXAMPLE-001
purpose: <host-only maintenance task>
reason_sandbox_insufficient: <documented boundary or failed prerequisite>
agent_session: <agent id and session key>
requester_approver: <authenticated sender and approver>
target: <gateway or node, host, OS account>
working_directory: <absolute path>
command_argv: [<absolute executable>, <static arguments>]
inputs: <paths or artifact hashes, no secret values>
expected_effects: <files, service, network, and account impact>
policy_snapshot: sandbox explain --json; approvals get --gateway --json
decision: allow-once
approval_id: <native approval id>
rollback: <backup or owner and stop condition>
post_check: <expected state and evidence path>

The exact fields are a proposed operator record, not a claim that OpenClaw writes all of them for you. The reason for keeping the distinction is practical: native approval evidence can show that a command was authorized, while the surrounding record explains why that authority was acceptable for this task.

Match the approval behavior to the risk

OpenClaw has several execution policy choices. They are not interchangeable.

Choice	Use it when	What to write down
One-time approval	A single host action needs an exception.	Exact command, host, working directory, approval ID, approver, and result.
`ask=always`	The workflow is being introduced or every command needs a human checkpoint.	Why repeated review is required and what counts as an acceptable request.
`auto`	Eligible low- or medium-risk misses can receive a native reviewer decision, while harder cases still reach a human.	The reviewer outcome, any human escalation, and the policy version used.
Allow always or a standing grant	The operation is repeatable, narrowly bound, owned, and worth durable authorization.	Scope, command and path binding, expiry, owner, review date, and revoke path.
`full` or `/elevated full`	A short break-glass operation has been approved under a policy that explicitly permits it.	Why narrower modes failed, who accepted the larger blast radius, and when the exception closes.

The exec reference defines deny, allowlist, ask, auto, and full behavior. In auto mode, the native reviewer can return allow, deny, or ask; an allow is single-use. Reviewer failure, timeout, or an invalid response goes to human approval. That is useful for command triage, but it is not a substitute for deciding whether the task should have host authority.

For a first elevation, one-time approval is the cleanest record. The current approvals documentation presents an Allow Once decision and explains that a standing grant is a different scope. If a prompt is required but no approval surface is reachable, askFallback defaults to deny. Keep that failure closed. Changing the fallback to full merely to avoid a blocked run turns an availability problem into an authority problem.

Standing grants deserve extra care. OpenClaw documents a grant ledger that can show the automation, exact command, use count, and state. The CLI can list grants and revoke them. For automation grants, a change to the job, command, working directory, or requested environment invalidates the grant and returns the operation to review. A grant can still be too broad for the business purpose, so record the reason it exists and the person who owns its removal.

Failure paths and limits

The request is denied before it runs

Check the effective policy before trying a stronger directive. A required creator-role sandbox can reject elevation. A denied exec tool cannot be restored by /elevated. A node target can also fail because the node is not paired, connected, or eligible for execution. Treat the denial as evidence about the current boundary. Do not ask the agent to work around it with a different shell, plugin, or wrapper.

The prompt never appears

First check whether the request is actually host exec. Plugin permissions, outbound messaging, MCP calls, and browser actions may have their own approval paths. Then inspect the host policy. OpenClaw documents host approvals as local to the Gateway or node, and a no-UI request falls back according to askFallback. If the effective policy is full with approvals off, there may be no ordinary prompt to capture. Record that fact before changing policy.

The approved command changes while waiting

The approvals system binds important execution context and rechecks it before launch. The documentation describes binding for the working directory, arguments, executable identity, and some file operands. It also calls file binding best effort and does not claim to model every interpreter or runtime loader path. A changed path or unexpected wrapper should create a new review request. Sandboxing and host isolation remain the stronger controls for a serious boundary.

The command is “approved” but still too powerful

Approval is a decision about operator intent, not proof that the command is safe. An allowlisted interpreter can still load code or touch more files than the reviewer expected. An exec request can mutate files even when separate filesystem tools are denied. Use a narrower executable, static arguments, a disposable workspace, or a dedicated OS account when the action can affect valuable data.

Untrusted content changes the request

A trusted sender can paste a poisoned document, log, web page, or attachment. The prompt-injection guidance treats those contents as untrusted and recommends sandboxing sensitive tool execution, limiting high-risk tools, and keeping secrets out of prompts. The review record should say what content supplied the request and whether the command was independently checked. Approval should never mean “the model saw it, so it must be intentional.”

The Gateway is shared by people who do not share trust

OpenClaw's security pages describe one trust boundary per Gateway. Pairing, session labels, approval buttons, and per-agent policies can improve control inside that boundary, but they do not create hostile multi-tenant isolation. If one user must not access another user's credentials, files, sessions, or host authority, split the Gateway and the operating-system boundary before enabling elevation.

Revocation happens after the process starts

The approvals documentation says revocation blocks a pending launch at the next spawn boundary. It does not stop a process that already started. Add a maximum runtime, an external stop owner, and a post-run check for long or destructive operations. A revoke button is not an incident-response plan.

Close the exception after the run

The last part of the record should be written after execution, including failure. Attach the approval ID, effective target, exit status, redacted output, relevant log references, changed paths, and the result of the acceptance checks. If the command partially completed, record the partial state instead of marking it successful because the shell returned an exit code.

Return the session to its normal state with the documented control that fits the workflow. Remove a temporary allowlist entry, revoke a standing grant, disable elevated access for the agent or provider, or end the session that carried the exception. The native grant ledger should be reviewed after configuration changes, node changes, updates, and incidents. Existing grants keep the terms under which they were created unless they are revoked or expire, so changing a default does not necessarily retire old authority.

For recurring work, use the record as feedback. If the same request passes the same checks every day, make the command smaller and its inputs more stable. If the command keeps changing, keep human approval. If the action needs broad host access, move it behind a service or a separate operational job. The right outcome may be to remove elevation rather than to document it more elegantly.

Bottom line

Elevated execution is justified by a task-to-boundary mismatch. The sandbox cannot do the job, the host target is known, the command is bounded, a trusted operator can review it, and recovery is possible. Urgency, model confidence, or a failed first attempt are not enough.

The surrounding record should make the exception visible before it runs and accountable afterward: why the sandbox was insufficient, what exact authority was requested, who approved it, what could change, how it would be reversed, and what actually happened. That record will not make host execution safe by itself. It will make the remaining decision small enough to review.

Sources

Sandbox vs tool policy vs elevated: sandbox location, tool availability, elevated exec gates, and effective inspection. Accessed September 13, 2026.
Exec tool: host routing, elevated execution, mutating shell behavior, execution modes, and reviewer limits. Accessed September 13, 2026.
Exec approvals: local host enforcement, effective-policy inspection, fallback behavior, one-time decisions, standing grants, and revocation. Accessed September 13, 2026.
Configuration, tool policy: elevated enablement, sender allowlists, per-agent restriction, and session directives. Accessed September 13, 2026.
Security trust model: Gateway trust boundaries and the limits of approvals as isolation. Accessed September 13, 2026.
Prompt injection: untrusted external content, sensitive tools, sandboxing, and secret-handling guidance. Accessed September 13, 2026.