Bug: Telegram forum topic replies generated in transcript but not delivered to Telegram on OpenClaw 2026.5.2

Summary

On OpenClaw 2026.5.2 (8b2a6e5), Telegram forum topic messages are accepted and processed, and the assistant final response is written to the session transcript, but no Telegram outbound sendMessage occurs for many topic replies.

The user-visible symptom is: Telegram shows the bot typing, but no reply appears in the topic.

This appears related to existing issues:

• [Bug]: Telegram can show typing and complete generation but still drop the final outbound reply with no clear delivery log #50716 — Telegram can show typing and complete generation but drop final outbound reply
• Telegram responses not sent - missing "run done" event #51659 — Telegram responses not sent / missing run done event
• [Bug]: Telegram transcript contains final reply but no outbound send occurs for [thinking,text] turn on 2026.4.11 #66459 — transcript contains final reply but no outbound send occurs

Environment

• OpenClaw: 2026.5.2 (8b2a6e5)
• OS: Linux 6.17.0-14-generic x64
• Node: v24.13.0
• Channel: Telegram forum supergroup topics
• Telegram mode: long polling
• Group chat id: -1003707963225
• Affected account: proton (@protonmediaid_bot)
• Config: requireMention=false, privacy mode already disabled via BotFather
• channels.telegram.streaming.mode: tested both default partial and off

Expected behavior

When the assistant completes a final text response in a Telegram forum topic session, OpenClaw should send that response to the same Telegram topic/thread.

Actual behavior

The assistant final response exists in the session JSONL transcript, but the Telegram gateway log contains no corresponding outbound sendMessage for the topic/thread.

Some topics respond, others do not. The working cases are mostly when the agent uses the message tool directly; the broken cases rely on OpenClaw's automatic final-reply delivery path.

Reproduction / observed examples

Example A — topic 2166, final reply generated but not delivered

Session file:

/root/.openclaw/agents/proton/sessions/d09e53bd-0765-49ed-b6d0-9c1c85971aa1-topic-2166.jsonl

User message:

{"chat_id":"telegram:-1003707963225","message_id":"19800","topic_id":"2166","topic_name":"Passport to Sheet","text":"Test check ststus"}

Assistant transcript contains final answer:

All good ⚛️ Running OpenClaw 2026.5.2, model GLM-5, context at 16%, 92% token budget remaining.

But journalctl --user -u openclaw-gateway.service around that time shows no outbound Telegram sendMessage for the topic.

Example B — topic 1, final reply generated but not delivered before workaround

Session file:

/root/.openclaw/agents/proton/sessions/492708eb-52ce-4410-9725-b1f4e169554c-topic-1.jsonl

Transcript contains generated final replies such as:

[[reply_to_current]] All good, Bubu. Running OpenClaw 2026.5.2 on GLM-5, 16% context used, 93% token budget left. ⚛️

No matching topic outbound sendMessage appears in gateway logs.

Example C — direct message still works

Direct Telegram DM replies to telegram:7006786648 are delivered normally and show logs such as:

[telegram] sendMessage ok chat=7006786648 message=3720

Example D — message tool delivery works

In topic 2, after adding a systemPrompt workaround instructing the model to use the message tool, delivery succeeded:

Session file:

/root/.openclaw/agents/proton/sessions/323181e5-f6e4-4651-8239-6c8559c0f334-topic-2.jsonl

Transcript shows:

{"name":"message","arguments":{"action":"send","channel":"telegram","target":"-1003707963225","threadId":"2","message":"⚛️ All systems nominal..."}}

Tool result:

{"ok":true,"messageId":"19792","chatId":"-1003707963225"}

This confirms Telegram transport itself works; the issue is likely the automatic final-reply delivery path.

Workarounds tested

1. Restart gateway — did not fix consistently.
2. Disable Telegram streaming:

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

Did not fix consistently.

3. SystemPrompt workaround: instruct topic agents to call message tool with channel=telegram, target=-1003707963225, threadId=<topic_id>, then final NO_REPLY.

This worked in some topics (e.g. topic 2), but is not reliable because model compliance varies.

4. Rerouting topic 2166 to minimax-test also did not reliably fix delivery; transcript still showed final text without actual topic delivery.

Why this seems like an OpenClaw delivery bug

• Telegram receives inbound updates (topic sessions are created and updated).
• The model generates final assistant responses successfully.
• Direct message tool sends to the Telegram topic work.
• Automatic final-reply delivery frequently does not emit any sendMessage ok or sendMessage failed log for the topic.
• This matches prior reports ([Bug]: Telegram can show typing and complete generation but still drop the final outbound reply with no clear delivery log #50716/Telegram responses not sent - missing "run done" event #51659/[Bug]: Telegram transcript contains final reply but no outbound send occurs for [thinking,text] turn on 2026.4.11 #66459).

Requested fix / diagnostics

Please ensure that when an embedded Telegram topic run reaches a final assistant text response, the final delivery stage always attempts Telegram delivery and logs one of:

• outbound final delivery start
• sendMessage ok with chat id + thread/topic id
• sendMessage failed with error
• final delivery intentionally suppressed with reason (e.g. NO_REPLY)

If this is related to missing run done events, the gateway should not mark the session sent/successful unless the channel delivery path has actually run or intentionally suppressed the reply.