Summary

• Problem: elevated exec approval follow-up runs could lose trusted elevated defaults, so a second elevated command in the same follow-up reported elevated as unavailable instead of requesting approval.
• Why it matters: users still hit the elevated exec flap after fix(exec): preserve turnSourceChannel as messageProvider in approval followup runs #74666 when follow-up work needs another elevated command.
• What changed: preserve elevated defaults through a short-lived, session-scoped internal follow-up token and forward them into embedded agent execution.
• What did NOT change (scope boundary): no public agent schema field, no approval policy changes, no new dependencies.

Change Type

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes Elevated exec still flaps after PR #74666 (v2026.4.29) #75832
• Related fix(exec): preserve turnSourceChannel as messageProvider in approval followup runs #74666
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: Approved elevated exec follow-up runs keep trusted elevated defaults, so a later same-turn elevated exec can request a fresh approval instead of failing as unavailable.
• Real environment tested: Local source checkout /root/74/openclaw on branch fix/issue-75832-elevated-followup, commit 47b4c76679, Node v24.11.0, using production OpenClaw source modules through node --import tsx.
• Exact steps or command run after this patch: PATH=/tmp/node-v24.11.0-linux-x64/bin:$PATH node --import tsx --input-type=module -e "import { buildExecApprovalFollowupIdempotencyKey, consumeExecApprovalFollowupElevatedDefaultsFromIdempotencyKey, registerExecApprovalFollowupElevatedDefaults, resetExecApprovalFollowupElevatedDefaultsForTests } from \"./src/agents/bash-tools.exec-approval-followup-state.ts\"; /* register same-session elevated defaults, consume wrong session, consume same session, try reuse */"
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output):

OpenClaw issue #75832 local runtime proof
commit=47b4c76679
session=agent:main:telegram:direct:redacted-owner
idempotency_key_has_internal_elevated_token=true
wrong_session_consumed=false
same_session_restored={"enabled":true,"allowed":true,"defaultLevel":"on","fullAccessAvailable":false,"fullAccessBlockedReason":"host-policy"}
reused_token_consumed=false
after_fix_result=same-session exec approval follow-up restores trusted elevated defaults; the next elevated exec can request fresh approval instead of reporting runtime=sandboxed unavailable

• Observed result after fix: The internal follow-up idempotency key carried the elevated token, a wrong-session consume did not consume it, the same-session consume restored the trusted elevated defaults, and token reuse failed. That proves the follow-up state transfer no longer drops elevated availability before the next elevated exec.
• What was not tested: Live Telegram or Discord approval UI flow and a real OS elevated command on a host; this local proof exercises the OpenClaw runtime state-transfer path without external channel credentials.
• Before evidence (optional but encouraged): Issue Elevated exec still flaps after PR #74666 (v2026.4.29) #75832 reported that after approving an elevated exec follow-up, a later elevated command in the same follow-up hit elevated is not available right now (runtime=sandboxed) instead of requesting a fresh approval.

Root Cause

• Root cause: exec approval follow-up dispatch kept routing context but dropped bashElevated, so later elevated exec calls failed the elevated-defaults gate.
• Missing detection / guardrail: no regression test verified trusted elevated defaults survived into the follow-up embedded run.
• Contributing context (if known): fix(exec): preserve turnSourceChannel as messageProvider in approval followup runs #74666 fixed provider/channel context but not the elevated-defaults state.

Regression Test Plan

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/agents/bash-tools.exec-approval-followup.test.ts, src/agents/bash-tools.exec-host-shared.test.ts, src/agents/command/attempt-execution.cli.test.ts, src/gateway/server-methods/agent.test.ts
• Scenario the test should lock in: valid follow-up tokens restore elevated defaults; forged tokens do not; wrong-session tokens do not consume valid state; embedded runs receive trusted defaults.
• Why this is the smallest reliable guardrail: it covers the exact follow-up state transfer without requiring a live channel or real elevated command.
• Existing test that already covers this (if any): none.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

Approved elevated exec follow-ups can request approval for subsequent elevated commands instead of reporting elevated as unavailable.

Diagram

Before:
approved exec -> follow-up agent run -> bashElevated missing -> elevated unavailable

After:
approved exec -> internal token -> gateway consumes token -> embedded run has bashElevated -> next elevated command can request approval

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (Yes)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation: the command execution surface only preserves already-authorized elevated availability across the same follow-up session. The token is random, short-lived, session-scoped, one-use, internal-only, and does not carry an approval decision forward; subsequent elevated commands still go through approval policy.

Repro + Verification

Environment

• OS: Linux local checkout
• Runtime/container: Node v24.11.0 source runtime through node --import tsx
• Model/provider: N/A for local state-transfer proof
• Integration/channel (if any): Telegram-shaped redacted session key for session matching; no live channel credentials used
• Relevant config (redacted): session-scoped elevated defaults { enabled: true, allowed: true, defaultLevel: "on" }

Steps

1. Register follow-up elevated defaults for agent:main:telegram:direct:redacted-owner.
2. Build the internal exec approval follow-up idempotency key.
3. Attempt consumption from a different session.
4. Consume from the matching session.
5. Attempt token reuse.

Expected

• Wrong-session consume fails without consuming the token.
• Same-session consume restores elevated defaults.
• Reuse fails because the token is one-use.

Actual

• Matches expected output in the Real behavior proof section.