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’une session Claude écrit pour une autre. Il ne contient ni historique de conversation ni fichiers. Claude trouve l’autre session avec l’outil ListAgents et lui transmet le texte avec SendMessage. Vous n’appelez donc jamais ces deux outils manuellement. Vous indiquez ce que l’autre session doit savoir, puis Claude rédige lui-même le message.

Cette fonctionnalité s’appelle la communication 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. Windows ne dispose d’aucun support natif. Elle n’est pas disponible sur Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform ni Microsoft Foundry. Lorsqu’une session remplit ces conditions, 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 assez longtemps actives pour qu’il soit pertinent de leur envoyer des messages. Sur un ordinateur portable, vous refermez 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 façon dont elles communiquent cesse d’être théorique. Si ce n’est pas encore configuré, 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 que la fonctionnalité existe avant de vous appuyer dessus

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 du tout, cette session ne prend pas en charge la communication entre sessions 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 communication entre sessions 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 ont 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 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'

Désactivez toute variable qui affiche une valeur. Pour DISABLE_TELEMETRY et CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, toute valeur non vide active le comportement, y compris la chaîne 0. Ainsi, 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 s’y adresser

Claude adresse un message à une session par son nom. Définissez le 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éduit un à partir du nom du dossier du répertoire de travail, par exemple myapp-3f. Cela convient pour une seule session, mais devient confus avec quatre sessions. Deux sessions peuvent aussi finir par avoir 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 de Claude ajoute également un identifiant court à l’adresse lorsque des noms sont en conflit. Les nommer vous-même coûte moins cher que de lire les identifiants.

Une configuration tmux à deux sessions reproductible

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 git worktree distinct. Les deux sessions n’écrivent donc jamais dans le même fichier. git worktree add avec HEAD crée un checkout détaché. C’est ce qu’il faut pour 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. Cela modifie le system prompt de cette 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 celle à utiliser. Dans la fenêtre de développement, exécutez /list-agents. Vous devez 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 s’applique. Transmettez ensuite une consigne 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. 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 un tour est en cours, le message attend entre deux appels d’outils. Une commande en cours n’est donc jamais interrompue. Une fois que Claude l’a lu, le message est réduit à une ligne Message from que Ctrl+O développe. Les deux sessions fonctionnent mieux lorsque la session de développement conserve des modifications limitées. Un diff restreint produit un hand-off plus court et une revue que l’autre session peut terminer en un seul tour. C’est cette pratique que la compétence du développeur senior paresseux cherche à imposer.

Qui peut voir qui sur un même VPS

Les échanges locaux 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 lancée avec root et une session lancée avec 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 exécutée dans Docker et une session exécutée sur l’hôte ne peuvent pas communiquer, car elles ne lisent pas les mêmes fichiers d’enregistrement. Deux sessions exécutées dans le même conteneur peuvent échanger normalement. Si vous gardez les agents dans des conteneurs pour les isoler, comme dans l’exécution d’agents de programmation dans une VM temporaire, 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 choisi de ne pas le distribuer. Chaque message reçu aboutit à l’un de trois résultats : distribué, mis en attente (conservé sans être distribué jusqu’à votre approbation) ou refusé (supprimé sans être distribué).

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 catégorie, et toutes les autres sessions dans l’autre. auto, acceptEdits et dontAsk comptent comme des modes avec demande d’autorisation. Le mode Plan compte comme un contournement dans une session qui dispose des autorisations nécessaires. Si vous ne savez pas dans quelle catégorie se trouve une session, lisez d’abord ce que fait réellement chaque mode d’autorisation, car auto est désormais le mode de démarrage de la plupart des sessions et se trouve du côté des sessions avec demande d’autorisation. La règle est donc symétrique :

• Une session réceptrice qui demande des autorisations distribue chaque message. Elle n’en met un en attente que lorsque la session émettrice s’identifie comme contournant 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 également les demandes d’autorisation.

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 l’exécuter sans intervention, vous laissez le reviewer avec la configuration par défaut, et chaque message envoyé par le builder attend dans une boîte de dialogue d’approbation que personne ne consulte. Cette boîte de dialogue se ferme après le délai dialogExpiry, qui vaut par défaut 5m, et le message est supprimé. 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 le laisse expirer. Consultez donc l’écran de l’émetteur avant d’accuser 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’ordre accept < hold < refuse. Un accept dans .claude/settings.json est moins strict que toutes les autres valeurs, et est donc ignoré dès qu’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 lie 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 mis en attente y reste conservé jusqu’à ce qu’un changement de mode ou de paramètres permette sa réception. La ligne --settings ci-dessus permet à un tel worker d’accepter les messages. Une session démarrée en mode bare ne lie 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 pour vous. 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 ; au-delà, les plus anciens sont supprimés.

Le problème qui se produit 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 pour continuer, puis devient inactive. B conserve le message, traite une tâche longue ou répond à une question que A n’a pas réellement posée. A attend. Vous revenez une heure plus tard et trouvez deux sessions inactives, sans aucun travail effectué.

Rédigez des messages de relais qui n’exigent pas de réponse. Un bon message transmet un fait ou une décision : ce qui a changé et quel 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 doit déjà ne jamais demander à une autre session d’effectuer une action que ses propres paramètres d’autorisation empêcheraient. Il doit 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. La discipline du contexte aide également : une session qui a perdu le fil rédige des messages vagues. Gérer le contexte dans Claude Code traite 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 aussi les actions que ce message peut déclencher. Cette restriction est appliquée par le programme qui entoure le modèle, et non par la volonté du modèle d’obéir. C’est la différence pratique qu’apporte un agent harness. 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 le lui demande. Une slash command présente dans le texte, comme /compact, arrive sous forme de 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, et un message qu’il bloque n’atteint jamais le destinataire. Ces limites restent actives dans les modes permissifs. C’est pourquoi une session qui contourne les autorisations bloque par défaut les messages entrants au lieu de leur faire confiance.

Cela couvre les autorisations, mais 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 rédigé par un inconnu. Tout ce qu’elle a lu peut influencer le texte qu’elle écrit à votre autre session. Le message est une donnée. Il doit être considéré avec la même méfiance que tout autre texte entré dans une session depuis l’extérieur. C’est la discipline décrite dans la protection des secrets dans 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 permettent de réduire ce risque. Définir crossSessionInbound sur refuse supprime les messages entrants des pairs sans les remettre à leur destinataire. 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 de la hiérarchie. Pour empêcher cette session d’envoyer ou d’afficher des messages, ajoutez des règles de refus d’autorisation nommant SendMessage et ListAgents, tous deux écrits comme de simples noms d’outils, sans spécificateur. Définir isolatePeerMachines sur true exige votre approbation explicite avant qu’un message soit remis à 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 sous-agents, car le même outil sert aux deux fonctions. Une session qui refuse 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 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 par rapport à 2.1.224, car cette fonctionnalité nécessite cette version ou une version ultérieure. Vérifiez ensuite la plate-forme : elle 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, car 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 précis a empêché ce message d’arriver. Les modes d’autorisation sont la cause la plus fréquente. Une session qui contourne les demandes d’autorisation conserve chaque message entrant jusqu’à votre approbation, sauf si l’expéditeur contourne lui aussi ces demandes. La boîte de dialogue d’approbation est supprimée après le délai de dialogExpiry, fixé à cinq minutes par défaut. Vérifiez la présence de la notification indiquant que le message est en attente dans la session émettrice. 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é, puisque sa valeur est moins restrictive.

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

Non. Les sessions se découvrent 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 situé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 avec votre utilisateur normal : le socket est limité à l’utilisateur du système d’exploitation qui le possède.

Puis-je considérer comme fiable un message provenant d’une autre session Claude Code ?

Considérez ce texte comme une entrée non fiable, car la session émettrice 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 de manière autonome : 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 comme du texte brut et ne s’exécute jamais. Ces protections couvrent les autorisations, 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é, jamais l’historique de la conversation ni les fichiers. Les messages destinés à une session située sur une autre de vos machines, ou à une session sur le web, transitent 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 initier un. Définissez isolatePeerMachines sur true pour demander votre approbation avant qu’une information ne quitte la machine.