Messagerie inter-sessions dans Claude Code

Depuis la v2.1.224, chaque session interactive de Claude Code sur un Mac ou une machine Linux ouvre un socket Unix dès son démarrage (le mien se trouve à /tmp/cc-socks/38590.sock, avec des permissions restreintes au propriétaire), et n’importe quelle autre session que vous exécutez peut y déposer un message texte.¹ Deux outils portent la fonctionnalité : ListAgents découvre celles de vos sessions qui sont joignables, et SendMessage livre le message à l’une d’elles, désignée par son nom.² Rien à activer, rien à configurer. Si les deux sessions tournent en v2.1.224 ou ultérieure sur la même machine, elles peuvent déjà se parler.

L’essentiel

Les sessions Claude Code peuvent désormais s’écrire entre elles : sur une même machine via des sockets locaux qui ne transitent jamais par les serveurs d’Anthropic, et d’une machine à l’autre via Remote Control — en réponse uniquement au lancement, la v2.1.225 ajoutant la possibilité d’engager ces conversations par le nom du destinataire.¹⁵ Un message est du texte brut, jamais un historique de conversation, des fichiers ou des permissions, et la session réceptrice le traite comme une entrée, pas comme une autorité : il ne peut ni valider une demande de permission, ni modifier la configuration, ni exécuter de commandes.¹ La fonctionnalité transforme une flotte de terminaux indépendants en quelque chose qui ressemble à une équipe, et les meilleurs usages sont les messages de coordination que vous transportiez jusqu’ici à la main : « la migration est terminée », « j’ai renommé cette colonne », « on peut rebaser sur main sans risque ». Le piège le plus vicieux reste l’absence silencieuse : quatre variables d’environnement de confidentialité, sans rapport apparent entre elles, désactivent chacune la fonctionnalité sans un mot.³

Ce qui a été livré

La v2.1.224 a ajouté SendMessage inter-sessions avec la découverte par ListAgents sur macOS et Linux ; la v2.1.225 a étendu le dispositif pour qu’une session puisse aussi engager une conversation avec vos sessions Remote Control sur d’autres machines, là où elle ne pouvait auparavant que répondre.⁴⁵

Trois surfaces donnent à voir la mécanique :

• /list-agents (alias /peers) énumère toutes les sessions que Claude peut atteindre : les sous-agents de la session courante, vos autres sessions locales y compris celles en arrière-plan et, tant que Remote Control est connecté, vos sessions sur d’autres machines ainsi que sur Claude Code sur le web.¹
• /status affiche une ligne Peer address avec le socket de réception propre à la session, préfixé par uds:.¹
• CLAUDE_CODE_MESSAGING_SOCKET est exportée vers chaque point d’accroche et chaque commande Bash, et contient le chemin du socket de la session elle-même.⁶ Nous y reviendrons plus bas.

Vérification sur ma propre machine : une session en v2.1.226 liste deux sessions pairs avec leur état (« busy ») et leur ancienneté, et le fichier socket porte les permissions srw-------, c’est-à-dire lisible et modifiable par mon seul compte utilisateur — la frontière qui compte sur une machine partagée.¹

Les sessions répondent à des noms. Attribuez-en un avec /rename ou l’option --name ; sinon Claude Code en dérive un du répertoire de travail, du type myapp-3f.¹ Quand deux sessions portent le même nom, la liste les distingue par leur répertoire de travail et un identifiant court.¹

Le modèle de confiance, voilà ce qui est intéressant

La conception d’Anthropic répond à une question que la plupart des systèmes multi-agents esquivent : que vaut un message venu d’un autre agent ? La réponse est ici sans ambiguïté : un message est une information, jamais une autorité.¹

Lorsque la session A écrit à la session B, quatre règles encadrent ce qui arrive :¹

1. Le message ne valide rien. Une demande de permission en attente dans B ignore tout ce que dit A. Vous seul répondez aux demandes.
2. Il ne modifie aucune configuration. Claude côté réception a pour consigne de ne jamais toucher aux paramètres de permission, à CLAUDE.md ou à quelque configuration que ce soit parce qu’une autre session l’a demandé.
3. Les commandes arrivent sous forme de texte. Un /compact dans le corps du message n’est qu’une suite de caractères, jamais une commande exécutée.
4. Les demandes de permission se déclenchent toujours. Si agir sur le message exige une permission dont B ne dispose pas, vous voyez la même demande que pour n’importe quel autre travail.

La livraison entrante a sa propre barrière. Chaque message reçu aboutit à l’un de trois résultats — livré, mis en attente de votre approbation, ou refusé — selon le paramètre crossSessionInbound (accept, hold, refuse).¹ Si vous ne réglez rien, Claude Code tranche message par message à partir des modes de permission des deux sessions, et la logique par défaut est élégante : les sessions qui contournent les demandes de permission forment une classe, toutes les autres la seconde. Une session qui demande des permissions reçoit librement les messages mais met en attente tout ce qui provient d’une session en contournement ; une session en contournement met tout en attente, sauf les messages venus de ses semblables.¹ L’asymétrie est délibérée : un message ne doit pas voyager sur l’autorité d’une session permissive, principe que la v2.1.224 applique en entrée après que la v2.1.222 l’a appliqué en sortie en mode auto, où le classificateur de permissions examine chaque envoi avant expédition.⁷

Les messages mis en attente ouvrent une boîte de dialogue d’approbation indiquant l’expéditeur et un aperçu ; une boîte laissée sans réponse expire au bout de cinq minutes (réglable via dialogExpiry) et le message est perdu.¹ Cent messages au plus peuvent être en attente simultanément.¹ Deux réglages supplémentaires resserrent encore le cadre : isolatePeerMachines: true exige votre approbation explicite avant qu’un message ne quitte la machine, y compris en mode bypassPermissions, et un true posé dans n’importe quelle portée de paramètres l’emporte — un fichier de projet versionné peut donc durcir la règle, jamais l’assouplir.¹ Les organisations peuvent supprimer la fonctionnalité de bout en bout avec des règles de refus sur SendMessage et ListAgents, plus crossSessionInbound: "refuse" dans les paramètres gérés.¹

Comment circulent les messages

L’endroit où tourne l’autre session détermine à la fois le transport et ce que vous pouvez envoyer :¹

Une contradiction dans la documentation mérite d’être signalée : à l’heure où j’écris, la page d’Anthropic consacrée à la messagerie inter-sessions décrit encore toute messagerie entre machines comme limitée aux réponses, tandis que les notes de version de la v2.1.225 indiquent que SendMessage « peut désormais engager une conversation avec vos sessions Remote Control sur d’autres machines en les désignant par leur nom ». Les notes de version sont plus récentes ; la page de documentation est en retard sur la livraison.¹⁵

La règle de la « même machine » tient en réalité à la visibilité du système de fichiers : les sessions s’enregistrent dans des fichiers sur disque, si bien que deux sessions ne se joignent que lorsqu’elles voient les mêmes fichiers. Une session dans un conteneur et une session sur l’hôte ne peuvent pas communiquer ; deux sessions dans le même conteneur, si.¹

La livraison respecte le rythme de la session réceptrice : un message est lu entre deux appels d’outil pendant un tour actif, sans jamais interrompre un outil en cours d’exécution, et déclenche un nouveau tour lorsque la session est inactive.¹ Les messages livrés comptent dans votre consommation comme une invite que vous auriez tapée.¹

Cinq usages qui valent le détour

1. Coordination entre worktrees. L’évidence même, et le cas que la documentation illustre par son propre exemple de message : des sessions travaillant sur le même dépôt dans des worktrees distincts s’informent mutuellement de ce qui a été intégré.¹ « Migration de schéma terminée : la nouvelle colonne s’appelle tenant_id, et rebaser sur main est désormais sans risque. » — c’est l’exemple donné par la documentation, exactement le type de nouvelle qui, sans cela, suppose que vous le remarquiez, changiez de terminal et le retapiez. Si plusieurs sessions partagent une même copie de travail au lieu de worktrees, le message de coordination gagne encore en valeur : « je m’apprête à committer content/guides/, ne l’ajoutez pas à l’index » évite la collision classique de l’arbre partagé, où une session valide le travail à moitié fini d’une autre.

2. Veille et intervention. Faites tourner une session de surveillance sur un déploiement, une suite de tests ou un journal, et faites-lui écrire à la session chargée des correctifs dès que quelque chose casse. La session réceptrice reçoit le constat comme contexte, pas comme ordre ; c’est toujours elle qui décide, sous ses propres permissions, de la suite. Associez cela aux sessions en arrière-plan et aux points d’accroche de notification, et vous obtenez une chaîne d’escalade qui ne remonte jusqu’à un humain que lorsqu’elle le doit.

3. La tâche longue qui rend des comptes. Lancez une migration ou une longue campagne de tests dans une session, puis faites-lui rendre compte à celle que vous regardez vraiment.¹ L’état d’avancement cesse d’habiter un terminal que vous avez oublié. L’inverse fonctionne aussi ; posez la question depuis la session qui observe : « demandez à la session de mon autre terminal si la migration est terminée » est une simple invite, et Claude se charge lui-même de la découverte, de l’adressage et de la formulation.¹

4. Des flottes de travailleurs sans surveillance. Les sessions headless claude -p ouvrent elles aussi un socket de réception : un travailleur -p de longue haleine peut donc recevoir des messages et apparaît dans les listes.⁸ Le hic : une session -p ne peut pas afficher la boîte de dialogue d’approbation, si bien qu’un message mis en attente le reste, sans autre issue qu’un changement de paramètres ou de mode (la v2.1.225 a d’ailleurs corrigé le cas de ces messages stationnant sans notification ni expiration). Pour faire tourner un travailleur qui accepte les messages sans surveillance, démarrez-le avec crossSessionInbound: "accept" dans sa valeur --settings : une autorisation accordée à ce travailleur-là, plutôt qu’un accept dans les paramètres utilisateur qui s’appliquerait à toutes vos sessions.⁸ Les sessions en mode bare ignorent complètement le socket et restent injoignables.⁸

5. Des boîtes de réception scriptées. La puissance discrète : puisque CLAUDE_CODE_MESSAGING_SOCKET est exportée vers les points d’accroche et les commandes Bash, un script peut déposer un message dans la boîte de réception de sa propre session.⁶ Claude Code authentifie les messages émis par ses propres processus enfants : le message qu’un point d’accroche ou une commande adresse à sa session d’origine est livré sans formalité lorsqu’aucun crossSessionInbound explicite ne s’applique.¹ Une tâche nocturne, un hook Git, un script de CI : tout ce qui sait écrire dans un socket Unix peut désormais injecter une ligne de contexte dans la session qui l’a lancé. Sous Linux, la vérification fonctionne même après la fin du processus émetteur ; sous macOS, uniquement tant qu’il tourne ; dans un conteneur où Claude Code est le PID 1, la vérification échoue et le message retombe sur les règles d’entrée ordinaires.¹ Les commandes exécutées en bac à sable ont besoin que le socket soit autorisé via sandbox.network.allowUnixSockets.¹

Ce que la fonctionnalité refuse d’être

Les limites sont des décisions de conception, et les respecter vous épargne de construire la mauvaise chose.

Pas un canal d’approbation. Tout le modèle de confiance existe pour empêcher qu’une session en autorise une autre à agir. Tout flux de travail de la forme « la session A approuve, la session B exécute » va explicitement à l’encontre de la conception. Faites toujours passer l’autorité par l’humain.¹

Pas un transfert de contexte. Un message est du texte qu’un Claude écrit à un autre, jamais un historique de conversation ni des fichiers. La documentation d’Anthropic le dit sans détour : pour déplacer une conversation, reprenez plutôt la session.¹ Résumez, ne déversez pas.

Pas des équipes d’agents. Des sessions indépendantes qui s’écrivent, c’est le cas pair-à-pair. Une équipe coordonnée que Claude crée et supervise (messages de protocole structurés, liste des membres, état des tâches partagé) relève de la fonctionnalité des équipes d’agents, et les messages structurés d’une équipe restent délibérément à l’intérieur de celle-ci.¹ Si vous vous surprenez à concevoir un protocole de messages par-dessus le texte inter-sessions, c’est d’équipes d’agents que vous avez besoin.

Pas une boucle de discussion. Claude Code limite le débit des messages répétés par expéditeur, écarte les répétitions identiques arrivant dans un court intervalle et plafonne à 50 par session les messages acceptés non lus : une boucle de messages entre deux sessions s’épuise donc d’elle-même, par construction.¹ Construisez des échanges de type requête-réponse, pas des conversations.

Les pièges

Les variables de confidentialité la désactivent en silence. La messagerie inter-sessions repose sur l’évaluation des indicateurs de fonctionnalité, et l’une quelconque des variables CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK ou DISABLE_GROWTHBOOK peut couper cette évaluation, emportant la messagerie avec elle, sans le moindre avertissement.³ Le diagnostic passe par /list-agents : si la commande n’est même pas reconnue, la session ne dispose pas du tout de la fonctionnalité ; si elle fonctionne mais qu’un envoi n’arrive jamais, la cause est plus étroite — une règle de refus, les contrôles d’entrée du destinataire, ou une cible sur une autre machine qui n’accepte que les réponses.¹

Lacunes de plateformes et de fournisseurs. Pas de prise en charge native de Windows (Linux sous WSL 2 fonctionne). Indisponible sur Amazon Bedrock, Claude Platform sur AWS, l’Agent Platform de Google Cloud et Microsoft Foundry.¹

Le cas de la réponse à sens unique. Une réponse adressée à une session sur une autre machine, envoyée alors que la session émettrice n’est pas connectée à Remote Control, arrive bien, mais sans adresse de retour : le destinataire ne peut donc pas répondre. Claude en est informé au moment de l’envoi, et les correctifs de la v2.1.225 ont resserré l’adressage pour qu’un destinataire confirmé sur une autre machine ne soit jamais remplacé en silence par une session locale portant le même nom.⁵

Les mises en attente en headless. Le travailleur -p qui ignore mystérieusement les messages est presque toujours un problème de message en attente : pas de boîte de dialogue, pas de livraison. Réglez crossSessionInbound: "accept" sur les travailleurs censés écouter.⁸

À retenir

Pour les utilisateurs quotidiens de Claude Code : - Lancez /list-agents une fois pour voir ce que vos sessions peuvent déjà atteindre ; nommez les sessions importantes avec /rename pour que les messages s’adressent proprement. - Formulez vos demandes de message en langage courant (« dites à la session qui travaille sur les paiements ce que nous avons changé ») et laissez Claude rédiger le message lui-même.¹

Pour ceux qui construisent de l’automatisation : - Déposez des messages dans les sessions depuis vos points d’accroche et vos scripts via CLAUDE_CODE_MESSAGING_SOCKET ; sous Linux, les messages émis par les processus enfants sont livrés sans friction d’approbation.¹⁶ - Donnez crossSessionInbound: "accept" aux travailleurs -p autonomes dans leur propre --settings, pas globalement.⁸

Pour les équipes et les auditeurs sécurité : - La fonctionnalité arrive avec les bons réglages par défaut : les messages ne portent aucune autorité, les sessions en contournement sont mises en quarantaine par défaut, et isolatePeerMachines conjugué aux règles de refus des paramètres gérés vous donne des interrupteurs par machine et à l’échelle de l’organisation.¹ - Auditez les quatre variables d’environnement de confidentialité avant de conclure que la messagerie est cassée, et sachez qu’une session qui refuse les messages ne présente aucune différence visible pour ses pairs.¹

Références