Skip to content

Elevated exec fails in cron and sessions_send (nested) runs despite correct config #18748

Description

@cbraneclaw

Description

Elevated exec is blocked for sandboxed agents when triggered via cron jobs or sessions_send (cross-agent messaging), even though the config correctly sets tools.elevated.enabled: true both globally and per-agent, and allowFrom includes the relevant providers.

Environment

  • OpenClaw version: 2026.2.15
  • OS: macOS 15.3.1 (arm64)
  • Node: v25.5.0
  • Multi-agent setup with 6 agents, sandbox mode "all", Docker containers

Config (relevant parts)

{
  "tools": {
    "elevated": {
      "enabled": true,
      "allowFrom": {
        "telegram": ["<user_id>"],
        "webchat": ["*"],
        "*": ["*"]
      }
    }
  },
  "agents": {
    "list": [
      {
        "id": "scout",
        "sandbox": { "mode": "all" },
        "tools": {
          "elevated": { "enabled": true }
        }
      }
    ]
  }
}

Steps to Reproduce

  1. Set up a multi-agent system with sandbox mode "all" for agents
  2. Configure tools.elevated.enabled: true globally and per-agent
  3. Set tools.elevated.allowFrom with wildcards ("*": ["*"])
  4. Set agents.defaults.elevatedDefault: "full"
  5. Try any of these:
    • Cron job fires for an agent -> agent tries exec(elevated=true) -> fails
    • Main agent uses sessions_send to message another agent -> target agent tries exec(elevated=true) -> fails
    • Direct Telegram message from allowed user -> agent tries exec(elevated=true) -> works

Observed Behavior

Error message:

elevated is not available right now (runtime=sandboxed).
Failing gates: enabled (tools.elevated.enabled / agents.list[].tools.elevated.enabled)
Context: provider=webchat session=agent:scout:telegram:scout:direct:<user_id>

The error says the "enabled" gate is failing, but the config has enabled: true in both global and per-agent settings.

For cron sessions:

Context: provider=telegram session=agent:scout:cron:<cron_id>

Expected Behavior

Elevated exec should work in all session types (cron, sessions_send/nested, direct) when the config explicitly enables it. The docs state: "Elevated exec runs on the host and bypasses sandboxing."

Source Code Analysis

In reply-B1AnbNl6.js, the check is:

const elevatedDefaults = defaults?.elevated;
const elevatedAllowed = Boolean(elevatedDefaults?.enabled && elevatedDefaults.allowed);

The elevatedDefaults object appears to not resolve correctly for nested/cron session contexts, causing enabled to evaluate as falsy even when the config explicitly sets it to true.

Workaround

Unsandboxing agents that need elevated access (sandbox.mode: "off"). This works because unsandboxed agents run directly on the host and do not need elevated exec. However, this reduces security isolation.

Impact

This effectively prevents sandboxed agents from using any host-only CLI tools (like gog for Google Workspace, remindctl for Apple Reminders, memo for Apple Notes) during automated/scheduled operations, which is a core use case for multi-agent systems.

Metadata

Metadata

Assignees

No one assigned

    Labels

    staleMarked as stale due to inactivity

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions