Messagerie inter-session
- Pourquoi deux sessions Claude Code sur la même machine ne peuvent pas se parler d'origine — et pourquoi vous restez le pont copier-coller
- Les trois patterns qui livrent pour la messagerie peer-to-peer entre sessions : filesystem, bus WebSocket local, et canaux MCP
- Comment installer et utiliser un plugin fonctionnel de bout en bout en moins de deux minutes
- La frontière de confiance à établir — le message d'un peer est du texte arbitraire arrivant comme instruction
- Quand se tourner vers ce pattern vs un sous-agent, un worktree partagé, ou juste tout exécuter dans une seule session
Le problème : vous êtes le pont
Ouvrez Claude Code dans le Terminal A sur libfoo/ et le Terminal B sur app-that-uses-libfoo/. Le Terminal B tombe sur une erreur de type de la librairie. Aujourd'hui, vous — l'humain — faites le routage : lire l'erreur, changer de terminal, la coller dans A, attendre le fix, revenir, relancer le build. Chaque changement de contexte perd de l'état des deux côtés.
C'est exactement la douleur dans la RFE Anthropic fermée claude-code#36181, ouverte en mars 2026 : "When working on interdependent projects across multiple terminals, users currently must manually context switch between sessions." L'issue est fermée — mais un canal inter-session natif n'est pas encore dans Claude Code. Alors la communauté a livré le sien.
Les trois patterns
Trois projets open source indépendants ont convergé sur le même problème début 2026, chacun choisissant un transport différent. Ils comptent parce que les compromis sont cuits dans le choix du transport — pas dans un projet particulier.
| Pattern | Transport | Livré comme | Latence | Multi-machine | Débuggable |
|---|---|---|---|---|---|
| Inbox basée fichier | Fichiers JSON sous ~/.claude/session-bridge/sessions/<id>/{inbox,outbox}/ | 9 scripts bash + jq | ~5–10s (poll 3s) | ❌ mono-machine | ✅ cat message.json |
| Bus WebSocket local | WebSocket localhost, daemon de session | Plugin Claude Code | niveau ms | ❌ mono-machine | ⚠️ nécessite dump du bus |
| Canaux MCP | Serveur MCP avec canaux style Slack + recherche sémantique | npx claude-slack | saut réseau | ✅ fonctionne sur réseau | ✅ requête MCP |
Choisissez le transport qui correspond à comment vous déboguez déjà et à combien de machines vous exécutez réellement des agents.
1. Inbox basée fichier — PatilShreyas/claude-code-session-bridge (MIT, 65★)
Chaque session a un répertoire : ~/.claude/session-bridge/sessions/<id-6-chars>/. Les messages sont des fichiers JSON avec un champ status qui bascule atomiquement pending → read. Le récepteur sonde son inbox toutes les 3 secondes. La raison propre de l'auteur pour sauter WebSockets et MCP : "They're debuggable. You can literally cat a message."
Session A devient écouteur ; Session B lui pose une question
# In session A (the library repo) /bridge listen # → prints A's 6-char session id, e.g. a1b2c3 # In session B (the app that consumes the library) /bridge connect a1b2c3 /bridge ask "Which version of libfoo exports the parseDate() helper, and did its signature change?"
La Session A répond depuis son contexte live — les fichiers chargés, les résultats d'outils récents, son plan mode. La Session B reçoit la réponse comme un message qu'elle traite comme entrée trusted human-adjacent. Cette dernière phrase est toute l'histoire de sécurité de ce pattern ; continuez de lire.
2. Bus WebSocket local — yilunzhang/claude-code-inter-session (MIT, 27★)
Un daemon local bind un WebSocket sur votre interface loopback. Chaque session connectée enregistre un nom et peut send, broadcast (payload plafonné à 256 KB), ou list les peers. La livraison utilise l'outil Monitor de Claude Code, donc les sessions idle ne brûlent aucun token et aucune boucle de polling ne tourne. Nécessite Claude Code ≥ 2.1.105 et Python ≥ 3.10.
Installez comme marketplace de plugin, puis utilisez ses commandes slash :
Installer le plugin inter-session et connecter deux terminaux
# In any Claude Code session (run once per machine) /plugin marketplace add https://github.com/yilunzhang/claude-code-inter-session /plugin install inter-session # Terminal A /inter-session:inter-session connect libfoo # Terminal B /inter-session:inter-session connect app /inter-session:inter-session send libfoo "Does parseDate() still accept a string?" # Broadcast to everyone /inter-session:inter-session broadcast "About to bump libfoo to 2.0 — hold merges."
3. Canaux MCP — theo-nash/claude-slack (MIT, 8★)
Un serveur MCP complet qui expose des abstractions style Slack : #general, canaux par projet, DMs, et une couche de connaissance à recherche sémantique adossée à Qdrant. Les messages persistent à travers les redémarrages, ce que les deux autres ne font pas. Le compromis : vous exécutez maintenant un service réseau et ses dépendances, et les messages doivent circuler via un aller-retour d'appel d'outil à chaque tour.
Démarrer le serveur MCP et l'utiliser depuis un tour d'agent
# Start once (in its own terminal) npx claude-slack # In any Claude Code session, once claude-slack is added to your MCP config: Post to #libfoo-consumers that parseDate() moved from utils to date-helpers in v2.0. Then search the channel for prior questions about parseDate to make sure I answered them.
Utilisez les canaux MCP quand vous voulez de la persistance (des sessions ultérieures peuvent chercher ce que les précédentes ont dit) ou quand les peers vivent sur des machines différentes — les deux autres sont mono-machine uniquement.
Choisir le bon transport
- Si les sessions tournent sur des portables différents ou une box distante, seul le pattern canal MCP fonctionne. L'inbox fichier et le bus WebSocket local sont mono-machine par conception.
- Les canaux MCP stockent les messages pour qu'une session démarrée demain puisse chercher le contexte d'hier. Les deux autres traitent les messages comme éphémères.
- Si vous aimez lire les transcripts avec cat et grep, choisissez l'inbox basée fichier. Si la livraison sub-seconde compte, choisissez le bus WebSocket. Si vous exécutez déjà des serveurs MCP, choisissez claude-slack.
- Les sessions peer portent chacune leur propre état projet live — fichiers chargés, plan mode, éditions récentes. Si vous avez juste besoin d'un worker scopé pour exécuter une tâche focalisée et retourner, lancez un sous-agent à la place ; c'est plus simple et natif.
- Essayez le bridge basé fichier sur une douleur à deux repos avant d'introduire un daemon ou un serveur MCP. Si la latence de polling va, vous avez fini.
La frontière de confiance à ne pas sauter
Voici la partie dont personne ne parle clairement. Dans chaque pattern ci-dessus, un message arrive à la session réceptrice comme du texte que l'agent traitera comme instruction par défaut. Cela signifie : une autre session — ou tout ce sur votre box qui peut écrire dans l'inbox/socket/MCP — peut injecter des prompts dans votre agent.
- Un message peer est une entrée non fiable, pas un tour utilisateur. Même sur votre propre machine, l'expéditeur est un autre agent autonome qui peut lui-même avoir été prompt-injecté par un fichier qu'il a lu.
- N'exécutez jamais la messagerie inter-session avec un jeu d'outils grand ouvert. Associez-la à un profil de permissions Claude Code qui bloque le shell destructif, les web fetches arbitraires, et les chemins de secrets.
- Les patterns WebSocket et basé fichier n'ont AUCUNE authentification de l'expéditeur par défaut. Tout processus local qui peut bind au socket loopback ou écrire dans ~/.claude/session-bridge/ peut se faire passer pour un peer.
- Traitez les broadcasts comme un rayon d'impact. Un seul message empoisonné vers 5 sessions connectées, c'est 5 agents compromis, pas 1.
- En cas de doute, médiatisez : faites en sorte que la session réceptrice résume le message entrant pour votre approbation avant d'agir dessus — un hook léger ou un garde-fou de prompt dans la frontmatter du plugin fait le job.
Pour le modèle de menace général dans lequel cela s'inscrit, voir Prompt Injection et Securing Agents. Pour les risques de bus spécifiques à MCP, Invisible-Comment MCP Attacks est directement pertinent — la même classe de bug « message arrivant avec instructions cachées » s'applique à un canal style Slack exactement comme à un résultat d'outil.
Quand cela bat un sous-agent — et quand pas
Sessions peer et sous-agents résolvent des problèmes différents. Un sous-agent est un Claude frais avec un jeu d'outils scopé que vous lancez pour protéger le contexte principal ou spécialiser une tâche ; il commence vide et retourne un résultat. Une session peer est une instance Claude Code long-running, human-driven avec ses propres fichiers chargés, plan mode actif, et une conversation entière d'état — vous empruntez son contexte, vous n'en créez pas un nouveau.
Tournez-vous vers la messagerie inter-session quand la valeur est dans l'état live de l'autre session : la librairie sur laquelle elle raisonne déjà, le test qui vient d'échouer, le commit qu'elle vient de stager. Tournez-vous vers un sous-agent quand la valeur est dans exécuter une tâche bornée en isolation. Si vous vous retrouvez à utiliser la messagerie inter-session pour tirer des questions one-shot sans dépendance au contexte du peer, vous voulez probablement un sous-agent — ou un worktree partagé.
Pour les workflows multi-agents à long format qui dépassent les deux patterns, voir Long-Running Agent Harnesses et Native Multi-Agent APIs.
Erreurs courantes
Vérifiez-vous
0/3- Claude Code ne livre pas de messagerie inter-session native (encore) ; trois projets communautaires comblent le vide avec des transports différents.
- Choisissez basé fichier pour la débuggabilité, WebSocket pour la latence sub-seconde sur une machine, et canaux MCP seulement si vous avez besoin de persistance ou de peers cross-machine.
- Un message d'une session peer est une entrée non fiable — traitez-le comme toute autre surface d'injection de prompt et associez le bus à un profil de permissions serré.
- Si vous avez seulement besoin d'un worker scopé pour une tâche, utilisez un sous-agent à la place ; les sessions peer sont pour emprunter l'état live d'une autre session.
- La RFE officielle (claude-code#36181) est fermée mais pas implémentée — surveillez le repo pour une version native et attendez-vous à ce que les projets communautaires convergent ou meurent une fois qu'elle atterrit.
Sources et lectures complémentaires
- claude-code#36181 — Cross Session Messaging for Multi Project Coordination — la RFE officielle qui nomme la douleur et esquisse le jeu de capacités désiré.
PatilShreyas/claude-code-session-bridge— MIT, basé fichier, 9 scripts bash +jq; la justification de l'auteur est dans le billet de blog ci-dessous.- Shreyas Patil — session-bridge: I Made Two Claude Code Sessions Talk to Each Other (2026-03-20) — l'écrit sur le choix de transport qui explique pourquoi le filesystem a battu les WebSockets et MCP pour cet auteur.
yilunzhang/claude-code-inter-session— MIT, bus WebSocket, installé comme plugin Claude Code ; nécessite Claude Code ≥ 2.1.105.theo-nash/claude-slack— MIT, serveur MCP avec canaux style Slack, DMs, et recherche sémantique sur les messages antérieurs.- Subagents & Parallel Agents — l'alternative quand vous avez besoin d'un worker frais scopé, pas d'un peer live.
- Prompt Injection & Invisible-Comment MCP Attacks — le modèle de menace qui gouverne chaque message traversant ce bus.