OpenClaw Elevated Mode: Break Glass Without Making It the Default

Every serious agent operator eventually hits the same question: can I let the agent touch the real machine when production is stuck?

For normal work, I want a sandbox. I want builds, file edits, logs, and scratch commands to stay inside a boundary that is easy to reason about. But there are recovery jobs that do not fit cleanly inside that boundary: restarting a local service, checking a Gateway process, running a deploy command from the host environment, or targeting a paired node that owns the device context.

OpenClaw elevated mode is the break-glass lane for that moment. It lets a sandboxed agent run exec outside the sandbox on the configured host path. That can mean the Gateway host by default, or a paired node when the configured or session exec target is node. The important part is that elevated mode is not a general productivity preference. It is a controlled exception for work that genuinely needs host or node authority.

The buyer-intent version is simple. If you are evaluating whether an agent can handle maintenance, deploys, and recovery work without becoming a liability, elevated mode is one of the controls you need to understand before you trust the system.

What elevated mode changes

The official docs are narrow on purpose. When an agent runs inside a sandbox, normal exec commands are confined to the sandbox environment. Elevated mode lets that sandboxed agent break out and run commands outside the sandbox, with approval gates depending on the selected level. If the agent is already unsandboxed, elevated mode does not add a new superpower, because exec already runs on the host.

That distinction matters. Elevated mode is about escaping a sandboxed execution boundary. It is not a replacement for tool policy. It is not a separate authorization system. It does not make a denied exec tool available. It does not turn host=auto into permission to run anywhere. It uses the configured or session exec target rules and chooses node only when the target is already node.

In practice, I treat elevated mode as a workflow state. The operator decides that a specific conversation, or a specific message, needs host-level command access. Then the session either keeps approvals in place or enters full break-glass mode for a short, supervised task.

The four directives

Elevated mode is controlled with slash directives. These can be sent as directive-only messages to set the session default, or used inline so the setting applies only to that message.

/elevated on
/elevated ask
/elevated full
/elevated off
/elevated on run the deployment script

/elevated on and /elevated ask are the sane default for break-glass work: leave the sandbox, but keep configured exec approvals. /elevated off returns execution to the sandbox. /elevated full leaves the sandbox and skips exec approvals, which is why I reserve it for incident-style tasks where a human is watching the command lane closely.

You can also use the shorter /elev on|off|ask|full forms. Sending /elevated with no argument shows the current level, which is a small habit that prevents many "why did this command run there?" mistakes.

Availability is allowlisted

Elevated mode has to be enabled in config and the sender has to match the allowlist. The docs show a global gate under tools.elevated.enabled, with per-channel allowFrom lists:

{
  tools: {
    elevated: {
      enabled: true,
      allowFrom: {
        discord: ["user-id-123"],
        whatsapp: ["[phone]"]
      }
    }
  }
}

There are also per-agent gates under agents.list[].tools.elevated.enabled and per-agent allowlists under agents.list[].tools.elevated.allowFrom. The per-agent gate can only further restrict access. A sender has to satisfy both global and per-agent allowlists when both exist. If tools.elevated.allowFrom.discord is omitted, OpenClaw can fall back to channels.discord.allowFrom.

Allowlist entries can match sender IDs, E.164 numbers, From fields, display names, usernames, tags, or explicit prefixed forms such as id:, from:, and e164:. I prefer explicit identity-style entries for production operations because they age better than display names.

Need agents that can recover production without getting unlimited shell access?

ClawKit gives you the operating patterns for sandboxing, elevated work, command approvals, memory, and deploy follow-through. Get ClawKit for $9.99.

How it resolves in a real session

Elevated mode resolves in a predictable order. An inline directive on the current message wins first. A session override set by a directive-only message comes next. The global default, agents.defaults.elevatedDefault, is the fallback.

That order is useful because it lets you keep the daily session conservative while still making one command run outside the sandbox. I would rather write an explicit inline directive for a one-off recovery command than leave an entire session in an elevated state and forget about it.

The same idea applies to /exec. The /exec directive sets per-session defaults for host, security, ask, and node. It updates session state only; it does not write persistent config.

/exec host=auto security=allowlist ask=on-miss node=mac-1

The docs are clear that /exec is honored only for authorized senders through channel allowlists, pairing, and access-group checks. Use it to steer one conversation. Do not use it as your whole security model.

Elevated mode still depends on exec policy

exec is a mutating shell surface. Current docs state plainly that commands can create, edit, or delete files wherever the selected host or sandbox filesystem permits. Disabling file-write tools such as write, edit, or apply_patch does not make exec read-only.

That is why elevated mode should sit on top of a real exec policy. A reasonable baseline keeps host routing explicit, keeps approval prompts available, and hardens inline interpreter eval before broad runtimes are trusted:

{
  tools: {
    exec: {
      host: "auto",
      mode: "allowlist",
      ask: "on-miss",
      strictInlineEval: true
    }
  }
}

The exact shape depends on your workspace, but the principle does not. Use allowlist or a stricter mode for host work. Keep ask="on-miss" or ask="always" where a human should review surprises. Turn on strictInlineEval before letting interpreters such as python, node, ruby, perl, php, lua, or osascript become durable trust paths.

If you need a deeper policy model, I would pair this post with the existing OpenClaw exec approvals guide and the safe bins guide. Elevated mode decides when a sandboxed agent can reach outside. Exec approvals and safe bins decide what host commands are acceptable once it does.

Why full mode should stay rare

The docs describe full mode as the no-approval path. In the exec approval docs, no-approval host exec requires both policy layers to be open: requested exec policy in OpenClaw config and host-local approvals policy in ~/.openclaw/exec-approvals.json. The docs call that YOLO mode, and the defaults can be permissive unless you tighten them explicitly.

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off
openclaw gateway restart

That snippet is not my recommended daily posture. It is a useful example because it shows what has to be true for persistent gateway-host no-prompt execution. If you choose that mode, you are accepting that host commands run without approval prompts. For revenue and production operations, I want that to be an explicit, temporary decision, not the background condition of the whole agent.

The safer operating habit is to make the agent ask by default and make the human choose when to bypass. /elevated full is appropriate when the system is already down, the command needs host authority now, and the operator can inspect the plan before and after. It is not appropriate because approvals feel annoying during normal content, build, or deploy loops.

A practical break-glass checklist

When I am deciding whether a command deserves elevated mode, I use a short checklist:

1. Can the task finish inside the sandbox? If yes, do not elevate.
2. Does the task need the Gateway host, or a specific paired node? Set the target intentionally.
3. Is the sender allowed to request elevated access? Check the channel and per-agent allowlists.
4. Can /elevated on with approvals finish the job? Prefer that over /elevated full.
5. Is the command mutating production state? Read the exact command and expected output before running.
6. After the task, turn elevated mode off or verify that the next message is no longer elevated.

This is the difference between authority and ambient authority. The agent may need host power for one job. It does not need to keep that power while you switch topics, debug a page title, or ask it to summarize logs.

Where elevated mode fits in the operating stack

OpenClaw has several overlapping boundaries: sandboxing, tool policy, exec approvals, node binding, safe bins, and elevated mode. They are not competing features. They answer different questions.

Sandboxing answers where normal command work can happen. Tool policy answers whether a tool is allowed at all. Exec approvals answer which host commands can run and whether a prompt is required. Node binding answers which physical or companion host receives node-targeted execution. Elevated mode answers whether this sandboxed agent is allowed to leave the sandbox for the current session or message.

If you are running agents as operators, that composition is the product. It is what lets you move from toy automation to production workflows without pretending the shell is harmless. You can let the agent build, check, deploy, recover, and inspect real systems while still leaving a clear trail of who allowed the host boundary to open.

My rule is straightforward: make the default boring, make the exception explicit, and make the return path just as easy as the escape hatch.

Want the complete guide? Get ClawKit — $9.99

Originally published at https://www.openclawplaybook.ai/blog/openclaw-elevated-mode-break-glass/

Get The OpenClaw Playbook → https://www.openclawplaybook.ai?utm_source=devto&utm_medium=article&utm_campaign=parasite-seo