openclaw - 💡(How to fix) Fix Telegram group replies to bot messages can lose reply context under group allowlist

Version

OpenClaw 2026.5.12 stable.

Problem

In a Telegram group that is configured as a dedicated agent group with an allowlist, replying to a message sent by the OpenClaw Telegram bot itself can lose the quoted/replied-to message context before the turn reaches the agent.

The incoming Telegram update does include reply_to_message with the bot message text, and the message is also present in the local Telegram message cache. However, the final agent turn may only receive the user's short text, such as what happened?, without the Reply target of current user message / reply-chain context.

This makes the agent answer from stale conversation context instead of the referenced bot notification.

Expected Behavior

If a user replies to a bot-sent message in Telegram, that bot message should be included as visible supplemental quote/reply context.

This also matches the docs expectation that:

• Telegram reply/quote/forward supplemental context is normalized when the gateway has observed the parent message.
• Replying to a bot message in a group counts as an implicit mention.

Observed Behavior

For a Telegram group with requireMention=false and group allowlist enabled:

1. OpenClaw bot sends a cron/system notification into the group.
2. A user replies to that bot message with a short follow-up.
3. The raw Telegram cached update contains reply_to_message.text.
4. The agent session receives only the short user text, without the reply target/reply chain.
5. The agent answers using unrelated/stale context.

Likely Cause

In the Telegram inbound context builder, shouldIncludeGroupSupplementalContext() computes senderAllowed by checking the quote/reply target sender against effectiveGroupAllow.

For a quoted bot/self message, the sender is the Telegram bot account. That sender may not be in the group allowlist, so the quote/reply target is filtered out even though it is the bot's own message and should be safe/visible context.

Local Workaround

We applied a minimal local patch:

const botSenderId = primaryCtx.me?.id != null ? String(primaryCtx.me.id) : void 0;
const shouldIncludeGroupSupplementalContext = (params) => {
  if (!isGroup) return true;
  const isBotSelfMessage = botSenderId != null && params.senderId === botSenderId;
  const senderAllowed = isBotSelfMessage ? true : effectiveGroupAllow?.hasEntries ? isSenderAllowed({
    allow: effectiveGroupAllow,
    senderId: params.senderId,
    senderUsername: params.senderUsername
  }) : true;
  return evaluateSupplementalContextVisibility({
    mode: contextVisibilityMode,
    kind: params.kind,
    senderAllowed
  }).include;
};

We also added a conservative local fallback to record text messages delivered by the Telegram delivery path into the same .telegram-messages.json reply cache, so cron/system notifications sent by the bot are available for future reply-chain hydration even if Telegram returns only a shallow parent.

Suggested Fix

Treat Telegram bot/self messages as allowed supplemental context when they are the reply_to_message / quote target, regardless of group allowlist membership.

Optionally, persist outbound Telegram bot messages with body text into the observed message cache, so bot-originated cron/system notifications can reliably participate in reply-chain hydration.