You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When an OpenClaw agent is connected to Microsoft Teams with both DM and channel conversations active, DM replies intermittently leak to a team channel instead of routing back to the originating DM. This appears to be the same lastChannel routing race documented in #45514 and #13332, but specific to the MSTeams plugin.
Additionally, the [[reply_to_current]] tag is fragile for DMs — if the agent produces any text on a separate line after the tag, that trailing content has no routing context and falls through to the default (public) channel.
Steps to Reproduce
Configure MSTeams with an agent that has both DM and team channel conversations active
User sends a DM to the agent
Agent processes and replies
Reply sometimes appears in the team channel instead of the DM
This is intermittent — it correlates with the team channel being the most recently active surface.
Expected Behavior
DM replies should always route back to the originating DM conversation, regardless of which surface was most recently active.
Agent-level: When using [[reply_to_current]], any multi-line response where text appears after the tag on a separate line causes that text to leak to the default channel. The tag only covers the first line.
Workaround Attempted
Instructed the agent (via system prompt) to stop using [[reply_to_current]] entirely for DMs and instead use the message tool with explicit conversation targeting + NO_REPLY. This fixes the agent-level leak but does not fix the gateway-level lastChannel race — the gateway can still misroute even when the agent does everything right.
Environment
OpenClaw: 2026.3.x (latest)
Channel: MSTeams (single-tenant Azure Bot)
OS: macOS (arm64)
Multiple surfaces active: Teams DMs + Teams channel
Reply routing should be pinned to the inbound message's channel/conversation origin at dispatch time, not derived from lastChannel on the session. The [[reply_to_current]] tag should also handle multi-line agent output gracefully (route the entire response, not just the first line).
Summary
When an OpenClaw agent is connected to Microsoft Teams with both DM and channel conversations active, DM replies intermittently leak to a team channel instead of routing back to the originating DM. This appears to be the same
lastChannelrouting race documented in #45514 and #13332, but specific to the MSTeams plugin.Additionally, the
[[reply_to_current]]tag is fragile for DMs — if the agent produces any text on a separate line after the tag, that trailing content has no routing context and falls through to the default (public) channel.Steps to Reproduce
This is intermittent — it correlates with the team channel being the most recently active surface.
Expected Behavior
DM replies should always route back to the originating DM conversation, regardless of which surface was most recently active.
Actual Behavior
lastChannel(the team channel) instead of the per-message origin (the DM). Same root cause as [Bug] Multi-channel session routing - replies go to wrong channel #45514.[[reply_to_current]], any multi-line response where text appears after the tag on a separate line causes that text to leak to the default channel. The tag only covers the first line.Workaround Attempted
Instructed the agent (via system prompt) to stop using
[[reply_to_current]]entirely for DMs and instead use themessagetool with explicit conversation targeting +NO_REPLY. This fixes the agent-level leak but does not fix the gateway-levellastChannelrace — the gateway can still misroute even when the agent does everything right.Environment
Related Issues
lastChannelroot cause)target=user:403)replyToModeignored in DMsSuggested Fix
Reply routing should be pinned to the inbound message's channel/conversation origin at dispatch time, not derived from
lastChannelon the session. The[[reply_to_current]]tag should also handle multi-line agent output gracefully (route the entire response, not just the first line).