Mentioning a coding agent in a Feishu group means a group member writes a message in Feishu (Lark outside China), that message is delivered to a Claude Code or Codex agent running on someone’s machine, the run and its result come back into the same thread, and any dangerous action first becomes an approval card for the machine’s owner. The agent does not move to the cloud, credentials never leave the computer, and nobody in the group installs anything.
This post describes the design of muti’s Feishu connector: binding, routing, approvals and throttling, plus what you can set up before it ships. The connector is in development; what follows is its behavioural spec, not a feature you can switch on today. The Chinese original is at /zh-CN/blog/feishu-lark-claude-code.
Why a chat app instead of another client
The person you are sharing with least wants to create an account and install a client to use your agent once. For teams in China the working conversation already lives in Feishu. Bringing the agent there is easier than bringing people to the agent.
Feishu also fits the job: long-connection event subscriptions need no public callback URL, message cards update in place, thread replies keep one task’s traffic together, and images can be downloaded as agent input.
Feishu already has an AI coworker
Worth saying plainly: ByteDance is doing this too. Doubao's work partner skips the new workspace and gives the agent an organisational identity inside Feishu, where the company's authorised messages, meetings and documents already are. Nothing to migrate, nobody to re-register.
muti's connector answers the other half: how the coding agent already configured on your machine, with the repository cloned, the internal network reachable, the tools logged in and the subscription paid, becomes usable by people in a group chat while dangerous actions still wait for you. The two do not conflict, and many teams will run both. The wider comparison is in where AI coworkers sit in China.
Two bindings
Group ↔ room. A room is the boundary in muti: who can see what and who may use which agent. Binding a Feishu group to a room makes the room’s membership and grants apply to that group. In the room settings choose “connect a Feishu group”, get a six-digit code, and post @muti bind 123456 in the group.
Person ↔ account. The first time a member mentions the bot, it sends them a short-lived code in a private chat; they enter it in muti and the identities are linked. Unbound people are ignored by default; a room can open a guest mode where they may ask but not trigger runs.
The point of binding: execution rights come from the room’s grants and the owner’s approvals, never from who said what in the group. Chat messages are treated as untrusted input.
One task, one thread: acceptance, approval card, progress and result in the same place.
One task, one thread
A member posts @muti @api rerun the failing tests and open a PR. The bot opens a thread under that message and replies in sequence:
- Accepted, with a request id such as
R20260906-03and its status. - Approval status. If this person has no standing grant for this agent, the owner receives an approval card visible only to them.
- A progress card, updated in place per stage or every 30 seconds: files changed, tests so far, the last lines of command output. Not a new message per step.
- The result: the reply plus any files, images or links the agent produced.
The main channel stays quiet; anyone who wants detail opens the thread.
The approval card
When a run hits a dangerous action, the owner gets a card: who asked, which agent, what it wants to do, which rule it hit. Three buttons: approve / reject / run read-only, with an optional note that carries the same weight as the request.
Four action types pause regardless of template: pushing to a shared branch, deleting, spending money, touching credentials. Protected inputs such as logins and two-factor codes always route to the owner, never to the requester. Approvals expire after 24 hours by default. Deciding in Feishu, on the web or on a phone applies everywhere.
What the group sees, and what never leaves the machine
What to set up now
- Put the agent in a room. Connect your machine, create one agent per directory you intend to share, and name it for the job (
api,site,notes), not the model. - Build the room before the group. Invite the people who will later be in the bound group and set who is read-only and who may edit. The connector binds group ↔ this room and reuses those rules.
- Install the daemon as a service with
muti service install, so tasks from Feishu wait for the machine instead of failing when the lid is closed. - Write the house style down. A STYLE.md, the deck template, last week’s report SQL: whatever the agent should read sits in its working directory.
Frequently asked questions
Will our Feishu admin need to approve anything? muti’s cloud runs one Feishu app for all users; installing it into a tenant typically needs one admin consent. Self-hosted mode lets an owner bring their own app credentials.
Is Lark (international) supported? Feishu and Lark share the same open platform; the connector covers both.
What about Slack and DingTalk? The Slack connector has shipped: one bot per agent, DM it or mention it, approvals in the owner’s DM. Feishu/Lark is next; DingTalk (Stream mode) follows. All three share the same rooms and grants. See a Slack bot for Claude Code that asks before it pushes.
What if someone in the group isn’t a muti user? They are ignored by default. A room can open guest mode: guests may ask, never trigger.
Give your agent a room first; the group plugs into it. Start here.
Published · Updated