Comment faire communiquer deux sessions Claude Code

Ce que signifie le fait que des sessions Claude Code s’envoient des messages

Deux sessions Claude Code peuvent s’envoyer des messages lorsqu’elles s’exécutent sur la même machine, avec le même utilisateur du système d’exploitation. Un message est un simple texte qu’une session Claude rédige pour une autre. Il ne contient ni historique de conversation ni fichier. Claude trouve l’autre session avec l’outil ListAgents et lui transmet le texte avec SendMessage. Vous n’appelez donc jamais ces deux outils directement. Vous indiquez ce que l’autre session doit savoir, et Claude rédige lui-même le message.

Cette fonctionnalité s’appelle la messagerie intersessions. En août 2026, elle nécessite Claude Code v2.1.224 ou une version ultérieure. Elle fonctionne sur macOS et Linux, y compris Linux dans WSL 2. La prise en charge native de Windows n’est pas disponible. La fonctionnalité n’est pas non plus disponible sur Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform ou Microsoft Foundry. Lorsqu’une session remplit ces conditions, la messagerie est déjà activée et aucune configuration n’est nécessaire. Le comportement décrit ci-dessous vient de la documentation Anthropic sur la messagerie intersessions.

C’est sur un VPS que cette fonctionnalité devient utile, car les sessions y restent suffisamment longtemps actives pour qu’il soit pertinent de les contacter. Sur un ordinateur portable, vous fermez le capot. Sur un serveur utilisant tmux, une session démarrée lundi peut encore être active jeudi et conserver le contexte d’un dépôt. Dès que vous en avez deux, la manière dont elles communiquent cesse d’être théorique. Si vous n’avez pas encore configuré cet environnement, commencez par exécuter Claude Code sur un VPS avec tmux, qui présente la configuration des sessions supposée par ce guide.

Quand une deuxième session justifie son coût

Commencez par le coût. Chaque session correspond à une instance Claude distincte, avec sa propre fenêtre de contexte. Deux sessions coûtent donc environ deux fois plus cher qu’une seule sur la même période. Un message envoyé est comptabilisé dans l’utilisation exactement comme un prompt que vous avez saisi. La coordination n’est pas gratuite. Un travail qui constitue réellement une suite d’étapes devient plus lent et plus coûteux si vous le répartissez entre plusieurs sessions.

Les cas où une deuxième session se justifie ont un point commun. Deux tâches s’exécutent en parallèle sans dépendre l’une de l’autre, et l’une obtient en cours de route une information dont l’autre a besoin.

• Une session détecte une breaking change pendant que l’autre construit sur le code concerné. Claude résume la modification et la transmet, au lieu de vous obliger à la ressaisir dans l’autre terminal.
• Deux sessions travaillent sur le même repository dans des git worktrees distincts, et l’une doit savoir ce qui a été intégré.
• Une migration longue ou un test communique son résultat à la session que vous surveillez.
• Une session de build et une session de revue : la session de revue lit ce que la première a produit et lui transmet ses conclusions.

Lorsque le travail est séquentiel ou que les deux sessions doivent modifier les mêmes fichiers, utilisez une seule session. Si vous voulez un groupe coordonné que Claude lance et supervise dans le cadre d’une même tâche, il s’agit des agent teams, une fonctionnalité distincte qui reste expérimentale. Si vous voulez seulement retrouver la même conversation dans un autre terminal, reprenez la session à la place. La messagerie intersessions est destinée aux sessions indépendantes que vous démarrez et pilotez vous-même.

Vérifiez la présence de la fonctionnalité avant de vous baser dessus

Commencez par vérifier la version :

claude --version

Comparez le numéro avec 2.1.224. Ensuite, dans une session, saisissez /list-agents, qui répond également à /peers. La commande affiche tous les agents que cette session peut joindre, avec le nom auquel chacun répond. Si la commande n’est pas reconnue, cette session ne prend pas en charge la messagerie intersessions et aucun fichier de configuration ne pourra l’activer. Saisissez /status et recherchez une ligne Peer address : elle contient l’adresse de la boîte de réception de cette session, précédée de uds:.

Les utilisateurs de VPS sont particulièrement exposés à un piège. La messagerie intersessions dépend de l’évaluation des feature flags, et plusieurs variables de confidentialité désactivent cette évaluation. La fonctionnalité reste alors désactivée par défaut. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC et DISABLE_GROWTHBOOK produisent tous cet effet. Pour renforcer la sécurité d’un serveur fraîchement installé, certains ajoutent ces variables dans ~/.bashrc, puis se demandent pourquoi /list-agents n’existe pas. Les mêmes valeurs peuvent provenir de la map env d’un fichier de configuration ou de managed settings. Vérifiez donc d’abord l’environnement du shell.

env | grep -E 'DO_NOT_TRACK|DISABLE_TELEMETRY|DISABLE_GROWTHBOOK|NONESSENTIAL'

Supprimez la variable qui s’affiche. Pour DISABLE_TELEMETRY et CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, toute valeur non vide active le comportement, y compris la chaîne 0. Par conséquent, DISABLE_TELEMETRY=0 ne produit pas l’effet attendu. Pour le désactiver, supprimez la variable ou définissez-la sur une chaîne vide.

Nommez vos sessions, sinon Claude ne peut pas les cibler

Claude adresse un message à une session en utilisant son nom. Définissez ce nom au démarrage de la session :

claude --name builder-api

Vous pouvez aussi le définir avec /rename dans une session en cours. Si vous ne définissez aucun nom, Claude Code en dérive un du nom du dossier du répertoire de travail, par exemple myapp-3f. Cela convient pour une seule session, mais devient source de confusion avec quatre sessions. Deux sessions peuvent également recevoir le même nom. La sortie de /list-agents affiche le répertoire de travail de chaque session locale, ce qui permet de distinguer les sessions portant le même nom. La liste générée par Claude ajoute aussi un identifiant court à l’adresse lorsque des noms sont en conflit. Les nommer vous-même coûte moins de temps que de lire les identifiants.

Une disposition tmux à deux sessions que vous pouvez reproduire

Il s’agit d’une session de développement et d’une session de revue sur un même dépôt. La session de revue utilise un worktree Git distinct. Les deux sessions n’écrivent donc jamais dans le même fichier. git worktree add avec HEAD fournit un checkout détaché, ce qui convient à une session qui lit les fichiers sans effectuer de commit.

cd ~/src/api
git worktree add ../api-review HEAD
tmux new-session -d -s agents -n builder -c ~/src/api
tmux new-window -t agents -n reviewer -c ~/src/api-review
tmux send-keys -t agents:builder 'claude --name builder-api' C-m
tmux send-keys -t agents:reviewer 'claude --name reviewer-api' C-m
tmux attach -t agents

Ctrl+b puis w liste les fenêtres par nom afin que vous puissiez en sélectionner une. Dans la fenêtre de développement, exécutez /list-agents. Vous devriez voir reviewer-api avec son répertoire de travail ~/src/api-review. S’il n’apparaît pas, la session de revue n’a pas fini de démarrer ou l’un des deux problèmes décrits dans la section suivante s’applique. Transmettez ensuite les informations en langage courant :

Tell reviewer-api which files I changed for the rate limiter and what to look at first.

Claude rédige le résumé et l’envoie. Vous ne rédigez pas le texte du message, et le contenu envoyé par Claude varie. Dans la fenêtre de revue, le message apparaît dans la conversation avec le nom de l’expéditeur. Si cette session est inactive, Claude y démarre immédiatement un nouveau tour. Si elle est en cours de traitement, le message attend entre deux appels d’outils. Une commande en cours n’est donc jamais interrompue. Une fois que Claude a lu le message, celui-ci est réduit à une ligne Message from que Ctrl+O développe. Le fonctionnement des deux sessions est meilleur lorsque la session de développement conserve des modifications limitées, car un diff restreint produit une transmission plus courte et permet à l’autre session de terminer la revue en un seul tour. C’est l’habitude que la compétence du développeur senior paresseux cherche à imposer.

Qui peut voir qui sur un même VPS

Les échanges entre sessions sur la même machine ne passent jamais par les serveurs d’Anthropic. Chaque session écrit des fichiers d’enregistrement sur le disque et ouvre son propre socket de boîte de réception. Claude Code lit ces fichiers pour trouver vos autres sessions. Deux conséquences en découlent, et toutes deux posent problème sur un serveur.

Le socket est limité à votre utilisateur du système d’exploitation. Une session que vous avez démarrée en tant que root et une session que vous avez démarrée en tant que deploy ne peuvent pas se voir, même côte à côte dans le même serveur tmux, car les sessions d’un utilisateur ne peuvent pas accéder au socket d’un autre utilisateur. Exécutez les deux sessions avec le même utilisateur.

Un conteneur possède son propre système de fichiers. Une session dans Docker et une session sur l’hôte ne peuvent pas communiquer, car elles ne lisent pas les mêmes fichiers d’enregistrement. Deux sessions dans le même conteneur peuvent normalement s’envoyer des messages. Si vous utilisez des conteneurs pour isoler vos agents, comme dans l’exécution d’agents de code dans une VM jetable, attendez-vous à ce que la messagerie fonctionne à l’intérieur d’un conteneur, mais pas entre le conteneur et l’hôte.

Vos sessions sur d’autres machines et sur le Web apparaissent dans la liste uniquement lorsque Remote Control est connecté, et elles sont identifiées comme telles. Claude ici peut uniquement répondre à un message reçu de l’une de ces sessions. Il ne peut pas démarrer cet échange.

Pourquoi votre message n’est jamais arrivé

La raison habituelle n’a rien à voir avec le réseau. La session réceptrice a décidé quoi faire du message, et a décidé de ne pas le distribuer. Chaque message entrant aboutit à l’un de trois résultats : distribué, mis en attente (conservé sans être distribué jusqu’à votre approbation) ou refusé (abandonné sans distribution).

Lorsqu’aucune valeur crossSessionInbound ne s’applique, Claude Code décide du sort de chaque message en comparant les modes d’autorisation des deux sessions. Il regroupe les sessions qui contournent les demandes d’autorisation dans une classe, et toutes les autres sessions dans l’autre. auto, acceptEdits et dontAsk comptent comme des modes avec demande d’autorisation. Le plan mode compte comme un contournement dans une session qui dispose des autorisations nécessaires pour contourner les demandes. La règle est donc symétrique :

• Une session réceptrice qui demande des autorisations reçoit chaque message. Elle n’en met un en attente que lorsque la session émettrice indique qu’elle contourne les demandes d’autorisation.
• Une session réceptrice qui contourne les demandes d’autorisation met chaque message en attente de votre approbation. Elle n’en distribue un que lorsque l’émetteur contourne lui aussi les demandes.

Le premier workflow que la plupart des utilisateurs mettent en place est donc précisément celui qui ne fonctionne pas. Vous démarrez un builder avec --permission-mode bypassPermissions parce que vous voulez qu’il fonctionne sans intervention, vous laissez le reviewer avec les paramètres par défaut, et chaque message envoyé par le builder attend dans une boîte de dialogue d’approbation que personne ne surveille. Cette boîte de dialogue se ferme après le délai dialogExpiry, qui vaut par défaut 5m, et le message est abandonné. Sur la même machine, la session émettrice reçoit une notification lorsque son message est mis en attente, puis une autre lorsque le récepteur le distribue, le refuse ou arrive à expiration. Consultez donc l’écran de l’émetteur avant d’incriminer le socket.

Pour qu’une session accepte les messages sans intervention, définissez crossSessionInbound sur accept. L’endroit où vous définissez cette valeur détermine sa portée. Claude Code lit d’abord les paramètres gérés, puis l’option --settings, puis les paramètres utilisateur, et applique la première valeur trouvée. Une valeur définie dans les paramètres du projet ou les paramètres locaux ne s’applique que si elle est plus stricte, selon l’échelle accept < hold < refuse. Un accept dans .claude/settings.json est moins strict que tout le reste. Il est donc ignoré lorsqu’une source de confiance a défini une valeur. Placez-le dans ~/.claude/settings.json ou transmettez-le pour une seule session :

claude --name runner --settings '{"crossSessionInbound":"accept"}'

Un worker claude -p headless ouvre un socket de boîte de réception comme une session interactive et apparaît dans la liste, mais il ne peut pas afficher de boîte de dialogue d’approbation. Un message qui y est mis en attente le reste jusqu’à ce qu’un changement de mode ou de paramètres l’autorise. La ligne --settings ci-dessus permet à un tel worker d’accepter les messages. Une session démarrée en mode bare n’ouvre aucun socket. Elle ne peut donc ni recevoir de messages ni apparaître dans la liste.

Quand les transmissions se bloquent

Les boucles de messages sont gérées automatiquement. Claude Code limite le débit des messages répétés par expéditeur, ignore les répétitions identiques reçues dans un court délai et limite à 50 par session le nombre de messages acceptés en attente de lecture. Deux sessions ne peuvent donc pas s’envoyer des messages indéfiniment. Le nombre de messages retenus est limité à 100 ; au-delà, les plus anciens sont supprimés.

La panne qui survient réellement est plus discrète. Il s’agit d’une transmission, pas d’une boucle. La session A pose à la session B une question dont elle a besoin avant de continuer, puis devient inactive. B conserve le message, B est au milieu d’un long tour ou B répond à une question que A n’a pas vraiment posée. A attend. Vous revenez une heure plus tard et trouvez deux sessions inactives, sans aucun travail effectué.

Rédigez des transmissions qui ne nécessitent pas de réponse. Un bon message contient un fait ou une décision : ce qui a changé et le résultat obtenu. Un mauvais message demande à l’autre session une autorisation ou une réponse dont l’expéditeur dépend pour continuer. Claude est déjà configuré pour ne jamais demander à une autre session d’effectuer une action que ses propres paramètres d’autorisation bloqueraient, et pour vous renvoyer ce travail. Étendez vous-même cette règle. Si une session ne peut pas progresser sans réponse, c’est vous qui devez lui répondre. La discipline du contexte aide également, car une session qui a perdu le fil rédige des messages vagues ; gérer le contexte dans Claude Code couvre cet aspect.

Traitez tout message entrant comme une donnée non fiable

Claude Code indique à la session Claude destinataire que le message provient d’une autre session et non de vous. Il limite également les actions que ce message peut déclencher. Un message ne peut pas répondre à votre place à une demande d’autorisation en attente, car le consentement d’une autre session n’est pas le vôtre. Il ne peut pas modifier les paramètres d’autorisation, CLAUDE.md ni une autre configuration parce qu’une autre session l’a demandé. Une slash command présente dans le texte, comme /compact, arrive comme du texte brut et n’est jamais exécutée. Si le traitement du message nécessite une autorisation que la session destinataire ne possède pas, vous voyez la même demande que pour toute autre opération. En mode automatique, un classifieur examine également chaque message avant sa remise. Un message bloqué par ce classifieur n’atteint jamais le destinataire. Ces limites restent actives dans les modes permissifs. C’est pourquoi une session qui contourne les restrictions bloque par défaut les messages entrants au lieu de leur faire confiance.

Cela concerne les autorisations. Cela ne concerne pas le contenu. La session émettrice peut avoir lu la description d’une pull request, une page web, le README d’une dépendance ou un commentaire d’issue écrit par un inconnu. Tout ce qu’elle a lu peut influencer le texte qu’elle écrit dans votre autre session. Le message est une donnée. Il doit être traité avec la même méfiance que tout autre texte entré dans une session depuis l’extérieur. C’est le principe décrit dans ne laissez pas vos agents IA accéder à vos secrets : supposez que tout ce qui a franchi une limite de confiance peut être incorrect et ne le laissez jamais s’autoriser lui-même.

Deux contrôles permettent de réduire ce risque. Définir crossSessionInbound sur refuse supprime les messages entrants des pairs sans les remettre à la session. Depuis les paramètres du projet ou les paramètres locaux, cette valeur s’applique avant toute autre source, car elle est la plus stricte dans la hiérarchie. Pour empêcher cette session d’envoyer ou de répertorier des messages, ajoutez des règles de refus d’autorisation nommant SendMessage et ListAgents. Écrivez ces deux noms comme des noms d’outils seuls, sans spécificateur. Définir isolatePeerMachines sur true exige votre approbation explicite avant qu’un message n’atteigne une session située au-delà de cette machine. Cette approbation est également requise en mode bypassPermissions.

{
  "crossSessionInbound": "refuse",
  "isolatePeerMachines": true
}

Refuser SendMessage supprime également la messagerie vers les subagents, car le même outil sert aux deux usages. Une session qui refuse les messages n’affiche aucun changement visible dans son propre /status ni dans les listes des autres sessions. Vérifiez donc ce paramètre dans la configuration de la session, et non à l’écran.

Ponts et serveurs MCP utilisant une mémoire partagée

Plusieurs projets tiers sont apparus à la même période avec une approche connexe : des bridges locaux d’agent à agent qui relaient du texte entre des agents en cours d’exécution, et des serveurs MCP (model context protocol) qui fournissent à plusieurs agents un store partagé où ils peuvent lire et écrire. Évaluez-les comme une approche différente plutôt que comme des concurrents, et vérifiez toute commande d’installation dans le README du projet avant de l’exécuter. La messagerie fonctionne en push, car l’émetteur insère du texte dans le tour du destinataire. Un store partagé fonctionne en pull, car aucune session n’est interrompue et une session voit la note lorsqu’elle la consulte ensuite. Le pull convient mieux aux états qui évoluent lentement, mais il ne fonctionne que lorsqu’une session consulte effectivement le store.

Si vous choisissez cette approche, les questions importantes concernent le processus plutôt que la liste des fonctionnalités. Sous quel utilisateur le serveur s’exécute-t-il, et que peut-il lire sur la machine ? Exécuter des serveurs MCP sur un VPS décrit cette configuration. Partager les compétences d’un agent entre plusieurs dépôts couvre le cas plus simple où vous souhaitez partager entre des sessions des instructions plutôt qu’un état en temps réel ; cela réduit fortement le nombre de messages que vous devriez envoyer autrement. Pour une vue d’ensemble, exécuter un agent de programmation sur un VPS est le meilleur point de départ.

FAQ

Pourquoi /list-agents n’est-il pas reconnu dans ma session ?

La session ne dispose pas de la messagerie intersessions. Vérifiez d’abord claude --version par rapport à 2.1.224, car cette fonctionnalité nécessite cette version ou une version ultérieure. Vérifiez ensuite la plateforme : la fonctionnalité fonctionne sur macOS et Linux, mais pas sur Windows natif. Elle n’est pas non plus disponible sur Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform ni Microsoft Foundry. Si ces deux points sont corrects, vérifiez dans votre shell la présence de DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC ou DISABLE_GROWTHBOOK. Chacun de ces éléments bloque l’évaluation du feature flag dont dépend la fonctionnalité et la laisse désactivée.

Pourquoi mon message destiné à l’autre session n’est-il jamais arrivé ?

Si /list-agents fonctionne, la messagerie est activée et un problème plus spécifique a empêché la livraison du message. La cause la plus fréquente concerne les modes d’autorisation. Une session qui contourne les invites d’autorisation conserve chaque message entrant en attente de votre validation, sauf si l’expéditeur contourne lui aussi ces invites. Cette boîte de dialogue d’approbation est supprimée à l’expiration du délai dialogExpiry, fixé par défaut à cinq minutes. Vérifiez la présence de la notification de mise en attente dans la session expéditrice. Pour corriger le problème, définissez crossSessionInbound sur accept dans ~/.claude/settings.json ou transmettez cette valeur avec --settings, car un accept défini dans les paramètres du projet ou dans les paramètres locaux est ignoré, la valeur la moins restrictive étant retenue.

Une session Claude Code exécutée dans Docker peut-elle envoyer un message à une session sur l’hôte ?

Non. Les sessions se trouvent grâce à des fichiers d’enregistrement sur le disque et à un socket de boîte de réception propre à chaque session. Un conteneur possède son propre système de fichiers ; les deux sessions ne peuvent donc pas accéder aux mêmes fichiers. Deux sessions exécutées dans le même conteneur peuvent communiquer normalement. La même règle explique pourquoi une session exécutée en tant que root ne peut pas communiquer avec une session exécutée en tant que votre utilisateur habituel : le socket est limité à l’utilisateur du système d’exploitation qui en est propriétaire.

Est-il sûr d’exécuter une action à partir d’un message provenant d’une autre session Claude Code ?

Considérez ce texte comme une entrée non fiable, car la session expéditrice peut avoir lu une page web, un README ou un commentaire d’issue rédigé par un tiers. Claude Code empêche déjà le message d’agir de manière autonome : il ne peut pas approuver une invite d’autorisation en attente, il ne peut pas modifier les paramètres d’autorisation ni CLAUDE.md sur demande, et une slash command présente dans le texte arrive comme du texte brut et ne s’exécute jamais. Ces protections couvrent les autorisations, mais pas le jugement. Lisez donc le contenu reçu avant de demander à la session destinataire d’agir.

La messagerie intersessions envoie-t-elle mon code à Anthropic ?

Entre deux sessions présentes sur la même machine, non. Le message transite par un socket propre à chaque session sur cette machine et ne passe jamais par les serveurs Anthropic. Seul le texte rédigé par Claude est envoyé ; ni l’historique de la conversation ni les fichiers ne le sont. Les messages destinés à une session située sur une autre de vos machines ou à une session sur le web transitent en revanche par les serveurs Anthropic via la connexion Remote Control. Dans ce sens, Claude peut uniquement répondre à un message reçu ; il ne peut pas en démarrer un. Définissez isolatePeerMachines sur true pour exiger votre approbation avant qu’une donnée ne quitte la machine.