Tus sesiones de Claude Code ya se hablan entre sí: mensajería entre sesiones

Sesgo declarado, como siempre: enseño Claude Code a equipos de ingeniería, así que cualquier cosa que cambie cómo coordinas varias sesiones a la vez me toca de lleno. Precisamente por eso esta pieza va de hechos verificables y de qué te toca mirar esta semana, no de vender el cambio como una revolución.

La novedad que abre la semana 32 (3–7 de agosto de 2026) es sencilla de enunciar y fácil de subestimar: tus sesiones de Claude Code pueden ahora mandarse mensajes entre sí. Si hasta ahora tenías dos terminales abiertas y hacías de correo humano entre ellas —"oye, en la otra sesión he cambiado el nombre de esa columna"—, ese trabajo lo puede hacer Claude solo.

Los hechos

Según la documentación oficial de mensajería entre sesiones y el changelog, la versión 2.1.224 introduce la función. Los datos que importan:

• Qué hace. Una de tus sesiones puede entregar un mensaje a otra. Cuando un cambio en una sesión rompe lo que otra está construyendo, Claude puede avisar antes de que lo notes; cuando una sesión resuelve una duda que bloqueaba a otra, puede pasarle la respuesta.
• Qué viaja. Solo texto plano que una instancia de Claude escribe para otra. Nunca tu historial de conversación ni tus archivos. Si lo que quieres es mover todo el contexto, eso sigue siendo retomar la sesión, no un mensaje.
• Cómo funciona por dentro. Claude descubre a qué sesiones llega con la herramienta ListAgents y envía con SendMessage, dirigiendo el mensaje por el nombre de la sesión. Tú no llamas a ninguna de las dos: Claude decide el destinatario y redacta el texto. Para ver qué sesiones tienes al alcance, escribe /list-agents (también /peers).
• Cómo lo ves. El mensaje aparece en la conversación de la sesión que lo recibe. Una vez leído, se colapsa a una línea Message from que despliegas con Ctrl+O.
• Dónde funciona. En macOS y Linux (incluido WSL 2). No hay mensajería entre sesiones en Windows nativo, ni en Amazon Bedrock, Google Cloud's Agent Platform o Microsoft Foundry. Cuando la sesión cumple los requisitos, la función está activa sin nada que activar.

En la misma máquina, el mensaje viaja por un socket por sesión y no pasa por servidores de Anthropic. Para llegar a una sesión en otra de tus máquinas o en Claude Code en la web, sí pasa por servidores de Anthropic, a través de tu conexión de Remote Control.

Qué cambia en tu flujo

Lo interesante no es la mecánica, sino el patrón que desbloquea. Si ya trabajas con varias sesiones sobre el mismo repositorio, antes cada una vivía en su burbuja y la coordinación la ponías tú a mano. Ahora:

• Traspasar un hallazgo. Una sesión descubre un breaking change o toma una decisión y se lo resume a la sesión que trabaja en la zona afectada, sin que se lo vuelvas a explicar allí.
• Coordinar worktrees en paralelo. Cuando varias sesiones tocan el mismo repositorio en worktrees separados, una puede avisar a las demás de qué acaba de aterrizar.
• Pedir estado a trabajo largo. Dejas una migración o una tanda de tests corriendo en una sesión y le pides desde otra que te reporte cuando termine.

Es exactamente la clase de coordinación que trabajamos en el curso de orquestar agentes: cuándo tiene sentido repartir el trabajo entre sesiones, qué información se pasa entre ellas y cómo no acabar con seis terminales que ya no sabes qué probaban. Ojo a un matiz de diseño: la misma herramienta SendMessage sirve para hablar con subagentes dentro de una sesión; lo nuevo aquí es que cruza la frontera entre sesiones independientes.

El detalle que de verdad importa: un mensaje no es un permiso

Aquí está la parte que conviene entender antes de dar acceso a esto en un equipo. Cuando la sesión A escribe a la sesión B, Claude Code le dice a B que el mensaje viene de otra sesión, no de ti, y limita lo que puede provocar:

• No aprueba nada. Un mensaje de otra sesión nunca cuenta como tu consentimiento: no puede responder por ti a una petición de permiso pendiente.
• No cambia configuración. La sesión que recibe tiene instrucción de no tocar permisos, CLAUDE.md ni otra configuración porque otra sesión se lo pida.
• Los comandos no se ejecutan. Un /compact en el texto del mensaje llega como texto plano; Claude Code no lo ejecuta.
• Los permisos siguen disparándose. Si actuar sobre el mensaje requiere un permiso que la sesión receptora no tiene, ves el mismo prompt de siempre.

En otras palabras: la mensajería mueve información, no autoridad. Ese límite es el que hace que la función sea usable en serio y no un agujero por el que una sesión ordene cosas a otra.

Qué te afecta, según quién seas

Si trabajas con una sola sesión. Poco cambia hoy. No rompes nada por ignorarlo, y puedes empezar a apoyarte en ello el día que abras una segunda terminal para una tarea en paralelo.

Si ya orquestas varias sesiones. Es tu novedad de la semana. Prueba a pedir en una sesión "avisa a la sesión que trabaja en la API de pagos de que users.name ahora es users.display_name" y observa cómo llega al otro lado. Gana quien reparte trabajo con criterio, no quien abre sesiones sin control.

Si administras Claude Code para un equipo. Aquí hay decisión de política. La entrada de mensajes se gobierna con crossSessionInbound (accept, hold o refuse); isolatePeerMachines: true exige tu aprobación antes de que cualquier mensaje salga de la máquina; y desde managed settings puedes apagar las dos direcciones a la vez, combinando reglas deny sobre SendMessage y ListAgents con crossSessionInbound: "refuse". Decidir qué permites cruzar entre sesiones —y entre máquinas— es justo el tipo de criterio que trabajamos en el curso de permisos, settings y seguridad.

Qué llevarte

• Mensajería entre sesiones (2.1.224): una sesión puede mandar texto a otra; Claude elige destinatario con ListAgents y envía con SendMessage. Tú no llamas a ninguna de las dos.
• Solo texto, nunca contexto: viaja un mensaje que Claude escribe, no tu historial ni tus archivos. Para mover contexto, retoma la sesión.
• macOS y Linux, activo sin configurar: no hay versión para Windows nativo; míralo con /list-agents (o /peers).
• Un mensaje no es un permiso: no aprueba prompts, no cambia configuración y los comandos en el texto no se ejecutan.
• Controles para equipos: crossSessionInbound, isolatePeerMachines y reglas deny sobre SendMessage/ListAgents en managed settings.

Preguntas rápidas

¿Tengo que activarlo? No. Si la sesión cumple los requisitos (2.1.224+, macOS o Linux), está activo sin nada que tocar. Confírmalo con /list-agents.

¿Se comparte mi conversación con la otra sesión? No. Solo viaja el texto que Claude redacta para el otro lado; nunca tu historial ni tus archivos.

¿Puede otra sesión aprobar acciones o cambiar mi configuración? No. El mensaje llega marcado como de otra sesión, no tuyo: no aprueba permisos ni cambia CLAUDE.md, y cualquier comando en el texto queda como texto.

¿Vais a repartir trabajo entre varias sesiones sin perder el control? Decidir cuándo coordinar sesiones, qué información dejáis cruzar entre ellas y bajo qué política de permisos es exactamente el tipo de criterio que trabajamos en la formación en directo para equipos — sobre vuestro repo y con vuestro flujo real.