Summary

On this OpenClaw deployment, Telegram quote/reply handling has been functional only after local runtime patching, and it regressed again later because the implementation was effectively split across two independently drifting surfaces:

• prompt-side quote/reply rendering in dist/get-reply-*.js
• runtime inbound body mapping in dist/bot-*.js

The concrete failure mode was that the prompt-side quote markers were still present, but the runtime bot bundle had drifted back to bodyForAgent: bodyText instead of passing the richer reply-aware body through to the agent.

This suggests the Telegram quote/reply path is not yet a stable first-class contract inside OpenClaw. It behaves more like a fragile composition of prompt formatting plus runtime body mapping.

This is not just asking for one bug fix in one bundled file.

The broader request is to make quoted/replied message context a supported, durable part of the inbound message model so that:

• channels like Telegram can expose reply context consistently
• the agent-visible body and metadata cannot silently diverge
• updates do not require local rebasing of built dist/* files to preserve expected reply behavior

In other words: reply context should feel like a product capability, not a lucky byproduct of two cooperating patches.

Problem to solve

Observed behavior

The inbound Telegram quote/reply path traced locally was:

dist/bot-*.js
  -> describeReplyTarget() / sessionRuntime.finalizeInboundContext(...)
  -> runInboundReplyTurn(...)
  -> dist/get-reply-*.js

The prompt-side work had already been patched so agent-visible prompt context exposed reply metadata such as:

• reply_to_* fields
• a quoted/replied reference block for request context

But a later live regression showed the runtime-side bot bundle had drifted back to plain:

bodyForAgent: bodyText

even though it was already constructing a richer reply-aware body.

The local recovery was to restore the runtime-side mapping to the equivalent of:

const agentBody = `${forwardPrefix}${bodyText}${replySuffix}`;
body: agentBody,
bodyForAgent: agentBody,

After restart, reply-aware behavior returned.

Why this is brittle

The current shape appears brittle for a few reasons:

1. The agent-visible reply experience depends on both prompt-side formatting and runtime-side body mapping staying aligned.
2. Either side can drift during updates or bundle changes.
3. The regression is easy to miss because raw Telegram reply metadata may still exist internally while the final agent-visible body silently loses the quoted/replied context.
4. Operators end up compensating with local post-update checks against built dist/* markers instead of relying on a supported upstream contract.

Proposed solution

Requested outcome

1. Define quoted/replied inbound context as a first-class internal contract for supported channels like Telegram.
2. Ensure the agent-facing body and the structured reply metadata are produced from one canonical path, not two loosely-coupled surfaces that can drift.
3. Preserve structured reply data explicitly, for example fields equivalent to:
   • replied message id
   • replied message body or quote text when available
   • whether the source was a quote vs ordinary reply
4. Make the final agent-visible input deterministic: if reply context exists, the runtime should either reliably include it in the agent body or expose it through a stable structured field that prompt generation consumes.
5. Add regression coverage for the full Telegram inbound reply/quote flow so updates cannot silently fall back to bodyForAgent: bodyText while still appearing superficially healthy.
6. If OpenClaw intends reply context to be channel-generic, document the contract so other channels can implement the same behavior consistently.

Nice-to-have

• A small integration test fixture for Telegram inbound reply payloads that verifies both:
  • structured reply metadata survives ingestion
  • the final agent-visible input reflects the reply context
• A clearer boundary between untrusted quoted message content and trusted runtime metadata, since quoted text should remain request context, not instruction-trusted content.

Alternatives considered

No response

Impact

When this drifts, the user can still be “replying” in Telegram, but the assistant loses the important reference context that makes the reply intelligible. The result is a degraded conversational experience that feels random from the user side, even though the underlying issue is a runtime contract gap.

Evidence/examples

Additional information

Environment

• Host: ClawBox-managed OpenClaw deployment
• Channel: Telegram
• Relevant installed runtime surfaces observed locally:
  • dist/bot-*.js
  • dist/get-reply-*.js

This request is based on a real regression observed in production on an OpenClaw deployment, but the ask is upstream-facing: make quote/reply context durable enough that operators do not need local dist/* patching and post-update marker checks just to preserve expected Telegram reply behavior.