Summary

When an exec approval is resolved via /approve <id> in a Lansenger (external channel plugin) session, the framework injects a context message ("An async command did not run…") into the session. This injected message does not carry the original channel's routing target (turnSourceTo), causing the Agent's post-approval reply to be delivered to webchat instead of back to the Lansenger DM.

Reproduction

1. Lansenger channel plugin with fully working native approval cards (approvalCapability.nativeRuntime)
2. User sends a non-whitelist command in Lansenger DM → approval card delivered
3. User sends /approve <id> allow-once in the same DM
4. Framework resolves the approval and injects a context message
5. Agent produces a reply — but it goes to webchat, not the Lansenger channel

Log evidence

21:20 → beforeDeliverPayload: approval-pending
21:20 → deliverPending: approveCard sent
21:22 → inbound.run completed (original command session ends)
21:39 → inbound: /approve command (new session)
21:40 → exec.approval.resolve
21:40 → deliverReply: "Approval allow-once submitted" → sent to Lansenger
21:43 → agent.wait 2914ms → no further outbound via Lansenger

The post-approval context injection appears at webchat, confirming the Agent produced a reply but it routed to the wrong surface.

Expected behavior

The injected approval-resolution context message should preserve the original channel's routing target (turnSourceTo, turnSourceChannel, turnSourceAccountId) so the Agent's reply is delivered back to the originating channel.

Impact

Makes the exec approval flow effectively broken for external channel plugins — the user approves the command but never sees the execution result in the channel.

Environment

• OpenClaw 2026.6.9
• External channel plugin: @lansenger-pm/openclaw-lansenger-channel
• approvals.exec.enabled: true
• Native approval route registered via registerChannelRuntimeContext + CHANNEL_APPROVAL_NATIVE_RUNTIME_CONTEXT_CAPABILITY