openclaw - 💡(How to fix) Fix Telegram group: mentioned bot processes Claude CLI turn to completion but never sends `sendMessage` outbound — silent reply loss [1 comments, 2 participants]

Summary

In a Telegram group containing several OpenClaw-bound bots, the agent runtime processes incoming @mention messages end-to-end (inbound → Claude CLI turn → turn completion logged) but never emits an outbound Telegram message back to the group. There is no error, no warning, and no audit trail of an attempted sendMessage. The reply is silently dropped.

The same bot, in the same gateway process:

• replies normally in direct DM (1:1) chats, and
• can send messages to the same group via direct https://api.telegram.org/bot<token>/sendMessage (verified — returns ok: true with a message_id).

So the bot token, group permissions, and gateway authentication are all healthy. The failure is contained to the OpenClaw outbound path for telegram:group:<id> after a Claude CLI turn completes.

Environment

• OpenClaw 2026.5.12 (f066dd2)
• Runtime: claude-cli (Claude Code subscription, OAuth)
• Node v22.22.2
• Ubuntu 24.04.1, kernel 6.17.0-29-generic
• Config: ~/.openclaw/openclaw.json
• Channel: Telegram, multi-account (8 accounts bound, 4 of them members of the affected group)
• Group: 9 members (1 user + 8 bots), requireMention: true

Minimal reproduction

1. Define multiple Telegram bot accounts in channels.telegram.accounts, each bound to its own agent in bindings[].
2. Add 2+ of those bots to the same Telegram group.
3. Group has requireMention: true. BotFather settings for each bot: groups allowed, group privacy disabled, bot-to-bot allowed.
4. From a permitted user, post a message in the group that begins with @<bot_username> (e.g., @<BOT_USERNAME> شلونك).
5. Observe gateway log:

   [INFO] Inbound message telegram:group:<GROUP_ID> -> @<BOT_USERNAME> (group, 22 chars)
   [INFO] cli exec: provider=claude-cli model=opus promptChars=1032 trigger=user useResume=false session=none resumeSession=none
   [INFO] claude live session start: provider=claude-cli model=claude-opus-4-7 activeSessions=2
   [INFO] claude live session turn: provider=claude-cli model=claude-opus-4-7 durationMs=23929 rawLines=58

6. No outbound / sendMessage log entry follows. No reply appears in the group. No error is emitted.
7. The exact same bot, same process, can send to the same group via direct Bot API:

   curl -s -X POST "https://api.telegram.org/bot${TOKEN}/sendMessage" \
     -d "chat_id=<GROUP_ID>" \
     --data-urlencode "text=probe"
   # → {"ok":true,"result":{"message_id":677,...}}

Expected vs actual

Expected: When a mentioned bot in a group completes a Claude CLI turn with non-empty output, the gateway sends the reply to the originating group chat (telegram:group:<id>), or emits a clear error if the send fails (auth, permissions, rate limit, malformed payload).

Actual: Turn completes (logged with rawLines=58/67/92 depending on the message), then nothing. No sendMessage is attempted at the gateway level. The reply is lost without a trace at INFO/WARN/ERROR.

Impact

• Multi-bot group conversations — a flagship demo use case for OpenClaw — silently break. Users see no reply, get no error, and the gateway looks healthy on the surface.
• The asymmetry with DM (where the same agent and same Claude CLI session reply fine) makes the failure mode confusing: operators rule out auth, model, and permissions because all of those work in DM.
• Diagnosis requires correlating inbound log + Claude turn log + manual Bot API send — none of which is part of a normal "why didn't my bot reply" debug flow.

What I have ruled out

• Bot permissions: Direct sendMessage from the same token to the same chat works (message_id returned).
• Group settings: requireMention: true; mention is detected (Inbound log explicitly names @<BOT_USERNAME>).
• Auth: Claude CLI OAuth valid (expires in 8h); turn completes successfully.
• Runtime registration: After gateway restart, harness is registered; turn still completes; outbound still missing.
• groupPolicy gap: Adding channels.telegram.groupPolicy: "open" does not change the behavior.
• Same agent in DM works: telegram:<USER_ID> -> @<BOT_USERNAME> (direct, ...) replies normally throughout.

Suggestions

• Emit an INFO log at gateway outbound dispatch for every group reply attempt (with chatId, messageId parent, len, botUsername) — symmetric to the Inbound log — so silent drops become visible.
• If the post-turn handler can decide "no message to send" (empty output, tool-only turn, suppressed), log that explicit decision with reason, not silence.
• Audit the path from claude live session turn completion to the Telegram sendMessage call specifically for telegram:group:<id> lanes — DM lanes work, so the divergence is in group-specific routing.

Workaround

None known at the OpenClaw layer. Out-of-band workaround:

curl -s -X POST "https://api.telegram.org/bot${TOKEN}/sendMessage" \
  -d "chat_id=<group_id>" --data-urlencode "text=<reply>"

This bypasses OpenClaw and confirms the bot/permissions are healthy but defeats the point of using the gateway.

Discovery context

Encountered while building a multi-agent Telegram group demo (8 bots, distinct personas) on a single Claude Code subscription. Each bot replies fine in DM. After mentioning a specific bot in the group, the gateway logs an Inbound, runs a Claude CLI turn to completion, and then goes silent — no outbound, no error. Verified with raw Bot API that the bot itself can send to the group; the failure is entirely contained to OpenClaw's outbound path for group lanes.