Summary

On OpenClaw 2026.3.7, elevated exec works in the main Telegram direct session but fails in a freshly spawned subagent with the enabled gate error, even when elevated is explicitly enabled globally and per-agent.

This appears to be another manifestation/regression of the bashElevated propagation bug family around nested / agentCommand / subagent paths.

Environment

• OpenClaw: 2026.3.7
• Install: npm global
• OS: Ubuntu 24.04.4 LTS
• Kernel: 6.8.0-101-generic
• Arch: x86_64
• Node: v22.22.0
• Channel: Telegram direct session
• Model: openai-codex/gpt-5.4

Minimal config (redacted)

{
  "agents": {
    "defaults": {
      "model": { "primary": "openai-codex/gpt-5.4" }
    },
    "list": [
      {
        "id": "main",
        "tools": {
          "profile": "full",
          "elevated": {
            "enabled": true,
            "allowFrom": {
              "telegram": ["<owner-id>"]
            }
          }
        }
      }
    ]
  },
  "tools": {
    "profile": "full",
    "elevated": {
      "enabled": true,
      "allowFrom": {
        "telegram": ["<owner-id>"]
      }
    },
    "exec": {
      "security": "full",
      "ask": "off"
    }
  }
}

Repro steps

1. Configure elevated exec as shown above.
2. Restart the gateway.
3. From the main Telegram direct session, run an elevated exec call.
   • Result: works.
4. From that same main session, spawn a fresh subagent (sessions_spawn, runtime=subagent).
5. In the fresh subagent, run:
   • plain exec: whoami
   • elevated exec: systemctl --version | head -1
6. Observe that plain exec works, but elevated exec fails.

Expected behavior

If elevated exec is enabled globally and per-agent, and the parent Telegram session is already allowed, a spawned subagent should resolve equivalent elevated state for that execution path, or at least fail for a more specific reason than enabled=false.

Actual behavior

Main session elevated exec succeeds, but the subagent fails immediately with:

elevated is not available right now (runtime=direct).
Failing gates: enabled (tools.elevated.enabled / agents.list[].tools.elevated.enabled)
Context: provider=telegram session=agent:main:subagent:<uuid>
Fix-it keys:
- tools.elevated.enabled
- tools.elevated.allowFrom.<provider>
- agents.list[].tools.elevated.enabled
- agents.list[].tools.elevated.allowFrom.<provider>

A representative successful subagent verification result in the same install was:

• plain exec ok: albi
• elevated exec fail: elevated is not available right now (runtime=direct)...

Why this does not look like local corruption

• The same install/config allows elevated exec in the main Telegram direct session.
• tools.elevated.enabled and agents.list[].tools.elevated.enabled are explicitly set to true.
• The failure reproduces in a fresh isolated OpenClaw 2026.3.7 environment with minimal config (same failure class: elevated denied on runtime=direct despite enabled config).
• The isolated repro was created separately from the live install and did not rely on the live state dir.
• This matches existing upstream bug history around missing / mis-propagated bashElevated in nested paths.

Related upstream issues / PRs

• Elevated permissions not resolved in agentCommand path (sessions_spawn, sessions_send, sub-agents) #18834 — Elevated permissions not resolved in agentCommand path (sessions_spawn, sessions_send, sub-agents)
• Elevated exec fails in cron and sessions_send (nested) runs despite correct config #18748 — Elevated exec fails in cron and nested runs despite correct config
• Isolated cron agentTurn sessions missing bashElevated — elevated exec always denied #30379 — Isolated cron agent turns missing bashElevated
• [Bug]: Telegram direct session cannot use elevated exec (channel: unknown, allowedByConfig: false) #38455 — Telegram direct session cannot use elevated exec (channel / elevated resolution bug)
• PR fix: pass bashElevated to runEmbeddedPiAgent in cron and agent command paths #27119 — fix: pass bashElevated to runEmbeddedPiAgent in cron and agent command paths
• PR fix(cron): wire bashElevated into isolated agentTurn runs #30425 — fix(cron): wire bashElevated into isolated agentTurn runs

Impact

This blocks a practical workflow where:

• the main Telegram session can orchestrate tasks,
• subagents can do normal work,
• but any elevated/system step delegated to a subagent fails immediately.

So the current safe operational workaround is to keep elevated/system commands in the main session only, which defeats part of the point of subagent delegation.

Suggested fix direction

Please re-audit all live agentCommand / subagent / nested execution paths to ensure bashElevated is resolved and propagated consistently, not only cron and some agent paths.

Defense-in-depth would also help:

• if defaults.elevated is missing/false in a nested runtime, the exec tool could re-resolve elevated state from live config + current session/provider context before failing the enabled gate.

Additional note

If helpful, I can provide a smaller repro transcript, but I’m intentionally not including any sensitive config, tokens, or personal identifiers here.