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:

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

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

    text
    /elevated full

    Or use it inline (applies to that message only):

    text
    /elevated on run the deployment script
  • Commands 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

    1. Inline directive on the message (applies only to that message)
    2. Session override (set by sending a directive-only message)
    3. 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 further restrict; both the global and per-agent gate must be true)
    • 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 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 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 auto into a free cross-host override. It uses the configured/session exec target rules, choosing 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.
    Was this useful?
    On this page

    On this page