A Slack bot for a coding agent turns a message in Slack into a request for Claude Code or Codex running on someone’s machine and posts the result back in the thread. muti gives each agent its own bot with its own name. People in your workspace DM it or mention it in a channel; that message is the task. If the person asking is not the agent’s owner, the request waits, and the owner approves it with buttons in their own DM. Pushes, destructive deletes, spending and credential access never become automatic, for anyone.
This post explains how the connector works, what “Allow always” actually stores, and why treating Slack as untrusted input is the whole point.
What most bridges get wrong
The typical bridge stores a bot token, listens for mentions, and pipes the text to a local CLI. It works, and it has three problems: channel membership becomes the permission model, nobody approves the risky step, and progress floods the channel one message per tool call. None of those is a Slack problem. They are permission problems that happen to surface in Slack.
채널 스레드에는 요청과 그 상태가 표시되고, 승인 버튼은 소유자의 DM에 나타나며, 에이전트는 소유자의 머신에서 실행됩니다.
One bot per agent
You create the Slack app from a manifest muti generates for that agent, so the bot carries the agent’s name and its own event URLs. There is nothing to bind and no command to learn:
- 봇에게 DM 보내기: 텍스트가 곧 작업이 됩니다. 해당 DM은 나와 에이전트 소유자가 공유하는 룸이 됩니다.
- 채널에서 멘션하기: 해당 채널은 처음 사용될 때 muti의 그룹 룸이 됩니다. 봇은 스레드에서 답변합니다.
- 파일 첨부하기: 웹 업로드와 마찬가지로 에이전트가 읽을 수 있는 룸 첨부 파일로 전달됩니다.
Slack users become muti users by the email Slack holds for them, verified by Slack inside the owner’s own workspace. If Slack hides the email, the bot sends a six-digit link code to redeem on the web once. Either way, permissions attach to the account, not to a display name.
The same gate as the web
Every request passes the gate the web uses. The owner’s own messages run at once. Anyone else waits for the owner, unless the owner has already allowed them always for this agent. Status lands in the thread: accepted with a request id, waiting, running with tool-call summaries, done with the result. One card, updated in place, rather than a message per step.
Approval buttons, and what “always” means
When a request from someone else arrives, or when a run reaches a tool call that needs a human, the owner gets a card in their DM with three buttons: Allow, Allow always, Deny.
Allow is for that single call. Allow always stores a rule for the agent that is exactly as narrow as the call: this domain for WebFetch, this command prefix for Bash, this skill by name, this read-only tool. Future matching calls are answered by muti without a prompt. The rules are listed and revocable in the agent’s dialog.
Calls in the dangerous classes never qualify for a rule and never match one: pushing to shared branches, destructive deletes, privilege escalation, publishing and deploys, and reads or writes of credential paths. They stay one call at a time, with only Allow and Deny. That is the connector’s version of the 에이전트가 실행 전 항상 물어봐야 하는 네 가지 작업. Unanswered approvals expire after 24 hours, like requests.
What the channel sees
Request text, status and id; tool-call summaries; diff paths and line counts; the tail of command output; produced files and links. Never: environment variables, key files, the working tree, or anything from another room. The Slack tokens are stored encrypted in muti; nothing Slack-related lives on the owner’s machine, which keeps its outbound-only daemon connection. See daemon이 업로드하는 항목.
Setup
- In the console, open Slack for the agent you want to expose and create a Slack app from the generated manifest. Upload the agent’s avatar as the app icon if you like; the wizard renders it.
- 앱 설정에서 확인한 두 개의 문자열을 붙여넣습니다. muti가 Slack을 한 번 호출하여 이메일로 사용자를 찾은 뒤 소유자로 연결하므로 승인 버튼이 즉시 작동합니다.
- Install the app to your workspace. DM the bot, or invite it to a channel and mention it.
- 팀원의 첫 번째 요청을 DM에서 승인합니다. 범위가 좁고 위험 부담이 없는 호출에만 Allow always를 사용하고, 위험한 작업은 항상 확인을 거치도록 두세요.
Frequently asked questions
Does the bot need my Slack admin? 워크스페이스에 앱을 설치할 때는 일반적으로 한 번의 관리자 승인이 필요합니다. 이 앱은 muti의 매니페스트로 직접 생성한 본인 소유의 앱이므로, 어떤 서드파티 앱도 워크스페이스 토큰을 보유하지 않습니다.
Can channel members approve for themselves? 아니요. 승인 권한은 에이전트 소유자에게만 있으며 소유자의 DM으로 전달됩니다. 멤버는 취소하거나 컨텍스트를 추가할 수 있습니다.
What about Feishu, Lark and DingTalk? Feishu/Lark가 다음 순서이며 동일한 룸 및 승인 모델을 따릅니다. Feishu 설계를 참조하세요. 그 이후 DingTalk이 지원될 예정입니다.
Is this the same as Claude Code Dispatch? Dispatch relays your Telegram messages to your own session. This connector is for other people, with approvals; see Dispatch와 룸 비교.
룸이 권한 관리를 담당하며, Slack은 룸으로 들어오는 또 하나의 문일 뿐입니다. 에이전트에 룸을 만들어 보세요.
게시일 · 수정일