feat(msteams): support multiple bot accounts#104692
Conversation
|
Codex review: needs maintainer review before merge. Reviewed July 15, 2026, 10:25 PM ET / July 16, 2026, 02:25 UTC. Summary Reproducibility: not applicable. this is a new Microsoft Teams capability rather than a report of broken established behavior; current main and current docs clearly expose only one root-level bot identity. Review metrics: 2 noteworthy metrics.
Stored data model Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Risk before merge
Maintainer options:
Next step before merge
Maintainer decision needed
Security Review detailsBest possible solution: Keep #71058 as the product-decision record; if a maintainer sponsors this exact hybrid account contract, reopen or refresh the implementation on current main and require clean fresh-install, legacy-upgrade, credential-isolation, and state-isolation proof before merge. Do we have a high-confidence way to reproduce the issue? Not applicable: this is a new Microsoft Teams capability rather than a report of broken established behavior; current main and current docs clearly expose only one root-level bot identity. Is this the best way to solve the issue? Unclear as a product decision: the implementation follows OpenClaw's established account-routing pattern and has strong coverage, but the exact root-inheritance, default selection, and legacy compatibility contract needs maintainer approval before it can be considered the best permanent solution. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 08ecf63bb608. Label changesLabel justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (34 earlier review cycles; latest 8 shown)
|
|
@steipete I know that you get tagged/requested to view PR's all the time, but you are listed as the first "Likely related people". I know this is a large PR, and I'm ready to break it into the parts you need to review. We're using OC in our office & need to expose the agents to MS Teams as separate applications, so this is a very important feature to us. There are existing discussions about this from others as well. Getting MS Teams to be in closer feature parity with the other channels would be great. |
a19dadb to
1ab9746
Compare
…-account-clean-rebuild
|
Validation update for exact head
|
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
…-account-clean-rebuild # Conflicts: # extensions/msteams/src/sent-message-cache.ts # src/config/bundled-channel-config-metadata.generated.ts
…-account-clean-rebuild # Conflicts: # src/config/bundled-channel-config-metadata.generated.ts
…-account-clean-rebuild # Conflicts: # src/config/config-misc.test.ts # src/config/zod-schema.providers-core.ts
…-account-clean-rebuild
|
Validation update for exact head
|
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
…-account-clean-rebuild # Conflicts: # extensions/msteams/src/monitor-handler/message-handler.authz.test.ts
…-account-clean-rebuild # Conflicts: # src/config/bundled-channel-config-metadata.generated.ts
|
Superseded by #112811. This PR became detached: its internal head b686b01 no longer matched the fork branch ref 603892d, and those commits were not in the same forward ancestry. #112811 was rebuilt from current upstream with preserved Teams multi-account history, independently verified matching fork/PR heads, full local validation, and GitHub MERGEABLE status. Closing this detached predecessor to keep one active review target. |
Related: #71058
What Problem This Solves
Resolves a problem where Microsoft Teams could only be configured as one bot identity per OpenClaw gateway. That made it difficult to run multiple Teams-visible agents, each with its own Teams app/bot registration, from the same OpenClaw instance in the same way operators can use account-specific routing with other channel integrations.
Why This Change Was Made
This adds first-class account support to the Microsoft Teams channel while preserving the legacy single-bot configuration path.
channels.msteams.accounts.<id>now defines Teams bot accounts,channels.msteams.defaultAccountselects the implicit account when one is not provided, and existing root-levelappId/appPassword/tenantId/webhookconfig continues to work as the default account.The implementation keeps account identity fields explicit per named account: named accounts must provide their own
appId, credential, and webhook port, while shared settings such astenantId, webhook path, policies, Graph/SSO/delegated-auth settings, streaming behavior, and delivery settings can be inherited from the root and overridden per account. Inbound handling, proactive sends, replies, Graph-backed actions, SSO/delegated token storage, polls, sent-message cache, conversation state, probes, setup flows, and routing all carry the account context.User Impact
Users can now configure multiple Microsoft Teams bot accounts in one OpenClaw gateway and bind each account to the agent that should answer:
Existing single-bot configs remain valid and do not require bindings:
Evidence
pnpm test:extension msteamspnpm test:contracts:channels(45 files, 305 tests)pnpm buildpnpm checkgit diff --checkcodex review --base upstream/main: no actionable correctness issues found.AI-assisted: yes. I used Codex to help implement, audit, test, and review this change, and I reviewed the behavior and code paths before opening the PR.
If this gets merged, then I will focus on enhancements next.
Migration note: This PR replaces #97340 with the same published head commit, moved from
spinen/openclawtojimmypuckett/openclawso OpenClaw maintainers and repository automation can update the contribution without transferring authorship. Prior review, proof, and CI history remain available on #97340.