Mensajería entre sesiones en Claude Code

Desde la v2.1.224, cada sesión interactiva de Claude Code en una Mac o en una máquina Linux enlaza un socket Unix apenas arranca (el mío vive en /tmp/cc-socks/38590.sock, con permisos exclusivos del propietario), y cualquier otra sesión que tengas abierta puede dejarle ahí un mensaje de texto.¹ La función se apoya en dos herramientas: ListAgents descubre cuáles de tus sesiones son alcanzables, y SendMessage entrega el mensaje a una de ellas por nombre.² No hay nada que activar ni que configurar: si ambas sesiones están en la v2.1.224 o posterior en la misma computadora, ya pueden hablar entre sí.

Resumen

Las sesiones de Claude Code ahora pueden enviarse mensajes: dentro de una misma computadora, por sockets locales que jamás pasan por los servidores de Anthropic, y entre computadoras distintas a través de Remote Control —solo como respuesta cuando se lanzó, hasta que la v2.1.225 agregó la posibilidad de iniciar esas conversaciones por nombre.¹⁵ Un mensaje es texto plano y nada más: nunca historial de conversación, ni archivos, ni permisos. Y la sesión receptora lo trata como entrada, no como autoridad: no puede aprobar solicitudes, ni cambiar la configuración, ni ejecutar comandos.¹ La función convierte una flota de terminales independientes en algo más parecido a un equipo, y sus mejores usos son justamente esos mensajes de coordinación que antes acarreabas a mano: «terminó la migración», «renombré esa columna», «ya es seguro hacer rebase sobre main». La trampa más filosa es la ausencia silenciosa: cualquiera de cuatro variables de entorno de privacidad, sin relación entre sí, desactiva la función sin avisar.³

Qué se lanzó

La v2.1.224 sumó SendMessage entre sesiones con descubrimiento vía ListAgents en macOS y Linux; la v2.1.225 lo extendió para que una sesión también pueda iniciar una conversación con tus sesiones de Remote Control en otras computadoras, cuando antes solo podía responder.⁴⁵

Hay tres superficies donde se ve la maquinaria:

• /list-agents (con el alias /peers) enumera todas las sesiones que Claude puede alcanzar: subagentes dentro de la sesión actual, tus otras sesiones locales —incluidas las que corren en segundo plano— y, mientras Remote Control esté conectado, tus sesiones en otras computadoras y en Claude Code en la web.¹
• /status muestra una fila Peer address con el socket de entrada de la propia sesión, con el prefijo uds:.¹
• CLAUDE_CODE_MESSAGING_SOCKET se exporta a cada gancho y a cada comando de Bash, y contiene la ruta del socket de la propia sesión.⁶ Más abajo explico por qué eso importa.

Verificado en mi propia computadora: una sesión con la v2.1.226 enumera otras dos sesiones pares, con su estado («busy») y su antigüedad, y el archivo del socket lleva permisos srw-------, es decir, lectura y escritura únicamente para mi usuario, que es el límite real en computadoras compartidas.¹

Las sesiones responden a nombres. Puedes asignar uno con /rename o con la opción --name; si no, Claude Code deriva uno del directorio de trabajo, del estilo myapp-3f.¹ Cuando dos sesiones chocan con el mismo nombre, el listado las distingue por directorio de trabajo y por un identificador corto.¹

Lo interesante está en el modelo de confianza

El diseño de Anthropic responde a una pregunta que la mayoría de los sistemas multiagente resuelve mal: ¿cuánto vale un mensaje que viene de otro agente? Aquí la respuesta es precisa: un mensaje es información, nunca autoridad.¹

Cuando la sesión A le escribe a la sesión B, cuatro reglas delimitan lo que llega:¹

1. No puede aprobar nada. Una solicitud de permiso pendiente en B ignora cualquier cosa que diga A. Las solicitudes las respondes solo tú.
2. No puede cambiar la configuración. El Claude receptor recibe la instrucción explícita de no alterar jamás los ajustes de permisos, CLAUDE.md ni ninguna otra configuración porque otra sesión se lo haya pedido.
3. Los comandos llegan como texto. Un /compact en el cuerpo del mensaje son unos cuantos caracteres de prosa, nunca un comando ejecutado.
4. Las solicitudes de permiso siguen apareciendo. Si actuar sobre el mensaje requiere un permiso que B no tiene, verás la misma solicitud que para cualquier otra tarea.

La entrega entrante tiene su propia puerta. Cada mensaje que llega termina en uno de tres resultados —entregado, retenido a la espera de tu aprobación, o rechazado—, y eso lo controla el ajuste crossSessionInbound (accept, hold, refuse).¹ Si no configuras nada, Claude Code decide mensaje por mensaje según los modos de permisos de ambas sesiones, y la lógica por defecto es elegante: las sesiones que se saltan las solicitudes de permiso forman una clase, y todas las demás forman la otra. Una sesión que pide permisos recibe mensajes sin fricción, pero retiene todo lo que llega desde una sesión que se los salta; una sesión que se salta los permisos retiene todo salvo los mensajes que vienen de otras sesiones igualmente permisivas.¹ La asimetría es deliberada: un mensaje no debe viajar montado en la autoridad de una sesión permisiva, un principio que la v2.1.224 aplica a la entrada después de que la v2.1.222 lo aplicara a la salida en modo auto, donde el clasificador de permisos revisa cada envío antes del despacho.⁷

Los mensajes retenidos abren un diálogo de aprobación que muestra remitente y vista previa; los diálogos sin respuesta expiran a los cinco minutos (ajustable con dialogExpiry) y el mensaje se descarta.¹ Como máximo pueden quedar 100 mensajes retenidos a la vez.¹ Otros dos controles cierran todavía más el cerco: isolatePeerMachines: true exige tu aprobación explícita antes de que cualquier mensaje salga de la computadora, incluso en modo bypassPermissions, y un true en cualquier ámbito de configuración gana, de modo que un archivo de proyecto versionado puede endurecerlo pero jamás aflojarlo.¹ Las organizaciones pueden desactivar la función por completo con reglas de denegación sobre SendMessage y ListAgents más crossSessionInbound: "refuse" en la configuración administrada.¹

Cómo viajan los mensajes

Dónde corre la otra sesión determina tanto el transporte como lo que puedes enviar:¹

Vale la pena señalar una contradicción en la documentación: al momento de escribir esto, la página de mensajería entre sesiones de Anthropic sigue describiendo toda la mensajería entre computadoras como exclusivamente de respuesta, mientras que las notas de la v2.1.225 dicen que SendMessage «ahora puede iniciar una conversación por nombre con tus sesiones de Remote Control en otras computadoras». Las notas de versión son más recientes; la página de documentación viene rezagada.¹⁵

La regla de «misma computadora» es en realidad una regla de visibilidad del sistema de archivos: las sesiones se registran en archivos en disco, así que dos sesiones se alcanzan solo si ven los mismos archivos. Una sesión dentro de un contenedor y otra en el host no pueden hablarse; dos sesiones dentro del mismo contenedor, sí.¹

La entrega respeta el ritmo de la sesión receptora: el mensaje se lee entre llamadas a herramientas durante un turno activo, sin interrumpir nunca una herramienta en ejecución, y arranca un turno nuevo cuando la sesión está inactiva.¹ Los mensajes entregados cuentan para el uso igual que cualquier instrucción que escribas tú.¹

Cinco patrones que vale la pena construir

1. Coordinación entre worktrees. El caso evidente, y el que la documentación ilustra con su propio ejemplo: sesiones que trabajan en el mismo repositorio en worktrees separados se avisan entre sí qué acaba de entrar.¹ «Terminó la migración del esquema: la columna nueva es tenant_id, y ya es seguro hacer rebase sobre main» es el mensaje de ejemplo de la propia documentación, esa clase de aviso que de otro modo exige que te des cuenta, cambies de terminal y lo vuelvas a escribir. Si en vez de worktrees varias sesiones comparten un mismo checkout, el mensaje de coordinación vale todavía más: un «estoy por hacer commit de content/guides/, no lo prepares» evita la colisión clásica del árbol compartido, donde una sesión hace commit del trabajo a medio terminar de otra.

2. Vigía y trabajador. Deja corriendo una sesión que vigile un despliegue, una suite de pruebas o un log, y haz que le escriba a la sesión responsable de las correcciones en cuanto algo se rompa. La sesión receptora recibe el hallazgo como contexto, no como orden; sigue decidiendo por su cuenta, bajo sus propios permisos, qué hacer con él. Combina esto con sesiones en segundo plano y los ganchos de notificación y obtienes una cadena de escalamiento que llega a un humano solo cuando corresponde.

3. El proceso largo que reporta. Lanza una migración o una corrida larga de pruebas en una sesión y haz que te reporte a la sesión que de verdad estás mirando.¹ El estado deja de vivir en una terminal que olvidaste. También funciona al revés, preguntando desde el lado que observa: «Pregúntale a la sesión de mi otra terminal si terminó la migración» es una instrucción común y corriente, y Claude se encarga solo del descubrimiento, del direccionamiento y de la redacción.¹

4. Flotas de trabajadores desatendidos. Las sesiones sin interfaz lanzadas con claude -p también enlazan sockets de entrada, así que un trabajador -p de larga duración puede recibir mensajes y aparece en los listados.⁸ El detalle: una sesión -p no puede mostrar el diálogo de aprobación, así que un mensaje retenido se queda retenido, sin camino a la entrega salvo un cambio de configuración o de modo (la v2.1.225 también corrigió que esos mensajes quedaran estacionados sin aviso ni expiración). Para correr un trabajador que acepte mensajes de forma desatendida, inícialo con crossSessionInbound: "accept" en su valor de --settings: un permiso otorgado por trabajador, en vez de un accept en la configuración de usuario que se aplicaría a todas las sesiones que ejecutes.⁸ Las sesiones en modo bare se saltan el socket por completo y quedan inalcanzables.⁸

5. Bandejas de entrada por script. La joya discreta: como CLAUDE_CODE_MESSAGING_SOCKET se exporta a los ganchos y a los comandos de Bash, un script puede escribir en la bandeja de entrada de la propia sesión.⁶ Claude Code verifica los mensajes de procesos hijos propios: un gancho o un comando que le escribe de vuelta a su propia sesión entrega sin ceremonia cuando no hay un crossSessionInbound explícito que aplique.¹ Una tarea nocturna, un gancho de git, un envoltorio de CI: cualquier cosa capaz de escribir en un socket Unix puede ahora inyectar una línea de contexto en la sesión que la lanzó. En Linux la verificación funciona incluso después de que el proceso emisor haya terminado; en macOS, solo mientras sigue vivo; y en un contenedor donde Claude Code es el PID 1, la verificación falla y el mensaje cae de vuelta en las reglas normales de entrada.¹ Los comandos que corren en el entorno aislado necesitan que el socket esté habilitado mediante sandbox.network.allowUnixSockets.¹

Lo que se niega a ser

Los límites son decisiones de diseño, y respetarlos te ahorra construir lo que no debías.

No es un canal de aprobación. Todo el modelo de confianza existe para impedir que una sesión autorice las acciones de otra. Cualquier flujo de trabajo con la forma «la sesión A aprueba, la sesión B ejecuta» está descartado explícitamente por diseño. La autoridad pasa siempre por el humano.¹

No es transferencia de contexto. Un mensaje es texto que un Claude le escribe a otro, nunca historial de conversación ni archivos. La documentación de Anthropic lo dice sin rodeos: para mover una conversación, reanuda la sesión en su lugar.¹ Resume; no vuelques todo.

No son equipos de agentes. Sesiones independientes que se escriben entre sí es el caso de igual a igual. Un equipo coordinado que Claude crea y supervisa —con mensajes de protocolo estructurados, una lista de integrantes y estado de tareas compartido— es la función de equipos de agentes, y los mensajes estructurados de equipo se quedan deliberadamente dentro del equipo.¹ Si te descubres diseñando un protocolo de mensajes encima del texto entre sesiones, lo que quieres son equipos de agentes.

No es un bucle de chat. Claude Code limita la frecuencia de mensajes repetidos por remitente, descarta repeticiones idénticas que llegan en una ventana corta y limita a 50 por sesión los mensajes aceptados sin leer, de modo que un bucle de mensajes entre dos sesiones se extingue solo, por diseño.¹ Construye intercambios de pregunta y respuesta, no conversaciones.

Las trampas

Las variables de privacidad la desactivan en silencio. La mensajería entre sesiones depende de la evaluación de feature flags, y cualquiera de CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK o DISABLE_GROWTHBOOK puede apagar esa evaluación y llevarse la mensajería por delante, sin decir nada.³ El diagnóstico es /list-agents: si el comando ni siquiera se reconoce, la sesión no tiene la función; si funciona pero un envío nunca llega, la causa es más acotada: una regla de denegación, los controles de entrada del receptor, o un destino en otra computadora que solo acepta respuestas.¹

Huecos de plataforma y de proveedor. No hay soporte nativo de Windows (Linux dentro de WSL 2 sí funciona). No está disponible en Amazon Bedrock, en Claude Platform sobre AWS, en Agent Platform de Google Cloud ni en Microsoft Foundry.¹

El caso límite de la respuesta sin retorno. Una respuesta a una sesión en otra computadora, enviada mientras la sesión que responde no está conectada a Remote Control, igual llega, pero sin dirección de retorno, así que el receptor no puede contestar. A Claude se le avisa de esto al enviar, y las correcciones de la v2.1.225 afinaron el direccionamiento para que un destinatario confirmado en otra computadora nunca se sustituya en silencio por una sesión local del mismo nombre.⁵

Retenciones en modo sin interfaz. El trabajador -p que misteriosamente ignora los mensajes casi siempre es un problema de mensajes retenidos: sin diálogo, no hay entrega. Configura crossSessionInbound: "accept" en los trabajadores que deban escuchar.⁸

Puntos clave

Para quienes usan Claude Code a diario: - Ejecuta /list-agents una vez para ver qué alcanzan ya tus sesiones; ponles nombre a las importantes con /rename para que los mensajes se dirijan sin ambigüedad. - Pide los mensajes en lenguaje llano («dile a la sesión que está trabajando en pagos lo que cambiamos») y deja que Claude redacte el mensaje.¹

Para quienes construyen automatizaciones: - Escribe en las sesiones desde ganchos y scripts mediante CLAUDE_CODE_MESSAGING_SOCKET; en Linux, los mensajes de procesos hijos propios se entregan sin fricción de aprobación.¹⁶ - Dale a los trabajadores -p desatendidos un crossSessionInbound: "accept" en su propio --settings, no de forma global.⁸

Para equipos y auditores de seguridad: - La función viene con los valores por defecto correctos: los mensajes no cargan autoridad, las sesiones permisivas quedan en cuarentena de fábrica, e isolatePeerMachines más las reglas de denegación en configuración administrada te dan interruptores de apagado por computadora y para toda la organización.¹ - Audita las cuatro variables de entorno de privacidad antes de concluir que la mensajería está rota, y ten presente que una sesión que rechaza mensajes no muestra ninguna diferencia visible ante sus pares.¹

Referencias