Claude Code : faire communiquer deux sessions

Ce que signifie la communication entre sessions Claude Code

Deux sessions Claude Code peuvent communiquer lorsqu’elles s’exécutent sur la même machine, avec le même utilisateur du système d’exploitation. Un message est un texte brut qu’un Claude rédige pour un 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 communication intersessions. En octobre 2026, elle nécessite Claude Code v2.1.224 ou une version ultérieure sur macOS et Linux, y compris Linux dans WSL 2, et v2.1.234 ou une version ultérieure sur Windows natif. La communication entre sessions sur la même machine fonctionne avec tous les fournisseurs, notamment Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform et Microsoft Foundry, pour lesquels elle nécessite la version v2.1.248 ou une version ultérieure. L’accès à vos sessions sur d’autres machines ou dans le cloud est plus limité : il passe par Remote Control, qui nécessite une connexion à claude.ai. Il ne fonctionne donc pas avec une clé API ni avec ces quatre fournisseurs. Lorsqu’une session respecte ces prérequis, la communication est déjà activée et aucune configuration n’est nécessaire. Le comportement décrit ci-dessous provient de la documentation Anthropic sur la communication intersessions.

C’est sur un VPS que cette fonctionnalité est utile, car les sessions y restent suffisamment longtemps 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 fonctionne encore jeudi et conserve toujours le contexte d’un dépôt. Dès que vous en avez deux, leur mode de communication devient concret. 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 utilisée dans 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 durée. Un message envoyé compte dans l’utilisation exactement comme un prompt que vous avez saisi. La coordination n’est pas gratuite. Un travail qui constitue réellement une seule 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 est rentable ont un point commun. Deux tâches s’exécutent en parallèle sans dépendre l’une de l’autre, et l’une d’elles découvre en cours de route une information dont l’autre a besoin.

• Une session détecte un breaking change pendant que l’autre s’appuie sur le code concerné. Claude résume la modification et la transmet, au lieu de vous obliger à la saisir de nouveau dans l’autre terminal.
• Deux sessions travaillent sur le même dépôt dans des git worktrees distincts, et l’une doit savoir ce qui a été intégré.
• Une migration longue ou une exécution de tests renvoie 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 renvoie ses conclusions.

Lorsque le travail est séquentiel ou lorsque les deux sessions doivent modifier les mêmes fichiers, utilisez une seule session. Si vous voulez un groupe coordonné que Claude crée et supervise dans le cadre d’une seule 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 messagerie entre sessions sert aux sessions indépendantes que vous démarrez et pilotez vous-même.

Vérifiez la présence de la fonctionnalité avant de vous y appuyer

Commencez par vérifier la version :

claude --version

Comparez le numéro à 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 dispose pas de la messagerie intersessions, et aucune valeur de crossSessionInbound ne l’activera. 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:.

Un piège concerne les utilisateurs de VPS qui exécutent d’anciennes versions. Avant la v2.1.248, la messagerie entre sessions sur une même machine dépendait de la récupération des feature flags. Plusieurs variables de confidentialité désactivent cette récupération, ce qui laissait la fonctionnalité désactivée par défaut. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC et DISABLE_GROWTHBOOK ont toutes cet effet. Les utilisateurs renforcent un serveur neuf en ajoutant ces variables dans ~/.bashrc, puis se demandent pourquoi /list-agents n’existe pas. À partir de la v2.1.248, la messagerie entre sessions sur une même machine fonctionne même lorsque la récupération est désactivée. La mise à jour est donc la solution la plus simple. Ces variables restent importantes pour les sessions situées au-delà de cette machine : lorsque la récupération est désactivée, Claude ne peut les joindre que si Remote Control est disponible, et CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC ainsi que DISABLE_GROWTHBOOK rendent Remote Control indisponible. Ces mêmes valeurs peuvent provenir de la map env dans un fichier de configuration ou des paramètres gérés. Vérifiez donc d’abord l’environnement du shell.

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

Avec une ancienne version, 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. DISABLE_TELEMETRY=0 n’a donc pas l’effet apparent. 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 le nom au démarrage de la session :

claude --name builder-api

Vous pouvez également le définir avec /rename dans une session en cours d’exécution. Si vous ne définissez aucun nom, Claude Code en déduit un à partir du nom 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 aussi recevoir le même nom. Sauf si la session est connectée à Remote Control, la sortie de /list-agents affiche le répertoire de travail de chaque session locale. Vous pouvez ainsi distinguer les sessions portant le même nom. La liste de Claude ajoute également un identifiant court à l’adresse lorsque des noms sont en conflit. Les nommer vous-même évite de devoir lire ces identifiants. Un nom que vous avez choisi rend aussi la saisie prédictive @ utile : depuis la version v2.1.232, saisissez @builder dans une invite, puis sélectionnez la session. Claude saura exactement quelle session vous désignez.

Une configuration 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 séparé. Les deux sessions n’écrivent donc jamais dans le même fichier. git worktree add avec HEAD crée un checkout détaché, ce qui convient à une session qui lit le dépôt sans y faire de commit. Comme les deux sessions ont des rôles différents, il est utile de donner à la session de revue son propre style de sortie. Celui-ci modifie le system prompt de la session et s’applique donc à chaque tour, au lieu de disparaître comme une instruction saisie une seule fois.

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 affiche la liste des fenêtres par nom. Vous pouvez ainsi choisir la bonne fenêtre. Dans la fenêtre de développement, exécutez /list-agents. Vous devriez voir reviewer-api avec le 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 se présente. Transmettez ensuite la demande 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 sous la forme d’un aperçu d’une ligne en grisé. Il contient le nom de l’expéditeur et la première ligne du texte, par exemple › Message from @builder-api: …. Si la session est inactive, Claude y démarre immédiatement un nouveau tour. Si un tour est en cours, le message attend le prochain intervalle entre deux appels d’outil. Une commande en cours n’est donc jamais interrompue. Ctrl+O ouvre le transcript viewer avec le texte complet. Claude lit l’intégralité du message, que vous développiez ou non l’aperçu. Les deux sessions fonctionnent mieux lorsque la session de développement limite la taille de ses modifications. Un diff réduit produit un hand-off plus court et permet à l’autre session de terminer la revue en un seul tour. C’est précisément l’habitude que la compétence du développeur senior paresseux cherche à imposer.

Qui peut voir qui sur un même VPS

Les communications entre sessions sur la même machine ne passent jamais par les serveurs Anthropic. Chaque session associe sa propre socket de réception, une socket de domaine Unix dont le chemin se trouve dans le système de fichiers de cette machine. Une session n’apparaît dans les listes de vos autres sessions que lorsqu’elle en associe une. Deux conséquences en découlent, et toutes deux posent problème sur un serveur.

La socket est limitée à 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 à la 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. Deux sessions dans le même conteneur peuvent normalement échanger des messages. Si vous utilisez des conteneurs pour isoler vos agents, comme dans exécuter des agents de programmation 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 vos sessions cloud apparaissent dans la liste uniquement lorsque cette session est connectée à Remote Control. Les sessions sur d’autres machines portent le libellé Remote Control. Depuis la version 2.1.225, Claude peut démarrer une conversation avec l’une d’elles, et pas seulement lui répondre. Ces messages passent par les serveurs Anthropic. Si cette session n’est pas connectée à Remote Control lorsque Claude envoie un message vers une autre machine, le message est tout de même transmis, mais sans adresse de réponse. L’autre côté ne peut donc pas y répondre.

Pourquoi votre message n’est jamais arrivé

La raison habituelle n’a rien à voir avec le réseau. La session destinataire a décidé quoi faire du message, et a choisi de ne pas le remettre. Chaque message reçu aboutit à l’un de trois résultats : remis, conservé (mis de côté sans être remis jusqu’à votre approbation) ou refusé (supprimé sans remise).

Lorsqu’aucune valeur crossSessionInbound ne s’applique, Claude Code décide pour 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 dans l’autre. auto, acceptEdits et dontAsk sont considérés comme des modes qui demandent une autorisation. Le mode Plan est considéré comme un contournement dans une session de terminal interactive qui dispose des autorisations de contournement. Si vous ne savez pas dans quelle classe se trouve une session, lisez d’abord ce que fait réellement chaque mode d’autorisation, car auto est le mode de départ de la plupart des sessions et se trouve du côté des demandes d’autorisation dans cette séparation. La règle est donc symétrique :

• Une session destinataire qui demande des autorisations remet chaque message. Elle n’en conserve un que lorsque la session émettrice s’identifie comme contournant les demandes d’autorisation.
• Une session destinataire qui contourne les demandes d’autorisation conserve chaque message en attente de votre approbation. Elle n’en remet un que lorsque l’émetteur contourne lui aussi ces 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 valeurs 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 supprimé. Vérifiez l’écran de la session destinataire pour voir si une boîte de dialogue d’approbation est en attente avant d’incriminer le socket.

Pour qu’une session accepte des 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 restrictif que toutes les autres valeurs ; il est donc ignoré lorsqu’une source approuvée a défini une valeur. Placez-le dans ~/.claude/settings.json ou transmettez-le pour une seule session. Depuis la v2.1.232, la ligne /config Messages provenant de vos autres sessions écrit le même paramètre utilisateur à votre place.

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

Un worker claude -p headless ouvre un socket d’inbox comme une session interactive et apparaît dans la liste, mais il ne peut pas afficher de boîte de dialogue d’approbation. Claude Code conserve le message pendant le même délai dialogExpiry, soit cinq minutes par défaut, le remet si une modification du mode ou des paramètres l’autorise pendant ce délai, puis le supprime et le signale comme expiré à un émetteur qu’il peut joindre. 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 relais 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 intervalle 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 en attente est limité à 100 ; les plus anciens sont supprimés au-delà de cette limite. Depuis la v2.1.238, la session émettrice est informée lorsqu’un message est supprimé de la boîte de réception du destinataire, avec la raison. Une chaîne de relais qui repasse continuellement par les mêmes sessions est également interrompue.

Le problème qui survient réellement est plus discret. Il s’agit d’un relais, 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 exécute une longue tâche, ou B répond à une question que A n’a pas réellement posée. A attend. Une heure plus tard, vous retrouvez deux sessions inactives et aucun travail effectué.

Rédigez des relais qui ne nécessitent pas de réponse. Un bon message contient un fait ou une décision : ce qui a changé et quel en a été le résultat. Un mauvais message demande à l’autre session une autorisation ou une réponse dont l’expéditeur dépend pour continuer. Claude reçoit déjà l’instruction de ne jamais demander à une autre session d’effectuer une action que ses propres paramètres d’autorisation bloqueraient, et de vous renvoyer cette tâche. É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. Une bonne gestion du contexte aide également, car une session qui a perdu le fil rédige des messages vagues ; la gestion du contexte dans Claude Code couvre cet aspect.

Traiter un message entrant comme une entrée non fiable

Claude Code indique au Claude récepteur que le message provient d'une autre session et non de vous, et il limite les actions possibles pour ce message. Cette application des règles réside dans le programme qui enveloppe le modèle plutôt que dans la volonté du modèle de s'y conformer, ce qui constitue la différence pratique apportée par un agent harness. Un message ne peut pas répondre à une demande d'autorisation en attente à votre place, car le consentement provenant d'une autre session n'est pas le vôtre. Il ne peut pas modifier les paramètres d'autorisation, CLAUDE.md, ou toute autre configuration sur demande d'une autre session. Une commande slash contenue dans le texte, telle que /compact, arrive sous forme de texte brut et n'est jamais exécutée. Si l'action liée au message nécessite une autorisation dont la session réceptrice ne dispose pas, vous verrez la même invite que pour n'importe quelle autre tâche. Lorsque la session émettrice fonctionne en mode auto, son classificateur examine également chaque message avant que Claude Code ne le transmette, et tout message bloqué n'atteint jamais le destinataire. Ces limites subsistent même dans les modes permissifs, c'est pourquoi une session qui contourne ces règles retient les messages entrants par défaut au lieu de leur faire confiance.

Cela couvre les autorisations. Cela ne couvre 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, et tout ce qu'elle a lu peut influencer le texte qu'elle écrit vers votre autre session. Le message est une donnée. Il mérite la même méfiance que tout autre texte ayant pénétré une session depuis l'extérieur. C'est la discipline décrite dans garder les secrets hors de vos agents IA : supposez que tout ce qui a franchi une limite de confiance peut être erroné, et ne le laissez jamais s'autoriser lui-même.

Deux contrôles existent si vous souhaitez limiter cela. Définir crossSessionInbound sur refuse rejette les messages pairs entrants sans les transmettre ; depuis les paramètres du projet ou les paramètres locaux, cette valeur prévaut sur toutes les autres sources, car il s'agit de la valeur la plus stricte de la hiérarchie. Pour empêcher cette session d'envoyer ou de lister des éléments, ajoutez des règles de refus d'autorisation nommant SendMessage et ListAgents, toutes deux écrites sous forme de noms d'outils nus sans spécificateur. Définir isolatePeerMachines sur true requiert votre approbation explicite avant qu'un message n'atteigne une session située au-delà de cette machine, et cette approbation est requise même en mode bypassPermissions.

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

Refuser SendMessage supprime également la messagerie vers les sous-agents, car le même outil sert aux deux. Une session qui refuse les messages ne montre aucun changement visible dans son propre /status ou dans les listes des autres sessions ; vérifiez donc le paramètre depuis la configuration de la session plutôt qu'à l'écran.

Bridges et serveurs MCP à mémoire partagée

Plusieurs projets tiers sont apparus à la même période avec une fonction connexe : des bridges locaux entre agents qui relaient du texte entre des agents en cours d’exécution, et des serveurs MCP (model context protocol) qui fournissent à plusieurs agents un même espace de stockage pour lire et écrire. Considérez-les comme une architecture 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 espace de stockage 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 si une session consulte effectivement l’espace de stockage.

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 à quelles données peut-il accéder sur la machine ? Exécuter des serveurs MCP sur un VPS décrit cette configuration. Partager les skills des agents entre des dépôts couvre le cas plus simple où vous souhaitez partager entre les sessions des instructions plutôt qu’un état dynamique, ce qui réduit le nombre de messages que vous auriez autrement besoin d’envoyer. Pour une vue d’ensemble, exécuter un agent de codage sur un VPS est le bon 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 : cette fonctionnalité nécessite la version 2.1.224 ou ultérieure sur macOS et Linux, la version 2.1.234 ou ultérieure sur Windows natif, et la version 2.1.248 ou ultérieure sur Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform et Microsoft Foundry. Avec un build antérieur à 2.1.248, vérifiez également si votre shell contient DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC ou DISABLE_GROWTHBOOK, car chacun de ces paramètres désactive la récupération des feature flags dont les anciens builds avaient besoin pour la messagerie. La mise à jour vers la version 2.1.248 ou ultérieure supprime cette dépendance pour les sessions sur la même machine.

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 ciblé a empêché la transmission de ce message. La cause la plus fréquente concerne les modes d’autorisation. Une session qui contourne les demandes d’autorisation conserve chaque message entrant en attente de votre validation, sauf si l’expéditeur les contourne également. Cette boîte de dialogue d’autorisation est supprimée après le délai dialogExpiry, fixé par défaut à cinq minutes. Vérifiez si une boîte de dialogue d’autorisation est en attente dans la session destinataire. 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 les paramètres locaux est ignoré lorsqu’il est moins restrictif.

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

Non. La boîte de réception de chaque session est un socket situé dans le système de fichiers de la machine concernée. Un conteneur possède son propre système de fichiers. Une session exécutée dans le conteneur ne peut donc pas atteindre une session exécutée sur l’hôte, et inversement. 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 par votre utilisateur normal : le socket est accessible uniquement par l’utilisateur du système d’exploitation qui en est propriétaire.

Est-il prudent d’exécuter une instruction reçue d’une autre session Claude Code ?

Considérez le 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 quelqu’un d’autre. Claude Code empêche déjà le message d’agir seul : il ne peut pas approuver une demande d’autorisation en attente, il ne peut pas modifier les paramètres d’autorisation ni CLAUDE.md à la demande, et une slash command présente dans le texte arrive sous forme de 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 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é, jamais l’historique de la conversation ni les fichiers. Les messages destinés à une session sur une autre de vos machines, ou à une session cloud, transitent par les serveurs Anthropic. Depuis la version v2.1.225, Claude peut également démarrer cet échange, et pas seulement y répondre. Définissez isolatePeerMachines sur true pour exiger votre approbation avant que quoi que ce soit ne quitte la machine.