Hey folks! 👋 Quick context before you dive in: I'm one of the maintainers of @microsoft/teams.ts — the TypeScript SDK this PR migrates onto. Happy to answer questions about the SDK side and help reconcile any incompatibilities.

The Microsoft Bot Framework SDK is deprecated and its patterns predate Teams as a first-class platform. The "boilerplate tax" of staying on it shows up clearly in this diff — most of the ~1300 deleted lines are things like a custom JWT validator, a no-op HTTP adapter, hand-rolled streaming-card protocol with streaminfo entities, manual REST calls to the Bot Connector for sends/edits/deletes, and a custom turn-context shim. The new @microsoft/teams.apps SDK absorbs all of that into typed, supported primitives (ExpressAdapter, tokenManager, ctx.stream, app.api.conversations.activities(), typed invoke routes for card.action / file.consent.*, and SDK-owned sign-in routes). That's why the diff is net negative even though it adds substantive new functionality (proper streaming with feedback loops, Action.Execute card handling, fixed edit/delete plumbing).

🤖 AI-assisted: built and validated end-to-end with Claude (Sonnet 4.6 + Opus 4.7) over multiple live Teams app + devtunnel sessions. Author has reviewed the diff. Degree of testing: full regression-pass against the closed-issue history of the msteams plugin — see "Validated end-to-end" below.

Summary

Migrate the msteams plugin from the legacy Bot Framework SDK to @microsoft/teams.apps 2.0.x.

The migration replaces ~580 lines of custom plumbing (JWT validator, HTTP adapter shim, manual REST calls, token casting, custom streaming protocol) with built-in SDK primitives. Migration scope (extensions/msteams/ + lockfile/workspace metadata): +1518 / -3608 lines, net -2090. Drops the plugin-local jsonwebtoken / jwks-rsa validator stack; JWT validation is now delegated to the Teams SDK. The plugin keeps direct SDK deps on @microsoft/teams.api and @microsoft/teams.apps.

Why

The old Bot Framework SDK forced us to:

• maintain our own multi-issuer JWT validator with JWKS rotation
• run a no-op HTTP adapter just to register routes
• cast tokenManager results through unknown because internals weren't typed
• implement Teams streaming protocol (streaminfo entities + sequence numbers + stream IDs) ourselves
• manually POST to serviceUrl/v3/conversations/... for sends, edits, deletes

@microsoft/teams.apps 2.0.x ships all of this. Migrating reduces surface area we own, removes deps with their own audit footprint, and gets us on the Microsoft-supported codepath for future protocol changes.

Bugs fixed (not refactor-only)

This PR finishes the SDK migration started in earlier commits. It is not a refactor-only PR — it fixes concrete user-visible bugs introduced when the SDK swap left adapter mismatches behind:

1. Streaming card never closed. The new SDK's ctx.reply() runs typing activities through TypingActivity.from() which strips our custom streaminfo entities. Our sendActivity mapping was routed through reply(), so streaming chunks went out without correlated stream IDs and Teams never collapsed the streaming card to the final message. Fixed by routing sendActivity → ctx.send() and replacing the entire custom streaming pipeline with the SDK's built-in ctx.stream.
2. Final streamed message had no AI-generated badge or thumbs up/down. The custom streaming impl wired feedback via feedbackLoopEnabled channelData on each chunk; the SDK's HttpStream.close() only carries entities/channelData accumulated from emitted MessageActivitys. Fixed by emitting an empty final MessageActivity with addAiGenerated() + addFeedback() channelData before close().
3. Adaptive card button clicks silently failed. Our poll card used Action.Submit + msteams.type: "messageBack" — a legacy Bot Framework pattern. With the new SDK, button clicks never reached the bot at all (zero log entries). Fixed by migrating the poll card to Action.Execute (Universal Action Model) and registering app.on('card.action', ...) that returns a real typed InvokeResponse. Without the typed response, Teams shows "Unable to reach app" after the 5s invoke timeout.
4. Edit and delete didn't work. ctx.updateActivity / ctx.deleteActivity don't exist on the new SDK context — only on the old Bot Framework TurnContext. Calls were silently failing. Fixed by wiring them through app.api.conversations.activities(id).update/delete() in adaptSdkContext.
5. ctx.sendActivity({ type: "invokeResponse" }) quietly POSTed garbage. The new SDK has no special-case for invokeResponse activities; our adapter routed them to ctx.send() which POSTed them to Bot Framework as regular outbound activities. Bot Framework rejected them silently. File-consent, card, and feedback invokes now use SDK route/return semantics; SSO intentionally stays on the SDK's built-in sign-in routes so Teams gets the right 200/412 fallback behavior.
6. Test fixtures referenced an adapter field that no longer existed. The original migration commit renamed MSTeamsMessageHandlerDeps.adapter → app but three test fixtures (monitor-handler.adaptive-card.test.ts, monitor-handler/message-handler.test-support.ts, monitor-handler/reaction-handler.test.ts) and one test (monitor.lifecycle.test.ts) didn't get updated. Caught by the changed-gate now.
7. Contract test stale. package-manifest.contract.test.ts still expected jsonwebtoken and jwks-rsa in msteams's plugin-local deps — both were removed in the original migration commit (the SDK does JWT validation internally now).
8. Lint debt left over from earlier auth refactor. Unused appId destructures in five places in send.ts, an unused MSTEAMS_WEBHOOK_MAX_BODY_BYTES const + import in monitor.ts, an orphaned requireConversationId test helper, and String(token) triggering no-base-to-string in sdk.ts. All caught by pnpm check:changed.

Items 1–5 are user-visible Teams bugs caused by the SDK shape mismatch; 6–8 are gate-blocking debt left in the prior commit.

Follow-up fixes

These six fixes landed on top during a regression-test pass. Each is its own commit so they can be reviewed independently.

1. Thread routing for channel and group-chat replies. (regression fix) adaptSdkContext now uses ctx.reply() for channels/groupChats (so the SDK threads outbound activities to the inbound's replyToId/serviceUrl) and ctx.send() only for personal DMs (where reply()'s blockquote-prepend is ugly). Companion fix in messenger.ts:sendProactively passes resolvedThreadId on the non-thread fallback so channel @mentions that route through outbound.ts → send.ts still land in the original thread. Live-validated: thread reply → bot reply in same thread, no top-level leak.

2. OpenClaw User-Agent on outbound SDK calls. (observability) New buildOpenClawUserAgentFragment() returns just OpenClaw/<version>. Teams SDK 2.0.11 merges that with its own teams.ts[apps]/<sdk-version> identifier even when OpenClaw passes plain client headers, so the final UA looks like teams.ts[apps]/<sdk-version> OpenClaw/<openclaw-version>. Lets the Teams backend identify OpenClaw traffic for usage telemetry.

3. StreamCancelledError when user presses Stop mid-stream. (regression fix) Real, gateway-crashing regression found during the regression-test pass. SDK throws StreamCancelledError synchronously from stream.emit/update when Teams replies 403 to the next chunk update (Stop button or 2-min timeout). Old custom TeamsHttpStream either swallowed cancel or didn't expose this exception type, so the migration inherited an SDK behavior the original code didn't have to handle. Result: Node 24 unhandled rejection → process crash → Docker restart, ~2 minutes after each Stop click. Fixed with try/catch around all stream.emit/update/close calls + wasCanceled latch that drops the would-be block fallback (so no duplicate message lands) and suppresses typing-keepalive (so no zombie typing pulses for the rest of the agent run). 6 new regression tests cover the crash and dedupe scenarios.

4. SDK streaming delta tracking + app.reply for proactive thread sends. (one regression fix and one refactor, in the same commit)

   • Streaming delta tracking (regression fix) — the SDK's HttpStream.emit appends each chunk to its internal buffer (this.text += activity.text), but the channel reply pipeline emits cumulative text on each chunk. Forwarding cumulative into an appending sink produced "chunk1 + chunk1chunk2 + chunk1chunk2chunk3..." duplication for streamed (DM) replies. Track the emitted prefix length in the stream controller and only forward the new tail.
   • app.reply() in messenger.ts:sendProactively (refactor, not a regression fix — mechanically equivalent to the manual URL build it replaces) — replaced the manual ${convId};messageid=${msgId} URL construction with app.reply(), which builds the threaded conversation id via the SDK's own toThreadedConversationId helper. Removes coupling to Teams' URL format and tracks any future SDK changes; the threaded-proactive-reply behavior was already correct via follow-up fix: add @lid format support and allowFrom wildcard handling #1's resolvedThreadId plumbing. Adds the reply method to the structural MSTeamsApp type so the refactor typechecks without casts.

5. Bump @microsoft/teams.api and teams.apps to 2.0.11. (dependency bump that resolves Codex review items) 2.0.10 includes the AAD v1 token issuer support from microsoft/teams.ts#556, and 2.0.11 preserves caller-provided User-Agent fragments when plain client headers are used. No release-age bypass remains for @microsoft/teams.*; 2.0.11 is now past the workspace freshness window.

6. SSO sign-in invokes now use the SDK defaults, with OpenClaw token persistence. (regression fix found during live SSO testing) The first SSO pass registered explicit app.on("signin.token-exchange") / app.on("signin.verify-state") handlers. That replaced the SDK's built-in system routes, which was wrong: when Bot Framework returned Consent Required, our handler effectively turned the failed silent exchange into a successful HTTP 200, preventing Teams from continuing the consent fallback correctly. The fix leaves the SDK's built-in sign-in routes in control so Teams gets the SDK's expected 200/412 InvokeResponse semantics, passes channels.msteams.sso.connectionName into the SDK as the default OAuth connection, and persists successful delegated tokens from the SDK signin event into OpenClaw's msteams SSO token store. Live-validated against a real Teams app through devtunnel: msteams sso token persisted and a Graph delegated token was written for connection graph.

What changed

Auth + bootstrap

• ExpressAdapter from @microsoft/teams.apps handles route registration and JWT validation internally — replaces our custom multi-issuer validator
• app.tokenManager.getBotToken() / .getGraphToken() (public API) replaces our manual token acquisition + unknown casts. A small tokenToString() helper calls IToken.toString() explicitly to keep the lint clean
• Bearer-presence middleware retained for pre-parse DoS protection (rejects requests with no Authorization header before the SDK does JSON body parsing)

SSO

• SDK built-in signin.token-exchange / signin.verify-state system routes stay in control. OpenClaw intentionally does not replace them with user routes because the SDK defaults preserve Teams' required sign-in InvokeResponse semantics, including 412 when silent token exchange needs interactive consent fallback.
• channels.msteams.sso.connectionName is passed into the SDK app as the default OAuth connection name, so the SDK verify-state handler uses the same connection OpenClaw is configured for.
• OpenClaw subscribes to the SDK signin event and persists successful delegated tokens into the msteams SSO token store. This gives us token persistence without reimplementing the sign-in invoke protocol.

Outbound messaging

• app.send(conversationId, activity) replaces adapter.continueConversation() for proactive sends
• app.reply(conversationId, messageId, activity) for proactive sends that need to land in an existing channel thread (uses the SDK's own toThreadedConversationId helper, no manual ;messageid= URL building)
• app.api.conversations.activities(id).update/delete() replaces manual REST calls for edit/delete

Inbound dispatch + context adapter (the bridge)

The new SDK delivers an IActivityContext (with send / reply methods) but our handler chain expected the old MSTeamsTurnContext interface (with sendActivity / sendActivities / updateActivity / deleteActivity). adaptSdkContext in monitor.ts bridges them:

• sendActivity → ctx.reply() for channel/groupChat (threaded), ctx.send() for personal DMs (no blockquote)
• updateActivity → app.api.conversations.activities(id).update(activityId, activity)
• deleteActivity → app.api.conversations.activities(id).delete(activityId)
• stream → passthrough of ctx.stream

Streaming via ctx.stream

Deleted streaming-message.ts (~300 lines of custom streaminfo entity management). The SDK's HttpStream (exposed via ctx.stream) handles the full Teams streaming protocol — update(text) for informative status, emit(chunk) for streaming chunks, close() for the final message.

createTeamsReplyStreamController is now a small bridge that wires openclaw's reply-pipeline callbacks to ctx.stream. Two protocol mismatches surfaced and got fixed inline:

• Cumulative-vs-delta: the channel reply pipeline emits cumulative text on each chunk, but the SDK's HttpStream.emit(activity) appends each chunk to its internal buffer (this.text += activity.text). The controller tracks the emitted prefix length and forwards only the new tail (follow-up commit 5).
• Cancel handling: try/catch around all emit/update/close plus a wasCanceled latch (follow-up commit 3).

Before close, the controller emits a final empty MessageActivity carrying the AIGeneratedContent entity and feedbackLoopEnabled: true channelData — the SDK's HttpStream accumulates that into the closing activity, so streamed messages still get the AI-generated label and thumbs up/down.

Adaptive card actions

The poll card was using Action.Submit + msteams.type: "messageBack" (legacy Bot Framework pattern). With the new SDK, vote clicks weren't reaching the bot at all. Migrated to Action.Execute (Universal Action Model) which sends an adaptiveCard/action invoke.

Registered app.on('card.action', ...) that returns a real InvokeResponse. Poll vote detection is inlined in the handler — extracts pollId and choices from the new value.action.data payload shape (vs the old value.openclawPollId), records the vote via pollStore, and returns { statusCode: 200, type: 'application/vnd.microsoft.activity.message', value: 'Vote recorded.' }. Without a typed InvokeResponse, Teams shows "Unable to reach app" after the 5s invoke timeout.

Removed (dead/replaced)

• streaming-message.ts and its test — replaced by ctx.stream
• MSTEAMS_WEBHOOK_MAX_BODY_BYTES const + import — unused
• requireConversationId test helper in messenger.test.ts — orphaned
• appId destructures in send.ts — leftover from the earlier auth pass-through refactor
• jsonwebtoken, jwks-rsa, @types/jsonwebtoken, and the now-unneeded direct @microsoft/teams.common dependency from the msteams package surface — JWT validation and User-Agent merging are SDK-owned now. @microsoft/teams.api and @microsoft/teams.apps remain direct SDK deps.

Polish

• attachments/download.ts: improved "attachment download failed" warn (host + error inline in the message text — the structured meta object was being dropped by the logger formatter)
• Docker Matrix native-addon verification now parses both comma- and space-separated OPENCLAW_EXTENSIONS, matching the manifest-copy stage.
• Test fixtures: renamed adapter → app on MSTeamsMessageHandlerDeps (was renamed in the original migration commit but several test fixtures didn't get updated, causing pre-existing tsgo failures that the changed-gate now catches)
• Contract test: dropped jsonwebtoken / jwks-rsa from msteams expected plugin-local deps (the new SDK does JWT validation internally — those packages are gone)

Validated end-to-end

Tested live in a Teams app installation behind a devtunnel, with a deliberate regression-pass against the closed-issue history of the msteams plugin.

Side-by-side parity check. The migration build was validated against a parallel main-branch bot (OpenMAINClaw, separate Azure App ID + tunnel + config) running on the same host. Channel @-mention with default config produced identical behavior on both bots (message_tool_only is the documented default for group/channel chats — the agent must call the message(action=send) tool to reply, or operators set messages.groupChat.visibleReplies: "automatic" to opt in to auto-replies). After flipping both configs to automatic, channel @-mentions, threaded replies, proactive sends, edits, and adaptive cards all produced equivalent output on the migration build vs main. No regression introduced by the SDK swap.

pnpm check:changed is green: typecheck, lint, contract tests, and all msteams unit tests pass (865 tests). Two pre-existing failures on the branch (parallels-smoke-model.test.ts, tui.test.ts) are unrelated to msteams.

Not tested / still out of scope:

• Clipboard-paste DM image handling — pre-existing limitation, separate follow-up.
• Full productized SSO UX/tool integration. The SDK sign-in flow and token persistence are live-proven here, but exposing that token through a polished user-facing auth/tool surface belongs in the dedicated SSO follow-up.

Codex review findings

@clawsweeper's review surfaced four items I worked through as part of the regression-test pass.

• [P1] JWT validator audience/issuer contract — split into two pieces:
  • Issuer ([Bug] MS Teams SingleTenant bot: JWT validation fails (issuer + audience mismatch) #64270, SingleTenant sts.windows.net): addressed upstream by microsoft/teams.ts#556 which accepts the v1 sts.windows.net/{tenantId}/ issuer alongside the existing v2 issuer by default. Picked up in this PR via the @microsoft/teams.api / teams.apps 2.0.11 bump. No openclaw-side change needed.
  • Audience ([Bug]: Teams webhook broken in 2026.3.24+: publicUrl removed breaks JWT validation #58249, aud=https://api.botframework.com): intentionally not restoring this. The Entra access-token spec requires aud to be the app's clientId; tokens with aud=https://api.botframework.com are spec-violating, and the SDK's deliberate scope-narrowing in Docs/hetzner guide #556 (commit da3c94c: "drop audience changes from auth PR") confirms that's the correct stance. The pre-rebase custom validator that accepted the global audience was a compatibility shim for legacy/canary tokens, not a property of well-formed Entra tokens. We won't carry it forward.
• [P1] Proactive send routing metadata — public-cloud behavior is live-validated for DM, group/channel sends, thread replies, edits, deletes, cards, polls, and file-consent sends through the SDK path. The support boundary is now documented: this migration is validated for public cloud; GCC/GCC High/DoD or other non-public Connector routing needs an explicit future msteams cloud/serviceUrl configuration before we call it supported.
• [P2] Dual /api/messages route registration — fixed with a compatibility forwarder. The SDK registers the configured webhook.path; when that path is not /api/messages, OpenClaw also accepts legacy /api/messages POSTs and forwards them to the configured path with a one-time deprecation warning. This keeps existing Azure Bot registrations working through the transition while still nudging operators to update the endpoint.
• [P2] Docker port mismatch — fixed. docker-compose.yml now exposes ${OPENCLAW_MSTEAMS_PORT:-3978}:3978 to match the plugin's default webhook.port (3978, also the Bot Framework default used in Microsoft samples). Operators wanting a custom port override both webhook.port in config and OPENCLAW_MSTEAMS_PORT env var.

Known followups (intentionally out of scope, separate PRs)

1. Productize SSO usage beyond token persistence. The SDK sign-in routes are now the active path: OpenClaw leaves signin.token-exchange / signin.verify-state to the SDK and persists successful tokens from the SDK signin event. Live testing confirmed a Graph delegated token is written for the configured graph connection. Follow-up work is to expose a normal user-facing sign-in entrypoint and wire the persisted token into tool/runtime auth surfaces. The old explicit signin-invoke.ts helper and lower-level sso.ts exchange helpers can likely be simplified or removed once the dedicated SSO/tooling path lands.

2. Replace catch-all activity dispatch with per-type SDK routes: today we register app.on("activity", ...) as a catch-all that pattern-matches activity.type / activity.name internally via a buildActivityHandler shim mimicking the old Bot Framework ActivityHandler.run() shape. The new SDK has typed routes for every activity type/invoke we care about — app.on("message"), app.on("conversationUpdate"), app.on("messageReaction"), app.on("file.consent.accept"|"decline"), app.on("message.submit.feedback"), etc. This is what slack does (extensions/slack/src/monitor/events/*.ts registers ~10 specific Bolt handlers, no catch-all). Splitting drops buildActivityHandler + the MSTeamsActivityHandler interface + the if (ctx.activity?.type === "invoke" && ctx.activity?.name === "...") chain in the wrapper, gives each handler a typed context, and lets the SDK auto-ack invoke responses for paths that don't need a typed response. Keep SDK sign-in routes as SDK-owned unless/until we have a concrete reason to replace their 200/412 fallback behavior.

3. Clipboard-paste DM image handling — Teams puts inline DM images directly on *.asm.skype.com URLs without an HTML <attachment> wrapper, so they don't trigger the existing BF-v3-attachments fallback. The +button "Upload from this device" path works because Teams generates the HTML wrapper. Fixing clipboard-paste means extracting the object ID from the asm.skype.com URL and rewriting to <serviceUrl>/v3/attachments/<id>/views/imgo.

4. Re-implement upstream's preview / progress-draft / live-finalization features on top of ctx.stream. While this PR was open, upstream landed #77674 / #78081 and several other commits that extended the OLD TeamsHttpStream class with: preview-mode streaming, progress-draft labels (e.g. "Looking up the schema..." that updates as tools run), and live-finalization that edits the preview-stream activity in place when the final reply lands. This PR deletes TeamsHttpStream in favor of the SDK's ctx.stream, so those features need to be re-built on the new substrate. Scope is moderate (~200-300 lines): track preview-stream-id from the SDK's HttpStream, route progress-draft text through ctx.stream.update(...) instead of a custom sendInformativeUpdate, and use app.api.conversations.activities(id).update(activityId, ...) for the in-place final edit. The plugin-sdk helpers (createLiveMessageState, defineFinalizableLivePreviewAdapter, createChannelProgressDraftGate, etc.) already work shape-agnostically — they just need a different editFinal adapter that uses the SDK API instead of the custom TeamsHttpStream methods. Out of scope for this PR to keep the migration scope contained.

Rebase / merge notes

This branch was force-rebased onto upstream/main on 2026-05-06 (1454 upstream commits since the original migration commit). The rebase took ours wholesale for the 6 conflicting files in commit 8e90628cb6:

• monitor.ts, reply-dispatcher.ts, reply-stream-controller.ts, reply-stream-controller.test.ts, sdk.ts, sdk.test.ts (took migration's version)
• streaming-message.ts and its test (deleted by the migration; upstream had modified them)

Follow-up commit e38f323173 fix(msteams): post-rebase reconciliation with main reconciled the rest:

• createChannelReplyPipeline → createChannelMessageReplyPipeline (renamed in plugin-sdk during the rebase window)
• Tightened onStartError typing for upstream's stricter type checks
• Removed the unconditional thread suffix on the proactive bottom-fallback (upstream test asserts replyStyle: 'top-level' should not thread; the original fix(msteams): preserve channel reply threading in proactive fallback #55198 fix is preserved on the replyStyle === 'thread' onRevoked branch)
• Updated attachments.test.ts warn assertion to match the migration's inline message format

On 2026-05-07 the branch was merged with upstream/main again (1820 commits since the prior rebase point). Two conflicts resolved in commit 10629d08df:

• extensions/msteams/src/send.ts and send-context.ts: kept the SDK's app over main's legacy adapter, adopted main's new replyStyle propagation through MSTeamsProactiveContext (so CLI proactive sends to channel threads pick the policy-resolved replyStyle and route through messenger.ts:sendProactively with the thread root id, leveraging follow-up commit 4's app.reply path).

Same merge commit also rewrote two tests in extensions/msteams/src/messenger.test.ts (not conflict-marked but materially changed): the tests referenced the deleted MSTeamsAdapter / noopUpdateActivity / noopDeleteActivity and were ported to the migration's MSTeamsApp mock pattern.

All msteams unit tests (865) pass after the merge.

Real behavior proof

Behavior or issue addressed: SDK-migration end-to-end behavior on the live Teams runtime — DM streaming (with the cumulative-vs-delta tracking fix from follow-up #4), DM streaming with tool-progress informational updates above the streaming card, channel proactive + threaded-reply messaging (follow-up #1), and SSO token persistence via the SDK signin event. Together these exercise ctx.stream, app.on("card.action"), ctx.reply for channels, the proactive app.send / app.reply paths, and the SDK default sign-in invoke routes.

Real environment tested: Microsoft Teams app installed in an M365 tenant via devtunnel, against a docker-deployed openclaw gateway running this branch. A separate main-build control bot was installed in the same tenant for side-by-side parity comparison; behaviors below were observed equivalent on both bots after messages.groupChat.visibleReplies: "automatic" was set, so no migration-only regression.

Exact steps or command run after this patch:

1. DM the bot a streaming-eligible prompt ("write a short sonnet about a llama") and watch the streaming card fill in.
2. DM the bot a tool-triggering prompt and watch the tool-progress informational lines render above the streaming card as tools fire, then transition to the final reply.
3. From the gateway, send a proactive top-level channel message via openclaw message send --channel msteams --target <channelId> --message …, then reply to that message in a thread inside Teams.
4. Trigger a live SSO sign-in in DM with a temporary local /test-signin hook that called ctx.signin({ connectionName: "graph" }), complete consent, and verify token persistence.

Evidence after fix:

Basic streaming in DMs:

Streaming with tool-call informational updates:

Messaging in channels (proactive top-level + threaded reply):

SSO flow working:

Observed result after fix:

• DM streaming card fills in token-by-token without duplication (pre-fix, each chunk re-emitted the cumulative prefix on top of all earlier chunks).
• Tool-progress informational status renders above the streaming card and the live preview transitions in place to the final reply on close.
• Channel proactive top-level send lands at the channel root; the bot's reply to a user's threaded follow-up lands inside the same thread (no top-level leak).
• app.reply() proactive thread path verified mechanically equivalent to the previous manual ;messageid= URL build.
• SSO sign-in completed through the SDK default sign-in routes; OpenClaw logged msteams sso token persisted, and a Graph delegated token was written to ~/.openclaw/msteams-sso-tokens.json for connection graph.
• The temporary /test-signin hook and JWT diagnostic logging used for live proof were removed before handoff.
• Targeted local proof covered SDK construction/User-Agent, plugin package guardrails, extension typecheck, Docker build, and the live Teams smoke matrix above.

What was not tested: Clipboard-paste DM image handling remains a pre-existing limitation and is tracked as a separate follow-up. Full productized SSO/tool integration remains follow-up work; the SDK sign-in route and token persistence path itself is live-proven here.