Summary

On OpenClaw 2026.4.11 in a Telegram direct chat, an assistant final reply existed in the session transcript but was never delivered to Telegram. The affected assistant turn contained both a thinking block and a text block. Session/transcript state made it look like the reply had been sent, but the Telegram gateway log had no corresponding outbound sendMessage entry for that turn.

This looks closely related to the existing Telegram bug family around:

• thinking + text final text being dropped on Telegram partial streaming ([Bug]: streaming: partial drops text block when assistant turn contains [thinking, text] #53384)
• commentary / scratch leaking to Telegram (Bug: commentary-phase assistant text leaks to Telegram as user-visible messages #62409, Telegram surface leaks assistant pre-tool scratch/commentary into user-visible chat #66161)
• internal delivered state diverging from actual Telegram delivery (Cron announce may report delivered=true without actual Telegram delivery #43177)

Environment

• OpenClaw: 2026.4.11
• Surface: Telegram direct chat
• Runtime: main session
• Model observed in active session: openai-codex/gpt-5.4
• Telegram config before mitigation: channels.telegram.streaming.mode = "partial"

What happened

I asked the assistant to run a background verification task and proactively report back when complete.

The assistant later produced a user-facing completion reply in the Telegram main-session transcript, but I never received that reply in Telegram.

A follow-up manual resend from a later turn did arrive successfully.

Evidence

1. Assistant reply exists in transcript

Session JSONL contains an assistant message with id ffb4429e, seq 26, timestamp 2026-04-14T06:17:34.547Z / response timestamp 1776147444055.

That assistant turn contains:

• a thinking block
• followed by the final text block

Text content was:

已经完成并汇报过了 📋 简单说：

- 2个bug已修复，73个测试全部通过
- 今日pipeline运行正常（0封新alert，已投递Telegram）
- 发现的问题已现场修复，commit hash 有更新

具体修复内容在上一条消息里，可以滑上去看 👆

2. Gateway log does NOT show Telegram delivery for that turn

In ~/.openclaw/logs/gateway.log, nearby successful Telegram sends are visible:

• 2026-04-14T13:23:13.267+08:00 [telegram] sendMessage ok chat=5866004662 message=3037
• 2026-04-14T13:23:30.291+08:00 [telegram] sendMessage ok chat=5866004662 message=3038
• later manual resend messages also appear:
  • 2026-04-14T14:25:02.032+08:00 [telegram] sendMessage ok chat=5866004662 message=3047
  • 2026-04-14T14:25:21.813+08:00 [telegram] sendMessage ok chat=5866004662 message=3049

But there is no corresponding sendMessage ok (or sendMessage failed) entry for the missing assistant reply around the transcript turn above.

3. Internal state looked successful / sent-like

Session inspection still showed:

• transcript contains the assistant turn
• systemSent: true
• correct Telegram delivery context for the session

So this is another case where:

• assistant output exists
• internal/session state implies it was sent
• user never received a Telegram message
• lower Telegram delivery log has no actual outbound send record for that reply

Why this seems important

This is not just commentary leakage. In this case the more serious symptom is:

• the final user-facing text reply appears to have been dropped entirely before Telegram transport
• transcript/session state made it look like delivery happened
• user had to ask again for the result

That makes proactive notifications unreliable in Telegram direct chats.

Why this looks related to existing issues

This issue seems adjacent to:

• [Bug]: streaming: partial drops text block when assistant turn contains [thinking, text] #53384 because the affected assistant turn contains [thinking, text], and the text appears never to have reached Telegram
• Bug: commentary-phase assistant text leaks to Telegram as user-visible messages #62409 / Telegram surface leaks assistant pre-tool scratch/commentary into user-visible chat #66161 because Telegram handling of non-final / mixed assistant content seems fragile
• Cron announce may report delivered=true without actual Telegram delivery #43177 because internal “sent/delivered” style state diverges from actual Telegram delivery

Workaround that helped locally

Changing Telegram config from partial streaming to off:

"channels": {
  "telegram": {
    "streaming": {
      "mode": "off"
    }
  }
}

After switching from partial to off and restarting the gateway, I am using that as the current mitigation.

Expected behavior

If an assistant turn contains a user-visible final text reply, Telegram delivery should either:

1. actually send that final text, with a corresponding outbound delivery log, or
2. explicitly record failure

It should not:

• store the assistant final reply in transcript
• make the session look sent/successful
• but never actually dispatch a Telegram outbound message

Suggested investigation areas

• Telegram partial streaming finalization when a turn contains [thinking, text]
• whether a streamed/preview block marks the turn as already flushed before final text dispatch
• whether session-level systemSent or equivalent is being set before lower Telegram delivery confirmation
• whether this is a remaining/reintroduced variant of [Bug]: streaming: partial drops text block when assistant turn contains [thinking, text] #53384 on 2026.4.11