OpenClaw Main Fixes Three Silent Final-Reply Delivery Failures
Merged fixes stop short interim updates suppressing full answers, bind image context to the active turn and preserve structured heartbeat replies.
OpenClaw has merged three P1-class delivery and context corrections for turns that could complete internally without producing the answer a user should receive.
The failures sit at different boundaries: final-reply deduplication, hidden multimodal context and heartbeat delivery. Their shared operational risk is silence that can look like incomplete model work even though the actual loss happens after—or around—the model turn.
The fixes are on main; the upstream records do not identify a containing package.
A short progress update can no longer swallow the full answer
PR #118178 fixes a shared messaging dedupe predicate. An agent might send “Checking the deploy logs now.” through the message tool, then begin its final answer with the same line. The old forward substring check treated any final reply containing that prior send as a duplicate, regardless of how small the overlap was.
With default block streaming disabled, the final payload set may be the only delivery of the substantive answer. The user could receive the short interim sentence while the full answer survived only in the transcript.
The repaired predicate requires the prior send to cover at least half of the final reply before substring dedupe applies. Exact restatements and short suffix acknowledgements remain suppressible; a small quoted progress line no longer suppresses a much larger answer.
This shared decision point affects final payloads, follow-up delivery and streamed chunk suppression across channels. Acceptance should therefore cover Telegram, WhatsApp, Signal, Slack or whichever adapters the deployment actually uses—not just one UI.
Image analysis is attached to the active question
PR #117364 addresses current-turn runtime context carried across multiple model calls. In a multimodal turn, a configured vision model can analyze an image before a local reasoning model answers the user’s question. Position-relative hidden instructions such as “preceding message” or “message that follows” can become wrong as tool/model calls extend the same turn.
The result could be a successful vision analysis but no final response to the current user question. The fix makes the hidden context position-independent and binds it to the active user turn while retaining the runtime-context privacy notice and historical sanitization.
Interpretation: this is not evidence that every local model will answer every image. It removes one orchestration ambiguity. Model capability, vision-provider failure, context limits and ordinary refusal remain separate causes.
Structured heartbeat replies remain structured
PR #119655 preserves the original heartbeat reply at its delivery owner. Replies containing buttons, interactive payloads, locations or channel metadata could previously be discarded, deduplicated using unchanged text or leave completed delivery recovery pending.
The merged path classifies meaningful structured content before acknowledgement and dedupe, rejects future duplicate timestamps, and clears only run-owned recovery after a genuinely successful visible send. Same text with changed buttons should therefore count as changed content rather than disappear behind text-only equality.
That distinction matters for scheduled operations. A heartbeat can be semantically useful without changing its plain text at all.
Operator acceptance matrix
Use inert destinations and synthetic media:
| Scenario | Required proof |
|---|---|
| Short message-tool progress line, then long final quoting it | Progress appears once; substantive final arrives once |
| Exact final restatement of the tool send | Existing duplicate suppression still works |
| Same route text on a different destination | Route isolation prevents cross-destination suppression |
| Image plus explicit question through the configured vision/local-model chain | Final answer addresses the active question and does not expose hidden context |
| Heartbeat with buttons but no meaningful text change | Structured payload arrives |
| Same heartbeat text with changed buttons | New controls arrive; text-only dedupe does not hide them |
| Structured send fails | Recovery remains owned and retryable; success is not recorded early |
| Structured send succeeds | Run-owned recovery clears without touching unrelated work |
Inspect both recipient-visible output and the durable transcript. A transcript-only answer is a delivery failure; visible output with missing history is a persistence failure. They need different diagnosis.
What not to do
Do not “fix” the dedupe case by forbidding all progress updates. Interim messages are useful during long operations, and the repaired ratio preserves ordinary exact-duplicate suppression.
Do not expose hidden runtime context to make multimodal ordering easier to debug in production channels. Use isolated fixtures and logs with synthetic content.
Do not flatten structured heartbeat replies to text as a workaround. That discards the channel interaction the fix is intended to preserve.
Evidence and limits
For PR #118178, upstream drove the production final-payload assembly with a routed Telegram turn: a 29-character interim send suppressed a 316-character final before the fix, while the patched path delivered one substantive payload. It also reports focused and adjacent suite coverage, but not a live bot send.
PR #117364 supplies merged current-turn context changes and transcript-oriented regression coverage. PR #119655 reports focused heartbeat, Telegram-boundary, recovery and build checks. OpenClaw Academy reviewed those primary records but did not run paid providers or real recipient channels.
Collector IDs 40023/39898, 39823/39739, and 39843/39759 identify the three merged changes and their landed commits.
Bottom line
“Run completed” is not delivery proof. Stage a containing build until short progress text cannot hide a long final, multimodal context remains bound to the current question, and structured heartbeat changes reach the recipient exactly once.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF