Duplicate assistant replies in streamed chats: what OpenClaw v2026.6.11 fixed
Duplicate assistant replies are not a cosmetic bug. They are a trust bug. When the same answer shows up twice in Telegram, Discord, or Slack, users stop trusting the thread, retry the request, and make the problem worse.
OpenClaw v2026.6.11 tightens that delivery path. The new release keeps streamed output, progress updates, and final replies attached to the right conversation so the user sees one coherent turn instead of a messy replay.
If you want the broader architecture behind that behavior, start with How OpenClaw Works, then compare channel-specific behavior in Telegram and Slack. If the symptom looks like a missing answer rather than a duplicate, the OpenClaw not responding FAQ is the right place to rule out the simpler failure modes first.
What changed in v2026.6.11
OpenClaw did not ship a single toggle labeled “dedupe replies.” It tightened several layers of the message path. Each one solves a different part of the same problem.
| Failure mode | What v2026.6.11 changed |
|---|---|
| Final assistant replies appearing twice after a multi-message stream | #95432 stops completed assistant messages from being duplicated in Telegram, Discord, Slack, and other streamed chats. |
| Progress lines piling up or repeating the same heading | Telegram streaming replies now show each progress heading once, instead of echoing the same status label over and over. |
| Stale progress state hanging around after the answer is finished | #e114001 keeps the latest progress state visible during streaming instead of freezing on an older update. |
| Dedupe checks consuming more CPU than they should | #96087 reduces the overhead of checking whether block text was already sent. |
| Readable progress formatting breaking inside Telegram | #95007 keeps command, search, update, and API progress readable, with plain-text fallback when formatting fails. |
| Short previews making the chat look silent | #95183 keeps Telegram showing that OpenClaw is still working during short initial previews or progress-mode replies. |
That is the real pattern in this release: not one giant fix, but a set of guardrails around message identity, progress rendering, and final delivery.
Why duplicate assistant replies happen in streamed chats
Streaming makes reply handling harder because the system is doing several things at once:
- it is generating content in chunks
- it is updating progress while the model is still running
- it is holding a live conversation target in memory
- it may retry or reconnect mid-turn
- it still has to decide when a reply is truly final
That means the bug is often not “the model answered twice.” The bug is usually “the runtime lost track of which event was the final reply.”
That is why a fix like #95432 matters. It is about turn integrity, not model quality. The answer can be correct and still become confusing if the delivery layer emits it twice.
This is also why the issue shows up most clearly in messaging channels. In a web app, repeated state can be annoying. In a chat thread, repeated state looks like a system that cannot decide whether it has finished.
The practical effect for operators
For operators, the release matters because it reduces support noise and false alarms.
A duplicate reply often triggers a bad loop:
- The user sees the same answer twice.
- They resend the prompt.
- The thread now has two or three overlapping runs.
- The conversation becomes harder to trace than the original request.
Once that happens, the operator is debugging conversation state, not model behavior.
v2026.6.11 helps by keeping the reply attached to the right turn, the right chat, and the right stage of the stream. That is especially useful in channel-heavy setups where the same assistant can be talking through Telegram, Discord, Slack, and WebChat at the same time.
If you are mapping the product surface, OpenClaw vs alternatives is useful context, but the important point here is simpler: a chat system feels reliable only when the turn boundary is reliable.
What to watch if you run OpenClaw yourself
If you self-host or operate OpenClaw for a team, the safest mental model is this: dedupe by turn identity, not just by text.
Text can be identical for legitimate reasons. Two people can ask the same question. One user can ask a follow-up that produces the same summary. A retry can legitimately replay a partial response. So content alone is not enough.
A better operational checklist looks like this:
- keep a stable conversation ID across retries and reconnects
- treat progress updates and final replies as separate states
- do not let a session switch re-home an in-flight reply
- make sure the final send path can tell “already sent” from “still streaming”
- verify that channel-specific quote or thread mapping does not duplicate the same assistant turn
Those are the places where duplicate replies usually hide.
There is also a product lesson here. The most damaging bug is often not the loudest one. A reply that appears twice is worse than a reply that appears slowly, because it destroys confidence in the thread. Once trust breaks, every later turn feels less stable.
Why this release is about delivery, not fallback
It is tempting to group every reliability fix together. That would be the wrong reading.
OpenClaw v2026.6.11 also contains fallback and response-boundary improvements elsewhere in the release, but this post is about a different layer. Fallback says what happens when a response fails. Duplicate-reply fixes say what happens when a response succeeds but the runtime mishandles delivery.
That distinction matters because the right operator response is different.
- If the model fails, inspect provider routing and fallback.
- If the answer is correct but duplicated, inspect message identity, turn finalization, and channel attachment.
If the symptom is “OpenClaw replied, then replied again,” you are in the second category.
A quick comparison of the failure types
| Symptom | Likely layer | What to inspect first |
|---|---|---|
| No answer at all | Transport or provider failure | Session routing, provider health, retries |
| Answer appears once, then again | Delivery state | Final send path, reply ownership, turn identity |
| Progress text repeats but the final answer is fine | Stream rendering | Status updates, heading dedupe, formatting |
| Answer lands in the wrong chat | Conversation targeting | Thread mapping, reconnect handling, session switches |
That table is the simplest way to separate a model problem from a delivery problem.
FAQ
Is this the same as a retry fix?
No. A retry fix makes sure OpenClaw can recover from a failed send. A duplicate-reply fix makes sure a successful send does not get emitted twice.
Which channels were affected?
The release notes call out Telegram, Discord, Slack, and other streamed chats. The exact wording matters less than the pattern: anything that streams and finalizes a turn can show the bug.
Does this replace fallback and timeout handling?
No. It complements those fixes. Fallback handles failed responses. Duplicate-reply prevention handles successful responses that were delivered more than once.
What is the simplest way to diagnose it?
Check whether the first answer is correct and the duplicate appears only after the final stream completes. If yes, you are looking at delivery-state drift, not model reasoning.
Where should I start if users think OpenClaw is broken?
Start with the channel guide for the integration they are using, then check the OpenClaw not responding FAQ. If the issue is duplication rather than silence, move straight to turn integrity and reply ownership.