Fixes #87566

Summary

Telegram private DMs that route to a persistent OpenClaw session (e.g. agent:main:main) were receiving a duplicated Conversation context (untrusted, chronological, selected for current message) block on every inbound user turn. The block contains the last ~10 cached Telegram messages — but those messages are already in the persistent session transcript, so the model saw the same history twice and paid for it twice on every turn.

This change suppresses the chat_window prompt-context block when (and only when):

1. The chat is a Telegram private DM — no group, no supergroup, no channel.
2. The chat has no topic/thread id — DM-topics and forum topics still get the chat_window.
3. The route resolves to a session with prior activity (readSessionUpdatedAt returned a timestamp). Fresh sessions still get the chat_window.

No new config knob is introduced; the new behaviour is default-correct for the issue's repro and matches the clawsweeper "narrow session-aware suppression" recommendation.

Root cause

extensions/telegram/src/bot-handlers.runtime.ts builds a chat_window entry from the Telegram message cache on every inbound message via buildPromptContextForMessage → buildTelegramConversationContext({ recentLimit: 10, replyTargetWindowSize: 2 }), then extensions/telegram/src/bot-message-context.session.ts unconditionally attaches it as supplemental.untrustedContext. The persistent session transcript already covers that history, so for 1:1 DMs the block is pure duplication.

The fix lands at the attachment site in bot-message-context.session.ts, where we already have:

• isGroup (from the route classifier)
• threadSpec.id (forum / DM topic id, if any)
• previousTimestamp = sessionRuntime.readSessionUpdatedAt({ storePath, sessionKey: route.sessionKey }) — the per-session updated-at, which is exactly the "has this session already been written to?" signal we need to distinguish persistent-with-transcript from fresh.

The filtering logic lives in a tiny pure helper (bot-message-context.prompt-context-filter.ts) so it is unit-testable independent of the bot.

Minimal reproduction

A two-turn Telegram DM into a persistent session (agent:main:main):

Turn 1 (cached): #6792  User    : "Can you finish the deploy?"
Turn 1 (cached): #6793  OpenClaw: "Update is running in the background…"
Turn 2 (inbound now): #6795 User: "and the release notes?"

Before (every user turn duplicates recent history)

…
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    : Can you finish the deploy?
  #6793 Thu 2026-05-28 12:50 GMT+9 OpenClaw: Update is running in the background…
  #6795 Thu 2026-05-28 12:55 GMT+9 User    : and the release notes?
[/Conversation context]

and the release notes?

(Persistent session transcript already contains #6792 + #6793 → those two are now sent twice on every turn.)

After

…
Conversation info (untrusted metadata): …
Sender (untrusted metadata): …

and the release notes?

Reply-chain / quote / forwarded context is preserved separately via supplemental.quote, supplemental.forwarded, and extra.ReplyChain, so dropping the chat_window does not lose reply context.

Token-impact estimate

On long-lived 1:1 Telegram DMs the duplicated block grows linearly until it stabilises at recentLimit: 10 messages. With OpenClaw's typical 200–400-token envelope per cached message, that is ~2–4k extra tokens per inbound turn appended to user content (which also defeats prefix caching), in line with @piazzatron's "~5x token burn" comment on a 1:1 session that otherwise carries only a short transcript per turn. Group / topic / reply / fresh-session paths are unchanged.

Architecture affected

Telegram inbound flow:

on("message")
  → bot-handlers.runtime.ts: processMessageWithReplyChain
      → buildPromptContextForMessage  ← still builds chat_window unchanged
      → processMessage
          → bot-message-context.session.ts: buildTelegramChannelInboundEventContext
              ↳ resolveTelegramConversationRoute → route.sessionKey, mainSessionKey
              ↳ sessionRuntime.readSessionUpdatedAt({ storePath, sessionKey })  ← persistent-vs-fresh signal
              ↳ filterTelegramPromptContextForPersistentDm(promptContext, { isGroup, threadId, previousTimestampMs })  ← NEW
              ↳ supplemental.untrustedContext = effectivePromptContext
                  → channel-inbound prompt formatter → "Conversation context (…)"

The decision lives entirely inside the Telegram extension; the channel-inbound formatter, prompt assembly, and session transcript paths are untouched.

Behaviour matrix

Tests

Two new test files exercise the fix; both fail without it and pass with it.

extensions/telegram/src/bot-message-context.prompt-context-filter.test.ts — 11 pure unit tests of the suppression decision and the entry filter (group vs private, topic vs no-topic, persistent vs fresh, mixed entry types, identity / no-op semantics, edge-case timestamps).

extensions/telegram/src/bot.test.ts — 5 new integration tests under describe("Telegram chat_window suppression for persistent DMs (#87566)"):

1. Private DM, persistent session → no chat_window in UntrustedStructuredContext.
2. Private DM, fresh session (no previousTimestampMs) → chat_window present.
3. Group chat, persistent session → chat_window present.
4. Private DM with reply target, persistent session → chat_window suppressed, but ReplyChain preserved.
5. Group topic (message_thread_id), persistent session → chat_window present.

Acceptance criteria — node scripts/run-vitest.mjs output

extensions/telegram/src/bot.test.ts:

 ✓ extension-telegram ../../extensions/telegram/src/bot.test.ts (77 tests) 4513ms
 Test Files  1 passed (1)
      Tests  77 passed (77)

extensions/telegram/src/message-cache.test.ts:

 ✓ extension-telegram ../../extensions/telegram/src/message-cache.test.ts (16 tests) 14ms
 Test Files  1 passed (1)
      Tests  16 passed (16)

New filter unit tests:

 ✓ extension-telegram ../../extensions/telegram/src/bot-message-context.prompt-context-filter.test.ts (11 tests) 1ms
 Test Files  1 passed (1)
      Tests  11 passed (11)

Out of scope

• This PR does not change dmHistoryLimit semantics; the issue notes that knob is on a separate code path. The new behaviour is the default and needs no config opt-in or opt-out.
• Named-account DMs that route to a per-account persistent session (e.g. agent:main:telegram:atlas:direct:alice-shared) are treated identically to default-account DMs because the suppression decision uses previousTimestamp on the resolved sessionKey, not the literal mainSessionKey value.
• The chat_window build itself in buildPromptContextForMessage is left intact (it is still cheap and used by groups/topics/fresh sessions); we only filter at the attachment site. This keeps the surgery minimal and the suppression decision in one place.

CHANGELOG

Added under ## 2026.5.28 → ### Fixes.