OpenClaw on Microsoft Teams
The bundled plugin, the Teams CLI quick setup, the tunnel, and the manual Azure Bot path
Microsoft Teams ships as a bundled plugin in current OpenClaw releases, and the docs describe it plainly: text and DM attachments work, polls and approval prompts arrive as Adaptive Cards, and sending files in channels or group chats needs a SharePoint site id and Graph permissions. The setup is the most corporate of any channel, because Teams cannot reach localhost and a bot has to be registered before it can speak. Here is the quick setup the docs recommend, the config it produces, the access default, and the manual path when the CLI is not an option.
The quick setup
- Install the Teams CLI, published under a preview tag, and log in; the status command shows the tenant.
- Start a tunnel, because Teams cannot reach localhost: a dev tunnel with anonymous access allowed, since Teams cannot authenticate with it and every bot request is still validated by the Teams SDK; ngrok or a Tailscale funnel are the alternatives, with URLs that may change per session.
- Create the app with a name and the tunnel endpoint: that creates the Entra application, generates a client secret, builds and uploads the manifest with icons, and registers a Teams-managed bot with no Azure subscription needed; the output has the client id, secret, tenant id and the Teams app id, and offers to install the app in Teams.
- Configure OpenClaw with those three values and the webhook port and path, or the matching environment variables; install the app, then run the CLI’s doctor against the app id to check bot registration, the directory app, the manifest and single sign-on.
Group chats are blocked by default (channels.msteams.groupPolicy: "allowlist").
Access and routing
Group chats are blocked by default; allow specific senders with a group allow-from list, or set the group policy to open to allow any member behind a mention. DMs default to pairing. Routing is deterministic, replies go back to the channel they came from, and channel behaviour is safe by default, mentions required unless configured otherwise. For production the docs suggest federated authentication, a certificate or a managed identity, instead of a client secret.
The manual path
- Create an Azure Bot to get an app id, a secret and a tenant id, then build a Teams app package that references the bot and carries the resource-specific permissions from the manifest page.
- Upload the app into a team, or personal scope for DMs, configure the channel in the config file or environment, and start the Gateway, which listens for Bot Framework webhook traffic on the messages path by default.
- Capabilities depend on permissions: resource-specific consent alone covers the basics, Graph application permissions add media and history, and the troubleshooting page lists webhook timeouts and formatting limits.
OpenClaw on Slack is the closest channel in shape, and OpenClaw not responding the ladder when the bot is installed and silent.
On Diali
On Diali, Teams is on the roadmap rather than in the connect list; the Azure registration and the manifest would still be yours, and the tunnel would not, because the Gateway already has a public HTTPS address. Hosted OpenClaw on Diali is the assistant, and Slack on Diali is the workplace channel that connects today.
- Bundled plugin; the Teams CLI does registration in one command.
- A tunnel is mandatory in development; Teams cannot reach localhost.
- Groups are allowlisted by default; DMs pair.
Stop reading about it, build one
Set up an agent, pick a channel, and have it working inside the app you already keep open.
