As sessões do Claude Code conseguem mandar mensagem umas para as outras?

Resposta curta: sim. Desde o Claude Code v2.1.224, em macOS e Linux, uma das suas sessões do Claude Code consegue mandar uma mensagem para outra, usando duas ferramentas chamadas ListAgents, para achar a outra sessão, e SendMessage, para entregar o texto a ela. Uma mensagem é texto puro que um Claude escreve para outro, nunca o histórico da conversa e nunca arquivos. Nesta máquina, em 14 de agosto de 2026, rodando o Claude Code 2.1.232, a listagem devolveu oito sessões alcançáveis.

O que é a mensageria entre sessões do Claude Code?

A mensageria entre sessões é o Claude Code entregando um pedaço de texto, escrito pelo Claude de uma das suas sessões, ao Claude de outra sessão sua. A Anthropic documenta o recurso como exigindo Claude Code v2.1.224 ou posterior, rodando em macOS e Linux, inclusive Linux dentro do WSL 2, e não oferecido no Windows nativo. Ele também não existe no Amazon Bedrock, no Claude Platform on AWS, no Google Cloud's Agent Platform nem no Microsoft Foundry. Onde os requisitos são atendidos, a documentação diz que a mensageria está ligada sem nada para ativar, o que vale saber porque significa que isso chegou à sua instalação sem você ligar.

O propósito declarado é o momento em que uma sessão descobre algo de que outra precisa enquanto as duas ainda trabalham: uma mudança que quebrou coisa, uma decisão que foi resolvida, uma migração que terminou. A Anthropic separa o recurso de quatro vizinhos na mesma página, e a separação é útil porque eles se confundem com facilidade. Retomar uma sessão move a conversa inteira. Times de agentes são um grupo coordenado que o Claude cria e supervisiona. A visão de agentes acompanha muitas sessões de um lugar só. O Remote Control conduz uma sessão pelo seu celular. A mensageria entre sessões não é nenhum desses: é texto passando entre sessões independentes que você mesmo abriu e conduz. Tudo isso foi lido na página oficial de mensageria entre sessões em 14 de agosto de 2026.

Como ver quais sessões do Claude Code dá para alcançar?

Rode /list-agents dentro de uma sessão do Claude Code, comando que também existe como /peers. Ele imprime toda sessão que esta consegue endereçar, e o nome em cada linha é o endereço que o Claude usa ao mandar. Você não precisa rodá-lo antes de pedir uma mensagem, porque o Claude acha o destino sozinho com o ListAgents; o comando existe para você ver a mesma lista.

O que vem agora é medição nossa, não exemplo. Em uma máquina de desenvolvimento, em 14 de agosto de 2026, rodando Claude Code 2.1.232, a listagem devolveu oito sessões vizinhas, todas interativas, sete delas ociosas, a mais velha aberta dois dias antes. Os nomes delas eram derivados do nome da pasta de trabalho com um sufixo curto acrescentado, o que bate com o comportamento documentado para sessão que você não nomeou. Dois projetos tinham duas sessões cada, distinguidas só por esse sufixo, e os outros quatro nomes eram únicos. O mecanismo é o que vale levar: quando duas sessões moram na mesma pasta, é o sufixo que as mantém endereçáveis em separado, e quando várias sessões ainda respondem por um nome, o Claude Code acrescenta um identificador curto a cada linha e endereça a mensagem com ele. Você pode nomear uma sessão você mesmo com o comando /rename ou com a flag --name, que é o jeito confiável de ter um endereço previsível.

Se o /list-agents não for reconhecido, aquela sessão não tem o recurso, e a documentação manda começar conferindo o claude --version contra a exigência da v2.1.224.

O que uma sessão do Claude Code manda de fato para outra?

Texto puro, e nada além disso. A documentação é explícita ao dizer que uma mensagem é um pedaço de texto que um Claude escreve para outro e nunca histórico de conversa ou arquivos, e que a sessão que recebe fica só com esse texto, mais o nome de quem mandou e um endereço de resposta. Mensagens estruturadas do protocolo de times de agentes ficam dentro do time e não cruzam entre sessões independentes.

O Claude escreve a mensagem sozinho, o que muda o jeito de pedir uma. Você diz o que a outra sessão precisa saber, não as palavras a mandar. Desde o Claude Code v2.1.232 você também pode nomear o destino com uma menção de @ escolhida numa lista das suas sessões locais vivas, do mesmo jeito que se menciona um subagente. Para onde a mensagem viaja depende de onde a outra sessão roda, e esta é a parte que vale ler antes de usar o recurso em algo sensível: uma mensagem para sessão na mesma máquina vai por um socket próprio da sessão e nunca passa por servidor da Anthropic, enquanto uma mensagem para outra máquina sua ou para uma sessão do Claude Code na web viaja através de servidores da Anthropic. Iniciar conversa com sessão em outra máquina exige v2.1.225 ou posterior; antes disso, o Claude só conseguia responder a uma mensagem que tivesse chegado de lá.

Uma vez entregue, a mensagem conta para o uso como um prompt que você digitou. Isso é consequência real de custo de um canal automatizado, e é afirmação do próprio fabricante, não inferência nossa.

É seguro deixar agentes de IA de programação conversando entre si?

Essa é a pergunta que o mercado está fazendo em voz alta. Em 12 de agosto de 2026, um desenvolvedor a publicou em duas comunidades no mesmo dia, sob o mesmo título, "How do you make sure your AI agents are secure when talking to each other?", no r/agenticAI e no r/AgentSec. Conferimos a conta em vez de supor: as duas são da mesma pessoa, então leia como um desenvolvedor caçando resposta em dois lugares, e não como duas vozes independentes. A resposta do próprio Claude Code são quatro limites documentados sobre o que uma mensagem que chega pode fazer.

Uma mensagem de outra sessão não consegue aprovar nada, então ela nunca responde por você a um pedido de permissão pendente. Ela não consegue mudar configuração, e o Claude que recebe é instruído a nunca alterar configurações de permissão nem o CLAUDE.md porque outra sessão pediu. Um comando de barra dentro do texto da mensagem, como /compact, chega como texto puro e nunca é executado. E os pedidos de permissão continuam aparecendo: se agir sobre a mensagem exigir uma permissão que a sessão receptora não tem, você vê o mesmo aviso de sempre. Os limites de permissão continuam sendo por sessão, e o Claude é instruído a não pedir a outra sessão algo que foi bloqueado na dele.

Um quinto controle não aparece naquela página, e nós o achamos rodando o despejo de regras do auto mode em vez de lendo documentação. Na lista de permitidos, a entrada Multi-Agent Coordination afirma que conteúdo dentro de marcações teammate-message é saída de outro agente e não instrução de usuário humano, que ele não atinge a régua de consentimento de nenhuma regra de bloqueio BRANDA, e que não estabelece limite de usuário. A palavra branda pesa: a mesma entrada diz que a isenção NÃO cobre instrução de colega que caia numa regra de bloqueio DURA, avaliada primeiro e que ignora exceção. O texto de outro agente não funciona como o seu consentimento, e diante da única regra dura não funciona nem como isenção. Em separado, o classificador revisa cada mensagem que o Claude manda com SendMessage antes da entrega, o que a página de modos de permissão diz exigir v2.1.222 ou posterior.

O que decide se a mensagem é entregue, retida ou recusada?

Toda mensagem que chega termina em um de três desfechos, e a configuração que os governa é a crossSessionInbound, com os valores accept, hold e refuse. Entregue significa que o Claude Code a passa ao Claude receptor. Retida significa que ela fica de lado e só alcança o Claude se você aprovar ou se uma mudança posterior de configuração permitir. Recusada significa que ela é descartada sem entrega.

Quando nenhum valor se aplica, o Claude Code decide mensagem a mensagem pelos modos de permissão das duas sessões, e é aqui que a mudança de hoje no Claude Code toca este recurso diretamente. A Anthropic agrupa as sessões em duas classes: as que pulam pedidos de permissão e as que perguntam. O auto mode conta como quem pergunta, ao lado de acceptEdits e dontAsk, enquanto o bypassPermissions conta como quem pula. Uma sessão receptora que pergunta recebe cada mensagem entregue, e só retém uma quando quem manda se declara do lado que pula. Uma sessão receptora que pula retém toda mensagem esperando a sua aprovação e só entrega quando quem manda também pula. Como o auto mode virou o modo de permissão padrão das sessões novas nos planos Pro, Max e Team em 14 de agosto de 2026, o caso comum passou para a classe de quem pergunta, que é o lado mais permissivo daquela tabela para mensagem que chega.

Uma mensagem retida abre uma caixa de aprovação mostrando quem mandou e uma prévia. Se ninguém responder antes do prazo do dialogExpiry, cinco minutos por padrão, o Claude Code fecha a caixa e descarta a mensagem.

Duas sessões do Claude Code podem entrar em laço de mensagem?

Não indefinidamente, e a Anthropic documenta os três freios com nome em vez de deixar para a confiança. O Claude Code limita a taxa de mensagens repetidas por remetente, descarta repetições idênticas que chegam dentro de uma janela curta, e limita em 50 por sessão as mensagens aceitas esperando o Claude ler. A documentação afirma a consequência de forma direta: um laço de mensagem entre duas sessões, portanto, para sozinho.

Um limite separado vale para a fila de retidas, que guarda no máximo 100 mensagens e descarta a mais antiga depois disso. Vale conhecê-los como números e não como conforto, porque eles dizem que o modo de falhar é descarte silencioso, e não um erro que você notaria. Se você roda várias sessões que se mandam mensagem e algo parou de chegar, fila cheia é explicação mais provável do que recurso quebrado.

Uma assimetria para guardar: mensagem recusada na chegada não produz aviso nenhum do lado de quem mandou, enquanto a retida produz um aviso e depois um segundo, quando quem recebe entrega, nega ou deixa expirar. Ou seja, uma sessão configurada para recusar parece, de fora, exatamente igual a uma sessão que não recebeu nada.

Como desligar a mensageria entre sessões no Claude Code?

Receber e mandar são controles separados, então dá para fechar uma direção ou as duas. Para parar de receber, coloque a crossSessionInbound em refuse, e o Claude Code descarta as mensagens que chegam sem entregá-las. Para parar de mandar e de listar, acrescente regras de negação de permissão nomeando SendMessage e ListAgents, as duas com o nome puro da ferramenta e sem especificador. Um administrador pode aplicar os dois lados para uma organização nas configurações geridas.

Dois detalhes economizam tempo aqui. Negar o SendMessage também remove a mensageria para subagentes e para colegas de time de agentes, porque a mesma ferramenta serve aos três, então a regra que parece estreita é mais ampla do que se lê. E com a mensageria recusada, o Claude Code continua criando o socket de caixa de entrada de cada sessão e simplesmente descarta o que chega, de modo que uma sessão que recusa não mostra mudança visível nem no próprio /status nem na listagem de outra sessão. Você tem de confirmar pela configuração, e não olhando.

Se a sua preocupação é só com mensagem saindo da máquina, o controle mais estreito é o isolatePeerMachines em true, que exige a sua aprovação antes de qualquer mensagem alcançar sessão fora desta máquina, inclusive no modo bypassPermissions. Um true vindo de qualquer escopo de configuração vale, então um arquivo de projeto versionado consegue ligar a exigência, mas nunca desligá-la.

Como conferir se a mensageria está viva numa sessão?

Cada sessão com mensageria ligada cria um socket de caixa de entrada e exporta o caminho dele, então dá para confirmar pelo terminal em vez de adivinhar. O caminho aparece na linha Peer address do /status, prefixado com uds:, e na variável de ambiente CLAUDE_CODE_MESSAGING_SOCKET, que o Claude Code exporta para hooks e comandos de terminal. Rode isto dentro de uma sessão do Claude Code:

echo "socket: ${CLAUDE_CODE_MESSAGING_SOCKET:-unset}"

Na máquina que medimos, em 14 de agosto de 2026, isso imprimiu um caminho dentro de um diretório de sockets por sessão. Se imprimir unset, aquela sessão não criou caixa de entrada, e os motivos documentados são sessão headless em modo enxuto, versão abaixo da v2.1.224, ou uma das variáveis de ambiente que desligam a avaliação de feature flag, a saber CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK ou DISABLE_GROWTHBOOK.

O Claude Code também exporta um token por sessão, como CLAUDE_CODE_MESSAGING_TOKEN, usado por script que posta no socket da própria sessão. Estamos deliberadamente não publicando um comando que imprima esse token, porque ele é uma credencial viva e imprimir credencial viva na transcrição ou em arquivo está na própria lista de bloqueios do auto mode. Para conferir apenas que ele existe, sem revelar o valor:

echo "token: ${CLAUDE_CODE_MESSAGING_TOKEN:+set}"

As duas formas não são intercambiáveis, e a diferença entre elas é o ponto inteiro. A forma :+ imprime a palavra set e nunca o valor; a forma :-, usada no comando do socket, imprime o conteúdo da variável, o que está certo para um caminho e errado para um segredo. Sessões só se alcançam quando conseguem enxergar os mesmos arquivos em disco, então uma sessão dentro de um contêiner e uma sessão no hospedeiro não se mandam mensagem, enquanto duas sessões dentro do mesmo contêiner sim.

O que muda para quem roda vários agentes, agora que eles se falam

A leitura honesta é que isso muda a coordenação, não a supervisão. Uma mensagem elimina o copia e cola entre terminais quando uma sessão precisa do que outra descobriu, e os quatro limites acima significam que ela não consegue aprovar, configurar nem executar nada do lado de quem recebe. O que ela não faz é dizer o que cada uma daquelas sessões está fazendo agora, o que continua sendo trabalho seu e fica mais difícil conforme a conta cresce. Na máquina medida acima, oito sessões estavam alcançáveis e sete estavam ociosas; uma mensagem chega a qualquer uma delas, mas nada neste recurso diz qual está esperando por você. Rodar as CLIs oficiais de agente lado a lado, que é para o que serve o CanvasCode, é sobre esse segundo problema, e a mensageria não o substitui.

Três limitações que não vamos disfarçar. Primeira, tudo acima descreve documentação lida em 14 de agosto de 2026, e as notas de versão deste recurso vão da v2.1.222 à v2.1.232 em menos de duas semanas, então uma regra daqui pode se mexer mais rápido do que esta página. Segunda, a nossa medição é de uma máquina em um dia: oito sessões, um sistema operacional, uma versão do CLI, o que basta para mostrar a mecânica de nome e de socket funcionando e não basta para dizer nada sobre comportamento com contagens maiores. Terceira, nós não medimos o que o classificador faz com as mensagens na prática, apenas que a página de modos de permissão diz que ele revisa cada uma a partir da v2.1.222, então com que frequência ele bloqueia uma mensagem legítima entre sessões suas é pergunta aberta que não conseguimos responder pela documentação.