Your coding agent in Microsoft Teams

Teams works differently from the other channels, so read this first. Microsoft’s Bot Framework pushes messages to an endpoint you host, which means the gateway needs a public HTTPS URL that reaches it: a reverse proxy that terminates TLS, a host with a public name, or a tunnel you run. Warding does not provide one. Once that is in place, you chat with the agent in a 1:1 personal chat.

What has been run on which harness is on the verification log; a feature without a dated row there is unverified.

What works from Teams today

• Approve cards: Approve, Approve + auto-approve and Deny. No answer within five minutes is a deny. Each card carries a one-time token, so an old one in your history reports that it is no longer waiting.
• Files you send are read: images, text files, PDFs and Word documents; voice messages are transcribed when speech-to-text is installed.
• A progress message that updates while tools run, then the final answer in the same message.

Set it up

1. Give the gateway a public HTTPS URL, as above.
2. Install the Teams extra into the gateway’s environment. From a source checkout:

   .venv/bin/pip install -e '.[teams]'

3. Register an Azure Bot in the Azure Portal. Note the App ID, create a client secret, add the Microsoft Teams channel, and set the messaging endpoint to your public URL plus /api/messaging/teams.
4. Save the credentials in the data home’s .env: MICROSOFT_APP_ID, MICROSOFT_APP_PASSWORD and, for a single-tenant bot, MICROSOFT_APP_TENANT_ID. The password is read from the environment only, never from config.json.
5. Allow yourself in config.json:

   "teams": { "enabled": true, "allowed_emails": ["you@yourcompany.com"] }

6. Package the Teams app in the Teams Developer Portal (a bot with your App ID, scope Personal, supportsFiles set to true), upload it, restart the gateway and open a 1:1 chat:

   warding restart

Who can reach it

Anyone in your organisation can find a Teams bot, so the allow-list is the gate, and an empty one denies everyone. Channel and group chats are refused, because a reply there would show tool output to people who are not on the list. Every inbound request’s token is checked against the Bot Framework signing keys before anything runs.

Limits, stated plainly

• Owner-only. One person runs this gateway, as themselves, with their files and credentials. There is no shared or team mode.
• One harness for chat. The docked harness answers every channel; switching is one setting. A spawned subagent can be routed to another installed harness; that is registered, not verified.
• Your box has to stay on. Nothing of ours runs in the cloud.
• Creating jobs from chat (and subagents, and questions the agent asks you mid-turn) relies on the agent’s own tools, which reach kiro-cli only today. On other harnesses, schedule from the dashboard or the CLI; see the schedule page.
• A public HTTPS URL is on you. There is no tunnel built in.
• Approve + auto-approve is machine-wide. It is the same grant as the dashboard toggle and /yolo, and it still cannot approve what a deny rule refuses.
• No token streaming and no model picker in Teams, and only PNG or JPEG images can be sent back as files.

Approvals: buttons · All ten channels · Full reference publication pending