Describe the bug

When an exec command that the user previously approved completes, the system emits a completion notice that re-injects the user's original message context. This causes the agent to see the user's question a second time, leading to:

1. The agent re-responding to the already-answered question
2. Conversation flow being interrupted by the duplicate response
3. Wasted tokens and confusing chat history

Steps to reproduce

1. Agent needs to run a command requiring exec approval
2. User approves the command (e.g. via /approve)
3. Command runs asynchronously
4. Command completes and the system emits a completion notice
5. The completion notice includes the original user message as context
6. Agent sees the original question again and replies to it a second time

Expected behavior

The async completion notice should only contain the command result (success/failure/output) without re-injecting the original user message. The agent should be able to silently acknowledge the completion or provide a brief status update without re-answering the original question.

Actual behavior

The system message format is:

\
An async command the user already approved has completed.
Do not run the command again.
If the task requires more steps, continue from this result before replying to the user.
Only ask the user for help if you are actually blocked.

Exact completion details:
Exec finished (gateway id=xxx, session=xxx, code 0)

Continue the task if needed, then reply to the user in a helpful way.
\\

However, the inbound message context attached to this completion event includes the user's original question, causing the agent to think the user is asking the question again.

Impact

• Conversation quality: Agents reply to already-answered questions, cluttering the chat
• Token waste: Duplicate responses consume model tokens
• UX confusion: User sees their question answered twice
• Flow interruption: Agents lose track of the actual conversation thread

Suggested fix

The async completion system event should:

1. Only include the exec result (exit code, stdout/stderr)
2. Not re-inject the original user message as inbound context
3. Or mark the event with a flag (e.g. \completionOnly: true) so the agent knows not to reply to it unless there's an actual follow-up needed

Environment

• OpenClaw version: 2026.4.15
• Node.js: v25.9.0
• OS: Windows_NT 10.0.26200 (x64)
• Channel: webchat (Control UI)