openclaw - 💡(How to fix) Fix Telegram: delivery-mirror transcript entries are being delivered to Telegram and edit-replacing the real assistant reply with earlier/fragmentary content

Summary

In a Telegram direct chat on [email protected] (Mac mini, macOS 26.5), provider=openclaw model=delivery-mirror transcript-only assistant messages are leaking into the Telegram outbound delivery path. Telegram's client then shows the original (correct) reply being edited / deleted-and-replaced by the mirror entry's content — which is sometimes a duplicate of the current reply, and sometimes text from an earlier assistant turn in the same session.

User-visible symptom: a long assistant reply is delivered to Telegram, the user starts reading it, then partway through the message shows Telegram's client-side delete animation ("explode-to-dots") and is replaced by a shorter / earlier message in the same visual slot. If the user wasn't actively reading at the time of replacement, they would never see the original content.

This appears to be a regression — looks like the Slack-side fix landed long ago (#45489, CHANGELOG.md:6258) and a similar Telegram-side fix (#25835, CHANGELOG.md:7730) was in place but has either regressed in 2026.5.12 or has a new code path bypassing it.

Reproduction (organic, observed in production use)

Two incidents in one Telegram direct-chat session, 2026-05-17:

• 14:18:25–14:18:26 UTC — long assistant reply at 14:18:25.563 (Anthropic claude-opus-4-7) followed at 14:18:26.381 by a duplicate-text delivery-mirror transcript entry. Telegram replaced the visible message.
• 15:28:51–15:28:55 UTC — long assistant reply at 15:28:51.130 followed within ~4 seconds by THREE delivery-mirror transcript entries. Two of them contained text from earlier assistant turns in the same session (not the current reply). Telegram replaced the visible message with a fragment of an earlier reply.

I do not have a synthetic minimal reproducer; the bug manifested in a long working Telegram session with the user. I have preserved the full session transcript JSONL and can supply on request.

Trajectory evidence

Around the 15:28 incident, four assistant-role messages were appended to ~/.openclaw/agents/main/sessions/<sessionId>.jsonl within ~5 seconds:

Around the 14:18 incident, two assistant-role messages within 1s:

Pattern: the primary Anthropic assistant message is followed within 1-4s by one or more delivery-mirror transcript entries. The Telegram outbound listener appears to read these from session.transcript.update events and editMessage the user-visible Telegram post with their contents.

What I think is happening

bot-DVHbpZjZ.js (Telegram channel adapter) at lines 5338-5375 builds the delivery-mirror message and writes it to the transcript only — appendSessionTranscriptMessage + emitSessionTranscriptUpdate. It does NOT call any send-to-Telegram path itself.

A separate listener on session.transcript.update events is treating these transcript-only entries as deliverable assistant messages and dispatching them to Telegram. The existing filter helper (selection-61FIEezO.js:2501):

return provider === "openclaw" && (model === "delivery-mirror" || model === "gateway-injected");

is not being applied on this code path.

The dedupe in #67185 (CHANGELOG.md:4347) skips appends only when the latest assistant message has the same visible text. When the mirror entry contains text from an earlier turn (as happened twice in our 15:28 incident), the visible-text check passes ("different text → not a duplicate, deliver it") and Telegram gets the wrong content.

Suggested fix direction

Apply the Slack-side fix shape (#45489, CHANGELOG.md:6258 — "suppress transcript-only delivery-mirror assistant messages before embedded re-delivery") to the Telegram delivery path:

• Before the Telegram outbound listener dispatches an assistant transcript entry, call the existing isDeliveryMirrorOrInjected (or equivalent) check and skip if true
• Independent of (and stronger than) the text-equality dedupe in #67185 — that one is a safety net, this one is the structural fix

Workaround attempted / not attempted

I considered disabling delivery-mirror entirely via config but couldn't find a safe knob to disable just the outbound side without breaking transcript hygiene (replay, idempotency, compaction successor handoff). I haven't attempted it.

Environment

• [email protected] (Node v22.22.2, Mac mini, macOS Tahoe 26.5)
• Telegram bot, direct chat
• Anthropic provider, model claude-opus-4-7

Side observation (possibly related, possibly not)

~/.openclaw/agents/<agentId>/sessions/sessions.json.telegram-sent-messages.json stopped being updated yesterday around 22:14 PDT. Today's ~60 outbound Telegram messages are not tracked in that file. Either it was deprecated in 2026.5.12, or the new outbound path forgot to update it. Mentioning in case it's the same regression.