function isLikelyInterimCronMessage(value) {
const normalized = normalizeHintText(value);
if (!normalized) return true;
return normalized.split(" ").filter(Boolean).length <= 45
&& INTERIM_CRON_HINTS.some((hint) => normalized.includes(hint));
}

And later:

if (
!interimRunResult.meta?.error &&
!interimRunResult.didSendViaMessagingTool &&
!interimPayloadHasStructuredContent &&
!interimPayloads.some((payload) => payload?.isError === true) &&
countActiveDescendantRuns(agentSessionKey) === 0 &&
!hasDescendantsSinceRunStart &&
isLikelyInterimCronMessage(interimText)
) await runPrompt([
"Your previous response was only an acknowledgement and did not complete this cron task.",
"Complete the original task now.",
...
].join(" "));

This suggests the cron runner is still classifying the post-run text as interim and forcing a rerun.

───

Why this seems different from other fixed issues

This does not look like:

• Telegram DM duplicate reply routing
• Telegram announce delivery reporting
• transcript repair / missing tool result

Instead, it looks like a cron completion classifier bug:

• NO_REPLY is not being reliably short-circuited before interim-message detection
• or pickLastNonEmptyTextFromPayloads() is surfacing text that still matches interim heuristics

───

Repro pattern

1. Create an isolated cron job that instructs the assistant:

• do some lightweight check
• reply NO_REPLY when everything is normal

2. Let the job run
3. In some runs, transcript shows:

• assistant NO_REPLY
• then system-injected message:
Your previous response was only an acknowledgement and did not complete this cron task

4. The cron is forced into another round

───

Suggested fix

One of these should likely happen before isLikelyInterimCronMessage(interimText) is allowed to trigger a rerun:

1. Hard short-circuit on semantic NO_REPLY completion
2. Do not rerun if the final payload set already resolves to a silent-complete outcome
3. Narrow isLikelyInterimCronMessage() application
4. Add debug markers for which branch triggered the rerun

───

Impact

This bug still causes:

• unnecessary reruns
• extra token/tool cost
• transcript clutter
• confusion when using NO_REPLY for heartbeat/progress-style cron jobs

### OpenClaw version

OpenClaw: `2026.3.8`

### Operating system

## Environment  - OpenClaw: `2026.3.8` - Install method: npm/pnpm global - OS: Linux - Channel: Telegram - Session target: isolated cron

### Install method

_No response_

### Logs, screenshots, and evidence

```shell