Claude Code: cross-session messaging, agentes que se hablan

Si tienes dos terminales abiertos con Claude Code trabajando en cosas distintas del mismo repo, ya viviste la escena: una sesión descubre que cambió la firma de una función, la otra se sigue rompiendo contra esa firma, y tú eres el humano-in-the-loop que tiene que copiar el mensaje entre ventanas. Anthropic acaba de cerrar ese loop con cross-session messaging, una feature nueva que requiere Claude Code v2.1.224 o superior y ya está documentada oficialmente. La idea suena simple pero cambia bastante cómo se piensa un workflow multi-agente.

La documentación oficial está en Cross-session messaging y la noticia circuló el 9 de agosto por Hacker News. A primera vista parece "otro mensajito más entre agentes", pero si te sentaste a pelearte con workflows paralelos como los que cubrimos en Stacked PRs en GitHub o en Permission fatigue en coding agents, verás que esta era la pieza que faltaba.

Qué es cross-session messaging, en una línea

Es la capacidad de que una sesión de Claude Code le mande un mensaje a otra sesión — local o remota — usando dos herramientas internas: ListAgents para descubrir qué sesiones existen, y SendMessage para entregarles texto. Tú nunca llamas a esas herramientas a mano: Claude las invoca cuando ve la necesidad, o cuando se lo pides explícitamente.

El detalle clave: un mensaje es solo texto, no es historial de conversación ni archivos. Si quieres mover toda una conversación y su contexto a otra sesión, lo que corresponde es resumir la sesión, no mandarle un mensaje.

Esto importa porque separa dos cosas que los vendors mezclan todo el tiempo: "pasarle data" y "transferir el control". Cross-session messaging es data. Para el resto, Claude Code ya tiene primitivas dedicadas.

Cuándo lo vas a usar (los 4 casos oficiales)

La documentación lista cuatro casos canónicos. Vale la pena mirarlos porque cada uno ataca un dolor concreto que ya aparece en equipos que corren agentes en paralelo:

Handover de un hallazgo. Una sesión descubre un breaking change o toma una decisión arquitectónica. En vez de que tú abras la otra terminal y se lo expliques, Claude le manda un resumen a la sesión afectada. Es el caso clásico de los stacked PRs: la PR #2 rompe el contrato que la PR #1 asumía, y la sesión que trabaja en #2 le avisa a la sesión de #1 antes de mergear.

Coordinación entre worktrees. Si tienes varias sesiones trabajando en distintos worktrees del mismo repo, una puede avisarle a las demás qué cambió. Aquí se conecta con el flujo que cubrimos en Stacked PRs: dividir un cambio grande en PRs pequeños requiere coordinación, y hasta ahora esa coordinación la hacías tú a mano.

Status de tareas largas. Migraciones, test suites, benchmarks — cosas que tardan. La sesión que está corriendo la migración puede reportar de vuelta a la sesión que estás mirando, o tú mismo preguntarle desde otra terminal. Esto reduce la fricción del "voy a comprobar si terminó" cada cinco minutos.

Respuesta cross-machine. Si una sesión en tu Mac le manda un mensaje a una sesión en tu servidor (o viceversa), Claude puede responder, pero solo responder. No puede iniciar el intercambio del lado remoto. La razón es de seguridad y vale la pena tenerla clara: si cualquier sesión pudiera mandar mensajes a cualquier otra en cualquier máquina, sería un vector de exfiltración gratuito.

Cómo funciona por abajo (sin el marketing)

Tres puntos técnicos que la doc deja claros y que cambian tu modelo mental:

Entrega no-intrusiva. El Claude receptor lee el mensaje entre llamadas a tools durante un turno activo. Una tool que ya está corriendo no se interrumpe. Si la sesión está idle, Claude Code arranca un turno nuevo con el mensaje. Esto significa que el receptor no queda en un estado inconsistente a mitad de operación — patrón similar al de los canales push que también salieron recientemente, pero en el lado inter-sesión.

Tres resultados posibles por mensaje. Cada mensaje que llega se evalúa contra los inbound controls del receptor. El resultado es uno de tres:

• Delivered — pasa al Claude receptor.
• Held — se aparta sin entregar. Solo llega si tú lo liberas.
• Rejected — se descarta por alguna regla (por ejemplo, el receptor está en modo solo-lectura, o el origen no está en la allowlist).

Es el equivalente inter-sesión de los tres botones Approve / Deny / Always del prompt de permisos que cubrimos en Permission fatigue. Y aquí es donde está la decisión de diseño interesante: Anthropic no eligió "entregar siempre y dejar que el humano audite después". Eligió controles granulares por sesión, lo cual es la respuesta directa a los datos de Scale X sobre aprobar 64.7% de comandos maliciosos por cansancio.

Lectura crítica: cross-session messaging te ahorra el copy-paste entre terminales, pero te introduce una superficie de confianza nueva: ahora una sesión puede ser engañada por otra. Si tu sesión de testing le hace caso ciegamente a lo que le manda la sesión que trabaja con código generado por un atacante (como en el caso de OpenAI y Hugging Face que cubrimos en el agente de OpenAI que hackeó a Hugging Face), el canal se vuelve un vector. La feature viene con knobs para mitigar esto, no los dejes en default.

Mensaje ≠ historial. Ya lo dije arriba pero lo repito porque es donde la gente se confunde: si quieres que otra sesión vea el contexto completo, tienes que usar resume, no messaging. El canal de messaging es para hallazgos discretos, no para transferir estado.

Configuración: lo que deberías tocar hoy

La feature está activa por default en sesiones que cumplen los requisitos (macOS o Linux, Claude Code v2.1.224+, provider compatible). Pero hay tres perillas que conviene revisar antes de empezar a usarla en serio:

~/.claude/inbound_controls.json — define quién puede mandarte mensajes. Por default es permisivo dentro de la misma máquina. Si trabajas en una máquina compartida o quieres que solo ciertas sesiones de tu propiedad puedan mandarte cosas, edita esta allowlist. El paralelo con package.json post-mortem del incidente OpenAI es directo: si tu sesión de IA puede recibir instrucciones de cualquier origen sin validar, ya tienes un agujero.

/settings dentro de Claude Code tiene la opción cross_session_messaging: approve_required_for_remote. Esto te pone un prompt de aprobación para mensajes que vienen de otra máquina. El costo es un click extra. El beneficio es que ningún proceso headless en tu server te puede mandar comandos sin que tú los veas.

Worktrees. Para el caso de coordinación entre worktrees que mencioné arriba, conviene tener un worktree por sesión y darle a cada sesión un nombre memorable (con --name). Así cuando una sesión hace ListAgents, el resultado es legible y no una sopa de UUIDs.

Cuándo NO usar cross-session messaging

La doc oficial es bastante clara al respecto y vale la pena citarla textualmente, porque la tentación va a ser usarlo para todo:

Use messaging between independent sessions that you start and steer yourself. Para coordinar un equipo de sesiones que Claude spawnea y supervisa, usa agent teams. Para mirar y steerear muchas sesiones desde un solo lugar, agent view. Para controlarlas desde el móvil o desde otro dispositivo, Remote Control. Para pushear eventos externos (CI results, chat messages), channels.