Summary

We saw repeated visible messages from background/cron/heartbeat workflows that were supposed to remain silent on no-op results. Examples include HEARTBEAT_OK, watchdog summaries, and earlier voice-transcription NO_NEW_AUDIO handling. In some cases the same no-op/silent response appeared duplicated around context-engine maintenance or queued-message handling.

This may be partly prompt design, but the recurring pattern suggests OpenClaw could use a stronger runtime-level no-op/silent delivery mode for cron/systemEvent jobs.

Environment

• OpenClaw around Apr 18-Apr 24 2026
• Discord channel delivery
• Cron/heartbeat/system events
• Context engine maintenance active in some examples

Expected behavior

If a cron/heartbeat job has explicit no-op semantics, such as:

• NO_NEW_AUDIO means no visible reply
• SESSION_WATCHDOG_OK means no visible reply
• heartbeat says "If nothing needs attention, reply HEARTBEAT_OK"

then OpenClaw should suppress delivery or provide a first-class silent/no_reply mode for successful no-op runs, rather than posting literal sentinel strings or explanatory summaries.

Actual behavior

Archived evidence shows visible no-op messages and duplicate narration.

Examples:

Read HEARTBEAT.md if it exists... If nothing needs attention, reply HEARTBEAT_OK.
assistant: Heartbeat checks are clean: watchdog OK, OAuth healthy, core file mtimes are fine, and cron baseline remains unchanged. Nothing actionable surfaced from today/yesterday memory.
HEARTBEAT_OK

Read HEARTBEAT.md ... If nothing needs attention, reply HEARTBEAT_OK.
assistant: HEARTBEAT_OK

Duplicate/surprising visible output around maintenance/queued flow:

yes
assistant: HEARTBEAT_OK
Watchdog clean, no active tasks, no urgent follow-ups from 2026-04-22 notes. Security check was last run 2026-04-21 - within 48h so no alert needed.
assistant: Watchdog clean, no active tasks, no urgent follow-ups from 2026-04-22 notes. Security check was last run 2026-04-21 - within 48h so no alert needed.

Earlier summarized incident:

Second possible upstream report is cron/agent silence-rule replay/duplication from Apr 18 (voice-transcription cron emitted `NO_NEW_AUDIO`, stray `HEARTBEAT_OK`, and explanatory text despite silence instructions).

Impact

• Background jobs clutter user channels with sentinel strings and no-op status.
• Duplicate no-op messages reduce trust in automation.
• Prompt-only suppression is brittle; model compliance is not a reliable delivery-control mechanism.

Suggested fix

• Add a first-class cron/job delivery option for "silent on success/no-op".
• Allow structured job results to mark noReply: true / suppressDelivery: true.
• Treat sentinel outputs like NO_NEW_AUDIO, SESSION_WATCHDOG_OK, or job-defined no-op codes as suppressible by runtime config rather than relying on the model to choose NO_REPLY.
• Add diagnostics when a no-op run still produces visible output.