openclaw - 💡(How to fix) Fix Elevation gate evaluates `channel: (unknown)` for exec calls; `tools.elevated.allowFrom.<channel>` never matches

Summary

Elevation gating via tools.elevated.allowFrom.<channel> (e.g. allowFrom.telegram) never grants elevation for exec commands originating in that channel. openclaw sandbox explain shows the runtime evaluates the request with channel: (unknown) instead of the actual channel (e.g. telegram), so the configured channel allow-list never matches.

Environment

• OpenClaw: 2026.5.6 (also reproduced on 2026.4.25)
• OS: Windows 10/11 x64 (build 26200)
• Node: v24.15.0
• Channel: telegram (direct chat)
• Surface/session id: agent:main:telegram:direct:<chat_id>

Config (relevant excerpt of ~/.openclaw/openclaw.json)

{
  "tools": {
    "elevated": {
      "enabled": true,
      "allowFrom": {
        "telegram": ["<chat_id>"]
      }
    }
  }
}

Repro

1. Set the config above; restart gateway (this gate reportedly does not hot-reload — also worth confirming).
2. From the configured Telegram chat, ask the agent to run an elevated exec command.
3. Run openclaw sandbox explain --session agent:main:telegram:direct:<chat_id>.

Expected

Elevated: enabled: true, channel: telegram, allowedByConfig: true and the elevated command runs.

Actual

Elevated: enabled: true, channel: (unknown), allowedByConfig: false

Elevation is denied even though allowFrom.telegram is configured for this exact chat. Workaround is to elevate at the keyboard (admin PowerShell on the host).

Suspected cause

Channel context isn't propagated to the elevation gate matcher when the request flows through the standard exec runtime. Likely a one-line fix where the request's resolved channel is passed alongside the session id.

Impact

Channel-based elevation allow-lists are effectively non-functional. Forces operators to either disable elevation entirely or grant it more broadly than intended.