openclaw - 💡(How to fix) Fix [Bug]: Telegram replies appear to replace previous reply in chat scrollback instead of appending (regression ~2026-05-26)

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Telegram replies delivered via the OpenClaw gateway from multiple distinct bot accounts appear to replace the previously delivered reply in the user's chat scrollback instead of stacking as a new message, observed beginning approximately 2026-05-26.

Steps to reproduce

1. Have an OpenClaw 2026.5.20 gateway delivering replies to a Telegram chat via a configured bot account.
2. Send a message to the bot in a Telegram DM.
3. Receive reply A from the agent.
4. Send a follow-up message to the bot before navigating away from the chat.
5. Receive reply B from the agent.
6. Scroll up in the Telegram chat to look for reply A.

Expected behavior

Reply A remains visible in the Telegram chat scrollback alongside reply B, consistent with the standard Telegram message-append behavior observed in OpenClaw releases prior to approximately 2026-05-26.

Actual behavior

Reply A is no longer visible in the Telegram chat scrollback once reply B is delivered; only reply B appears in the chat view. Observed by user in live Telegram client across two distinct OpenClaw bot accounts (one Opus 4.7 agent, one Sonnet 4.6 agent). The underlying delivery mechanism (edit-in-place vs. delete-and-resend) has not been verified from gateway logs.

OpenClaw version

2026.5.20 (build e510042)

Operating system

macOS 26.5 (build 25F71), Apple Silicon (arm64), Darwin kernel 25.5.0

Install method

Homebrew global (/opt/homebrew/bin/openclaw)

Model

Observed on two distinct models in parallel: - anthropic/claude-opus-4-7 (agent id=main) - anthropic/claude-sonnet-4-6 (agent id=drhealth)

Provider / routing chain

openclaw gateway -> claude-cli runtime (subscription auth) -> anthropic

Additional provider/model setup details

Two separate OpenClaw agents (different ids, different bot tokens, different Telegram accounts) running on different model tiers both exhibit the bug simultaneously. This rules out a per-agent or per-model issue and points to the shared delivery layer (gateway -> Telegram channel adapter).

Relevant agent + channel config lives in ~/.openclaw/openclaw.json under agents.list[] and channels.telegram.accounts. No API keys, bot tokens, or secrets included here; the attached diagnostics bundle contains the auto-redacted equivalent.

openclaw-diagnostics-2026-05-27.zip

Logs, screenshots, and evidence

Attached: sanitized diagnostics bundle from `openclaw gateway diagnostics export`.

Impact and severity

Affected: User of OpenClaw-managed Telegram bot accounts (DM channel). Observed across two distinct agents on two distinct bot tokens. Severity: Blocks workflow — multi-step instructions, tables, tokens, and file paths delivered in one reply are no longer visible to the user once the next reply arrives, forcing the assistant to redundantly restate prior content in every follow-up. Frequency: Consistent since first observation on approximately 2026-05-26. Reproduced in live use within the same chat session multiple times in the past 24 hours, including loss of multi-step setup instructions mid-task. Consequence: Lost instructions and reference material mid-task; reduced usability of multi-turn workflows; no data loss on the gateway side observed.

Additional information

Last known good version and first known bad version cannot be determined from available evidence — the regression date (approximately 2026-05-26) is grounded in user observation, but no version pinning was performed at that date. Current running build is 2026.5.20 (e510042).

The diagnostics bundle attached above was generated via openclaw gateway diagnostics export and contains sanitized config, gateway logs, status, health, and stability snapshots.