¿Las sesiones de Claude Code pueden mandarse mensajes entre sí?

Respuesta corta: sí. Desde Claude Code v2.1.224, en macOS y Linux, una de tus sesiones de Claude Code puede mandar un mensaje a otra, usando dos herramientas llamadas ListAgents, para encontrar la otra sesión, y SendMessage, para entregarle el texto. Un mensaje es texto plano que un Claude escribe para otro, nunca el historial de la conversación y nunca archivos. En esta máquina, el 14 de agosto de 2026, con Claude Code 2.1.232, el listado devolvió ocho sesiones alcanzables.

¿Qué es la mensajería entre sesiones de Claude Code?

La mensajería entre sesiones es Claude Code entregando un fragmento de texto, escrito por el Claude de una de tus sesiones, al Claude de otra sesión tuya. Anthropic documenta que requiere Claude Code v2.1.224 o posterior, que funciona en macOS y Linux, incluido Linux dentro de WSL 2, y que no se ofrece en Windows nativo. Tampoco existe en Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform ni Microsoft Foundry. Donde se cumplen los requisitos, la documentación dice que la mensajería está activa sin nada que habilitar, lo que conviene saber porque significa que esto llegó a tu instalación sin que tú lo encendieras.

El propósito declarado es el momento en que una sesión descubre algo que otra necesita mientras las dos siguen trabajando: un cambio que rompió algo, una decisión que se resolvió, una migración que terminó. Anthropic lo separa de cuatro funciones vecinas en la misma página, y la separación es útil porque se confunden con facilidad. Reanudar una sesión mueve la conversación entera. Los equipos de agentes son un grupo coordinado que Claude crea y supervisa. La vista de agentes observa muchas sesiones desde un solo lugar. Remote Control conduce una sesión desde tu teléfono. La mensajería entre sesiones no es ninguna de esas: es texto que pasa entre sesiones independientes que tú mismo abriste y diriges. Todo esto se leyó en la página oficial de mensajería entre sesiones el 14 de agosto de 2026.

¿Cómo ver qué sesiones de Claude Code se pueden alcanzar?

Ejecuta /list-agents dentro de una sesión de Claude Code, comando que también existe como /peers. Imprime cada sesión que esta puede direccionar, y el nombre de cada fila es la dirección que Claude usa al mandar. No necesitas ejecutarlo antes de pedir un mensaje, porque Claude encuentra el destino por su cuenta con ListAgents; el comando existe para que tú veas la misma lista.

Lo que viene ahora es medición nuestra, no un ejemplo. En una máquina de desarrollo, el 14 de agosto de 2026, con Claude Code 2.1.232, el listado devolvió ocho sesiones vecinas, todas interactivas, siete de ellas inactivas, la más antigua abierta dos días antes. Sus nombres derivaban del nombre de la carpeta de trabajo con un sufijo corto añadido, lo que coincide con el comportamiento documentado para una sesión que no nombraste tú. Dos proyectos tenían dos sesiones cada uno, distinguidas solo por ese sufijo, y los otros cuatro nombres eran únicos. El mecanismo es lo que vale llevarse: cuando dos sesiones viven en la misma carpeta, es el sufijo lo que las mantiene direccionables por separado, y cuando varias sesiones responden todavía a un mismo nombre, Claude Code añade un identificador corto a cada fila y direcciona el mensaje con él. Puedes nombrar una sesión tú mismo con el comando /rename o con la opción --name, que es la forma fiable de tener una dirección previsible.

Si /list-agents no se reconoce, esa sesión no tiene la función, y la documentación manda empezar comprobando claude --version contra el requisito de la v2.1.224.

¿Qué manda realmente una sesión de Claude Code a otra?

Texto plano, y nada más. La documentación es explícita al decir que un mensaje es un fragmento de texto que un Claude escribe para otro y nunca historial de conversación ni archivos, y que la sesión que recibe se queda solo con ese texto, más el nombre de quien lo mandó y una dirección de respuesta. Los mensajes estructurados del protocolo de equipos de agentes se quedan dentro del equipo y no cruzan entre sesiones independientes.

Claude escribe el mensaje por su cuenta, lo que cambia la forma de pedir uno. Tú dices qué necesita saber la otra sesión, no las palabras que hay que mandar. Desde Claude Code v2.1.232 también puedes nombrar el destino con una mención de @ elegida de una lista de tus sesiones locales vivas, igual que se menciona a un subagente. A dónde viaja el mensaje depende de dónde corre la otra sesión, y esta es la parte que conviene leer antes de usarlo con algo sensible: un mensaje a una sesión de la misma máquina va por un socket propio de la sesión y nunca pasa por servidores de Anthropic, mientras que un mensaje a otra máquina tuya o a una sesión de Claude Code en la web viaja a través de servidores de Anthropic. Iniciar una conversación con una sesión de otra máquina requiere v2.1.225 o posterior; antes de eso, Claude solo podía responder a un mensaje que hubiera llegado de allí.

Una vez entregado, el mensaje cuenta para el uso como un prompt que tú escribiste. Esa es una consecuencia real de coste de un canal automatizado, y es afirmación del propio fabricante, no inferencia nuestra.

¿Es seguro dejar que los agentes de IA de programación se hablen entre sí?

Esa es la pregunta que el mercado está haciendo en voz alta. El 12 de agosto de 2026, un desarrollador la publicó en dos comunidades el mismo día, bajo el mismo título, "How do you make sure your AI agents are secure when talking to each other?", en r/agenticAI y en r/AgentSec. Comprobamos la cuenta en lugar de suponer: las dos son de la misma persona, así que léelo como un desarrollador buscando respuesta en dos sitios, y no como dos voces independientes. La respuesta del propio Claude Code son cuatro límites documentados sobre lo que un mensaje entrante puede hacer.

Un mensaje de otra sesión no puede aprobar nada, así que nunca responde por ti a una solicitud de permiso pendiente. No puede cambiar configuración, y al Claude que recibe se le instruye no alterar nunca los ajustes de permisos ni el CLAUDE.md porque otra sesión lo pidió. Un comando de barra dentro del texto del mensaje, como /compact, llega como texto plano y nunca se ejecuta. Y las solicitudes de permiso siguen apareciendo: si actuar sobre el mensaje exige un permiso que la sesión receptora no tiene, ves el mismo aviso de siempre. Los límites de permisos siguen siendo por sesión, y a Claude se le instruye no pedirle a otra sesión algo que fue bloqueado en la suya.

Un quinto control no aparece en esa página, y lo encontramos ejecutando el volcado de reglas del modo auto en lugar de leyendo documentación. En la lista de permitidos, la entrada Multi-Agent Coordination afirma que el contenido dentro de marcas teammate-message es salida de otro agente y no instrucción de un usuario humano, que no alcanza el listón de consentimiento de ninguna regla de bloqueo BLANDA, y que no establece un límite de usuario. La palabra blanda pesa: la misma entrada dice que la exención NO cubre instrucciones de un compañero que encajen en una regla de bloqueo DURA, evaluada primero y que ignora las excepciones. El texto de otro agente no funciona como tu consentimiento, y ante la única regla dura tampoco funciona como exención. Por separado, el clasificador revisa cada mensaje que Claude manda con SendMessage antes de la entrega, lo que la página de modos de permisos dice que requiere v2.1.222 o posterior.

¿Qué decide si un mensaje se entrega, se retiene o se rechaza?

Todo mensaje entrante termina en uno de tres desenlaces, y el ajuste que los gobierna es crossSessionInbound, con los valores accept, hold y refuse. Entregado significa que Claude Code se lo pasa al Claude receptor. Retenido significa que queda apartado y solo alcanza a Claude si tú lo apruebas o si un cambio posterior de configuración lo permite. Rechazado significa que se descarta sin entrega.

Cuando no se aplica ningún valor, Claude Code decide mensaje a mensaje según los modos de permisos de las dos sesiones, y aquí es donde el cambio de hoy en Claude Code toca esta función directamente. Anthropic agrupa las sesiones en dos clases: las que se saltan las solicitudes de permiso y las que preguntan. El modo auto cuenta como de las que preguntan, junto a acceptEdits y dontAsk, mientras que bypassPermissions cuenta como de las que se saltan. Una sesión receptora que pregunta recibe cada mensaje entregado, y solo retiene uno cuando quien manda se declara del lado que se salta. Una sesión receptora que se salta retiene todo mensaje esperando tu aprobación y solo entrega cuando quien manda también se salta. Como el modo auto pasó a ser el modo de permisos por defecto de las sesiones nuevas en los planes Pro, Max y Team el 14 de agosto de 2026, el caso común se movió a la clase de las que preguntan, que es el lado más permisivo de esa tabla para el mensaje que llega.

Un mensaje retenido abre un cuadro de aprobación que muestra quién lo mandó y una vista previa. Si nadie lo responde antes del plazo de dialogExpiry, cinco minutos por defecto, Claude Code cierra el cuadro y descarta el mensaje.

¿Pueden dos sesiones de Claude Code quedarse en un bucle de mensajes?

No indefinidamente, y Anthropic documenta los tres frenos con nombre en lugar de dejarlo a la confianza. Claude Code limita la tasa de mensajes repetidos por remitente, descarta repeticiones idénticas que llegan dentro de una ventana corta, y limita a 50 por sesión los mensajes aceptados que esperan a que Claude los lea. La documentación afirma la consecuencia de forma directa: un bucle de mensajes entre dos sesiones, por lo tanto, se detiene solo.

Un límite aparte rige la cola de retenidos, que guarda como máximo 100 mensajes y descarta el más antiguo a partir de ahí. Conviene conocerlos como números y no como consuelo, porque dicen que el modo de fallo es el descarte silencioso y no un error que notarías. Si ejecutas varias sesiones que se mandan mensajes y algo dejó de llegar, una cola llena es explicación más probable que una función rota.

Una asimetría que conviene guardar: un mensaje rechazado al llegar no produce ningún aviso del lado de quien lo mandó, mientras que uno retenido sí produce un aviso y después un segundo, cuando quien recibe entrega, deniega o deja expirar. O sea, una sesión configurada para rechazar se ve, desde fuera, exactamente igual que una sesión que no recibió nada.

¿Cómo apagar la mensajería entre sesiones en Claude Code?

Recibir y mandar son controles separados, así que puedes cerrar una dirección o las dos. Para dejar de recibir, pon crossSessionInbound en refuse, y Claude Code descarta los mensajes entrantes sin entregarlos. Para dejar de mandar y de listar, añade reglas de denegación de permisos nombrando SendMessage y ListAgents, las dos con el nombre pelado de la herramienta y sin especificador. Un administrador puede aplicar ambos lados para una organización en los ajustes gestionados.

Dos detalles ahorran tiempo aquí. Denegar SendMessage también quita la mensajería hacia subagentes y hacia compañeros de equipo de agentes, porque la misma herramienta sirve a los tres, así que la regla que parece estrecha es más amplia de lo que se lee. Y con la mensajería rechazada, Claude Code sigue creando el socket de bandeja de entrada de cada sesión y simplemente descarta lo que llega, de modo que una sesión que rechaza no muestra cambio visible ni en su propio /status ni en el listado de otra sesión. Tienes que confirmarlo desde la configuración, y no mirando.

Si tu preocupación es solo que salgan mensajes de la máquina, el control más estrecho es isolatePeerMachines en true, que exige tu aprobación antes de que cualquier mensaje alcance una sesión fuera de esta máquina, incluso en modo bypassPermissions. Un true desde cualquier ámbito de configuración se aplica, así que un archivo de proyecto versionado puede encender la exigencia, pero nunca apagarla.

¿Cómo comprobar si la mensajería está viva en una sesión?

Cada sesión con mensajería activa crea un socket de bandeja de entrada y exporta su ruta, así que puedes confirmarlo desde la terminal en vez de adivinar. La ruta aparece en la fila Peer address de /status, con el prefijo uds:, y en la variable de entorno CLAUDE_CODE_MESSAGING_SOCKET, que Claude Code exporta a los hooks y a los comandos de terminal. Ejecuta esto dentro de una sesión de Claude Code:

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

En la máquina que medimos, el 14 de agosto de 2026, eso imprimió una ruta dentro de un directorio de sockets por sesión. Si imprime unset, esa sesión no creó bandeja de entrada, y los motivos documentados son una sesión headless en modo escueto, una versión por debajo de la v2.1.224, o una de las variables de entorno que apagan la evaluación de feature flags, en concreto CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK o DISABLE_GROWTHBOOK.

Claude Code también exporta un token por sesión, como CLAUDE_CODE_MESSAGING_TOKEN, que usa un script que publica en el socket de su propia sesión. Deliberadamente no publicamos un comando que imprima ese token, porque es una credencial viva e imprimir una credencial viva en la transcripción o en un archivo está en la propia lista de bloqueos del modo auto. Para comprobar solo que existe, sin revelar el valor:

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

Las dos formas no son intercambiables, y la diferencia entre ellas es el punto entero. La forma :+ imprime la palabra set y nunca el valor; la forma :-, usada en el comando del socket, imprime el contenido de la variable, lo que está bien para una ruta y mal para un secreto. Las sesiones solo se alcanzan cuando pueden ver los mismos archivos en disco, así que una sesión dentro de un contenedor y una sesión en el anfitrión no se mandan mensajes, mientras que dos sesiones dentro del mismo contenedor sí.

Qué cambia para quien ejecuta varios agentes, ahora que se hablan

La lectura honesta es que esto cambia la coordinación, no la supervisión. Un mensaje elimina el copiar y pegar entre terminales cuando una sesión necesita lo que otra descubrió, y los cuatro límites de arriba significan que no puede aprobar, configurar ni ejecutar nada del lado de quien recibe. Lo que no hace es decirte qué está haciendo ahora cada una de esas sesiones, lo que sigue siendo tu trabajo y se vuelve más difícil conforme sube la cuenta. En la máquina medida arriba, ocho sesiones eran alcanzables y siete estaban inactivas; un mensaje llega a cualquiera de ellas, pero nada en esta función te dice cuál está esperándote. Ejecutar las CLIs oficiales de agente una al lado de la otra, que es para lo que sirve CanvasCode, va de ese segundo problema, y la mensajería no lo sustituye.

Tres limitaciones que no vamos a disimular. Primera, todo lo anterior describe documentación leída el 14 de agosto de 2026, y las notas de versión de esta función van de la v2.1.222 a la v2.1.232 en menos de dos semanas, así que una regla de aquí puede moverse más rápido que esta página. Segunda, nuestra medición es de una máquina en un día: ocho sesiones, un sistema operativo, una versión del CLI, lo que basta para mostrar la mecánica de nombres y de socket funcionando y no basta para decir nada sobre el comportamiento con cuentas mayores. Tercera, no hemos medido qué hace el clasificador con los mensajes en la práctica, solo que la página de modos de permisos dice que revisa cada uno a partir de la v2.1.222, así que con qué frecuencia bloquea un mensaje legítimo entre sesiones tuyas es una pregunta abierta que no podemos responder desde la documentación.