Tus sesiones de Claude se pueden mandar mensajes entre ellas

Si trabajas con dos o tres terminales abiertas, ya conoces el ritual: en una cambias algo, te acuerdas de que eso rompe lo que está haciendo la otra, te cambias de ventana y le escribes a mano "oye, cambié el esquema". Eso es la mitad de tu día como mensajero entre dos copias del mismo modelo.

Claude Code ya no lo necesita. Una sesión puede mandarle un mensaje a otra: la primera descubre a las demás, escribe el texto y lo entrega. Tú no invocas nada, solo dices a quién quieres avisarle qué.

La función viene encendida cuando tu instalación cumple los requisitos, así que lo primero no es configurarla: es verificar si ya la tienes. Y lo que hace la diferencia entre un truco y algo que de verdad usas todos los días son dos pasos que casi nadie da: ponerles nombre a las sesiones y escribirles una carta de equipo.

Qué se manda exactamente

Un mensaje es texto plano que un Claude le escribe a otro. Nada más. No viaja tu historial, no viajan tus archivos, no viaja el contexto de la conversación. La sesión que recibe ve el nombre de quien mandó y el texto, y ya.

Esa limitación es lo que hay que entender antes de usarlo. Si lo que quieres es mover una conversación completa a otra terminal, esto no es la herramienta: para eso se retoma la sesión. Los mensajes sirven para hechos cortos y accionables —"la migración terminó, la columna nueva se llama tenant_id"— no para transferir trabajo.

El resto de las reglas van en la misma dirección. Un mensaje de otra sesión no cuenta como tu consentimiento: no puede aprobar un permiso pendiente ni pedirle a la otra sesión que cambie configuración. Un comando dentro del texto llega como texto y no se ejecuta. Y si dos sesiones se ponen a contestarse en círculo, el sistema corta el ciclo solo.

Cómo verificar que ya lo tienes

1. Escribe /list-agents en una sesión. También responde a /peers. Si te lista tus otras sesiones, ya lo tienes y no hay nada que activar.
2. Si el comando no se reconoce, empieza por la versión: claude --version. La mensajería entre sesiones pide una versión reciente de Claude Code.
3. Revisa el sistema operativo. Corre en macOS y en Linux, incluido Linux dentro de WSL 2. En Windows nativo no está.
4. Revisa por dónde te conectas. No está disponible en algunos proveedores en la nube; si tu empresa te conecta a Claude por Bedrock o por una plataforma similar, no la vas a ver.
5. Con /status aparece una fila de dirección de la sesión. Si está, esa sesión tiene su buzón abierto.

Si /list-agents sí funciona pero tu mensaje no llegó, el problema es más chico: puede ser una regla de permisos que quitó las herramientas de mensajería, o el control de entrada de la sesión que recibe, que está reteniendo lo que le mandan.

El paso de nombrarlas

Aquí es donde la mayoría se queda a medias. Si no le pones nombre a una sesión, el sistema le pone uno derivado de la carpeta donde corre, del estilo mi-app-3f. Funciona, pero cuando tienes cuatro terminales en el mismo repositorio, todas se llaman casi igual y tú ya no sabes cuál es cuál.

Nómbralas por función, no por carpeta. Se puede al arrancar, con la bandera --name, o en caliente con el comando /rename.

claude --name migraciones
claude --name api
claude --name reportes

Con nombres así, pedir el mensaje se vuelve una frase normal: "avísale a la sesión de reportes que la columna cambió de nombre". Y en versiones recientes puedes mencionar la sesión con arroba, escribiendo @ y las primeras letras para que aparezca el selector.

Un detalle que ahorra confusiones: si le pones a una sesión un nombre que otra sesión viva ya está usando, el nombre se queda con la que llegó primero y la tuya recibe una variante. Cuando dos sesiones comparten nombre, la lista te muestra en qué carpeta corre cada una para que las distingas.

La carta de equipo

Esta parte no la trae la herramienta y es la que hace que sirva. Sin ella pasa lo mismo que con un equipo humano sin roles: se mandan mensajes de más, se avisan cosas que a nadie le importan, y lo importante no se avisa porque cada quien supuso que el otro ya sabía.

La carta es un archivo corto que vive en el repositorio y que todas las sesiones leen al arrancar, porque va dentro del contexto del proyecto. Define quién es cada sesión, qué le toca avisar y qué no. Este es el formato que uso:

# Carta de equipo — sesiones de este repositorio

## Roles

- migraciones: cambios de esquema y datos. Nadie más toca la base.
- api: endpoints y contratos de respuesta.
- reportes: consultas de lectura y tableros. Solo lee.

## Qué se avisa siempre

1. Cualquier cambio en el esquema de base de datos, con el nombre exacto
   de lo que cambió. Va a api y a reportes.
2. Cualquier cambio en la forma de una respuesta de la API. Va a reportes.
3. Cuando algo queda a medias y otra sesión podría chocar con ese archivo.
4. Cuando termina un proceso largo que alguien más está esperando.

## Qué NO se avisa

- Avances parciales sin consecuencia para nadie más.
- Preguntas de opinión. Esas van al humano, no a otra sesión.
- Nada que requiera aprobar un permiso: un mensaje entre sesiones no
  aprueba nada, así que eso regresa al humano.

## Formato del mensaje

Una oración. Hecho concreto y nombre exacto. Sin contexto de por qué.
Bien: "Migración lista: la columna nueva es tenant_id."
Mal: "Terminé de trabajar en la migración que habíamos platicado."

## Dueño de archivos

Si dos sesiones necesitan el mismo archivo, no se coordinan por mensaje:
se detiene una y lo hace la otra. Los mensajes avisan, no reparten
trabajo simultáneo sobre el mismo archivo.

Los controles que conviene poner antes

Antes de dejar esto suelto en una máquina de trabajo, vale revisar dos ajustes.

• Qué hace una sesión con lo que le llega. Hay un ajuste de entrada con tres valores: aceptar, retener para que tú apruebes, o rechazar sin entregar. En una sesión que corre desatendida, aceptar es lo práctico; en una sesión donde ya bajaste las barreras de permisos, retener es lo prudente.
• Si los mensajes pueden salir de la máquina. Entre sesiones de la misma computadora el mensaje viaja por un canal local y no pasa por servidores. Para alcanzar una sesión en otra máquina tuya o en la nube sí pasa. Hay un ajuste para exigir tu aprobación antes de que cualquier mensaje salga del equipo.

Y si tu organización no quiere nada de esto, se apaga por los dos lados: reglas que nieguen las herramientas de listar y mandar, más el ajuste de entrada en rechazar.

El error que lo vuelve ruido

Usarlo para repartir trabajo. La tentación es armar una fábrica: una sesión que asigna y tres que ejecutan. Para eso hay otras funciones, con lista de tareas compartida y coordinación de verdad. La mensajería entre sesiones es más simple y más útil de lo que parece: sirve para que una sesión no siga trabajando sobre un supuesto que otra acaba de romper.

Empieza con dos sesiones, tres reglas en la carta y una semana de uso. Cuando veas cuáles avisos sí te salvaron y cuáles fueron ruido, ahí creces la carta.

Para seguir: cómo correr agentes en paralelo y el archivo más importante de Claude Code, que es donde va a vivir tu carta de equipo.