Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
Related to #41390 but a distinct second bug affecting groupAllowFrom matching, not just the teams config structure.
Steps to reproduce
- Configure channels.msteams.groupPolicy: "allowlist"
- Add channel conversation ID to groupAllowFrom e.g. 19:[email protected]
- Send a message in that channel
- Observe: message dropped with matchKey=none matchSource=none
Expected behavior
Message is accepted and dispatched to agent when the base conversation ID matches a groupAllowFrom entry, regardless of whether a ;messageid= suffix is present in the runtime conversation ID, and regardless of whether the thread format is @thread.tacv2 or @thread.skype. The @thread.skype format is any Team that wasn't recently created, and you cannot update that thread ID without deleting and recreating the team and losing all history (not practical). Needs to support both ID formats.
Actual behavior
Message is dropped. Bot Framework appends ;messageid=XXXXXXXXX to the conversation ID at runtime (e.g. 19:[email protected];messageid=1782XXXXXXX4) but the allowlist comparison does not strip this suffix, so the match always fails.
OpenClaw version
2026.6.9
Operating system
Debian 13 trixie x86_64
Install method
npm global
Model
z-ai/glm-5.2
Provider / routing chain
openrouter
Additional provider/model setup details
No response
Logs, screenshots, and evidence
{"sender":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","label":"Joe Blow","allowlistMatch":"matchKey=none matchSource=none"} dropping group message (not in groupAllowFrom)
Configured groupAllowFrom: 19:[email protected]
Runtime conversation ID: 19:[email protected];messageid=1782122147084Impact and severity
Affected: all msteams users using groupPolicy: allowlist with groupAllowFrom
Severity: High -- groupAllowFrom is completely non-functional, forcing groupPolicy: open as the only workaround
Frequency: 100% reproduction
Consequence: No channel-scoped access control possible. Additional impact on legacy @thread.skype teams where requireMention: false also fails -- these teams cannot be recreated or migrated to @thread.tacv2, leaving users with no path to allowlisting or mention-free operation on any legacy team.
Additional information
Tested on both @thread.tacv2 (new teams) and @thread.skype (legacy teams). Both fail identically. The fix should strip the ;messageid=... suffix from the inbound conversation ID before comparing against groupAllowFrom entries. Related open PR for #41390 may or may not cover this depending on where the match comparison happens.
Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
No
Summary
Related to #41390 but a distinct second bug affecting groupAllowFrom matching, not just the teams config structure.
Steps to reproduce
Expected behavior
Message is accepted and dispatched to agent when the base conversation ID matches a groupAllowFrom entry, regardless of whether a ;messageid= suffix is present in the runtime conversation ID, and regardless of whether the thread format is @thread.tacv2 or @thread.skype. The @thread.skype format is any Team that wasn't recently created, and you cannot update that thread ID without deleting and recreating the team and losing all history (not practical). Needs to support both ID formats.
Actual behavior
Message is dropped. Bot Framework appends ;messageid=XXXXXXXXX to the conversation ID at runtime (e.g. 19:[email protected];messageid=1782XXXXXXX4) but the allowlist comparison does not strip this suffix, so the match always fails.
OpenClaw version
2026.6.9
Operating system
Debian 13 trixie x86_64
Install method
npm global
Model
z-ai/glm-5.2
Provider / routing chain
openrouter
Additional provider/model setup details
No response
Logs, screenshots, and evidence
{"sender":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","label":"Joe Blow","allowlistMatch":"matchKey=none matchSource=none"} dropping group message (not in groupAllowFrom) Configured groupAllowFrom: 19:[email protected] Runtime conversation ID: 19:[email protected];messageid=1782122147084Impact and severity
Affected: all msteams users using groupPolicy: allowlist with groupAllowFrom
Severity: High -- groupAllowFrom is completely non-functional, forcing groupPolicy: open as the only workaround
Frequency: 100% reproduction
Consequence: No channel-scoped access control possible. Additional impact on legacy @thread.skype teams where requireMention: false also fails -- these teams cannot be recreated or migrated to @thread.tacv2, leaving users with no path to allowlisting or mention-free operation on any legacy team.
Additional information
Tested on both @thread.tacv2 (new teams) and @thread.skype (legacy teams). Both fail identically. The fix should strip the ;messageid=... suffix from the inbound conversation ID before comparing against groupAllowFrom entries. Related open PR for #41390 may or may not cover this depending on where the match comparison happens.