openclaw - 💡(How to fix) Fix Auto-continue after compaction can lose user-facing task and reply NO_REPLY

Summary

A user-facing investigation turn can be left without a final visible reply when a runtime error/compaction interrupts the run. A later internal Continue the OpenClaw runtime event. wake may resume with generic context, do unrelated startup/bootstrap work, and reply NO_REPLY even though the original user task still has pending TODOs.

In the observed case the user only received the initial "I will investigate" progress message. The actual conclusion was not sent until the user manually poked the agent with Atlas?.

Observed timeline

Environment: local OpenClaw, agent atlas, WhatsApp group session agent:atlas:whatsapp:group:[email protected].

Session file inspected locally: /Users/edcorp/.openclaw/agents/atlas/sessions/7a1f048e-2f0a-4287-923d-b615431212b2.jsonl

Key events:

• 2026-05-12T15:23:01.630Z — user asked Atlas to investigate Hermes local dashboard/agent listing persistence.
• 2026-05-12T15:23:25.835Z — assistant sent visible WhatsApp progress reply: "Vou investigar sem alterar nada...".
• Delivery succeeded with WhatsApp messageId=3EB028E19B1CB45A2EFB2B.
• 2026-05-12T15:23Z..15:29Z — assistant continued using tools (memory_search, exec, process, etc.).
• During that span a runtime/model failure was observed in logs: embedded run agent end, runId d5cb38f5-746c-462e-9f4d-9510ffffd722, error=WebSocket error, around 2026-05-12T15:26:02Z.
• 2026-05-12T15:31:51.432Z — automatic compaction entry was written.
• After that compaction there was no final visible user-facing answer until a later manual poke.
• 2026-05-12T17:01:44.095Z — internal wake/user event: Continue the OpenClaw runtime event.
• The resumed agent tried startup/boot behavior, attempted to read memory/2026-05-12.md, got ENOENT, created/appended the daily memory file, then replied NO_REPLY at 2026-05-12T17:02:23.990Z.
• 2026-05-12T17:02:27.341Z — user sent Atlas?.
• Only then did the agent resume and send a final analysis at 2026-05-12T17:04:39Z, delivered as WhatsApp messageId=3EB0C5C8FB34F33525E4D0.

Why this is bad

The runtime had enough information in the compaction summary to preserve the pending user task:

• Pending user asks included investigating why Hermes-Atlas did not appear in the Hermes dashboard and why the dashboard was not persistent.
• Turn context preserved that this was a user-facing investigation and no changes/restarts should be made without notice.

But the internal auto-continue prompt was too generic and allowed the agent to do unrelated bootstrap work and answer NO_REPLY, leaving the user with no visible completion or failure notice.

Expected behavior

One or more of these should happen:

1. If a user-facing turn is interrupted by compaction/runtime error before a final answer, auto-continue should explicitly resume the pending objective, not merely inject a generic Continue the OpenClaw runtime event..
2. The runtime should prevent/suppress NO_REPLY when the compacted turn context contains pending user-facing TODOs and the previous visible reply was only a progress/ack message.
3. If the run cannot be resumed safely after compaction/WebSocket failure, send a visible failure/stall notice to the source channel.
4. Internal continuation events should be distinguished from new human messages so startup/boot obligations do not derail the resumed task.

Impact

This creates a silent-loss failure mode: the user sees "I will investigate" but never receives the conclusion unless they manually poke the agent. It is especially problematic on chat channels where progress/final delivery is the user's only visibility into whether work is still active.

Related context

This is adjacent to previous reliability issues around compaction/session continuation and silent replies, but the distinctive bug here is the combination of:

• runtime/WebSocket failure during tool-heavy work,
• auto-compaction mid-investigation,
• generic internal continuation event,
• NO_REPLY after startup/bootstrap work,
• no visible final/failure notification for the original user-facing task.