Bug: MS Teams startup resolution stores Graph group GUID as team key, but Bot Framework sends General channel conversation ID as team.id

Summary

When channels.msteams.teams config uses human-readable team names (e.g., "Automation"), OpenClaw's startup resolution correctly resolves the name to the team's Azure AD group GUID via Graph API (e.g., fa101332-cf00-431b-b0ea-f701a85fde81). However, at runtime the Bot Framework sends activity.channelData.team.id as the General channel's conversation ID (e.g., 19:[email protected]), which is a completely different format. This causes resolveMSTeamsRouteConfig() to fail team matching, and all channel messages are silently dropped with "dropping group message (not in team/channel allowlist)".

Reproduction

1. Configure channels.msteams.teams with a team name (e.g., "Automation") or the Graph API group GUID
2. Configure channels under that team with requireMention: true
3. Send an @mention to the bot in any channel
4. Observe: message dropped, no response

Diagnostic Evidence

Bot Framework channelData for a channel message:

{
  "team": {"id": "19:[email protected]"},
  "channel": {"id": "19:[email protected]"}
}

Note: team.name is not present in the Bot Framework payload.

Startup resolution log:

msteams channels resolved: Automation/General→fa101332-cf00-431b-b0ea-f701a85fde81/19:[email protected]

Drop diagnostic (with patched logger):

{
  "conversationId": "19:[email protected]",
  "teamKey": "none",
  "channelKey": "none",
  "channelMatchKey": "none",
  "channelMatchSource": "none"
}

Root Cause

In extensions/msteams/src/policy.ts, resolveMSTeamsRouteConfig() builds team candidates from:

const teamCandidates = buildChannelKeyCandidates(teamId, teamName, normalizeChannelSlug(teamName));

• teamId = 19:[email protected] (Bot Framework value)
• teamName = undefined (not sent by Bot Framework)

Config key after resolution: fa101332-cf00-431b-b0ea-f701a85fde81 (Graph GUID)

These never match → teamConfig is undefined → channels is empty → allowed is false → message dropped.

Additional Issue

The compiled runtime logger wrapper at reply-DeXK9BLT.js:82180 only passes the first argument:

debug: (message) => logger.debug?.(message)

This swallows all structured diagnostic data (teamKey, channelKey, etc.), making this bug extremely difficult to diagnose from logs.

Workaround

Use the Bot Framework's team.id value (General channel conversation ID) as the team config key instead of the Graph group GUID or team name:

{
  "channels": {
    "msteams": {
      "teams": {
        "19:[email protected]": {
          "channels": { ... }
        }
      }
    }
  }
}

Expected Fix

Startup resolution should resolve team names to the General channel conversation ID (which is what Bot Framework uses as team.id), NOT the Graph API group GUID. Alternatively, the runtime matching should try both formats.

Environment

• OpenClaw version: 2026.3.7
• Platform: macOS (Darwin 25.3.0, arm64)
• Node: 22.22.1
• Channel: MS Teams (Bot Framework)

Regression Note

This appears to be a regression in 2026.3.7 — zero drops were observed in the 2026-03-08 log. The auto-update to 2026.3.7 occurred at 2026-03-09T08:34:05.478Z, and the first drops appeared shortly after.