Como fazer sessões do Claude Code trocarem mensagens

O que significa as sessões do Claude Code enviarem mensagens entre si

Duas sessões do Claude Code podem enviar mensagens entre si quando são executadas na mesma máquina, com o mesmo utilizador do sistema operativo. Uma mensagem é um trecho de texto simples que uma sessão do Claude escreve para outra. Não inclui histórico da conversa nem ficheiros. O Claude encontra a outra sessão com a ferramenta ListAgents e entrega o texto com SendMessage, por isso nunca chama nenhuma das ferramentas manualmente. Basta indicar o que a outra sessão precisa de saber, e o Claude escreve a mensagem.

Esta funcionalidade chama-se messaging entre sessões. Em agosto de 2026, requer o Claude Code v2.1.224 ou posterior e funciona em macOS e Linux, incluindo Linux dentro do WSL 2. Não existe suporte nativo para Windows e a funcionalidade não está disponível no Amazon Bedrock, no Claude Platform on AWS, no Google Cloud's Agent Platform nem no Microsoft Foundry. Quando uma sessão cumpre estes requisitos, o messaging já está ativo e não é necessário ativar nada. O comportamento descrito abaixo baseia-se na documentação da Anthropic sobre messaging entre sessões.

É num VPS que esta funcionalidade é relevante, porque é num VPS que as sessões permanecem em execução durante tempo suficiente para justificar o envio de mensagens. Num portátil, fecha a tampa. Num servidor com tmux, uma sessão iniciada na segunda-feira ainda está em execução na quinta-feira e continua a manter o contexto de um repositório. Quando tem duas sessões assim, a forma como comunicam deixa de ser uma questão teórica. Se ainda não configurou este ambiente, comece por executar o Claude Code num VPS com tmux, que explica a configuração de sessões pressuposta por este guia.

Quando vale a pena usar uma segunda sessão

Comece pelo custo. Cada sessão é uma instância separada do Claude, com a sua própria janela de contexto. Por isso, duas sessões custam aproximadamente o dobro de uma sessão no mesmo período. Uma mensagem entregue conta para a utilização exatamente como um prompt que tenha introduzido. A coordenação não é gratuita. Um trabalho que é realmente uma sequência única de passos fica mais lento e mais caro quando é dividido entre sessões.

Os casos em que uma segunda sessão compensa têm uma característica comum. Duas partes do trabalho são executadas em simultâneo, sem dependerem uma da outra, e uma delas obtém durante a tarefa uma informação de que a outra precisa.

• Uma sessão encontra uma alteração incompatível enquanto a outra está a desenvolver com base no código afetado. O Claude resume a alteração e envia-a, em vez de ter de a introduzir novamente no outro terminal.
• Duas sessões trabalham no mesmo repositório, em git worktrees separados, e uma precisa de saber o que foi integrado.
• Uma migração longa ou uma execução de testes comunica o resultado à sessão que está a acompanhar.
• Uma sessão de desenvolvimento e uma sessão de revisão, em que a sessão de revisão lê o que a primeira produziu e envia as conclusões.

Quando o trabalho é sequencial ou quando ambas as sessões editariam os mesmos ficheiros, use uma única sessão. Quando pretende um grupo coordenado que o Claude cria e supervisiona dentro de uma única tarefa, trata-se de agent teams, uma funcionalidade separada e ainda experimental. Quando pretende apenas a mesma conversa noutro terminal, retome a sessão. A troca de mensagens entre sessões destina-se a sessões independentes que inicia e orienta manualmente.

Verifique se o recurso está disponível antes de depender dele

Primeiro, verifique a versão:

claude --version

Compare o número com 2.1.224. Depois, dentro de uma sessão, digite /list-agents, que também responde a /peers. O comando imprime todos os agentes que esta sessão consegue alcançar, com o nome ao qual cada um responde. Se o comando não for reconhecido, esta sessão não tem mensagens entre sessões, e nenhum ficheiro de configurações alterará esse comportamento. Digite /status e procure uma linha Peer address: ela contém o endereço da caixa de entrada desta sessão, com o prefixo uds:.

Existe uma armadilha que afeta especificamente os utilizadores de VPS. As mensagens entre sessões dependem da avaliação de feature flags, e várias variáveis de privacidade desativam essa avaliação, deixando o recurso desativado por predefinição. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC e DISABLE_GROWTHBOOK fazem isso. É comum reforçar a segurança de um servidor recém-instalado colando essas variáveis em ~/.bashrc e depois perguntar por que motivo /list-agents não existe. Os mesmos valores podem vir do mapa env num ficheiro de configurações ou de configurações geridas, por isso verifique primeiro a shell.

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

Remova a definição da variável que for apresentada. Para DISABLE_TELEMETRY e CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, qualquer valor não vazio ativa o comportamento, incluindo a string 0, portanto DISABLE_TELEMETRY=0 não faz o que parece. Para o desativar, remova a definição da variável ou atribua-lhe uma string vazia.

Dê nomes às suas sessões, ou o Claude não conseguirá endereçá-las

O Claude endereça uma mensagem a uma sessão pelo nome. Defina o nome ao iniciar a sessão:

claude --name builder-api

Também pode defini-lo com /rename dentro de uma sessão em execução. Quando não define um nome, o Claude Code deriva um nome do diretório de trabalho, como myapp-3f. Isso é adequado para uma sessão, mas torna-se confuso com quatro, e duas sessões podem acabar com o mesmo nome. A saída de /list-agents mostra o diretório de trabalho de cada sessão local, o que permite distinguir sessões com o mesmo nome. A própria listagem do Claude também adiciona um identificador curto ao endereço quando há colisão de nomes. Definir os nomes manualmente é mais simples do que consultar identificadores.

Um layout do tmux com duas sessões que pode reproduzir

Esta é uma sessão de implementação e uma sessão de revisão no mesmo repositório. A sessão de revisão trabalha num git worktree separado, por isso as duas nunca escrevem no mesmo ficheiro. git worktree add com HEAD cria um checkout desanexado, que é o que pretende para uma sessão que apenas lê e não faz commits. Como as duas sessões têm tarefas diferentes, vale a pena dar à sessão de revisão um estilo de saída próprio. Isso altera o system prompt dessa sessão e mantém-se em todos os turnos, em vez de desaparecer como uma instrução introduzida uma única vez.

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 e w listam as janelas pelo nome, para poder escolher uma. Na janela de implementação, execute /list-agents. Deverá ver reviewer-api com o diretório de trabalho ~/src/api-review. Se não aparecer, a sessão de revisão ainda não terminou de arrancar ou aplica-se um dos dois problemas da secção seguinte. Depois, transmita algo em linguagem simples:

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

Claude escreve o resumo e envia-o. Não escreve o texto da mensagem, e o conteúdo enviado por Claude varia. Na janela de revisão, a mensagem aparece na conversa com o nome do remetente. Se essa sessão estiver inativa, Claude inicia imediatamente um novo turno nessa sessão. Se estiver a meio de um turno, a mensagem aguarda até ao intervalo entre chamadas de ferramentas, por isso um comando em execução nunca é interrompido. Depois de Claude a ler, a mensagem é recolhida numa linha Message from que Ctrl+O expande. O par funciona melhor quando a sessão de implementação mantém as alterações pequenas, porque um diff limitado produz uma transferência mais curta e uma revisão que a outra sessão consegue concluir num único turno. É esse o hábito que a competência do programador sénior preguiçoso procura impor.

Quem pode ver quem num único VPS

A entrega entre sessões na mesma máquina nunca passa pelos servidores da Anthropic. Cada sessão grava ficheiros de registo no disco e associa o seu próprio socket de entrada, e o Claude Code lê esses ficheiros para encontrar as outras sessões. Daqui resultam duas consequências, e ambas são importantes num servidor.

O socket está limitado ao seu utilizador do sistema operativo. Uma sessão iniciada como root e uma sessão iniciada como deploy não conseguem ver-se, mesmo lado a lado no mesmo servidor tmux, porque as sessões de um utilizador não conseguem aceder ao socket de outro utilizador. Execute ambas as sessões com o mesmo utilizador.

Um contentor tem o seu próprio sistema de ficheiros. Uma sessão dentro do Docker e uma sessão no host não conseguem comunicar entre si, porque não leem os mesmos ficheiros de registo. Duas sessões dentro do mesmo contentor podem trocar mensagens normalmente. Se mantiver os agentes em contentores para isolamento, como em executar agentes de programação numa VM descartável, espere que as mensagens funcionem dentro de um contentor, mas não através do limite do contentor.

As suas sessões noutras máquinas e na web aparecem na lista apenas enquanto o Remote Control está ligado, e são identificadas como tal. O Claude aqui só pode responder a uma mensagem recebida de uma dessas sessões. Não pode iniciar essa troca.

Por que sua mensagem nunca chegou

O motivo mais comum não tem relação com a rede. A sessão receptora decidiu o que fazer com a mensagem, e decidiu não entregá-la. Toda mensagem recebida termina em um de três estados: entregue, retida (separada sem entrega até você aprová-la) ou recusada (descartada sem entrega).

Quando nenhum valor crossSessionInbound se aplica, Claude Code decide por mensagem comparando os modos de permissão das duas sessões. Ele agrupa as sessões que ignoram os prompts de permissão em uma classe e todas as outras na outra. auto, acceptEdits e dontAsk contam como modos que exibem prompts. O modo de planejamento conta como modo que ignora prompts em uma sessão que tem permissões para ignorá-los. Se você não tiver certeza em qual classe uma sessão se enquadra, vale a pena ler primeiro o que cada modo de permissão realmente faz, porque auto é onde a maioria das sessões começa atualmente e fica do lado dos prompts nessa divisão. A regra é simétrica:

• Uma sessão receptora que exibe prompts de permissão recebe cada mensagem. Ela retém uma mensagem somente quando a sessão remetente se identifica como uma sessão que ignora prompts.
• Uma sessão receptora que ignora prompts retém todas as mensagens para sua aprovação. Ela entrega uma mensagem somente quando o remetente também ignora prompts.

Portanto, o primeiro fluxo de trabalho que a maioria das pessoas cria é exatamente o que não funciona. Você inicia um builder com --permission-mode bypassPermissions porque quer que ele seja executado sem intervenção, deixa o reviewer com os padrões e todas as mensagens enviadas pelo builder ficam aguardando em uma caixa de diálogo de aprovação que ninguém está acompanhando. Essa caixa de diálogo é fechada após o prazo de dialogExpiry, que por padrão é 5m, e a mensagem é descartada. Na mesma máquina, a sessão remetente recebe uma notificação quando sua mensagem é retida e outra quando o receptor a entrega, recusa ou deixa expirar. Portanto, leia a tela do remetente antes de culpar o socket.

Para fazer uma sessão receber mensagens sem intervenção, defina crossSessionInbound como accept. O local onde você define isso determina a aplicação da configuração. Claude Code lê primeiro as configurações gerenciadas, depois a opção --settings e, por fim, as configurações do usuário. Ele aplica o primeiro valor encontrado. Um valor nas configurações do projeto ou locais só se aplica quando é mais restritivo, na escala accept < hold < refuse. Um accept em .claude/settings.json é menos restritivo do que qualquer outra opção e, portanto, é ignorado quando uma fonte confiável definiu um valor. Coloque-o em ~/.claude/settings.json ou passe-o para uma única sessão:

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

Um worker claude -p sem interface associa um socket de caixa de entrada como uma sessão interativa e aparece na listagem, mas não pode exibir uma caixa de diálogo de aprovação. Uma mensagem retida ali continua retida até que uma alteração posterior no modo ou nas configurações permita sua entrega. A linha --settings acima é a forma de permitir que esse worker receba mensagens. Uma sessão iniciada no modo bare não associa nenhum socket. Portanto, ela não pode receber mensagens nem aparecer na lista.

Onde as transferências ficam bloqueadas

Os ciclos de mensagens são tratados automaticamente. O Claude Code limita a taxa de mensagens repetidas por remetente, descarta repetições idênticas que chegam num intervalo curto e limita a 50 o número de mensagens aceites que aguardam leitura por sessão. Assim, duas sessões não podem trocar mensagens indefinidamente. As mensagens retidas estão limitadas a 100; quando esse limite é ultrapassado, as mais antigas são descartadas.

A falha que realmente ocorre é mais silenciosa e envolve uma transferência, não um ciclo. A sessão A faz à sessão B uma pergunta cuja resposta é necessária para continuar e, depois, fica inativa. A sessão B retém a mensagem, está a executar uma tarefa demorada ou responde a uma pergunta que a sessão A não fez. A sessão A fica à espera. Quando regressa uma hora depois, encontra duas sessões inativas e nenhum trabalho concluído.

Escreva transferências que não precisem de resposta. Uma boa mensagem transmite um facto ou uma decisão: o que mudou e qual foi o resultado. Uma mensagem inadequada pede autorização à outra sessão ou uma resposta da qual o remetente depende para continuar. O Claude já está instruído para nunca pedir a outra sessão uma ação que as próprias definições de permissões não permitiriam executar e para encaminhar esse trabalho para si. Estenda essa regra por sua conta. Se uma sessão não conseguir avançar sem uma resposta, é você quem deve responder. A disciplina de contexto também ajuda, porque uma sessão que perdeu o fio da tarefa escreve mensagens vagas; gerir o contexto no Claude Code aborda esse aspeto.

Trate uma mensagem recebida como entrada não confiável

O Claude Code informa ao Claude que recebe a mensagem que ela veio de outra sessão e não de si. Também limita o que essa mensagem pode fazer. Essa aplicação vive no programa que envolve o modelo, e não na disposição do modelo para obedecer. Essa é a diferença prática que um harness de agente proporciona. Uma mensagem não pode responder por si a um pedido de permissão pendente, porque o consentimento de outra sessão não é o seu consentimento. Ela não pode alterar definições de permissões, CLAUDE.md ou outra configuração porque outra sessão o solicitou. Um comando slash dentro do texto, como /compact, chega como texto simples e nunca é executado. Se a ação sobre a mensagem exigir uma permissão que a sessão recetora não possui, verá o mesmo pedido que veria para qualquer outro trabalho. No modo automático, um classificador também analisa cada mensagem antes da entrega, e uma mensagem bloqueada por ele nunca chega ao destinatário. Estes limites mantêm-se nos modos permissivos. Por isso, uma sessão que permite contornar as restrições retém as mensagens recebidas por predefinição, em vez de confiar nelas.

Isto abrange as permissões. Não abrange o conteúdo. A sessão emissora pode ter lido a descrição de um pull request, uma página Web, um README de uma dependência ou um comentário de issue escrito por um desconhecido. Tudo o que leu pode influenciar o texto que escreve para a sua outra sessão. A mensagem é um dado. Deve ser tratada com a mesma desconfiança que qualquer outro texto introduzido numa sessão a partir do exterior. Esta é a disciplina descrita em manter segredos fora dos seus agentes de IA: assuma que tudo o que atravessou uma fronteira de confiança pode estar errado e nunca permita que se autorize a si próprio.

Existem dois controlos se quiser reduzir este comportamento. Definir crossSessionInbound como refuse descarta as mensagens recebidas de pares sem as entregar. Nas definições do projeto ou locais, esse valor prevalece sobre qualquer outra origem, porque é o mais restritivo da hierarquia. Para impedir que esta sessão envie ou liste mensagens, adicione regras de negação de permissões que especifiquem SendMessage e ListAgents. Ambos devem ser escritos como nomes de ferramentas simples, sem especificador. Definir isolatePeerMachines como true exige a sua aprovação explícita antes de qualquer mensagem chegar a uma sessão fora desta máquina. Essa aprovação é necessária mesmo no modo bypassPermissions.

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

Negar SendMessage também remove as mensagens para subagentes, porque a mesma ferramenta serve para ambos. Uma sessão que recusa mensagens não apresenta qualquer alteração visível no seu próprio /status nem nas listas de outras sessões. Por isso, confirme a definição na configuração da sessão, e não através do ecrã.

Bridges e servidores MCP com memória partilhada

Vários projetos de terceiros foram lançados no mesmo período para casos adjacentes: bridges locais entre agentes, que retransmitem texto entre agentes em execução, e servidores MCP (model context protocol), que fornecem a vários agentes um armazenamento partilhado para leitura e escrita. Avalie-os como uma abordagem diferente, não como concorrentes, e confirme qualquer comando de instalação no README do próprio projeto antes de o executar. As mensagens usam push, porque o remetente coloca o texto no turno do recetor. Um armazenamento partilhado usa pull, porque ninguém é interrompido e uma sessão vê a nota quando a consulta na próxima vez. O pull é mais adequado para estados que mudam lentamente e só funciona quando uma sessão consulta efetivamente o armazenamento.

Se seguir essa abordagem, as perguntas importantes dizem respeito ao processo, não à lista de funcionalidades. Com que utilizador o servidor é executado e a que dados pode aceder no sistema. Executar servidores MCP numa VPS aborda essa configuração. Partilhar competências de agentes entre repositórios aborda o caso mais simples, em que o que pretende partilhar entre sessões são instruções, não estado em tempo real, eliminando muitas das mensagens que teria de enviar. Para uma visão mais abrangente, executar um agente de programação numa VPS é o ponto de partida.

FAQ

Por que /list-agents não é reconhecido na minha sessão?

A sessão não tem mensagens entre sessões. Primeiro, confirme claude --version em relação a 2.1.224, porque a funcionalidade exige essa versão ou posterior. Depois, confirme a plataforma, porque a funcionalidade é executada em macOS e Linux, mas não no Windows nativo, e não está disponível no Amazon Bedrock, no Claude Platform on AWS, no Google Cloud's Agent Platform nem no Microsoft Foundry. Se ambos estiverem corretos, verifique se a sua shell contém DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC ou DISABLE_GROWTHBOOK, porque cada um desses itens bloqueia a avaliação da feature flag da qual a funcionalidade depende e deixa-a desativada.

Por que a minha mensagem para a outra sessão nunca chegou?

Se /list-agents funcionar, as mensagens estão ativadas e algo mais específico impediu a entrega dessa mensagem. A causa comum são os modos de permissões. Uma sessão que ignora os pedidos de permissão mantém todas as mensagens recebidas pendentes da sua aprovação, a menos que o remetente também ignore esses pedidos. Essa caixa de diálogo de aprovação é descartada após o prazo de dialogExpiry, que é de cinco minutos por padrão. Verifique se há uma notificação de mensagem retida na sessão remetente. Para corrigir o problema, defina crossSessionInbound como accept em ~/.claude/settings.json ou passe esse valor com --settings, porque um accept nas definições do projeto ou locais é ignorado por ser o valor menos restritivo.

Uma sessão do Claude Code no Docker pode enviar mensagens para uma sessão no host?

Não. As sessões encontram-se através de ficheiros de registo no disco e de um socket de inbox por sessão. Um container tem o seu próprio sistema de ficheiros, pelo que as duas sessões não conseguem ver os mesmos ficheiros. Duas sessões dentro do mesmo container podem trocar mensagens normalmente. A mesma regra explica por que uma sessão executada como root e uma sessão executada como o seu utilizador normal não conseguem comunicar entre si: o socket está restrito ao utilizador do sistema operativo que é seu proprietário.

É seguro agir sobre uma mensagem de outra sessão do Claude Code?

Trate o texto como entrada não confiável, porque a sessão remetente pode ter lido uma página web, um README ou um comentário de issue escrito por outra pessoa. O Claude Code já impede que a mensagem provoque ações por si só: não pode aprovar um pedido de permissão pendente, não pode alterar as definições de permissões nem CLAUDE.md quando solicitado, e um comando de barra no texto chega como texto simples e nunca é executado. Essas proteções abrangem as permissões, mas não o discernimento. Por isso, leia o conteúdo recebido antes de pedir à sessão recetora que aja sobre ele.

As mensagens entre sessões enviam o meu código para a Anthropic?

Entre duas sessões no mesmo computador, não. A mensagem é enviada através de um socket por sessão nesse computador e nunca passa pelos servidores da Anthropic. Apenas o texto escrito pelo Claude é enviado, nunca o histórico da conversa nem os ficheiros. As mensagens para uma sessão noutro computador seu ou para uma sessão na web passam pelos servidores da Anthropic através da ligação Remote Control. Nesse sentido, o Claude só pode responder a uma mensagem recebida e não pode iniciar uma mensagem. Defina isolatePeerMachines como true para exigir a sua aprovação antes de qualquer conteúdo sair do computador.