Bug type

Behavior bug (incorrect output/state without crash)

Summary

In MSTeams channel-thread usage, I observed a malformed session key with two :thread: suffixes instead of a single clean thread-qualified key.

Observed production example:

agent:main:msteams:channel:19:ca40d1f8e22a428db72a0dec922e0a1f@thread.tacv2:thread:1775961751186:thread:1775973460425

The strongest current interpretation is that an old thread session was selected first, and then the new thread id was appended afterward, producing a mixed key of the form:

...:thread:OLD_THREAD_ID:thread:NEW_THREAD_ID

This appears related to MSTeams thread/session isolation problems, but it is not identical to the already reported issue where different channel threads collapse to the same base session key.

Version

• OpenClaw: investigated on local environment updated to around 2026.4.12 / 2026.4.14
• Channel: msteams

Expected behavior

A Teams channel thread should resolve to exactly one clean thread-qualified key, for example:

agent:main:msteams:channel:19:...@thread.tacv2:thread:1775973460425

It should not produce a mixed or doubly-threaded key.

Actual behavior

A malformed key was observed where:

• an old thread id remained in the selected session path, and
• the new thread id was appended afterward,
• resulting in a double-thread key.

This can plausibly lead to wrong-thread routing, duplicate session entries, confusing UI/session state, and continued conversation on the wrong prior context.

Why this seems distinct from #58615

Issue #58615 describes a simpler failure mode:

• different threads in the same Teams channel share the same base session key

The present symptom is different:

• a session key already containing one thread id appears to be reused or reselected
• then another thread id is attached
• yielding ...:thread:old:thread:new

So even if #58615 explains one class of thread-isolation failure, it may not fully explain this mixed-key failure.

Current root-cause hypothesis

The current best explanation is:

1. old-session reselection happens first
2. then normal new-thread attachment happens afterward
3. the malformed mixed key is created as a result

At the moment, the most plausible fault-domain is not the visible normal thread-attach logic alone, but some session reselection path around:

• conversation-binding resolution (resolveByConversation(...)-style path), and/or
• native target-session / command-target injection

Additional observations

• The malformed key is most naturally explained by old-session reselection before final new-thread attachment.
• A strongest old-session candidate during local investigation was:
  • fccdc361-9cc5-4138-84eb-51d23e12560a
• A malformed-derived observed session entry was:
  • 518b40fd-3292-43b0-92ff-3f000f3ffcca
• Visible normal MSTeams message-flow code alone did not appear to be the strongest primary culprit.
• Investigation also suggested that persisted conversation-binding / current-conversation selection could be relevant, but I do not want to overstate that as confirmed root cause yet.

Impact

This matters because a fix that only ensures "append the current thread id" may be insufficient if an incorrect prior session can still be reselected before that append step.

Reproduction status

I have confirmed this from production/local investigation and persisted session artifacts, but I do not yet have a minimal fresh-room reproduction recipe that isolates the exact responsible reselection path.

So this report is currently best treated as:

• confirmed malformed-key symptom
• plausible root-cause direction
• further tracing still needed for precise reproducer

Related issue

• [Bug]: msteams channel threads share the same session key (cross-thread context bleed) #58615