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, et n’importe quelle autre session que vous exécutez peut y déposer un message texte ; le mien se trouve à /tmp/cc-socks/38590.sock, avec des permissions réservées au propriétaire.¹ Windows en natif reçoit un tube nommé à la place, depuis la v2.1.239 d’après les notes de version, et une exception de liaison tardive figure dans la section Les pièges. 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 (v2.1.239 sous Windows) sur la même machine, elles peuvent déjà se parler.

Les sessions Claude Code s’écrivent entre elles via un socket Unix local (un tube nommé sous Windows depuis la v2.1.239) : ListAgents trouve une session joignable, SendMessage lui livre du texte brut en la désignant par son nom. Un message est une entrée, jamais une autorité. Il ne peut ni approuver une demande d’autorisation, ni modifier la configuration, ni exécuter de commandes, et il ne transporte ni historique de conversation ni fichiers.

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 a ajouté 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 davantage à 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 entre elles peuvent chacune désactiver la fonctionnalité sans un mot, selon leur valeur.³ Depuis le lancement, Windows a rejoint le dispositif en natif avec la v2.1.239, et la v2.1.236 a ajouté notify_when_idle, qui permet à une session de demander à une session pair de la même machine un avis unique la prochaine fois qu’elle passe à l’état inactif ou se termine.⁹¹⁰

Ce qui a été livré

La version 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) affiche sur sa première ligne le nom propre de la session (celui que vos autres sessions utilisent pour la joindre, affiché depuis la v2.1.239), puis toutes les sessions que Claude peut atteindre : les sous-agents de la session courante, les coéquipiers actifs de son équipe d’agents (listés depuis la v2.1.239 ; auparavant, un coéquipier joignable semblait absent), 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, que Claude Code exporte vers les hooks et les commandes Bash une fois la boîte de réception liée (voir la note sur la liaison tardive dans Les pièges), contient le chemin du socket de la session elle-même.¹⁶ Nous verrons plus bas pourquoi cela compte.

Vérification sur ma propre machine le 25 août 2026, avec Claude Code 2.1.246 : la liste des agents s’ouvrait sur la ligne « This session is blakecrosley-com-76 [04e18a] — the name other sessions use to message it (it is not listed below; a message to it would be a message to yourself). » (soit : cette session est blakecrosley-com-76, le nom que les autres sessions utilisent pour lui écrire ; elle n’est pas listée ci-dessous, et un message à son adresse serait un message à vous-même), puis 11 sessions pairs sous forme de lignes du type « resumegeni-25 [10d770] · interactive · idle · started 21h ago », des noms au format répertoire-plus-suffixe-de-deux-caractères avec un identifiant court entre crochets, des états idle, busy et shell, une ancienneté de démarrage par ligne, et un bloc Subagents distinct pour les propres enfants de la session. Les fichiers socket sous /tmp/cc-socks/ portent les permissions srw------- et le répertoire lui-même est en drwx------ : lisibles et modifiables par mon seul compte utilisateur, ce qui constitue la frontière sur les machines partagées.¹

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 my-app-3f.¹¹¹ Depuis la v2.1.232, quand vous démarrez, reprenez ou renommez une session interactive avec un nom qu’une autre session active de la machine utilise déjà, Claude Code laisse le nom à la session qui le détient, renomme la vôtre en une variante name-word-word (quelque chose comme auth-refactor-graceful-unicorn) et vous en informe.¹¹⁰ Les collisions subsistent quand une session tourne sur une version plus ancienne, quand le nom partagé a été généré par Claude Code, ou quand vous démarrez une session en arrière-plan ou -p avec un --name que Claude Code ne vérifie pas au démarrage.¹¹ La liste affiche toujours le répertoire de travail de chaque session locale, ce qui distingue les sessions homonymes quand elles tournent dans des répertoires différents ; pour un nom partagé, Claude ajoute aussi un identifiant court à chaque ligne et l’utilise dans l’adresse. Claude retombe sur ce même adressage par identifiant court lorsque Claude Code n’a pas pu vérifier tous les endroits où tournent vos sessions, par exemple un compte dont la liste de sessions cloud ou Remote Control dépasse le nombre de pages borné qu’il lit.¹

Ce qui a changé depuis le lancement (août 2026)

Cinq versions publiées dans les deux semaines suivant le lancement ont comblé la lacune Windows que ce billet signalait, resserré le nommage et l’adressage, et fermé quatre modes de défaillance silencieuse que le billet ne signalait pas :⁹¹⁰

Effet pratique : l’usage « la tâche longue qui rend des comptes », plus bas, n’a plus besoin d’une invite de relance. La session qui observe demande à la tâche longue un avis d’inactivité unique avec notify_when_idle et en est informée quand cette tâche passe à l’état inactif ou se termine. Deux des quatre modes de défaillance (un message trop volumineux, ou une rafale trop rapide pour la boîte de réception) échouent désormais d’emblée côté expéditeur ; les deux autres (un message refusé ou abandonné) reviennent à un expéditeur interactif de la même machine sous forme de signalements explicites.

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 précise : 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 Code donne pour consigne au Claude récepteur de ne jamais toucher aux paramètres de permission, à CLAUDE.md ni à 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 que huit caractères de prose, 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 (le mode plan compte comme un contournement quand la session dispose du contournement ; auto, acceptEdits et dontAsk comptent comme des modes avec demande). 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 abandonné.¹ Une session en arrière-plan sans terminal attaché garde la boîte ouverte au-delà de cette échéance ; une fois que vous vous y attachez, le message n’est abandonné que si la boîte reste sans réponse pendant une période d’échéance complète.¹ 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, si bien qu’un fichier de projet versionné peut durcir la règle mais 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 :¹

À la première parution de ce billet, la page de documentation d’Anthropic décrivait encore toute messagerie entre machines comme limitée aux réponses, tandis que les notes de version de la v2.1.225 indiquaient que SendMessage « can now start a conversation with your Remote Control sessions on other machines by name » (peut désormais engager une conversation avec vos sessions Remote Control sur d’autres machines en les désignant par leur nom). La documentation a depuis rattrapé son retard : la page précise maintenant qu’engager une conversation avec une session sur une autre de vos machines exige la v2.1.225 ou ultérieure et une cible qui apparaît dans la liste.¹⁵

La règle de la même machine tient à 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 : le Claude récepteur lit un message entre deux appels d’outil pendant un tour actif, sans jamais interrompre un outil en cours d’exécution, et Claude Code démarre un nouveau tour avec le message 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 la peine d’être construits

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. » est le type de nouvelle qui, sans cela, suppose que vous la remarquiez, changiez de terminal et la 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 la session de surveillance aux sessions en arrière-plan et aux hooks 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.¹ Depuis la v2.1.236, épargnez-vous la question : faites poser notify_when_idle sur la tâche longue par votre session d’observation, et celle-là rend compte une seule fois, la prochaine fois qu’elle passe à l’état inactif ou se termine, sans polling d’aucun côté.¹¹⁰ Les deux sessions doivent être en v2.1.236 ou ultérieure, et les limites suivent les contrôles d’entrée. Chaque abonnement est plafonné à 12 heures : si aucun avis n’est arrivé d’ici là, Claude Code abandonne l’abonnement et dit à Claude de cesser d’attendre. Avec refuse côté session observée, cette session écarte la demande sans l’enregistrer ni y répondre, si bien que l’abonnement expire sans réponse au plafond ; avec refuse côté demandeur, Claude Code ne s’abonne jamais. Avec hold d’un côté ou de l’autre, l’avis arrive dégradé : la session observée omet sa ligne de statut, et la session demandeuse affiche l’avis dans votre transcription sans le livrer à Claude.¹

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 par défaut patiente jusqu’à l’échéance dialogExpiry (cinq minutes par défaut ; dialogExpiry accepte 60s, 5m, 10m ou never), puis est abandonné et se déclare expiré auprès d’un expéditeur joignable ; seul un changement de mode ou de paramètres dans cet intervalle permet sa livraison.¹ Quand la session se termine avec des messages encore en attente, Claude Code les signale comme expirés à chaque expéditeur qu’elle peut joindre.¹ Avant la v2.1.225, aucune échéance ne s’appliquait : un message mis en attente stationnait sans notification ni expiration, et un travailleur qui se terminait avec des messages en attente ne disait rien à leurs expéditeurs.¹ 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 exporte CLAUDE_CODE_MESSAGING_SOCKET vers les hooks et les commandes Bash, un script peut déposer un message dans la boîte de réception de sa propre session.⁶ Claude Code vérifie les messages émis par ses propres processus enfants : un hook ou une commande qui écrit à sa session d’origine est livré sans formalité lorsqu’aucun crossSessionInbound explicite ne s’applique.¹ Un hook Git déclenché par le propre commit de la session, un wrapper de tests qu’elle a lancé, un script de déploiement qu’elle a exécuté : tout hook ou commande Bash que la session a elle-même démarré peut renvoyer une ligne de contexte dans cette session. Claude Code doit vérifier que l’émetteur est bien son propre enfant ; quand il ne peut le vérifier ni par les indices du processus ni par jeton, il traite le message comme un message qui ne revendique aucune classe de permission, si bien qu’une session en contournement le met en attente de votre approbation au lieu de le livrer.¹ Sous Windows en natif, la première ligne de la connexion doit être une ligne d’authentification portant CLAUDE_CODE_MESSAGING_TOKEN, sans quoi Claude Code ferme la connexion sans la lire ; ce jeton est aussi le seul moyen pour Windows de vérifier un message d’un processus enfant.¹ Sous Linux, la vérification par les indices du processus fonctionne même après la fin du processus émetteur ; sous macOS, uniquement tant qu’il tourne encore. Après sa fin sous macOS, et dans un conteneur où Claude Code est le PID 1, Claude Code vérifie à la place un enfant qui a envoyé dans sa ligne d’authentification le CLAUDE_CODE_MESSAGING_TOKEN exporté par la session.¹ Les commandes exécutées en bac à sable ont besoin que le socket soit autorisé : sandbox.network.allowUnixSockets liste les chemins de sockets sous macOS, et sous Linux et WSL 2, où le filtre seccomp ne peut pas inspecter les chemins, seul sandbox.network.allowAllUnixSockets: true l’ouvre ; sans ce filtre optionnel installé, le bac à sable ne bloque de toute façon jamais le socket.¹¹²

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. La conception exclut explicitement tout flux de travail de la forme « la session A approuve, la session B exécute ». 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.¹ La v2.1.236 refuse aussi d’emblée les messages suivants dès qu’une rafale rapide dépasserait ce que la boîte de réception du destinataire accepte, au lieu de les déclarer envoyés alors que le destinataire les abandonnait.¹⁰ 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 session ne reconnaît pas la commande, elle ne dispose pas du tout de la fonctionnalité ; si la commande 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, une cible absente de la liste (Remote Control non connecté, ou session tombée au-delà du nombre de pages borné que Claude Code lit), ou un expéditeur antérieur à la v2.1.225 qui tente d’engager une conversation entre machines.¹ Une cible qui n’a jamais lié de boîte de réception n’est pas le cas silencieux. Une session derrière une variable de confidentialité, en mode bare ou de l’autre côté d’une frontière de conteneur n’apparaît jamais dans /list-agents, si bien qu’un envoi vers elle échoue bruyamment, comme un nom que Claude Code ne trouve pas, et depuis la v2.1.234 SendMessage dit aussi quand il n’a pas pu vérifier complètement votre liste de sessions au lieu de traiter les sessions non vues comme absentes.¹³¹⁰ La première session après une mise à niveau relève de la liaison tardive, pas de l’absence : Claude Code lie la boîte de réception et exporte la variable du socket dès que la récupération des indicateurs de fonctionnalité aboutit, et la v2.1.228 a corrigé le cas où cette première session démarrait parfois sans boîte de réception du tout.¹¹⁰ Les cas véritablement silencieux se situent côté expéditeur. La documentation ne promet l’avis de mise en attente et sa suite, l’avis de refus à l’arrivée et l’avis d’abandon qu’à un expéditeur interactif de la même machine ; un expéditeur sur une autre machine ou un travailleur -p n’a donc aucun avis promis pour ces cas. Deux signalements vont bien à « chaque expéditeur joignable » : l’expiration d’un message mis en attente par défaut, et le refus quand un changement de paramètres abandonne les messages en attente. Un message stationné par un réglage hold explicite n’expire jamais, donc aucun signalement d’expiration ne revient à son sujet.¹

Lacunes de plateformes et de fournisseurs. Windows en natif est arrivé avec la v2.1.239 ; avant cela, seul Linux sous WSL 2 fonctionnait.¹⁹ La page de documentation d’Anthropic place le plancher Windows à la v2.1.234 ; les notes de version l’annoncent pour la première fois en v2.1.239. Considérez la v2.1.239 comme le plancher sûr.¹⁹ Une session sous WSL 2 et une session Windows native sur le même ordinateur ne peuvent pas non plus se joindre : elles s’enregistrent sous des répertoires personnels différents et écoutent sur des types de sockets différents.¹ 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 qui répond n’est pas connectée à Remote Control, arrive bien, mais sans adresse de retour : le destinataire ne peut donc pas répondre. Claude Code en informe Claude au moment de l’envoi, et la v2.1.225 a resserré l’adressage : quand Claude Code n’a pas pu vérifier sa propre liste de sessions, il ne remplace jamais un destinataire confirmé sur une autre machine par une session locale de 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. Le guide Claude Code couvre les commandes de session et les paramètres sur lesquels la fonctionnalité s’appuie. - 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 hooks 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 réglages par défaut mettent en quarantaine les sessions en contournement, 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. Une session qui refuse les messages a la même apparence dans les listes et dans son propre /status ; vérifiez donc les fichiers de paramètres qui s’appliquent à cette session plutôt que son statut. Depuis la v2.1.238, un envoi depuis une session de la même machine signale aussi le refus en retour.¹¹⁰

FAQ

La messagerie inter-sessions de Claude Code fonctionne-t-elle sous Windows ?

Oui, en natif depuis la v2.1.239 d’après les notes de version, avec les mêmes outils SendMessage et ListAgents et un tube nommé à la place du socket Unix. Avant cela, seul Linux sous WSL 2 fonctionnait. La page de documentation d’Anthropic place le plancher Windows à la v2.1.234 ; considérez la v2.1.239 comme le plancher sûr. Une session sous WSL 2 et une session Windows native sur le même ordinateur ne peuvent toujours pas se joindre.¹⁹

Une session Claude Code peut-elle approuver les demandes d’autorisation d’une autre session ?

Non. Un message est une information, jamais une autorité. Une demande d’autorisation en attente ignore tout ce que dit la session émettrice, parce que vous seul répondez aux demandes. Claude Code enjoint au Claude destinataire de ne jamais modifier les paramètres d’autorisation, CLAUDE.md ni la moindre configuration parce qu’une autre session l’a demandé, et un /compact dans le corps d’un message n’est que huit caractères de prose, jamais une commande exécutée.¹

Pourquoi mes autres sessions n’apparaissent-elles pas dans /list-agents ?

Auditez d’abord les variables d’environnement de confidentialité. La messagerie repose sur l’évaluation des indicateurs de fonctionnalité, et CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK ou DISABLE_GROWTHBOOK peuvent chacune couper cette évaluation, emportant la messagerie avec elle, en silence. Une session en mode bare ou de l’autre côté d’une frontière de conteneur n’apparaît jamais non plus, car deux sessions ne se joignent que lorsqu’elles voient les mêmes fichiers sur le disque.¹³

Comment permettre à un travailleur claude -p autonome de recevoir des messages ?

Lancez-le avec crossSessionInbound: "accept" dans la valeur de son --settings, une autorisation par travailleur plutôt qu’un accept dans les paramètres utilisateur qui s’appliquerait à chaque session que vous lancez. Une session -p lie une socket de boîte de réception et apparaît dans les listes, mais elle ne peut pas afficher la boîte de dialogue d’approbation ; un message mis en attente par défaut attend donc l’échéance dialogExpiry avant d’être abandonné.⁸

Puis-je envoyer un historique de conversation ou des fichiers à une autre session ?

Non. Un message est du texte brut qu’un Claude écrit à un autre, jamais un historique de conversation, des fichiers ou des autorisations. 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. Et si vous vous surprenez à concevoir un protocole de messages par-dessus le texte inter-sessions, c’est en réalité d’équipes d’agents que vous avez besoin.¹

Références