Anthropic lance une fonction expérimentale de messagerie entre sessions pour Claude Code, permettant l'envoi direct de messages entre différentes sessions. Cette fonction ne transmet pas le contexte complet, mais uniquement les résultats de tâches et les informations de dépendance, en utilisant deux outils internes : ListAgents et SendMessage. Chaque session locale s'enregistre sur le disque et se lie à un socket Inbox ; les messages locaux sont transmis directement via le socket, tandis que les messages inter-ordinateurs sont acheminés via le serveur Anthropic. Les messages déclenchent un nouveau tour lorsqu'une session est inactives, et sont lus entre les appels d'outil lorsqu'une session est active. Le récepteur distingue les messages inter-sessions des messages utilisateur ; ils ne peuvent pas remplacer une autorisation utilisateur, et trois modes de contrôle entrant sont disponibles : accepter, mettre en attente ou refuser. Cette fonctionnalité s'intègre aux capacités existantes telles que Resume Session, Agent Teams et Worktree, offrant à Claude Code une couche de coordination entre sessions.

Auteur et source de l'article : Leifengwang

Ces derniers jours, Anthropic a ajouté à Claude Code une nouvelle fonctionnalité expérimentale : la messagerie inter-sessions.

En bref, il vous permet d'envoyer des messages directement entre plusieurs sessions Claude Code en cours d'exécution simultanément.

Par exemple, vous avez ouvert 3 sessions Claude Code : une pour la base de données, une pour l’API backend et une pour les tests. Auparavant, bien que ces 3 sessions puissent fonctionner en parallèle, elles ne connaissaient pas l’avancement des autres. Une fois que la session base de données avait modifié le schéma, le développeur devait généralement passer manuellement à un autre terminal pour informer la session backend des changements.

Après l'ajout de la messagerie entre sessions, cette étape peut être directement effectuée par Claude. La session de base de données peut notifier la session backend quels champs ont été modifiés ; en cas de détection de problèmes de régression d'interface via la session de test, les résultats peuvent également être envoyés à la session en cours de modification du code concerné. Claude peut déterminer automatiquement quand il est nécessaire de notifier d'autres sessions, ou contacter des sessions spécifiques selon les exigences des développeurs.

Pour comprendre précisément ce qu'il fait, suivez le parcours complet d'un message : ce qu'il transmet, comment il trouve la cible, quand le message entre dans Claude, et pourquoi le destinataire ne peut pas simplement agir directement.

01

Les messages entre sessions n'ont pas modifié l'isolation des sessions d'origine de Claude Code.

Lorsqu'une session A envoie un message à une session B, elle n'envoie pas son historique de conversation, les fichiers lus ou l'ensemble de la fenêtre de contexte. Selon les règles officielles, seuls les textes sont transmis entre sessions. Pour migrer l'ensemble de la conversation et du contexte vers un autre terminal, il faut reprendre la session d'origine, et non utiliser le message inter-sessions.

Cela détermine la manière dont plusieurs Claude collaborent.

Supposons que la session de la base de données ait lu des dizaines de fichiers et testé plusieurs approches pour accomplir la migration, et qu'elle ait finalement déterminé qu'un champ doit être modifié. La session backend n'a pas besoin de connaître l'ensemble du processus d'analyse précédent ; elle doit simplement recevoir les modifications finales et comprendre comment celles-ci affecteront son API.

Ainsi, Cross-session messaging transmet les résultats des tâches et les informations de dépendance, et non la mémoire de travail complète.

Le bénéfice de cette approche est que les informations locales générées par différentes tâches n'inondent pas constamment les autres sessions. Les détails liés à la base de données restent dans la session de base de données, les processus de test restent dans la session de test, et seules les informations pertinentes franchissent la limite de la session lorsqu'un changement commence à affecter d'autres tâches.

Cela relève d'une approche différente de « tous les agents partagent un grand contexte ». Les messages entre sessions choisissent de garder les sessions indépendantes, puis de synchroniser explicitement les états nécessaires lorsque des dépendances entre tâches apparaissent.

Puisqu'un message clair est transmis, la question suivante est : comment Session A trouve-t-elle Session B ?

02 Il faut d'abord trouver une autre session

Claude Code ajoute son propre point de communication aux sessions prenant en charge les messages entre sessions.

Chaque session locale enregistre les informations pertinentes sur le disque et lie un socket Inbox. Claude peut rechercher les sessions actuellement joignables via ListAgents, puis envoyer un message à la cible désignée via SendMessage.

Les utilisateurs n'ont pas besoin d'opérer eux-mêmes ces outils internes ; ils n'ont qu'à indiquer à Claude quel Session contacter, ou à lui demander de notifier automatiquement l'autre partie lorsque la tâche génère une dépendance.

Le nom de la session participe ainsi à l'adressage. Claude peut rechercher la cible selon le nom ; en cas de doublon, le système ajoute un identifiant court pour distinguer les sessions, tout en affichant le Répertoire de travail pour aider à identifier quel projet ou répertoire chaque session traite.

Une fois la cible trouvée, les messages locaux sont transmis directement via le Socket de la session correspondante, sans passer par le serveur Anthropic. Les sessions sur un autre ordinateur ou sur Claude Code Web communiquent uniquement via le serveur Anthropic et les connexions liées au contrôle à distance.

Ce mécanisme de découverte détermine également les limites de la communication locale.

Claude Code doit lire les informations d'inscription écrites sur le disque par d'autres sessions, donc deux Claude, même s'ils s'exécutent physiquement sur le même ordinateur, peuvent ne pas se détecter mutuellement tant que leurs systèmes de fichiers sont isolés. C'est typiquement le cas entre l'hôte et un conteneur indépendant ; si les deux sessions s'exécutent dans le même conteneur, elles peuvent communiquer normalement.

Inbox Socket est également soumis aux restrictions de permissions utilisateur du système d'exploitation ; les autres utilisateurs OS sur le serveur partagé ne peuvent pas accéder directement à votre session.

Ainsi, ce qu'on appelle ici « communication locale » dépend en réalité de la visibilité des informations d'inscription, de la disponibilité du socket et de la permission accordée par le système d'exploitation.

Le message est désormais capable de trouver sa cible et d'être acheminé vers la boîte de réception ; il revient maintenant au Runtime de Claude Code de décider quand transmettre ce message au modèle.

03 Une fois le message envoyé

Supposons que la session backend est en train de modifier un fichier, et que la session de test envoie un message pour signaler qu'elle vient de détecter un problème de régression d'interface.

Claude Code n'interrompra pas immédiatement l'outil en cours d'exécution.

Si la session cible est en état Idle, le message peut déclencher un nouveau tour ; si Claude est déjà en cours de tour actif, le message attendra et sera lu entre deux appels d'outil.

Cela est lié à la manière dont l'Agent de codage exécute les tâches. Claude pourrait actuellement écrire un fichier, exécuter des tests, effectuer une migration ou traiter une autre tâche chronophage. Si un message externe pouvait modifier arbitrairement l'action en cours, il serait facile que l'outil n'ait exécuté qu'une partie de la tâche, tandis que l'Agent aurait déjà commencé à replanifier selon les nouvelles informations.

Ainsi, le message influence les décisions suivantes de Claude sans interrompre directement les opérations en cours.

Cela signifie également que Cross-session messaging a été intégré à la boucle agente de Claude Code, devenant une source d'entrée asynchrone. Et cet accès n'est pas réservé uniquement aux autres sessions Claude.

Claude Code expose le socket de messagerie de la session actuelle aux processus enfants lancés par Hook et Bash. Une fois qu'une tâche en arrière-plan de longue durée est terminée, elle peut envoyer activement le résultat à la session actuelle, sans que Claude doive le surveiller en boucle pour vérifier son achèvement.

Ce canal n'est pas lui-même une file d'attente de messages fiable. Les messages en double sont soumis à un limitateur de débit, et des contenus identiques sur une courte période peuvent être supprimés ; les messages déjà acceptés mais pas encore lus par Claude sont conservés jusqu'à 50 par session, tandis que les messages en état Hold utilisent un autre tampon, avec une capacité maximale de 100.

Il est donc plus adapté pour envoyer des changements d'état, des résultats de tâches et des notifications de collaboration. Les faits qui doivent être conservés à long terme doivent toujours être enregistrés dans Git, des fichiers, une base de données ou un autre système persistant.

Après avoir entré dans le Runtime, le message ne peut pas encore être transformé en action exécutable, car le destinataire doit d'abord déterminer quel niveau de privilèges possède le contenu reçu de l'autre Claude.

04 Comment les permissions sont héritées

Claude Code distingue clairement le message utilisateur et le message de session entre pairs.

Le contenu envoyé par une autre session ne sera pas considéré comme une autorisation de l'utilisateur, donc il ne peut pas approuver le Prompt de permission à la place de l'utilisateur, ni exiger par message que le destinataire modifie les Paramètres de permission, CLAUDE.md ou d'autres configurations. Même si le message contient une commande de code Claude, il sera traité comme un texte ordinaire.

Supposons que la session A demande à la session B de supprimer un fichier, et que cette opération nécessite une autorisation utilisateur dans la session B, alors l'invite de permission originale apparaîtra toujours.

Claude Code limite également un autre contournement de permission : si une opération a déjà été refusée par le système de permission dans la session actuelle, Claude ne doit pas demander à une autre session de l'exécuter à sa place.

Sinon, tant que les autorisations des sessions diffèrent, une session à faible autorisation peut continuellement transférer à une session à haute autorisation les opérations qu'elle ne peut pas accomplir, ce qui rend les limites d'autorisation initiales inopérantes.

Outre les permissions d'exécution, le message lui-même inclut un contrôle entrant. Le destinataire peut définir les messages inter-sessions comme accept、hold ou refuse : les transmettre directement à Claude, les conserver temporairement en attente de confirmation supplémentaire, ou les rejeter directement.

Si l'utilisateur n'a pas configuré explicitement les règles, Claude Code prend en compte le mode de permission actuel de l'expéditeur et du destinataire. Une session pouvant contourner l'invite de permission habituelle n'est pas considérée comme provenant de la même source qu'une session ordinaire ; lorsque les permissions du destinataire sont plus élevées, les messages externes peuvent également être mis en attente.

Il y a en réalité deux vérifications : d'abord déterminer si le message peut entrer dans Claude, puis déterminer si l'action que Claude prépare d'exécuter en fonction de ce message est autorisée.

À cette étape, le parcours complet d’un message Cross-session est terminé : de la génération du message, à la découverte de la cible, en passant par la livraison, puis la lecture du message par le Runtime, suivie du contrôle d’accès du côté récepteur.

Couche de coordination entre les sessions 05

Réintégrer ce lien dans les capacités actuelles de Claude Code permet de mieux comprendre la position du messaging entre sessions.

Resume Session permet de reprendre la conversation et le contexte précédents, Agent Teams permet de créer et gérer un groupe d'agents collaboratifs, Worktree isole les modifications de code entre différentes sessions, et Remote Control résout le problème de poursuite du contrôle d'une session depuis un autre appareil.

Les messages entre sessions gèrent un autre cas : plusieurs sessions qui fonctionnent initialement de manière indépendante, et qui, après avoir développé des dépendances pendant leur exécution, doivent échanger les informations nécessaires.

Auparavant, ouvrir plusieurs sessions Claude Code visait principalement à résoudre les problèmes de parallélisme, mais les développeurs devaient toujours surveiller la progression de chaque terminal et transmettre répétitivement l'état des tâches entre les humains et les sessions. Désormais, des informations telles que les changements d'interface, les résultats des tests ou la finalisation de la migration sont directement envoyées aux sessions concernées.

Cross-session messaging n'a pas fusionné plusieurs Claude en un seul agent, mais a ajouté une couche de communication en dehors du contexte, du répertoire de travail et des limites de permissions existants.

Vu dans un contexte de projet plus vaste, cette conception offre une autre approche multi-agent : différents agents n'ont pas besoin de partager un contexte de plus en plus volumineux, mais peuvent collaborer grâce à des interfaces de communication bien définies. Une fois les tâches, les états et les autorisations séparés, le système devient plus facile à étendre.

Au fur et à mesure que le nombre d'agents augmente, la question évolue progressivement de « combien une seule agent peut accomplir » à « ces agents peuvent-ils échanger stablement des états, gérer les dépendances et effectuer des transferts » .

Bien que le messaging entre sessions ne résolve qu'un seul maillon, il donne déjà à la méthode de travail multi-session de Claude Code une structure d'ingénierie plus complète. Peut-être que, dans le futur, ce mécanisme de communication inter-session au sein d'un réseau local évoluera-t-il en un protocole de communication Agent-to-Agent entre machines et écosystèmes distincts, auquel cas cette brève conversation entre ces deux instances de Claude constituerait une étape clé dans la formation d'une usine logicielle hautement automatisée.