Summary

OpenClaw has a broader class of duplicate transcript, replay, and context assembly bugs that show up across multiple channels and runtime paths.

These bugs are currently reported as separate issues in MSTeams, webchat, Telegram, followup queue handling, delivery-mirror consumer paths, bootstrap reinjection, and overflow recovery. The individual symptoms differ, but the reports cluster around a few recurring themes:

1. The same logical inbound or outbound turn is persisted more than once.
2. Internal transcript artifacts leak into user-facing or model-facing consumer paths.
3. Queue, replay, or recovery flows re-deliver or re-append already processed content.
4. Session history and context assembly do not consistently enforce idempotency.

This issue is the umbrella tracker for that broader problem family.

Why This Umbrella Exists

Several reports initially look channel-specific, but the evidence now points to a cross-cutting runtime problem rather than a single MSTeams-only or webchat-only defect.

Examples:

• MSTeams issue #67323 reports duplicate user context in DM sessions.
• Comments on #67323 report the same pattern on Feishu DM and webchat.
• #66443 reports repeated role=user entries during overflow recovery.
• #67419 reports repeated bootstrap context reinjection and includes additional findings about duplicate user messages around model-snapshot and bootstrap entries.
• Webchat issues such as #38061 and #39469 show duplicate assistant entries caused by delivery-mirror entries leaking into consumer paths.
• #30604 and #39795 show queueing and streaming paths that can redeliver or visibly duplicate messages.

The point of this umbrella is not to claim every listed issue is the exact same bug. The point is that they are close enough in symptom shape, transcript effects, and likely fix boundaries that we need one place to track the shared analysis and prevent fragmented fixes.

Related Issues

Core session and replay duplication

• #67323 [Bug]: MSTeams DM inbound messages appear duplicated in agent session context
• #66443 Overflow recovery duplicates role=user messages in session JSONL, amplifying transcript growth
• #67419 Session context bloat: bootstrap files re-injected every turn, wasting 20-30% tokens

Delivery-mirror and consumer-path leakage

• #33263 [Bug]: Webchat duplicates assistant replies via delivery-mirror transcript entry
• #38061 [Bug]: Webchat shows duplicate assistant messages because chat.history returns delivery-mirror transcript entries as normal assistant messages
• #39469 BUG: Control UI (webchat) double-records assistant messages in session JSONL

Queue, followup, and replay delivery duplication

• #30604 Followup queue delivers same message multiple times when agent is busy

Channel or transport specific duplicate delivery races

• #30316 [Bug]: Telegram duplicate messages, text and audio sent twice
• #39795 Telegram streaming partial creates duplicate messages due to generation counter race

Related PRs

Partial mitigations or earlier fixes

• #17340 fix(auto-reply): prevent duplicate transcript entries for followup queue messages
• #61268 perf(agents): add continuation-skip context injection

Open work that may mitigate part of this umbrella

• #40716 fix: filter delivery-mirror from all consumer paths (LLM context, webchat, API)
• #67447 Agents: default context injection to continuation-skip

Current Working Hypotheses

1. Session persistence and replay need stronger idempotency guarantees

There are multiple reports where the same logical user or assistant turn appears more than once in persisted session history. This suggests that replay, recovery, or transcript-write paths can re-append entries without a strong enough stable identity check.

Examples:

• same user message appears twice after model-snapshot
• repeated user entries during overflow recovery
• followup queue replay after the original item has already been delivered

2. Internal transcript artifacts are not consistently filtered from all consumer paths

Some entries appear to be intended as audit or routing artifacts rather than canonical conversational turns. Delivery-mirror is the clearest example. When those entries leak into chat history, session APIs, or model context, they become visible duplicates rather than internal metadata.

Examples:

• webchat duplicate assistant messages via delivery-mirror
• LLM context polluted by delivery-mirror or replayed transcript artifacts

3. Context assembly and bootstrap continuation handling are only partially solved

continuation-skip can reduce one kind of repeated bootstrap injection, but reports indicate that it does not fully solve duplicate user-message replay or all transcript growth paths.

Examples:

• #67419 describes bootstrap reinjection waste
• comments there and on #67323 describe duplicate user turns continuing even when bootstrap repetition is reduced

4. Some channel-specific duplicate reports may still need local hardening even if the main root cause is shared

Even if the broad issue is in session/transcript handling, channels may still need local dedupe or retry protection.

Example:

• MSTeams uses activity.id for metadata and routing, but the current evidence does not yet show a dedicated inbound idempotency guard that drops a repeated activity before it reaches session/state handling.
• Telegram streaming partial has an apparent generation-race path that may be channel-local even if it fits the same family.

What This Umbrella Should Track

1. Which of these issues are truly the same root cause versus only adjacent symptoms.
2. Whether the shared fix belongs in session persistence, replay sanitization, queueing, context assembly, channel ingress, or consumer filtering.
3. Which issues are solved by filtering artifacts from consumer paths only, and which require preventing duplicate persistence in the first place.
4. Which issues remain channel-local and should stay separate even if they are linked here.

Proposed Breakdown for Fixes

Track A: Prevent duplicate persistence

Goal:

• stop the same logical inbound or outbound turn from being appended more than once

Likely areas:

• session writer
• replay and recovery paths
• queue redelivery tracking
• idempotency keyed on stable message identity

Primary issues:

• #67323
• #66443
• #30604

Track B: Filter internal artifacts from consumer paths

Goal:

• keep internal transcript artifacts out of model context, chat history, and sessions APIs unless explicitly requested

Likely areas:

• delivery-mirror filtering
• sessions API filtering
• webchat and history consumer paths
• context sanitization before model assembly

Primary issues:

• #33263
• #38061
• #39469
• #40716

Track C: Reduce repeated bootstrap/context reinjection

Goal:

• stop repeated injection of stable bootstrap context on normal continuation turns

Likely areas:

• contextInjection defaults
• continuation detection
• prompt assembly

Primary issues:

• #67419
• #61268
• #67447

Track D: Channel-local duplicate delivery races

Goal:

• fix races or duplicate-visible transport behavior that are specific to one provider implementation

Likely areas:

• Telegram streaming state transitions
• provider-local preview/final handoff logic
• channel retry protection

Primary issues:

• #30316
• #39795

Suggested Exit Criteria

We should not close this umbrella until all of the following are true:

1. We can explain which linked issues were the same root cause and which were only adjacent.
2. Duplicate persistence of the same logical user or assistant turn is prevented in the known shared paths.
3. Internal transcript artifacts no longer leak into user-facing history or model-facing context in known consumer paths.
4. Bootstrap continuation behavior is no longer causing unnecessary repeated context growth by default.
5. Any remaining channel-specific duplicate races are either fixed or explicitly split out as independent issues.

Notes On Issue Closure

This umbrella should not automatically replace every linked issue.

Open issues that still contain unique reproductions, unique affected surfaces, or unresolved channel-specific behavior should stay open until their exact symptom is verified fixed.

This issue is intended to centralize analysis and linkage, not to erase the concrete reports.