openclaw - 💡(How to fix) Fix cron: add --skip-announce-on-no-reply flag or config option to suppress delivery when NO_REPLY appears anywhere in response [1 comments, 2 participants]

Problem

When a cron job uses NO_REPLY to suppress delivery on empty results, the LLM frequently leaks extra text alongside the token (e.g. "No new critical alerts found. Per contract: NO_REPLY."). The existing stripSilentToken() fix (PR #31080) removes the literal NO_REPLY text but preserves the surrounding message, so delivery still happens.

Root Cause

isSilentReplyText() only matches exact NO_REPLY messages via /^\s*NO_REPLY\s*$/i. The new stripSilentToken() handles "😄 NO_REPLY" → "😄" but does not help when NO_REPLY is part of a meaningful sentence that becomes non-empty after stripping (e.g. "No critical alerts. NO_REPLY" → "No critical alerts." — still delivered).

Suggested Solutions

Option A: Configurable noReplyHandling (preferred)

Add a per-job or per-message option for how NO_REPLY is treated:

{
  "noReplyHandling": "exact-only" | "strip-and-keep" | "suppress-if-present"
}

• exact-only — current behavior (exact match /^\s*NO_REPLY\s*$/i)
• strip-and-keep — current PR #31080 behavior (strip token, deliver remaining text)
• suppress-if-present — if NO_REPLY appears anywhere in the text, suppress delivery entirely (optionally skip stripping, just don't deliver)

Option B: Cron-level --skip-announce-regex

Add a CLI flag for cron jobs:

openclaw cron add --name "scan" --skip-announce-regex "NO_REPLY" ...

If the final output matches the regex, skip delivery.

Option C: Envelope/structured delivery flag

Support structured delivery metadata that signals "suppress" deterministically, bypassing LLM output entirely:

{"action": "suppress"}

Or make cron treat a sent_alert_ids-style state-based approach (if runner returned nothing, runner itself suppresses — already handled in agent-skill runners, but the model layer between runner and delivery is the weak link).

Use Case

Cron job alertmanager-scan-alerts running every 5 minutes in an isolated session with light context. Runner returns JSON (empty newCriticalAlerts list). Model is instructed to reply EXACTLY: NO_REPLY when empty — but fails ~0.3-0.7% of the time (Bifrost/DeepSeek). The result leaks to Telegram as "No new critical alerts found. Per contract: NO_REPLY.".

Related

• PR #31080 (fixes "😄 NO_REPLY" case but not this one)
• Issue #30916 (original NO_REPLY leak report)
• Issue #30955 (mixed-content stripping)