OpenClaw Main Changes Unset Heartbeats to Owner-Only Delivery

OpenClaw has changed what an unset heartbeat destination means. On current main, it resolves to a configured operator’s direct-message destination and must never fall back to a group.

This is an operator-visible routing change, not internal cleanup. Anyone relying on an implicit “last conversation” destination should review configuration before deploying a containing build.

The same-day chronology matters

PR #121892 first changed unset heartbeat delivery to follow the last conversation. Later the same day, PR #121988 replaced that default with owner semantics.

The later rule is the one operators should plan around:

• resolve candidates from configured command owners first;
• then consider concrete channel allowlist entries;
• reject wildcards and channel-scoped wildcards as destinations;
• require the channel adapter to positively classify the target as a direct destination; and
• never send an implicit heartbeat to a group.

If no safe owner DM can be proven, delivery is suppressed rather than guessed.

Interpretation: recent conversational activity is useful context, but it is not durable authorization for unattended notifications. A heartbeat can contain operational status that should not be sprayed into whichever room happened to speak last.

Explicit targets still win

This change is about an unset target. An operator who deliberately configures a concrete destination keeps that explicit routing decision, subject to ordinary channel validation and policy.

Do not “fix” a missing owner by adding a broad wildcard. Wildcards describe who may interact; they do not identify one person who should receive unattended operational output.

Installations with several configured owners also need a deterministic ownership policy. The merged resolver exhausts configured candidates in order rather than selecting a group fallback, but operators should still verify which concrete DM wins in their actual channel configuration.

Alerts no longer consume failed work

Two related fixes tighten failure semantics.

PR #118488 keeps failed heartbeat work pending after an alert. An alert saying that work failed is not completion of the work itself. Clearing the item at notification time would convert a transient execution or delivery failure into silent loss.

PR #122187 corrects the ordering for exhausted stream-source automations: durable cron run history is finalized before the generic failure alert is emitted. Alert consumers can therefore inspect the run record immediately instead of being told to check history that has not yet been written.

The operational invariant is simple: persist the failure, retain retryable work, then notify. An alert is evidence that somebody was told, not evidence that the job succeeded or its state was safely retired.

Rollout checklist

Before deploying a containing build:

1. list every heartbeat with no explicit target;
2. inventory concrete owner and channel-allowlist entries without exposing private identifiers publicly;
3. remove accidental wildcards from any assumption about notification ownership;
4. run a synthetic heartbeat and prove the recipient is a direct operator destination;
5. make the most recent conversation a group and prove the implicit heartbeat does not go there;
6. remove all eligible owner DMs and require visible suppression rather than group fallback;
7. force one heartbeat failure and verify the work remains pending after its alert; and
8. exhaust a test stream restart budget, then confirm durable run history exists before the alert consumer queries it.

Use inert test content. A routing acceptance test should not include production incidents, customer data or secrets.

Bottom line

OpenClaw is treating heartbeat delivery as unattended authority rather than conversational convenience. The owner-only default is safer, but it can move or suppress notifications compared with earlier main behavior. Make the destination explicit where continuity matters, and test failure persistence separately from alert delivery.