claude-peers-mcp — Messagerie ad-hoc entre instances Claude Code¶
Resume¶
Serveur MCP qui permet à plusieurs instances Claude Code simultanées de se découvrir et communiquer entre elles. Architecture : un broker daemon sur localhost:7899 avec SQLite, chaque session lance son propre serveur MCP qui s'enregistre auprès du broker. Les messages entrants sont poussés via le protocole claude/channel (quasi-instantané). Capacités : lister les pairs (filtrables par machine/répertoire/repo), envoyer des messages, définir un statut visible aux autres pairs. Idéal pour coordonner plusieurs projets en parallèle.
Analyse critique¶
Ce qui est techniquement solide :
L'architecture broker + MCP par session est propre. Pas de polling — les messages sont poussés via claude/channel. Le filtrage par répertoire/repo est la feature clé : dans un contexte multi-stories, une session PD-285 peut trouver la session PD-286 par son répertoire plutôt que par un ID arbitraire.
La persistence SQLite locale est bonne : les statuts et messages survivent aux redémarrages du broker, contrairement à une solution en mémoire.
Ce qui manque :
Pas de mécanisme de routage explicite par préfixe (type [PD-285]). Les sessions se découvrent par répertoire/repo, mais la logique de filtrage "cette instance traite ce message, les autres l'ignorent" doit être implémentée dans les hooks ou les prompts des sessions.
Pas de sécurité : le broker expose un port localhost non authentifié. Sur une machine de dev solo, ça passe. En multi-utilisateur ou CI/CD, c'est un risque.
Comparaison avec l'approche iMessage (PD-290) :
| Aspect | claude-peers-mcp | iMessage (PD-290) |
|---|---|---|
| Direction | Pairs ↔ Pairs | Humain → Session |
| Routage | Par répertoire/repo | Par préfixe [PD-XXX] |
| Persistance | SQLite local | Messages.app |
| Latence | Quasi-instantané | ~secondes |
| Mobile | Non | Oui (iPhone) |
| Usage | Coordination agent-agent | Arbitrage humain |
Les deux sont complémentaires, pas concurrents.
Pertinence ProbatioVault¶
Impact fort. Le use case principal n'est pas la coordination agent-agent (les agents step 6b sont volontairement isoles, Art. II), mais le multiplexage attentionnel.
Le probleme reel : le workflow supporte deja le parallelisme — chaque story a sa propre FSM Jira, on peut avoir 10 stories en parallele (PD-285 en step 6b, PD-286 en step 1, PD-287 en step 4). Le goulot d'etranglement n'est pas technique, c'est le cout cognitif humain de suivre N sessions Claude Code en parallele (N fenetres, N contextes, detecter soi-meme les blocages et escalades).
Le pattern "Lord of the Claude Code" : 1. Un seul Claude Code "Lord" — la seule interface de l'utilisateur 2. N sessions peers — chacune sur une PD-XXX, chacune avec /gov PD-XXX, chacune autonome 3. Le Lord ouvre les sessions, poll leur avancement ("ou en es-tu ?"), et remonte uniquement les escalades et arbitrages 4. L'utilisateur ne voit qu'une seule conversation au lieu de N
Combine avec /teleport et /remote-control (Claude Code v2.1.81+) : le Lord tourne sur le Mac, l'utilisateur le suit depuis l'iPhone. N stories en parallele, 1 Lord, 1 telephone. Le goulot d'etranglement humain est reduit de N sessions a 1 interface mobile.
Ce que ca ne change pas : les agents step 6b restent isoles (pas de communication inter-agents). Le Lord coordonne les stories, pas les agents au sein d'une story. L'isolation de contexte (Art. II) est preservee.
Prochaine etape : prototyper un skill /gov-lord qui lance N sessions peers via claude-peers-mcp et orchestre le suivi. Ajouter au TODO.