Summary

Elevated exec permissions drop after the first approved command completes in the same assistant turn. PR #74666 ("preserve turnSourceChannel as messageProvider in approval followup runs") was expected to fix this, but the issue persists on v2026.4.29 (a448042).

Environment

• OpenClaw version: 2026.4.29 (a448042)
• OS: Ubuntu Linux 6.8.0-110-generic (x64)
• Node: v22.22.1
• Channel: Telegram (direct chat)
• Runtime: docker/non-main (sandboxed agent)
• Elevated level: on (ask mode — requires per-command approval)

Repro Steps

1. Agent sends an elevated exec command (e.g., echo "test" with elevated: true)
2. User approves via /approve <id> allow-once
3. Command completes successfully
4. Agent sends a second elevated exec command in the same turn
5. Expected: Approval prompt appears again
6. Actual: Error returned immediately:

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

Key Observations

• The first elevated command in a turn always works (approval flow is correct)
• Subsequent elevated commands in the same turn fail with the "not available" error
• The error claims tools.elevated.enabled is the failing gate, but elevated is configured as on
• After the user sends a new message (new turn), elevated works again for one command
• This is 100% reproducible — happens every time, not intermittent
• Non-elevated exec commands work fine throughout

Workaround

Have the user send a new message between each elevated command, or ask the user to run commands manually.

Related

• PR fix(exec): preserve turnSourceChannel as messageProvider in approval followup runs #74666 — partial fix for turnSourceChannel preservation
• Original bug report filed by this deployment (elevated flapping, April 2026)