Tools
Elevated mode
When an agent runs inside a sandbox, its exec commands are confined to the sandbox environment. Elevated mode lets the agent break out of ordinary agent-configured sandboxing and run commands outside the sandbox instead, with configurable approval gates. Sessions whose creator role requires sandboxing cannot use elevated mode to escape.
Directives
Control elevated mode per-session with slash commands:
| Directive | What it does |
|---|---|
/elevated on |
Run outside the sandbox on the configured host path, keep approvals |
/elevated ask |
Same as on (alias) |
/elevated full |
Run outside the sandbox on the configured host path and skip approvals when the mode/host approval policy is already permissive |
/elevated off |
Return to sandbox-confined execution |
Also available as /elev on|off|ask|full.
Send /elevated with no argument to see the current level.
How it works
Check availability
Elevated must be enabled in config and the sender must be on the allowlist:
{ tools: { elevated: { enabled: true, allowFrom: { discord: ["user-id-123"], whatsapp: ["+15555550123"], }, }, },}Set the level
Send a directive-only message to set the session default:
/elevated fullOr use it inline (applies to that message only):
/elevated on run the deployment scriptCommands run outside the sandbox
With elevated active, exec calls leave the sandbox. The effective host is
gateway by default, or node when the configured/session exec target is
node. In full mode, exec approvals are skipped when the resolved exec
mode/host approval policy is already fully permissive (security full,
ask off); otherwise the normal approval policy still applies. In
on/ask mode, configured approval rules always apply.
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.elevatedDefaultin config)
Availability and allowlists
- Global gate:
tools.elevated.enabled(must betrue) - Sender allowlist:
tools.elevated.allowFromwith per-channel lists - Per-agent gate:
agents.entries.*.tools.elevated.enabled(can only further restrict; both the global and per-agent gate must betrue) - Per-agent allowlist:
agents.entries.*.tools.elevated.allowFrom(sender must match both global + 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 explicittools.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
execis denied by tool policy, elevated cannot override it. - Required role sandboxing: if the authenticated session creator's operator role required a sandbox, elevated mode cannot run commands on the Gateway or a node.
- Host selection policy: elevated does not turn
autointo a free cross-host override. It uses the configured/session exec target rules, choosingnodeonly when the target is alreadynode. - Separate from
/exec: the/execdirective adjusts per-session exec defaults (host, security, ask, node) for authorized senders and does not require elevated mode.
Related
Shell command execution from the agent.
Approval and allowlist system for exec.
Gateway-level sandbox configuration.
How the three gates compose during a tool call.
Per-agent sandbox and tool limits.
The reasoning budget an elevated run uses.