Elevated Mode for Sandboxed Agents

When an agent operates within a sandbox, its exec calls stay inside that sandbox environment. Elevated mode allows the agent to escape the sandbox and execute commands on the host instead, with configurable approval requirements.

Info

Elevated mode only affects behavior when the agent is sandboxed. For agents that are not sandboxed, exec already runs on the host directly.

Directives

Use slash commands to control elevated mode on a per-session basis:

Directive	What it does
`/elevated on`	Execute outside the sandbox on the configured host path, keeping approval checks in place
`/elevated ask`	Identical to `on` (shortcut)
`/elevated full`	Run outside the sandbox on the configured host path, skipping approvals when the mode/host approval policy is already permissive
`/elevated off`	Revert to sandbox-restricted execution

Also accessible as /elev on|off|ask|full.

Send /elevated without any argument to display the current level.

How it works

Check availability

Elevated must be enabled in the configuration, and the sender must appear on the allowlist:

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

Set the level

Send a message containing only the directive to set the session default:

/elevated full

Alternatively, use it inline (applies only to that single message):

/elevated on run the deployment script

Commands run outside the sandbox

When elevated is active, exec calls escape the sandbox. The default effective host is gateway, or node when the configured or session exec target is node. In full mode, exec approvals are bypassed when the resolved exec mode or host approval policy is already fully permissive (security full, ask off). Otherwise, the standard approval policy applies. In on or ask mode, configured approval rules always take effect.

Resolution order

Inline directive on the message (applies only to that message)
Session override (set by sending a directive-only message)
Global default (agents.defaults.elevatedDefault in config)

Availability and allowlists

Global gate: tools.elevated.enabled (must be true)
Sender allowlist: tools.elevated.allowFrom with per-channel lists
Per-agent gate: agents.entries.*.tools.elevated.enabled (can only add restrictions; both the global and per-agent gate must be true)
Per-agent allowlist: agents.entries.*.tools.elevated.allowFrom (sender must match both global and per-agent)
Channel-provided fallback allowlist: channel plugins can optionally supply a fallback allowlist through an SDK adapter hook, used when tools.elevated.allowFrom.<provider> is not configured. No bundled channel currently implements this hook, so in practice every provider needs an explicit tools.elevated.allowFrom.<provider> entry today.
All gates must pass; otherwise elevated is treated as unavailable

Allowlist entry formats:

Prefix	Matches
(none)	Sender ID, E.164, or From field
`name:`	Sender display name
`username:`	Sender username
`tag:`	Sender tag
`id:`, `from:`, `e164:`	Explicit identity targeting

What elevated does not control

Tool policy: if exec is denied by tool policy, elevated cannot override that.
Host selection policy: elevated does not turn auto into a free cross-host override. It follows the configured or session exec target rules, selecting node only when the target is already node.
Separate from /exec: the /exec directive adjusts per-session exec defaults (host, security, ask, node) for authorized senders and does not require elevated mode.

Note

The bash chat command (! prefix; /bash alias) is a separate gate that requires tools.elevated to be enabled in addition to its own tools.bash.enabled flag. Disabling elevated also locks ! shell commands out.

Exec tool, Shell command execution from the agent.
Exec approvals, Approval and allowlist system for exec.
Sandboxing, Gateway-level sandbox configuration.
Sandbox vs Tool Policy vs Elevated, How the three gates compose during a tool call.