Anthropic lanza la función experimental de mensajería entre sesiones para Claude Code, que permite enviar mensajes directamente entre sesiones diferentes. Esta función no transmite el contexto completo, sino solo los resultados de la tarea y la información de dependencias, implementada a través de dos herramientas internas: ListAgents y SendMessage. Cada sesión local se registra en el disco y se vincula a un Socket de Inbox; los mensajes locales se transmiten directamente mediante Socket, mientras que los mensajes entre máquinas se envían a través del servidor de Anthropic. Los mensajes se activan como un nuevo Turn cuando la sesión está inactiva, y se leen entre llamadas a herramientas durante un Turn activo. El extremo receptor distingue los mensajes entre sesiones de los mensajes del usuario; no pueden reemplazar la autorización del usuario, y cuenta con tres modos de control de entrada: accept/hold/refuse. Esta función se integra con capacidades existentes como Resume Session, Agent Teams y Worktree, proporcionando una capa de coordinación entre sesiones para Claude Code.

Autor y fuente del artículo: Leifeng.com

En los últimos días, Anthropic ha añadido a Claude Code una nueva capacidad experimental: mensajería entre sesiones.

En pocas palabras, te permite enviar mensajes directamente entre múltiples sesiones de Claude Code que se ejecutan simultáneamente.

Por ejemplo, si abres 3 sesiones de Claude Code: una para la base de datos, otra para la API del backend y otra para las pruebas. Antes, aunque estas 3 sesiones podían trabajar en paralelo, no sabían entre sí hasta dónde habían llegado. Después de que la sesión de base de datos modificara el esquema, el desarrollador aún tenía que cambiar manualmente a otra terminal y volver a informar los cambios a la sesión del backend.

Después de incorporar el mensajería entre sesiones, este paso puede realizarse directamente por Claude. La sesión de base de datos puede notificar a la sesión del backend qué campos han cambiado; si la sesión de prueba detecta problemas de regresión en la interfaz, también puede enviar los resultados a la sesión que está modificando el código relacionado. Claude puede determinar por sí mismo cuándo es necesario notificar a otras sesiones, o puede contactar con sesiones específicas según lo requiera el desarrollador.

Para entender exactamente qué hace, siga la ruta completa de un mensaje: qué transmite, cómo encuentra al destinatario, cuándo entra el mensaje en Claude y por qué el receptor no puede simplemente hacerlo directamente.

01

Los mensajes entre sesiones no alteran la aislamiento de sesiones original de Claude Code.

Cuando la Sesión A envía un mensaje a la Sesión B, no envía su Historial de Conversación, los archivos leídos ni toda la Ventana de Contexto. Según las normas oficiales, lo que se transmite entre sesiones es texto. Si se necesita migrar la conversación completa y el contexto a otro dispositivo, se debe reanudar la Sesión original, en lugar de utilizar el mensajería entre sesiones.

Esto determina la forma en que colaboran varios Claude.

Suponiendo que la sesión de la base de datos leyó docenas de archivos e intentó varias soluciones antes de determinar que se necesita modificar un campo específico, la sesión del backend no necesita conocer todo el proceso de análisis previo; solo necesita recibir los cambios finales y cómo afectarán su API.

Por lo tanto, el mensajería entre sesiones transmite resultados de tareas e información de dependencias, no la memoria de trabajo completa.

La ventaja de hacerlo es que la información local generada por diferentes tareas no inundará constantemente otras sesiones. Los detalles relacionados con la base de datos pueden permanecer en la sesión de base de datos, los procesos de prueba pueden permanecer en la sesión de prueba, y solo cuando un cambio comience a afectar otras tareas, la información relevante cruzará el límite de la sesión.

Es una idea diferente a "todos los Agentes comparten un gran Contexto". Cross-session messaging opta por mantener las Sesiones independientes y sincronizar explícitamente el estado necesario cuando surjan dependencias entre tareas.

Dado que se transmite un mensaje claro, la siguiente pregunta es: ¿cómo encuentra Session A a Session B?

02 Primero debes encontrar otra sesión

Claude Code agrega su propio punto de entrada de comunicación a las sesiones que admiten mensajería entre sesiones.

Each local Session registers relevant information to disk and binds an Inbox Socket. Claude can use ListAgents to find currently reachable Sessions, and then use SendMessage to send messages to the specified target.

Los usuarios no necesitan operar estas herramientas internas manualmente; solo deben decirle a Claude a qué sesión quieren comunicarse, o permitir que ella notifique automáticamente al otro cuando surja una dependencia en la tarea.

El nombre de la sesión también comienza a participar en la dirección. Claude puede buscar el objetivo según el nombre; si hay nombres duplicados, el sistema añade un identificador corto para distinguirlos, y además muestra el Directorio de Trabajo, ayudando a determinar qué proyecto o directorio está procesando cada sesión.

Una vez que se encuentra el objetivo, los mensajes locales se transmiten directamente a través del Socket de la sesión correspondiente, sin necesidad de pasar por el servidor de Anthropic. Las sesiones en otro equipo o en Claude Code Web sí utilizan el servidor de Anthropic y las conexiones relacionadas con el control remoto.

Este mecanismo de descubrimiento también determina los límites de la comunicación local.

Claude Code necesita leer la información de registro escrita en el disco por otras sesiones, por lo que dos Claude, aunque se ejecuten físicamente en la misma computadora, podrían no detectarse mutuamente si sus sistemas de archivos están aislados. Un caso típico es el host y un contenedor independiente; si ambas sesiones se ejecutan dentro del mismo contenedor, entonces pueden comunicarse normalmente.

Inbox Socket también está sujeto a restricciones de permisos de usuario del sistema operativo; otros usuarios del sistema operativo en el servidor compartido no pueden acceder directamente a tu sesión.

Entonces, lo que aquí se denomina "comunicación local" en realidad depende de si la información de registro es visible, si el socket es accesible y si el sistema operativo permite el acceso.

El mensaje ya puede encontrar su destino y enviarse a la Bandeja de entrada; ahora le toca al Runtime de Claude Code decidir cuándo entregar este mensaje al modelo.

03 Después de que se entregue la información

Supongamos que la sesión del backend está modificando un archivo, y en ese momento la sesión de prueba envía un mensaje informando que acaba de detectar un problema de regresión en la interfaz.

Claude Code no interrumpirá inmediatamente la herramienta en ejecución.

Si la sesión objetivo está en estado Idle, el mensaje puede activar un nuevo Turn; si Claude ya se encuentra en un Turn activo, el mensaje esperará y se leerá entre dos llamadas a herramientas.

La razón de este enfoque está relacionada con la forma en que el Coding Agent ejecuta las tareas. Claude podría estar escribiendo un archivo, ejecutando pruebas, realizando una migración o procesando otra tarea que consume tiempo. Si los mensajes externos pudieran cambiar arbitrariamente la acción actual en cualquier momento, sería fácil que la herramienta solo completara una parte de la tarea, mientras el agente ya comenzara a replantearse según la nueva información.

Por lo tanto, el mensaje afecta las decisiones futuras de Claude, pero no interrumpe directamente las operaciones en curso.

Esto también significa que Cross-session messaging ya está integrado en el Agentic Loop de Claude Code, convirtiéndose en una fuente de entrada asincrónica. Además, esta entrada no solo está disponible para otras sesiones de Claude.

Claude Code expone el Socket de mensajería de la sesión actual a los procesos secundarios iniciados por Hook y Bash. Después de que finalice una tarea en segundo plano de larga duración, puede enviar activamente el resultado de vuelta a la sesión actual, sin necesidad de que Claude lo consulte constantemente para verificar si ha terminado.

Este canal en sí mismo no es una cola de mensajes confiable. Los mensajes duplicados estarán sujetos a limitación de velocidad, y el mismo contenido dentro de un breve período puede ser descartado; los mensajes ya aceptados pero aún no leídos por Claude se conservarán hasta un máximo de 50 por sesión, mientras que los mensajes en estado Hold utilizan otro búfer, con un límite máximo de 100.

Por lo tanto, es más adecuado para enviar cambios de estado, resultados de tareas y notificaciones de colaboración. Los hechos que deben conservarse a largo plazo aún deben registrarse en Git, archivos, bases de datos u otros sistemas persistentes.

Después de que el mensaje ingrese al Runtime, aún no puede convertirse directamente en una acción de ejecución, ya que el receptor debe primero determinar: ¿qué nivel de permisos tiene el contenido enviado por otro Claude?

04 How are permissions inherited?

Claude Code distingue claramente el mensaje del usuario y el mensaje de la sesión entre pares.

El contenido enviado por otra sesión no se considerará autorización del usuario, por lo tanto, no puede aprobar el Permission Prompt en nombre del usuario ni solicitar mediante mensaje que el receptor modifique la Configuración de Permiso, CLAUDE.md u otra configuración. Incluso si el mensaje contiene un Comando de Código de Claude, se tratará únicamente como texto normal.

Si la sesión A solicita a la sesión B que elimine un archivo y esta operación requiere autorización del usuario en la sesión B, entonces la solicitud de permiso original aún aparecerá.

Claude Code también limita otro método de elusión de permisos: si una operación ya ha sido rechazada por el Sistema de Permisos en la sesión actual, Claude no debería solicitar que otra sesión la realice en su lugar.

De lo contrario, si solo algunos sessions tienen permisos diferentes, un session con permisos bajos puede seguir transfiriendo operaciones que no puede realizar a un session con permisos más altos, lo que hace que el límite de permisos original se vuelva ineficaz.

Además de los permisos de ejecución, el mensaje en sí tiene un control entrante adicional. El receptor puede configurar los mensajes entre sesiones como accept、hold o refuse: entregarlos directamente a Claude, mantenerlos temporalmente a la espera de confirmación adicional, o descartarlos directamente.

Si el usuario no configura explícitamente las reglas, Claude Code también considerará el Permission Mode actual del remitente y del destinatario. Una sesión que pueda omitir el Permission Prompt normal no se considerará una fuente de mensaje idéntica a una sesión normal; cuando los permisos del destinatario son más altos, los mensajes externos también pueden entrar primero en Hold.

Aquí hay en realidad dos evaluaciones: primero se determina si el mensaje puede ingresar a Claude, y luego se determina si el acción que Claude prepara para ejecutar según este mensaje tiene permiso.

Hasta este punto, se ha completado la ruta completa de un mensaje Cross-session: desde la generación del mensaje, la detección del destinatario, la entrega hasta que el Runtime lo lee y pasa por el control de permisos del extremo receptor.

Capa de coordinación entre sesiones 05

Colocar esta ruta de nuevo dentro de las capacidades actuales de Claude Code hace más clara la posición del mensajería entre sesiones.

Resume Session se utiliza para continuar la conversación y el contexto originales, Agent Teams se utiliza para crear y gestionar un grupo de agentes colaborativos, Worktree se encarga de aislar los cambios de código entre diferentes sesiones, y Remote Control resuelve el problema de continuar controlando la sesión desde otros dispositivos.

Cross-session messaging maneja otro caso: varios Session que originalmente funcionan de forma independiente, y cómo transmitir la información necesaria entre ellos una vez que surgen dependencias durante la tarea.

Anteriormente, abrir múltiples sesiones de Claude Code resolvía principalmente problemas de paralelismo, pero los desarrolladores aún tenían que monitorear el progreso de cada terminal y transmitir repetidamente el estado de las tareas entre personas y sesiones. Ahora, información como cambios en la interfaz, resultados de pruebas y finalización de migraciones se envía directamente a las sesiones afectadas.

Cross-session messaging no combina múltiples Claude en un solo Agente, sino que añade una capa de capacidad de comunicación fuera del contexto, directorio de trabajo y límites de permisos originales.

Visto en el contexto de un proyecto más amplio, este diseño ofrece otra aproximación multi-Agente: diferentes Agentes no necesitan compartir un Contexto cada vez más grande, sino que pueden coordinarse a través de interfaces de comunicación bien definidas. Una vez separadas la tarea, el estado y los permisos, el sistema se vuelve más fácil de escalar.

A medida que la cantidad de Agentes sigue aumentando, la pregunta también pasará de "¿cuánto puede hacer un solo Agente?" a "¿pueden estos Agentes intercambiar estados, manejar dependencias y completar transferencias de manera estable entre sí?".

Aunque el mensajería entre sesiones solo aborda una parte, ya ha permitido que el enfoque de múltiples sesiones de Claude Code comience a adquirir una estructura de ingeniería más completa. Quizás en el futuro, este mecanismo de comunicación entre sesiones dentro de una red local evolucione hacia un protocolo de comunicación Agente-a-Agente entre máquinas y ecosistemas distintos, y en ese momento, esta breve conversación entre dos instancias de Claude hoy sea un paso clave en la formación de una fábrica de software altamente automatizada.