Neura Market Logo

Elevated Mode: Run Host Commands from a Sandboxed Agent

Learn how Elevated mode lets a sandboxed agent execute commands on the host outside the sandbox. This page covers directives, approval gates, and when to use each mode.

Read this when

  • Adjusting elevated mode defaults, allowlists, or slash command behavior
  • Understanding how sandboxed agents can access the host

When an agent operates inside a sandbox, its exec commands are restricted to that sandbox environment. Elevated mode allows the agent to escape the sandbox and run commands on the host instead, with configurable approval gates.

Info

Elevated mode only takes effect when the agent is sandboxed. For unsandboxed agents, exec already runs on the host.

Directives

Control elevated mode per session using slash commands:

DirectiveWhat it does
/elevated onRun outside the sandbox on the configured host path, keep approvals
/elevated askSame as on (alias)
/elevated fullRun outside the sandbox on the configured host path and skip approvals when the mode/host approval policy is already permissive
/elevated offReturn 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 full

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

/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:

PrefixMatches
(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.
  • 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.

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 locks ! shell commands out as well.