Summary

Handle signin/tokenExchange and signin/verifyState invoke activities for Bot Framework OAuth SSO and magic code authentication flows.

Problem to solve

When a bot sends an OAuthCard or uses the Bot Framework Token Service for SSO, Teams sends signin/tokenExchange and signin/verifyState invoke activities back to the bot. The msteams plugin does not handle these invoke types — they fall through and are silently dropped, causing "Something went wrong" in the Teams card UI.

Without this, bots cannot complete OAuth SSO flows. Delegated Graph API permissions (per-user SharePoint search with security trimming, user-scoped email/calendar access) are blocked. Users must fall back to a manual magic code flow via sign-in URLs.

Proposed solution

Add handlers for signin/tokenExchange and signin/verifyState in monitor-handler.ts alongside the existing fileConsent/invoke and message/submitAction handlers:

if (ctx.activity?.type === 'invoke' && ctx.activity?.name === 'signin/tokenExchange') {
  await ctx.sendActivity({ type: 'invokeResponse', value: { status: 200, body: {} } });
  // Forward token data to agent
  return;
}

if (ctx.activity?.type === 'invoke' && ctx.activity?.name === 'signin/verifyState') {
  await ctx.sendActivity({ type: 'invokeResponse', value: { status: 200, body: {} } });
  // Forward verification state to agent
  return;
}

The invokeResponse with status 200 must be sent immediately to prevent the Teams UI timeout error.

Alternatives considered

Current workaround: We run a sidecar HTTP proxy that intercepts these invokes before they reach OpenClaw, sends invokeResponse 200, caches the delegated token to a shared volume, and forwards a synthetic text message to the agent. This works but adds operational complexity.

Magic code fallback: Instead of OAuthCards, we generate sign-in URLs via the Token Service API, send them as clickable text links, and have the user paste a 6-digit code back. This bypasses the invoke entirely but is a poor UX.

Impact

Affected: All Teams bot users needing delegated Graph API permissions (OAuth SSO)
Severity: High — blocks per-user SharePoint search, email drafts, calendar access
Frequency: Every OAuth sign-in attempt
Consequence: Delegated permissions impossible without sidecar workaround; must use manual magic code flow

Evidence/examples

Related: Issue 55384 / PR 60431 fixed adaptiveCard/action invoke forwarding. This issue covers two additional invoke types (signin/tokenExchange, signin/verifyState) in the same handler chain.

Environment: OpenClaw latest (includes PR 60431), msteams stock plugin, Azure Bot Single Tenant with OAuth Connection (Azure Active Directory v2), Microsoft Teams desktop + web.

Additional information

The relevant code is in extensions/msteams/src/monitor-handler.ts — the same handler chain that processes fileConsent/invoke and message/submitAction. The fix adds two more invoke name checks in the same pattern.

This is the companion to issue 60952 (messageBack card actions). Together with PR 60431 (adaptiveCard/action), these three changes would cover all common Teams invoke activity types.