openclaw - 💡(How to fix) Fix Telegram DMs duplicate recent conversation context despite persistent session transcript [2 pull requests]

Summary

Telegram direct messages inject a Conversation context (untrusted, chronological, selected for current message) block into every inbound user turn. That block contains roughly the last 10 Telegram messages, even when the Telegram DM is routed into a persistent OpenClaw session that already includes the full prior transcript.

This duplicates conversation history inside each new user message and significantly increases token usage.

Example

A Telegram DM user message is sent to the model with content like:

Conversation info (untrusted metadata):
...

Sender (untrusted metadata):
...

Conversation context (untrusted, chronological, selected for current message):
#6792 Thu 2026-05-28 12:49 GMT+9 User: <media:audio> ...
#6793 Thu 2026-05-28 12:50 GMT+9 OpenClaw: Update is running in the background...
#6795 ...
...

<actual user message>

The prior messages in Conversation context are already present in the persistent session transcript, so the model receives duplicated history.

Expected behavior

For a Telegram private DM that routes to an existing persistent session, OpenClaw should not inject a recent chat-window context block by default. The persistent session transcript should be the source of conversation history.

Recent chat-window context may still make sense for groups, topics, replies, fresh sessions, or non-persistent routing, but it should not be unconditionally added to normal 1:1 DMs.

Actual behavior

Telegram DMs include a supplemental Conversation context block on every inbound message.

Setting channels.telegram.dmHistoryLimit: 0 does not disable it, because this appears to be a separate code path from DM history seeding.

Environment

• OpenClaw version: 2026.5.25-beta.1 (f5b52bd)
• Channel: Telegram
• Gateway logs classify the inbound chat as direct
• Session: persistent direct session, e.g. agent:main:main

Suspected code path

The block appears to be created in the Telegram provider:

const promptContext = await buildPromptContextForMessage(params.msg, replyChainNodes, params.options);

In buildPromptContextForMessage(...), Telegram calls:

buildTelegramConversationContext({
  ...,
  recentLimit: 10,
  replyTargetWindowSize: 2,
})

and wraps it as:

{
  label: "Conversation context",
  source: "telegram",
  type: "chat_window",
  payload: {
    order: "chronological",
    relation: "selected_for_current_message",
    messages: ...
  }
}

That supplemental context is then attached as:

supplemental: {
  untrustedContext: promptContext.length > 0 ? promptContext : void 0
}

Later it is mapped to UntrustedStructuredContext and formatted into the prompt text by formatChatWindowStructuredContext(...).

Why this matters

In long-lived DM sessions, every user turn already carries the session transcript. Adding the last ~10 Telegram messages into the new user message duplicates context and causes unnecessary token/cache-write/cache-read cost. In active Telegram sessions this can become very expensive.

Suggested fix

Do not build Telegram chat-window prompt context for private DMs when the target route is already a persistent session.

A minimal fix might be:

const buildPromptContextForMessage = async (msg, replyChainNodes, options) => {
  if (msg.chat?.type === "private") return [];
  ...
}

A more nuanced fix would only include this context when needed, such as:

• group/supergroup/channel/topic messages
• replies to older messages not in the current session transcript
• fresh/non-persistent session routing
• explicit config enabling Telegram DM prompt context

It would also help to expose a config knob for this, separate from dmHistoryLimit, since dmHistoryLimit: 0 currently does not disable this behavior.