Summary

When OpenClaw starts up and resolves the MS Teams channel allowlist, it queries the Microsoft Graph API for team info and stores the Graph API group GUID (e.g. fa101332-cf00-431b-b0ea-f701a85fde81) as the team key in its allowlist config. At runtime, the Bot Framework sends activity.channelData.team.id as the General channel's conversation ID (e.g. 19:[email protected]) — a completely different format. The two keys never match, so every inbound channel message is silently dropped regardless of config. This PR fixes the mismatch by resolving the General channel's conversation ID during startup and storing that as the team key instead.

Problem

Observed behavior

After configuring a Teams channel in OpenClaw, channel messages are never processed. No errors appear — messages just vanish. The configured team matches by display name at startup, the resolved: true response looks correct, but at runtime nothing gets through.

Diagnostic evidence

Patching the message handler to log activity.channelData:

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

The startup resolver stored fa101332-cf00-431b-b0ea-f701a85fde81 (Graph GUID). The runtime key is 19:[email protected] (General channel conversation ID). These never match.

A workaround confirmed the root cause: manually replacing the Graph GUID in config with the General channel's conversation ID caused messages to flow correctly.

Root Cause

The Microsoft Graph API /teams endpoint returns groups by their AAD group GUID (e.g. fa101332-cf00-431b-b0ea-f701a85fde81). This is what listTeamsByName returns as team.id.

The Bot Framework, however, identifies the team context of a channel message using the General channel's conversation ID — the 19:…@thread.tacv2 format used for all Teams conversations. These are two different identifiers for the same team, and there is no documented 1:1 mapping without calling the channels API.

resolveMSTeamsChannelAllowlist was using the Graph GUID directly as teamId in the resolved config entry. At runtime, the allowlist check compares channelData.team.id (conversation ID format) against the stored teamId (GUID format) — a comparison that can never succeed.

Fix

In resolveMSTeamsChannelAllowlist's mapInput callback, after obtaining graphTeamId (the Graph GUID), the fix:

1. Always calls listChannelsForTeam(token, graphTeamId) — necessary to find the General channel regardless of whether a specific channel was requested.
2. Finds the General channel by displayName === "general" (case-insensitive).
3. Uses the General channel's conversation ID as teamId — this matches what Bot Framework sends as channelData.team.id at runtime.
4. Falls back to the Graph GUID if the General channel is not found (renamed or deleted edge case) so resolution still succeeds rather than silently breaking.
5. Reuses the channel list when a specific channel is also configured, avoiding a redundant second API call.

// Before
const teamId = teamMatch.id?.trim(); // Graph GUID — wrong format at runtime

// After
const graphTeamId = teamMatch.id?.trim();
const teamChannels = await listChannelsForTeam(token, graphTeamId);
const generalChannel = teamChannels.find(
  (ch) => ch.displayName?.toLowerCase() === "general",
);
const teamId = generalChannel?.id ?? graphTeamId; // Conversation ID — matches Bot Framework

Testing

Unit tests (extensions/msteams/src/resolve-allowlist.test.ts):

• Updated existing test "resolves team/channel by team name + channel display name" to assert that teamId is now the General channel's conversation ID, not the Graph GUID.
• Added "uses General channel conversation ID as team key for team-only entry" — verifies team-only resolution stores the correct key.
• Added "falls back to Graph GUID when General channel not found" — verifies the edge case gracefully degrades.

All 5 tests pass:

✓ extensions/msteams/src/resolve-allowlist.test.ts (5 tests) 3ms

Manual validation: Confirmed the workaround (manually setting the General channel conversation ID as config key) makes messages flow correctly. This fix automates that resolution at startup.

Breaking Changes

None. This is fully backward compatible:

• Existing configs using a conversation ID as the team key (the manual workaround) continue to work — if the input matches the GUID regex (/^[0-9a-fA-F-]{16,}$/), it goes through listChannelsForTeam against that ID, which will still resolve correctly.
• Configs using a team display name now automatically resolve to the correct conversation ID key.
• No changes to the config file format or external-facing API.

Secondary Issue (noted, not fixed here)

The compiled logger wrapper in the MS Teams extension swallows structured data — debug() and info() only pass the first argument to the underlying logger, silently dropping context objects. This made diagnosing the root cause significantly harder. Tracked separately.

Related

Fixes #41390