openclaw - 💡(How to fix) Fix Bug: Telegram reply metadata is missing from assembled model context

Summary

Telegram native reply context (reply_to_message / quoted target) is not reliably included in the assembled model turn for Telegram inbound messages.

When a user taps Reply on a previous Telegram message and sends a terse follow-up such as ?, yes, do that, or an ambiguous operational phrase, the model receives the new text plus generic Telegram inbound metadata, but no structured indication of the message being replied to and no excerpt of the replied-to message. The agent then has to guess from nearby conversation context, which is unreliable and has already caused wrong task association.

This appears to conflict with the Telegram channel docs, which say inbound messages normalize into the shared channel envelope with reply metadata and persisted reply-chain context for Telegram replies the gateway has observed.

Environment

• OpenClaw: observed on an npm-installed local gateway whose config metadata reports lastTouchedVersion: 2026.5.20 and wizard lastRunVersion: 2026.5.18
• OS: macOS arm64
• Channel: Telegram direct chat and Telegram group chat
• Runtime/model: Codex/OpenAI agent runtime; this looks model-agnostic because the missing reply target is absent before the model can reason about it
• Relevant sanitized config shape:
  • channels.telegram.enabled = true
  • channels.telegram.streaming.mode = partial
  • messages.queue.mode = steer
  • Telegram direct pairing enabled; multiple Telegram groups configured

Observed Evidence

Case 1: Telegram direct reply with only ?

A user replied in Telegram to the assistant's immediately previous answer by using Telegram's native Reply UI and sending only:

?

The assembled turn visible to the model contained only generic inbound metadata and the current request text. Sanitized shape:

{
  "schema": "openclaw.inbound_meta.v2",
  "account_id": "default",
  "channel": "telegram",
  "provider": "telegram",
  "surface": "telegram",
  "chat_type": "direct"
}

Then:

Current user request:
?

There was no visible reply_to_message, provider message id, target author/role, quoted target text, Telegram quote text, or resolved transcript reference for the message being replied to.

Case 2: Telegram group reply was associated with the wrong system

In a Telegram group, a user replied via Telegram's native Reply UI with a short ambiguous question similar to:

Our reauther not working?

The message was a reply to a specific OpenClaw failure alert about a Drive backup. Because the assembled context did not include the replied-to alert, the agent inferred the wrong subsystem from the text alone and investigated a GitHub/Codex credential guard instead of the Drive backup OAuth path. The user had to correct the association manually.

Sanitized root issue: the replied-to Telegram message would have disambiguated the task immediately, but the model turn did not receive that reply target.

Expected Behavior

When Telegram sends an inbound update containing reply_to_message and/or quote data, OpenClaw should preserve that relationship into the model-visible turn in a deterministic, trusted shape.

For example, the assembled context should include something like:

{
  "reply_to": {
    "provider": "telegram",
    "message_id": "<telegram_message_id>",
    "chat_id": "<redacted_or_internal_chat_ref>",
    "thread_id": "<optional_thread_or_topic_id>",
    "author_role": "assistant|user|unknown",
    "source": "telegram.reply_to_message",
    "text_excerpt": "<sanitized replied-to text excerpt, when available>",
    "session_message_id": "<optional resolved OpenClaw transcript id>"
  }
}

If the original message is no longer available, OpenClaw should still expose a structured marker such as:

{
  "reply_to": {
    "provider": "telegram",
    "message_id": "<telegram_message_id>",
    "unresolved": true,
    "reason": "target_not_in_cache_or_update_payload"
  }
}

The model should not have to infer reply target from recency or raw prose.

Actual Behavior

The model-visible inbound context can omit the Telegram reply relationship entirely. The agent sees only the user's new text plus generic Telegram channel metadata. This makes short/ambiguous Telegram replies behave like fresh standalone messages.

Reproduction Steps

1. Configure OpenClaw with Telegram enabled and a paired direct chat.
2. Let the assistant send any normal Telegram-visible answer, for example: This is probably an OpenClaw issue, not a model issue.
3. In Telegram, use the native Reply action on that exact assistant message.
4. Send a terse reply such as ?, yes, or do that.
5. Inspect the assembled model turn / prompt context / inbound metadata for the next agent run.
6. Observe whether the model receives the Telegram reply target (reply_to_message, target message id, target text/quote, or resolved transcript reference).
7. Repeat in a Telegram group by replying to a bot/agent alert or status message with a short ambiguous phrase.

Expected Reproduction Result

The next model turn includes structured reply-target metadata and, where available, a safe excerpt of the replied-to Telegram message.

Actual Reproduction Result

The next model turn may only include:

Current user request:
?

or the ambiguous text by itself, with no reply target. The agent either guesses incorrectly or asks a clarification that should not be necessary.

Impact

• High user-facing confusion in Telegram chats, especially when users naturally reply to a specific previous message.
• Short confirmations (yes, ok, do it, ?) lose their intended object.
• Operational messages can be routed to the wrong subsystem because the disambiguating replied-to alert is missing.
• This looks like an OpenClaw ingress/context-packaging bug, not a model reasoning bug: if the replied-to text is present, the model can use it; when it is absent, it cannot reliably reconstruct it.

Related Issues

• #54186: openclaw message send not writing to transcript can also cause user replies to lack context for programmatic outbound messages. This report is specifically about Telegram native inbound reply metadata missing from the model-visible turn.
• #14032 and #19144: Telegram reply/thread metadata propagation issues in outbound/topic contexts. This report is about inbound reply target propagation into the agent/model context.

Suggested Fix Direction

• Preserve Telegram reply_to_message and quote data during inbound update normalization.
• Add a stable reply_to object to trusted inbound metadata or a separate trusted context block.
• For messages originally sent by OpenClaw, maintain or consult a provider-message-id to transcript-message mapping so the model can see the correct assistant/user message excerpt.
• Add regression tests for direct chats and group chats where the inbound Telegram message text is intentionally ambiguous (?, yes, do that) and the only way to answer correctly is via the reply target.
• If the target cannot be resolved, include an explicit unresolved reply marker rather than silently dropping the relationship.