Summary

OpenClaw 2026.5.28 with the Microsoft Teams channel enabled delivers every assistant reply twice: once as a streamed/typing preview, then again as a separate finalized MessageActivity. The two are not merged in the Teams client — both persist as visible bubbles in the conversation.

This affects normal-length replies, not just large ones. Disabling streaming (channels.msteams.streaming.mode: "off") is a viable workaround, but live progress streaming becomes unavailable on Teams.

Environment

• OpenClaw version: 2026.5.28
• Install method: container image built FROM ghcr.io/nvidia/openshell-community/sandboxes/openclaw:latest with extra plugin layer (@openclaw/[email protected], @openclaw/[email protected], @martian-engineering/lossless-claw)
• OS: Ubuntu 24.04 in K3s on Docker on Ubuntu 24.04
• Node: v22.22.2
• Channel: channels.msteams with native config (no custom streaming overrides — bug occurs on defaults)
• Provider: bifrost-claude/claude-opus-4-8 via Bifrost v1.5.7 → Azure AI Foundry Anthropic endpoint
• Last working version: 2026.5.7 (NemoClaw was on 5.7 prior to the 5.28 upgrade yesterday; this duplicate behavior started immediately after the image swap)

Steps to reproduce

1. Install OpenClaw 2026.5.28 with channels.msteams.enabled: true.
2. Do not set channels.msteams.streaming.mode — let it default.
3. Send any non-trivial message from a Teams user (DM or group chat).
4. Observe the Teams DM/channel: the reply appears as a streaming preview, then the same reply appears again as a fresh message bubble immediately below.

Expected behavior

The Teams native streaming transport (pushStreamChunk + addStreamFinal()) should result in one visible message: the streaming preview gets replaced in place by the final MessageActivity carrying the streamFinal marker.

Actual behavior

The typing preview and the streamFinal message both persist as separate bubbles. Users see every reply duplicated.

What we've ruled out

• Model called twice: the session JSONL on disk shows one assistant turn entry per user message. The model is being invoked once. The duplication is purely in delivery.
• Slack-side issue: same gateway version handles Slack replies on our spark fleet without duplicates.
• Microsoft Teams client/service issue independent of OpenClaw: unlikely. NemoClaw worked correctly on 2026.5.7 immediately before the 5.28 upgrade. No Teams client change in that window.
• [Bug]: [Teams] Duplicate message rendering — same response appears twice in chat #70178 (closed): fixed the large-response duplicate via createTeamsReplyStreamController.preparePayload() and TeamsHttpStream.update(). Our duplicates happen on small and large replies, so the fallback-suppression path that fix introduced may have an unhandled case in 5.28.

Workaround

{
  "channels": {
    "msteams": {
      "streaming": { "mode": "off" }
    }
  }
}

Each reply now becomes one final MessageActivity posted via the normal delivery path. UX loses the live-typing preview but the duplication is gone.

Source-code area to investigate

Based on what we traced inside our deployed image:

• extensions/msteams/src/reply-stream-controller.ts (per [Bug]: [Teams] Duplicate message rendering — same response appears twice in chat #70178's fix description) — particularly preparePayload() and the fallback-delivery suppression
• extensions/msteams/src/streaming-message.ts — update() and finalize() paths
• The vendored @microsoft/teams.ai flush/close: the bundled dist-CmqLk4zC.js (line ~1893) shows flush() pushing TypingActivity chunks while building finalActivity, and close() constructing new MessageActivity(this.text).addStreamFinal() and calling this.send(activity)

The most likely culprit is that reply-stream-controller.ts is no longer detecting that the streamed text already covered the reply, so it falls through to the fallback delivery path and posts the final message regardless.

Cross-references

• [Bug]: [Teams] Duplicate message rendering — same response appears twice in chat #70178 — Closed Apr 2026, same symptom (Teams duplicate rendering) but different root cause (large-response fallback path). Fix shipped in v2026.4.23. We are on 2026.5.28, which should include that fix.
• [Bug]: 5.28 regression — reasoning/thinking content leaks into QQBot replies (regression of #6470) #89913 — Open June 3 2026, QQBot reasoning content leak in 5.28 — confirms 5.28 has a class of streaming-sanitization regressions. This Teams duplicate is plausibly the same family.

Impact

High for Teams-based deployments. Every assistant message is duplicated, which:

• Doubles message count in chat history, distorting context window when replayed
• Confuses users (we have reproduced this with multiple users in multiple Teams chats)
• Doubles outbound API call rate on the Teams bot framework
• Forces administrators to choose between no streaming (this workaround) or user-visible duplication

Affected platform: Microsoft Teams (the duplicate does not appear on Slack, Discord, Telegram, or other channels in our testing).