Problem
When a user replies in a Teams channel thread, the bot receives only the new message — it has no context of the preceding thread messages. Combined with session pruning (session.maintenance.pruneAfter), this means agents responding in channel threads frequently lose all context, even from messages sent hours earlier.
Current behavior
- Bot receives reply in thread
- Session may have been pruned (6h default)
- Agent has zero context of what the thread was about
- Agent asks user to repeat/clarify, which is a poor UX
Expected behavior
When a message arrives as a thread reply (has replyToId / is in a conversation thread), the msteams plugin should:
- Fetch the root message + preceding N replies via Graph API (
teams/{id}/channels/{id}/messages/{id}/replies)
- Inject them as conversation history / context in the session
- Configurable limit (e.g.,
msteams.config.threadContextMessages: 10)
Workaround
We built a Graph API thread reader script and are injecting thread context manually in cron job prompts. This is fragile and doesn't cover interactive channel use.
Environment
- OpenClaw 2026.3.13
- MSTeams plugin (Bot Framework)
- App-only Graph API credentials with ChannelMessage.Read.All working
Problem
When a user replies in a Teams channel thread, the bot receives only the new message — it has no context of the preceding thread messages. Combined with session pruning (
session.maintenance.pruneAfter), this means agents responding in channel threads frequently lose all context, even from messages sent hours earlier.Current behavior
Expected behavior
When a message arrives as a thread reply (has
replyToId/ is in a conversation thread), the msteams plugin should:teams/{id}/channels/{id}/messages/{id}/replies)msteams.config.threadContextMessages: 10)Workaround
We built a Graph API thread reader script and are injecting thread context manually in cron job prompts. This is fragile and doesn't cover interactive channel use.
Environment