openclaw - 💡(How to fix) Fix [Feature]: MSTeams channel-bound agents need opt-out from per-thread sessions

Bug type

Behavior / configuration gap

Summary

For Microsoft Teams channel-bound agents, OpenClaw currently forces channel thread replies into per-thread sessions after the #58615 fix. That is correct for many use cases, but it breaks agents that are intentionally bound to a whole Teams channel and expected to maintain a single continuous channel memory.

Concrete local example:

agent:pm:msteams:channel:19:[email protected]

After the Teams thread isolation changes, inbound channel replies are routed into fragmented sessions such as:

agent:pm:msteams:channel:19:[email protected]:thread:1778514795196
agent:pm:msteams:channel:19:[email protected]:thread:1778514795196:thread:1778515055246

The nested :thread:OLD:thread:NEW shape is related to #66771, but even after that is fixed, the remaining problem is that some Teams channel agents should not be split per thread at all.

Expected behavior

There should be a supported configuration option to keep a Teams channel-bound agent on the canonical channel session key for all messages in that channel, including replies inside Teams threads.

For example, a channel-bound PM agent should keep using:

agent:pm:msteams:channel:19:[email protected]

instead of automatically forking into:

agent:pm:msteams:channel:19:[email protected]:thread:<messageId>

Actual behavior

OpenClaw currently applies Teams channel thread session isolation globally. This can fragment channel-bound agents across many thread sessions, causing the agent to appear to forget prior channel context.

In one production channel, recent inspection found:

• 72 total PM sessions
• 57 matching the PM Teams channel base
• 56 thread sessions
• 52 nested thread sessions

This makes a channel-level PM agent behave like many separate thread-local agents.

Why this is not just #58615 or #66771

• #58615 fixed cross-thread context bleed by introducing per-thread isolation. That is useful and should remain available.
• #66771 addresses malformed nested keys like ...:thread:OLD:thread:NEW.
• This issue is about a missing policy/config choice: some channel-bound agents need canonical channel memory, not thread-isolated memory.

So the desired behavior is not “remove thread isolation”. It is “make Teams channel thread isolation configurable per channel/agent/session-binding policy”.

Proposed solution

Add an explicit policy/config option for MSTeams channel session routing, for example one of:

{
  "channels": {
    "msteams": {
      "threadSessionPolicy": "thread" // current default
    }
  }
}

with supported values like:

• thread — current behavior: Teams channel thread replies use per-thread sessions
• channel — channel replies stay on the canonical channel session

Or, if this belongs in the existing session/thread binding config, expose it there with enough granularity to apply to channel-bound agents only.

A local hotfix that restored the desired behavior was:

function resolveMSTeamsRouteSessionKey(params) {
  if (params.isChannel) return params.baseSessionKey;
  return resolveThreadSessionKeys({
    baseSessionKey: params.baseSessionKey,
    threadId: undefined,
    parentSessionKey: undefined,
  }).sessionKey;
}

That is not proposed as the global default, only as the behavior needed behind an opt-in config/policy.

Impact

For Teams channels where OpenClaw acts as a project-management or operations agent, fragmenting by Teams thread loses the intended shared channel memory. Users experience this as the agent “forgetting” instructions, project context, and prior channel decisions.

This is especially painful for long-lived channel agents used for project coordination.

Version / environment

Observed locally after update to:

OpenClaw 2026.5.7
msteams bundled/external plugin at @openclaw/msteams

The behavior was initially expected to be fixed around 2026.4.9, but that fix addressed #58615 by adding thread isolation. This issue asks for a supported way to opt out of that isolation for channel-level agents.

Related issues / PRs

• #58615 — msteams channel threads share the same session key / cross-thread context bleed
• #66771 — malformed mixed thread session key from old-session reselection
• #59294 — fix(msteams): isolate thread sessions, outbound targeting, and attachment resolution
• #78850 — normalize pre-suffixed thread session keys