openclaw - 💡(How to fix) Fix [Bug]: [Bug]: Telegram supergroup messages received but bot never replies (groups:unmentioned despite requireMention:false) — 2026.4.27 [2 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

OpenClaw Telegram Bot Direct Message 1 to 1 ok. When bot is added to group, bot does not reply. Try to solve this issues asking GPT and Google for the past 12 hours.

On 2026.4.27 the bot receives Telegram supergroup messages (probe shows in:1m ago) and runs the agent, but never delivers a reply back to Telegram; channels status --probe reports groups:unmentioned even though requireMention:false is set on that group.

Steps to reproduce

1. Install OpenClaw 2026.4.27 via Docker Compose on Linux x86_64.
2. Configure a Telegram bot with BotFather, Privacy Mode disabled, "Groups enabled".
3. Add the bot to a Telegram supergroup, promote to admin with Send Messages permission.
4. In openclaw.json under channels.telegram, set:
   • top-level groupPolicy: "open"
   • top-level groupAllowFrom: ["<numeric-user-id>"]
   • top-level allowFrom: ["<numeric-user-id>"]
   • groups."<group-id>".enabled: true
   • groups."<group-id>".groupPolicy: "open"
   • groups."<group-id>".requireMention: false
   • groups."<group-id>".allowFrom: ["<numeric-user-id>"]
5. Send any message in the supergroup, with or without @mention.

Expected behavior

Bot replies in the supergroup with text generated by the agent (same way DM replies work end-to-end). For comparison: identical bot, same token, same agent, replies fine in 1:1 DM.

Actual behavior

Bot receives the supergroup message (channels status --probe shows in:1m ago) and the agent runs (👀 reaction and "typing…" indicator visible in Telegram), but no text reply is ever delivered to the group. The probe also reports groups:unmentioned even though requireMention:false is set on that group. A direct curl sendMessage to the same chat ID returns HTTP 200, confirming the bot token, group ID, and admin permissions are all correct — outbound delivery works. The failure is inside OpenClaw's group routing.

OpenClaw version

2026.4.27

Operating system

UGOS Pro (Debian-based) on UGREEN NASync DXP4800 Plus, Intel N100 x86_64, kernel 6.x

Install method

docker

Model

google/gemini-2.5-flash-lite

Provider / routing chain

openclaw -> google generativelanguage api (direct, no proxy/router)

Additional provider/model setup details

Single Google Gemini provider, Tier 1 billing enabled. No fallback providers (Cerebras was removed because of issue #47705 sticky-fallback behavior). Auth profile is api_key only. DM with the same agent + same model replies normally — model and provider chain are not the problem.

Logs, screenshots, and evidence

Output of `openclaw channels status --probe`:

  Telegram default: enabled, configured, running, connected, in:1m ago, mode:polling, bot:@REDACTED, token:config, groups:unmentioned, works, audit ok

The flag `groups:unmentioned` persists even though `requireMention: false` is set on that group at every level (per-group and verified in the saved config).

Earlier verbose gateway logs from a session reset showed agent output routed to `channel=webchat` instead of the Telegram lane after a cron job hit the pre-supergroup-migration chat ID, with lines like:

  [agent:nested] session=agent:main:telegram:group:REDACTED run=... channel=webchat

After enabling `diagnostics.flags: ["telegram.*"]`, no telegram.* trace lines are emitted on inbound group messages — only on startup and outbound. So it is not visible at which exact gate the message is dropped.

`docker compose exec openclaw-gateway sh -c "curl ... https://api.telegram.org/"` returns HTTP 302 from inside the container, so network is fine.

Direct curl `https://api.telegram.org/bot<TOKEN>/sendMessage` to the supergroup chat ID returns:
  {"ok":true,"result":{...}}
confirming token + chat ID + admin permission are correct; outbound delivery works.

Happy to attach the full sanitised `openclaw.json` and 60 minutes of gateway logs on request.

Impact and severity

Affected: any OpenClaw user trying to use the Telegram channel in a supergroup. DMs are unaffected. Severity: High — completely blocks the supergroup workflow, which is the primary use case for adding the bot to a family/team chat. Frequency: 100% — every group message, with or without @mention, from owner account or other members. DM is 100% reliable in parallel. Consequence: Cron-scheduled posts to the group also fail the same way; users cannot use the bot for any group automation. No error is surfaced to the user inside Telegram, so the failure is silent.

Additional information

Affects 2026.4.27 in our setup. Per related issues #28901, #29175, #32524 the same family of group-routing failure was reported on 2026.2.26 and confirmed still reproducible on 2026.3.8. We have applied every config-level fix from those issues (top-level groupPolicy: "open", top-level groupAllowFrom, per-group requireMention: false, per-group allowFrom, per-group groupPolicy: "open"). None resolve it on 2026.4.27.

Group is a regular supergroup (no forum/topics enabled). The group was originally created as a regular group and was later auto-upgraded to supergroup by Telegram; old chat ID is now invalid (returns "group chat was upgraded to a supergroup chat") and the new chat ID is what the config uses.

No other channels configured. dmPolicy: allowlist with one numeric user ID. allowFrom is the same numeric ID at top-level and per-group. Bot is admin with Send Messages permission, BotFather Privacy Mode disabled and "Groups enabled" verified.

Asks:

1. Is groups:unmentioned in the probe output a known false-positive state, or does it indicate a real internal mention-required gate that ignores per-group requireMention: false?
2. Is there an undocumented top-level channels.telegram.* field gating group routing that we should set?
3. After a Telegram regular-group → supergroup migration, is there cleanup work in OpenClaw beyond updating the chat ID in config (e.g. session pruning, pairing reset)?
4. Is there a way to enable a more verbose telegram.* trace that actually emits lines on inbound updates (the current diagnostics.flags: ["telegram.*"] produced no inbound traces during testing)?