openclaw - 💡(How to fix) Fix WhatsApp final answer after internal continuation is not delivered

Summary

A WhatsApp-originated agent turn resumed from an internal continuation event produced a final assistant answer in the session transcript, but no WhatsApp outbound send was attempted. The user-facing result appeared only in the OpenClaw transcript/dashboard, so the WhatsApp group never received the answer.

Impact

For long WhatsApp tasks that cross auto-compaction / internal continuation / subagent completion boundaries, the agent can believe it has answered the user while the user receives nothing. This is especially risky because the transcript contains a normal final answer with stopReason: "stop", not an explicit delivery failure.

Observed timeline (sanitized from local evidence)

• Session key: a WhatsApp group session for agent atlas.
• 2026-05-12T17:35:26Z: auto-compaction occurred. The compaction summary preserved pending user-facing TODOs, including reporting a background profile task and TTS/audio findings.
• 2026-05-12T18:39:16Z: the session resumed via an internal event with user text Continue the OpenClaw runtime event. rather than a fresh WhatsApp inbound message.
• 2026-05-12T18:40:42Z: the transcript recorded an assistant final answer (textSignature.phase = "final_answer", stopReason = "stop") containing the answer that should have gone to WhatsApp.
• There was no message tool call and no WhatsApp delivery mirror / messageId for that final answer.
• Gateway log around local 15:39-15:42 showed the user's follow-up inbound and then only the later corrected explicit message tool send. No send/auto-reply line was present for the 15:40 final answer.
• The user immediately reported not receiving the audio/TTS answer in the WhatsApp group.
• 2026-05-12T18:42:25Z: sending the corrected answer with the first-class message tool succeeded and produced a WhatsApp messageId, confirming the WhatsApp channel itself was healthy.

Expected behavior

If an internal continuation resumes work that originated from a WhatsApp chat and a final answer is produced, OpenClaw should either:

1. deliver the final answer back to the original channel/session, or
2. explicitly mark it as non-deliverable and warn/notify instead of silently treating the turn as completed.

Actual behavior

The final answer was persisted in the session transcript only. No WhatsApp send was attempted, and no delivery error was surfaced.

Notes / likely area

This looks related to preserving delivery context across internal continuation events after compaction or child-task completion. The continuation event (Continue the OpenClaw runtime event.) may not carry the original WhatsApp delivery context, so the final answer is treated as a private/internal response even though the active session is a WhatsApp group session.

Suggested guardrails

• Preserve the originating deliveryContext / channel target across auto-compaction and internal continue events.
• If final output is generated in a channel-bound session but there is no delivery target, emit a clear warning and keep the run visibly incomplete or failed.
• Consider preventing NO_REPLY / private final answers when the compaction summary contains pending user-facing TODOs from a channel-bound turn.