Outil CLI
fujibee/agmsg avatar
fujibee/agmsg

agmsg : un transport Bash et SQLite pour agents IA CLI multi-fournisseurs

Messagerie multifournisseur pour les agents de codage CLI AI, laissez Claude Code, Codex, Gemini et Copilot se parler au sein d'une seule équipe. Bash + SQLite, pas de démon, pas de framework.

1 502 étoiles150 forksShellMIT

En bref

De quoi s’agit-il ?
Une couche de messagerie locale uniquement qui permet à Claude Code, Codex, Gemini CLI et d'autres agents CLI d'échanger des messages via une base SQLite partagée, sans démon ni réseau.
À qui s’adresse-t-il ?
Le README ne revendique pas de garanties de niveau production, et le projet est publié sous licence MIT sans garantie. Ce qu'il fournit, c'est un mécanisme concret permettant aux agents d'échanger de courts messages texte sur un fichier partagé, avec des commandes documentées, des modes de livraison et un système de plugins pour étendre le support des pilotes.
Puis-je l’utiliser commercialement ?
Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
Est-il encore maintenu ?
Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
En quel langage est-il écrit ?
Principalement Shell, d’après les statistiques de langage de GitHub.

Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.

ANALYSE OPEN SOURCE APPROFONDIE

Le transport : un fichier SQLite partagé, pas un MCP ni un courtier

agmsg est un transport pour agents IA CLI qui souhaitent échanger des messages sans qu'un humain copie du texte entre eux. L'implémentation est un ensemble de scripts Bash et un fichier de base de données SQLite. Claude Code, Codex, Gemini CLI, GitHub Copilot CLI et d'autres peuvent lire et écrire dans la même base via des hooks ou un flux de surveillance. Le README dit explicitement que ce n'est pas du MCP, pas un système de sous-agents, et pas une file de messages. Il n'y a ni démon ni réseau ; le fichier de base de données est le plancher partagé. Le stockage utilise le mode WAL pour que plusieurs lecteurs et un seul écrivain coexistent. Le README ne fournit pas de mesures de performance ou de résultats de test de charge au-delà des chiffres de latence dans le tableau des modes de livraison.

Chemins d'installation et suivi de version

Le README propose trois voies d'installation. La plus rapide affichée est 'npx agmsg', qui télécharge et exécute le setup.sh canonique sans installation globale. Un chemin de place de marché de plugins Claude Code installe une compétence dans le cache des plugins Claude, puis amorce le même environnement d'exécution sous ~/.agents/skills/agmsg. Un git clone direct et install.sh donne plus de contrôle, notamment un nom de commande personnalisé avec --cmd et un drapeau de type d'agent. Le paquet npm et le plugin sont issus de versions étiquetées, ils peuvent donc être en retard de quelques correctifs sur main ; les chemins clone et setup.sh suivent main directement. Sous Windows, les scripts s'exécutent via Git Bash, et il n'y a pas d'implémentation PowerShell. Le README ne décrit pas de gestionnaire de paquets pour Windows ni d'installateur signé.

Première exécution et surface de commande

Après installation, l'utilisateur exécute la commande slash pour son agent, comme /agmsg dans Claude Code ou $agmsg dans Codex. La première exécution demande un nom d'équipe et un nom d'agent. Une fois configuré, l'utilisateur peut instruire l'agent en langage naturel pour envoyer des messages, vérifier la boîte de réception ou lister les membres de l'équipe. Le README documente des sous-commandes pour l'envoi, l'historique, la liste d'équipe, la sélection de mode, la version et la réinitialisation. Il documente également 'actas' pour changer de rôle dans le même projet, 'drop' pour supprimer un rôle, 'spawn' pour lancer un nouveau processus d'agent, et 'despawn' pour le démonter. Le README note que les noms d'équipe et d'agent doivent être enregistrés avant l'envoi, et send.sh rejette les noms non enregistrés sauf si --force est utilisé.

Rôles, spawn, despawn et reprise de session

La commande actas est exclusive entre sessions : elle revendique un verrou qui empêche d'autres sessions de s'abonner au même nom, et elle refuse si une autre session détient le verrou. spawn lance un processus d'agent séparé dans un nouveau volet tmux ou une fenêtre de terminal OS, et peut passer une invite de démarrage pour que le nouvel agent revendique son identité et commence une tâche dans le même tour. spawn bloque jusqu'à ce que le nouvel agent écoute, sauf si --no-wait est donné. despawn supprime un membre spawné élégamment en envoyant un message de contrôle, ou de force en tuant son volet lorsque le surveillant ne répond pas. Les sessions sont nommées par équipe et agent, et le re-spawn reprend la session précédente par défaut, sauf si --fresh est utilisé. Le README décrit également l'intégration tmux-resurrect pour replacer les volets de rôle après un redémarrage du serveur.

Modes de livraison et comportement par agent

Les modes de livraison déterminent comment les messages entrants atteignent un agent. Le mode monitor utilise un hook SessionStart et un flux SQLite bloquant, avec environ cinq secondes de latence ; c'est le défaut sur Claude Code. Le mode turn vérifie la boîte de réception entre les tours de l'assistant et est le défaut sur Codex, Copilot CLI et OpenCode sans plugin. Le mode both utilise monitor avec turn comme secours. Off désactive la livraison automatique. Le README note que Codex n'a pas d'outil Monitor, donc le mode monitor passe par un pont serveur d'applications, et il y a une limitation connue avec les processus orphelins à la fermeture de la TUI. Copilot CLI ne prend en charge que turn et off. OpenCode prend en charge monitor via un plugin sentinelle externe. Le README fournit également des scripts shell directs pour l'automatisation, comme send.sh, inbox.sh, history.sh et delivery.sh.

Stockage, variables d'environnement et notes de sandbox

Le stockage de messages est une base SQLite en mode WAL, située par défaut à ~/.agents/skills/agmsg/db. La variable d'environnement AGMSG_STORAGE_PATH remplace cet emplacement, et le README montre un exemple pointant vers /tmp/agmsg-sandbox pour des tests isolés. Les configurations d'équipe vivent sous teams/ et ne sont pas affectées par le remplacement de stockage. Le README met en garde contre les restrictions de sandbox : le sandbox de Claude Code peut bloquer l'écriture dans le répertoire de compétences, donc une entrée de liste blanche pour ~/.agents/skills/agmsg/ est documentée. Codex peut avoir besoin de writable_roots dans son config.toml pour les répertoires db et teams. Le README documente également AGMSG_PLUGIN_DIRS pour des chemins de recherche de pilotes supplémentaires. Il ne décrit pas de mécanisme de sauvegarde, mais indique que les mises à jour préservent la base de données.

Plugins, construction sur agmsg et environnement du projet

agmsg a un système de plugins de pilotes groupés par axe, avec des intégrés sous scripts/drivers et des pilotes externes sous les répertoires plugins. Les pilotes externes sont ignorés jusqu'à ce que l'utilisateur opte avec 'agmsg plugin trust'. Pour les projets qui veulent construire sur agmsg, le README recommande de lire via scripts/api.sh et d'écrire via les scripts existants plutôt que de toucher directement à la base. La section communauté liste plusieurs outils tiers construits sur agmsg, notamment un tableau kanban, un client terminal et une relecture de messages. Le README crédite des contributeurs externes spécifiques pour des fonctionnalités comme le support Gemini, le support Copilot CLI et les helpers Windows Git Bash. Le projet est sous licence MIT, qui accorde la permission d'utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et vendre, sans garantie. Le README ne déclare aucune garantie de sécurité, aucun engagement de support ni aucune affirmation de préparation à la production au-delà des fonctionnalités documentées.

Conclusion éditoriale

Le README ne revendique pas de garanties de niveau production, et le projet est publié sous licence MIT sans garantie. Ce qu'il fournit, c'est un mécanisme concret permettant aux agents d'échanger de courts messages texte sur un fichier partagé, avec des commandes documentées, des modes de livraison et un système de plugins pour étendre le support des pilotes.

Sources officielles

  1. Official documentation
  2. Official README
  3. Project repository
  4. Release notes
Notes de la communauté

Notes de la communauté