Un bot Slack pour un agent de code transforme un message Slack en requête pour Claude Code ou Codex s'exécutant sur la machine de quelqu'un et renvoie le résultat dans le fil de discussion. muti attribue à chaque agent son propre bot avec son propre nom. Les membres de votre espace de travail lui envoient un message direct ou le mentionnent dans un canal ; ce message constitue la tâche. Si l'auteur n'est pas le propriétaire de l'agent, la requête se met en attente et le propriétaire l'approuve via des boutons dans ses messages directs. Les pushs, suppressions destructives, dépenses et accès aux identifiants ne deviennent jamais automatiques, pour personne.
Cet article explique le fonctionnement du connecteur, ce que stocke réellement « Allow always » et pourquoi traiter Slack comme une entrée non fiable est précisément tout l'intérêt.
Ce que la plupart des passerelles font mal
La passerelle classique stocke un bot token, écoute les mentions et envoie le texte à un CLI local. Cela fonctionne, mais pose trois problèmes : l'appartenance au canal devient le modèle de permissions, personne n'approuve l'étape risquée et la progression inonde le canal d'un message par appel d'outil. Aucun de ces points n'est un problème propre à Slack. Ce sont des problèmes de permissions qui se manifestent simplement dans Slack.
Un fil de canal affiche la requête et son statut ; les boutons d'approbation se trouvent dans le message direct du propriétaire ; l'agent s'exécute sur la machine du propriétaire.
Un bot par agent
Vous créez l'application Slack à partir d'un manifeste généré par muti pour cet agent ; le bot porte ainsi le nom de l'agent et dispose de ses propres URL d'événements. Il n'y a rien à lier et aucune commande à apprendre :
- Envoyez un message direct au bot et le texte devient une tâche. Le message direct devient une salle partagée entre vous et le propriétaire de l'agent.
- Mentionnez-le dans un canal et ce canal devient une salle de groupe dans muti dès la première utilisation. Le bot répond dans le fil.
- Joignez des fichiers et ils arrivent sous forme de pièces jointes de salle lisibles par l'agent, comme des téléversements web.
Les utilisateurs Slack deviennent des utilisateurs muti grâce à l'adresse e-mail enregistrée dans Slack, vérifiée par Slack au sein de l'espace de travail du propriétaire. Si Slack masque l'e-mail, le bot envoie un code de liaison à six chiffres à valider une seule fois sur le web. Dans les deux cas, les permissions sont rattachées au compte, et non à un nom d'affichage.
Le même sas de contrôle que sur le web
Chaque requête passe par le même sas de contrôle que sur le web. Les messages du propriétaire s'exécutent immédiatement. Ceux de tout autre utilisateur attendent le propriétaire, à moins que celui-ci ne leur ait déjà accordé un accès permanent pour cet agent. Le statut s'affiche dans le fil : acceptée avec un identifiant de requête, en attente, en cours d'exécution avec les résumés des appels d'outils, terminée avec le résultat. Une seule carte, mise à jour sur place, plutôt qu'un message par étape.
Boutons d'approbation et signification de « always »
Lorsqu'une requête émanant d'un tiers arrive, ou lorsqu'une exécution atteint un appel d'outil nécessitant une intervention humaine, le propriétaire reçoit une carte dans ses messages directs avec trois boutons : Allow, Allow always, Deny.
Allow s'applique à cet appel unique. Allow always enregistre pour l'agent une règle tout aussi ciblée que l'appel : ce domaine pour WebFetch, ce préfixe de commande pour Bash, cette compétence par son nom, cet outil en lecture seule. Les futurs appels correspondants sont autorisés par muti sans nouveau prompt. Les règles sont listées et révocables dans la boîte de dialogue de l'agent.
Les appels appartenant aux catégories dangereuses ne sont jamais éligibles à une règle et n'en satisfont jamais aucune : push sur des branches partagées, suppressions destructives, élévation de privilèges, publications et déploiements, ainsi que lectures ou écritures sur des chemins d'identifiants. Ils restent traités appel par appel, avec uniquement Allow et Deny. C'est la déclinaison pour le connecteur des quatre actions qui nécessitent toujours une confirmation. Les demandes d'approbation sans réponse expirent au bout de 24 heures, tout comme les requêtes.
Ce que le canal voit
Le texte de la requête, son statut et son identifiant ; les résumés d'appels d'outils ; les chemins des diff et le nombre de lignes ; la fin de la sortie des commandes ; les fichiers générés et les liens. Jamais : les variables d'environnement, les fichiers de clés, l'arbre de travail ou tout élément provenant d'une autre salle. Les tokens Slack sont stockés sous forme chiffrée dans muti ; rien de ce qui concerne Slack ne réside sur la machine du propriétaire, qui conserve sa connexion daemon sortante uniquement. Consultez ce que le daemon téléverse.
Configuration
- Dans la console, ouvrez Slack pour l'agent que vous souhaitez exposer et créez une application Slack à partir du manifeste généré. Téléversez l'avatar de l'agent comme icône d'application si vous le souhaitez ; l'assistant la prend en charge.
- Collez les deux chaînes issues des paramètres de l'application. muti interroge Slack une fois, vous retrouve par e-mail et vous associe en tant que propriétaire afin que les boutons d'approbation fonctionnent immédiatement.
- Installez l'application dans votre espace de travail. Envoyez un message direct au bot, ou invitez-le dans un canal et mentionnez-le.
- Approuvez la première requête d'un collègue dans vos messages directs. N'utilisez Allow always que pour les appels ciblés et sans risque ; laissez les opérations dangereuses demander confirmation.
Foire aux questions
Le bot a-t-il besoin de mon administrateur Slack ? L'installation d'une application dans un espace de travail nécessite généralement l'approbation d'un administrateur. L'application vous appartient, créée à partir du manifeste de muti ; aucune application tierce ne détient ainsi le token de votre espace de travail.
Les membres du canal peuvent-ils valider leurs propres requêtes ? Non. L'approbation relève du propriétaire de l'agent et arrive dans ses messages directs. Les membres peuvent annuler ou ajouter du contexte.
Qu'en est-il de Feishu, Lark et DingTalk ? Feishu/Lark sera le prochain et adoptera le même modèle de salles et d'approbations ; voir la conception pour Feishu. DingTalk suivra ensuite.
Est-ce la même chose que Claude Code Dispatch ? Dispatch relaie vos messages Telegram vers votre propre session. Ce connecteur est destiné à d'autres personnes, avec approbations ; voir Dispatch ou une salle.
La salle gère les permissions ; Slack n'est qu'une porte d'accès supplémentaire. Donnez une salle à votre agent.
Publié le · Mis à jour le