Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Telegram group messages silently dropped in 2026.4.27 (regression) [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#74858•Fetched 2026-05-01 05:40:44
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
2
Author
mlaihkmlaihk
Participants
clawsweeper[bot]clawsweeper[bot]mlaihkmlaihk
Timeline (top)
cross-referenced ×2closed ×1commented ×1

In OpenClaw 2026.4.27, Telegram group messages are received by the gateway and processed by the agent, but the agent's reply is never delivered back to the group. Messages sent directly to the bot work fine. This is a new regression introduced in 2026.4.27 — issue #66797 (closed in 2026.4.24) described a similar but now-fixed bug.

Error Message

  • ❌ No error log, no warning — response is silently dropped

Root Cause

In OpenClaw 2026.4.27, Telegram group messages are received by the gateway and processed by the agent, but the agent's reply is never delivered back to the group. Messages sent directly to the bot work fine. This is a new regression introduced in 2026.4.27 — issue #66797 (closed in 2026.4.24) described a similar but now-fixed bug.

Fix Action

Workaround

  • No known workaround at 2026.4.27
  • Downgrading to 2026.4.24 (where #66797 was fixed) or 2026.4.25 is the recommended path to restore group functionality

PR fix notes

PR #73583: Fix Telegram status and group reply delivery

Description (problem / solution / changelog)

Summary

  • Send Telegram native /status through the direct status helper instead of the normal buffered answer dispatcher.
  • Preserve Telegram topic threading/reply-to behavior for direct status responses while keeping /fast status on the generic native command route.
  • Pass Telegram group sourceReplyDeliveryMode into normal message turns, so model guidance matches message-tool-only delivery.
  • Add a core suppressed-source fallback hook for group/channel turns that produce ordinary assistant output instead of using the channel message tool.
  • Wire that fallback into Telegram group/topic delivery so final replies, block replies, and verbose progress do not disappear silently when automatic source delivery is suppressed.
  • Normalize suppressed-source fallback payloads through the normal reply dispatcher semantics before channel delivery, so exact silent tokens and channel transforms do not leak through the Telegram fallback.
  • Route queued follow-up run failures back to the original channel/topic as a generic error reply, so model/auth failures do not leave Telegram topics silent.

Root cause

Telegram native /status was authorized for the requested group/user, but after resolving the command it still delivered through the generic Telegram reply dispatcher. During an active chat turn that delivery path can be occupied by normal answer streaming/final delivery, so /status could appear to do nothing until the turn cleared.

Normal Telegram group/topic messages had a related delivery-mode mismatch after the message-tool-only privacy change: the dispatcher suppresses automatic group/channel finals by default unless messages.groupChat.visibleReplies is automatic, but Telegram was not passing the effective mode into the reply runtime or providing a channel fallback for suppressed ordinary assistant output. That let the model produce a plain final reply while the channel treated it as private-only and did not send it back to Telegram.

Live topic testing exposed two more gaps: some turns emitted visible assistant text as block-streamed output instead of a final return value, and verbose progress messages also returned early under the same suppressed delivery mode. The fallback now covers final answers, block replies, and verbose progress without changing the preferred message-tool behavior or bypassing sendPolicy: deny.

A later live check showed two Telegram topic messages did reach OpenClaw but both failed in the queued/follow-up runner with openai-codex/gpt-5.5 auth 401 errors and no model fallback configured. That queued runner path logged the model failure and returned without routing a failure payload, so Telegram still looked dead even though the transport and inbound handling were working.

Upstream reconciliation

  • Current main already fixed native-command generic visibility via #73672 / 195f704c74a2, so this branch no longer carries the native skill-command fallback portion from the original patch.
  • Current main still did not contain the Telegram direct /status fast path, the core suppressed-source fallback contract, the Telegram group/topic fallback, or the queued follow-up failure reply, so this PR is still needed rather than closeable as upstreamed.
  • The review concern about senderIsOwner is addressed by threading Telegram command auth's computed senderIsOwner into resolveDirectStatusReplyForSession.

Validation

  • pnpm test extensions/telegram/src/bot.create-telegram-bot.test.ts -- -t "threads native command replies inside topics|reloads native command routing bindings"
  • pnpm test extensions/telegram/src/bot-message-dispatch.test.ts -- -t "source reply delivery mode|suppressed group final"
  • pnpm test src/auto-reply/reply/dispatch-from-config.test.ts -- -t "suppressed source fallback|source delivery|verbose progress"
  • pnpm test src/auto-reply/reply/dispatch-from-config.test.ts -- -t "suppressed source fallback|normalizes suppressed final replies|uses dispatcher normalization"
  • pnpm test src/auto-reply/reply/followup-runner.test.ts -- -t "routes a generic error reply"
  • pnpm test src/auto-reply/reply/followup-runner.test.ts
  • pnpm exec oxfmt --check --threads=1 extensions/telegram/src/bot-message-dispatch.test.ts extensions/telegram/src/bot-message-dispatch.ts extensions/telegram/src/bot-native-commands.ts extensions/telegram/src/bot.create-telegram-bot.test-harness.ts extensions/telegram/src/bot.create-telegram-bot.test.ts src/auto-reply/get-reply-options.types.ts src/auto-reply/reply/dispatch-from-config.test.ts src/auto-reply/reply/dispatch-from-config.ts
  • pnpm exec oxfmt --check --threads=1 src/auto-reply/reply/followup-runner.ts src/auto-reply/reply/followup-runner.test.ts
  • git diff --check

Not run

  • pnpm check:changed in Blacksmith Testbox: local Blacksmith CLI is not authenticated in this shell (blacksmith testbox warmup ci-check-testbox.yml --ref main --idle-timeout 90 reports not authenticated). GitHub CI should run against the pushed SHA.

Changed files

  • extensions/telegram/src/bot-core.ts (modified, +133/-3)
  • extensions/telegram/src/bot-message-dispatch.test.ts (modified, +98/-0)
  • extensions/telegram/src/bot-message-dispatch.ts (modified, +48/-1)
  • extensions/telegram/src/bot-native-commands.ts (modified, +62/-0)
  • extensions/telegram/src/bot.create-telegram-bot.test-harness.ts (modified, +27/-0)
  • extensions/telegram/src/bot.create-telegram-bot.test.ts (modified, +122/-13)
  • extensions/telegram/src/bot/delivery.send.ts (modified, +18/-2)
  • extensions/telegram/src/reply-run-runtime.ts (added, +1/-0)
  • extensions/telegram/src/sequential-key.runtime.ts (added, +113/-0)
  • extensions/telegram/src/sequential-key.test.ts (modified, +32/-0)
  • extensions/telegram/src/sequential-key.ts (modified, +20/-1)
  • src/agents/context-runtime-state.ts (modified, +3/-0)
  • src/agents/context.ts (modified, +10/-6)
  • src/agents/model-selection-cli.ts (modified, +16/-3)
  • src/auto-reply/get-reply-options.types.ts (modified, +12/-0)
  • src/auto-reply/reply/dispatch-from-config.test.ts (modified, +196/-0)
  • src/auto-reply/reply/dispatch-from-config.ts (modified, +43/-10)
  • src/auto-reply/reply/followup-runner.test.ts (modified, +34/-0)
  • src/auto-reply/reply/followup-runner.ts (modified, +19/-0)
  • src/auto-reply/reply/reply-dispatcher.ts (modified, +26/-15)
  • src/auto-reply/reply/reply-dispatcher.types.ts (modified, +4/-0)
  • src/auto-reply/reply/reply-run-registry.test.ts (modified, +16/-0)
  • src/auto-reply/reply/reply-run-registry.ts (modified, +4/-0)
  • src/gateway/protocol/schema/sessions.ts (modified, +6/-0)
  • src/gateway/server-methods/sessions.ts (modified, +29/-0)
  • src/gateway/server.sessions.list-changed.test.ts (modified, +1/-1)
  • src/gateway/session-utils.fs.ts (modified, +58/-1)
  • src/gateway/session-utils.ts (modified, +163/-22)
  • src/plugin-sdk/reply-runtime.ts (modified, +1/-0)
  • src/utils/usage-format.ts (modified, +33/-2)

Code Example

"jordi": {
  "groupPolicy": "allowlist",
  "dmPolicy": "allowlist",
  "groups": {
    "-1003999717081": {"requireMention": false}
  },
  "allowFrom": ["8703284429"]
}

---

"main": {
  "groupPolicy": "allowlist",
  "dmPolicy": "allowlist",
  "groups": {
    "-1003917245520": {"requireMention": false}
  },
  "allowFrom": ["8703284429"]
}

---

"jisoo": {
  "groupPolicy": "allowlist",
  "dmPolicy": "allowlist",
  "groups": {},
  "allowFrom": ["8703284429"]
}

---

# Active-memory runs on group session — confirming message IS received and processed
2026-04-30T04:15:48.423Z info plugins {"subsystem":"plugins"} active-memory: agent=jordi session=agent:jordi:telegram:group:-1003999717081:topic:33 activeProvider=ollama activeModel=deepseek-v4-flash:cloud start timeoutMs=60000 queryChars=596
2026-04-30T04:16:29.157Z info plugins {"subsystem":"plugins"} active-memory: agent=jordi session=agent:jordi:telegram:group:-1003999717081:topic:33 done status=empty elapsedMs=40735 summaryChars=0

# Same message type in direct chat — works fine (single grey tick only happens in groups)
2026-04-30T04:07:46.885Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=8703284429 message=3442
RAW_BUFFERClick to expand / collapse

name: Bug report about: '[Bug]: Telegram group messages silently dropped in 2026.4.27 (regression)' labels: 'bug,telegram,regression' title: '[Bug]: Telegram group messages silently dropped in 2026.4.27 (regression)'

Summary

In OpenClaw 2026.4.27, Telegram group messages are received by the gateway and processed by the agent, but the agent's reply is never delivered back to the group. Messages sent directly to the bot work fine. This is a new regression introduced in 2026.4.27 — issue #66797 (closed in 2026.4.24) described a similar but now-fixed bug.

Environment

  • OpenClaw: 2026.4.27
  • OS: Linux 6.6.87.2-microsoft-standard-WSL2 (x64) on WSL2
  • Node.js: v24.14.1
  • Gateway: local (systemd service, state active)
  • Channel: Telegram (accounts: jisoo, main, jordi)
  • Telegram polling: long-polling via bot token

Configuration

Three Telegram bot accounts configured:

jordi account:

"jordi": {
  "groupPolicy": "allowlist",
  "dmPolicy": "allowlist",
  "groups": {
    "-1003999717081": {"requireMention": false}
  },
  "allowFrom": ["8703284429"]
}

main account:

"main": {
  "groupPolicy": "allowlist",
  "dmPolicy": "allowlist",
  "groups": {
    "-1003917245520": {"requireMention": false}
  },
  "allowFrom": ["8703284429"]
}

jisoo account:

"jisoo": {
  "groupPolicy": "allowlist",
  "dmPolicy": "allowlist",
  "groups": {},
  "allowFrom": ["8703284429"]
}

What works

  • ✅ DMs to all three bots — sends and receives correctly
  • ✅ Cron announcements delivered to Telegram direct chats
  • ✅ Slash commands (e.g. /whoami) in groups — reply is sent
  • ✅ active-memory plugin runs successfully on group sessions when messages arrive
  • ✅ Bot is administrator in group, privacy mode disabled (via BotFather)
  • ✅ telegram sendMessage ok appears in gateway logs for direct chats
  • ✅ update_id advances confirming gateway consumes group messages

What is broken

  • ❌ Natural-language messages in group chats — agent receives and processes (active-memory runs), but reply is never sent back to the group
  • ❌ No error log, no warning — response is silently dropped
  • ❌ Session transcript shows the assistant turn exists (confirmed via web UI)
  • ❌ No sendMessage entry in gateway logs for group chat IDs
  • ❌ Telegram shows single grey tick (message sent, not delivered)

Steps to reproduce

  1. Have a bot configured with groupPolicy: "allowlist" and a groups entry with "requireMention": false
  2. Send any natural-language message in the configured group
  3. Bot receives it, active-memory runs, agent generates a reply
  4. Reply is visible in session transcript
  5. Expected: reply appears in Telegram group
  6. Actual: single grey tick, reply never arrives, no gateway log entry

Gateway log evidence

# Active-memory runs on group session — confirming message IS received and processed
2026-04-30T04:15:48.423Z info plugins {"subsystem":"plugins"} active-memory: agent=jordi session=agent:jordi:telegram:group:-1003999717081:topic:33 activeProvider=ollama activeModel=deepseek-v4-flash:cloud start timeoutMs=60000 queryChars=596
2026-04-30T04:16:29.157Z info plugins {"subsystem":"plugins"} active-memory: agent=jordi session=agent:jordi:telegram:group:-1003999717081:topic:33 done status=empty elapsedMs=40735 summaryChars=0

# Same message type in direct chat — works fine (single grey tick only happens in groups)
2026-04-30T04:07:46.885Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=8703284429 message=3442

Note: sendMessage ok only ever appears for direct chats (chat=8703284429). Zero sendMessage entries for any group chat ID (chat=-100...) despite active sessions existing for those groups.

Probable cause

The 2026.4.27 changelog includes this change:

"Plugin SDK: expose shared channel route normalization, parser-driven target resolution... switch native approval origin matching onto that route contract with optional delivery and match-only target normalization"

This significantly changed channel route/target resolution logic for the Telegram plugin. The most likely explanation is that the channel-route refactor introduced a subtle routing mismatch where group message responses are generated but the delivery path for group chat IDs is silently broken.

Impact

  • Group chat functionality is completely broken for natural-language messages
  • Slash commands still work (they may use a different code path)
  • This regression affects all users on 2026.4.27 with group chats
  • Proactive notifications from agents to groups are silently unreliable

Workaround

  • No known workaround at 2026.4.27
  • Downgrading to 2026.4.24 (where #66797 was fixed) or 2026.4.25 is the recommended path to restore group functionality

extent analysis

TL;DR

Downgrade to OpenClaw version 2026.4.24 or 2026.4.25 to restore group chat functionality for natural-language messages.

Guidance

  • Review the changelog for 2026.4.27 to understand the changes made to the channel route normalization and target resolution logic.
  • Verify that the issue is specific to group chats and not direct messages or other channels.
  • Check the gateway logs for any errors or warnings related to message delivery to group chat IDs.
  • Consider testing the issue with different group policies or configurations to isolate the root cause.

Example

No code snippet is provided as the issue seems to be related to a specific version of OpenClaw and its configuration.

Notes

The issue appears to be a regression introduced in version 2026.4.27, and downgrading to a previous version is the recommended workaround. However, this may not be a viable long-term solution, and further investigation is needed to identify and fix the root cause.

Recommendation

Downgrade to OpenClaw version 2026.4.24 or 2026.4.25, as this is the most straightforward way to restore group chat functionality for natural-language messages. This recommendation is based on the information provided in the issue and the fact that downgrading is mentioned as a workaround.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#response parsing#generation error#database connection#vector store#embedding generation

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Telegram group messages silently dropped in 2026.4.27 (regression) [1 pull requests, 1 comments, 2 participants]