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

Si tenés 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 vos sos el humano-en-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, vas a ver que esta pieza faltante.

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. Vos nunca llamás esas herramientas a mano: Claude las invoca cuando ve la necesidad, o cuando vos se lo pedís explícitamente.

El detalle clave: un mensaje es solo texto, no es historial de conversación ni archivos. Si querés 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 vos 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 labura en #2 le avisa a la sesión de #1 antes de mergear.

Coordinación entre worktrees. Si tenés varias sesiones laburando en distintos worktrees del mismo repo, una puede avisarle a las demás qué cambió. Acá se conecta con el flujo que cubrimos en Stacked PRs: dividir un cambio grande en PRs chicos requiere coordinación, y hasta ahora esa coordinación la hacías vos en el teclado.

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 vos mismo preguntarle desde otra terminal. Esto reduce la fricción del "voy a chequear 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 vos lo liberás.
• 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 acá es donde está la decisión de diseño interesante: Anthropic no eligió "deliverar 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 labura en código generado por un atacante (caso OpenAI/Hugging Face que cubrimos en consolidación de IA agentica), 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 querés que otra sesión vea el contexto completo, tenés 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 trabajás en una máquina compartida o querés que solo ciertas sesiones de tu propiedad puedan mandarte cosas, editá 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 tenés 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 vos 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, usá agent teams. Para mirar y steerear muchas sesiones desde un solo lugar, agent view. Para controlá vos desde el celular o desde otro device, Remote Control. Para pushear eventos externos (CI results, chat messages), channels.

En criollo: messaging es para sesiones independientes. Cada vez que necesites primitivas más estructuradas, hay una feature dedicada. Mezclar canales termina en debugging doloroso, y la doc lo sabe.

Mi take

Cross-session messaging no es la feature que va a aparecer en los benchmarks. No mueve scores, no cambia rankings, no aparece en el changelog de Anthropic con bombo. Pero es exactamente el tipo de plumbing que faltaba para que el multi-agente pase de "demo en Twitter" a "flujo de producción". El combo de worktrees por sesión + messaging entre ellas + remote control desde el celu te permite algo que antes era exclusivo de plataformas con governance pesada tipo Cloudflare OS (que cubrimos acá en su variante navegador agent-first) pero con la diferencia de que lo hacés en tu propio entorno.

Si ya estás quemando tokens en coding agents — y si leíste Tokenpocalypse probablemente lo estés — esta feature es un trade interesante: un poquito más de superficie de ataque a cambio de muchísimo menos context-switching humano. Para equipos chicos laburando en paralelo sobre el mismo repo, es un win claro. Para equipos grandes con sesiones corriendo en infra compartida, activalo con las inbound controls restrictivas y revisalas cada semana.

El cambio de versión mínimo (v2.1.224) ya está en el canal estable, así que no hay excusa. Abrí dos terminales, levantá dos worktrees, y probá mandarle a la otra sesión un "decime el status del refactor de auth/". Es la mejor forma de entender si esta pieza encaja en tu workflow.