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
- Set up a multi-agent system with sandbox mode "all" for agents
- Configure
tools.elevated.enabled: true globally and per-agent
- Set
tools.elevated.allowFrom with wildcards ("*": ["*"])
- Set
agents.defaults.elevatedDefault: "full"
- 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.
Description
Elevated exec is blocked for sandboxed agents when triggered via cron jobs or
sessions_send(cross-agent messaging), even though the config correctly setstools.elevated.enabled: trueboth globally and per-agent, andallowFromincludes the relevant providers.Environment
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
tools.elevated.enabled: trueglobally and per-agenttools.elevated.allowFromwith wildcards ("*": ["*"])agents.defaults.elevatedDefault: "full"exec(elevated=true)-> failssessions_sendto message another agent -> target agent triesexec(elevated=true)-> failsexec(elevated=true)-> worksObserved Behavior
Error message:
The error says the "enabled" gate is failing, but the config has
enabled: truein both global and per-agent settings.For cron sessions:
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:The
elevatedDefaultsobject appears to not resolve correctly for nested/cron session contexts, causingenabledto evaluate as falsy even when the config explicitly sets it totrue.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
gogfor Google Workspace,remindctlfor Apple Reminders,memofor Apple Notes) during automated/scheduled operations, which is a core use case for multi-agent systems.