Mensajes entre sesiones de Claude Code: deja de copiar y pegar entre terminales

TL;DR Desde la v2.1.224, una sesión de Claude Code le puede escribir a otra sin que actives nada, y entre sesiones de la misma máquina el texto nunca sale de tu disco. Se lo pides en lenguaje normal ("cuéntale a la sesión del repo X que la migración ya está") y Claude localiza el destino y envía. Comprueba antes con /list-agents que la ve: si no sale en esa lista, no hay nada que enviar. Y si la sesión que recibe corre en bypassPermissions y la que manda no, el mensaje se queda retenido esperando tu aprobación en la otra ventana.

Actualización, 1 de noviembre de 2026: La mensajería entre sesiones ya funciona también en Windows nativo desde la v2.1.239: SendMessage y ListAgents hacen lo mismo que en macOS y Linux.

Actualización, 31 de octubre de 2026: Un mensaje que la sesión de destino rechaza (por ejemplo, con crossSessionInbound en refuse) ya no parece un envío correcto: al que envía le llega "refused". Y desde la v2.1.248 la mensajería entre sesiones de la misma máquina funciona también en Bedrock, Claude Platform on AWS, Google Cloud Agent Platform y Microsoft Foundry, y con la telemetría apagada.

Dos terminales abiertas sobre el mismo repositorio. En una acabas de renombrar una columna de la base de datos. En la otra, Claude lleva veinte minutos construyendo encima del nombre viejo y no tiene forma de saberlo. La manera de avisar siempre ha sido la misma: copias el resumen de una ventana, cambias de pestaña, lo pegas. Tú haciendo de cable entre dos Claudes.

Desde la versión 2.1.224 ese cable ya existe. Una sesión puede entregarle un texto a otra, y no hay nada que activar: si tu sesión cumple los requisitos, está encendido.

Primero, comprueba que se ven

/list-agents

En mi máquina, con una sesión de fondo trabajando en otro proyecto:

Other Claude sessions (1):
  [idle]  ·  wmedia  ·  /Users/juan.nunez/Herd/wmedia  ·  started 20h ago

Cada fila es una sesión que Claude puede alcanzar, y el nombre de la fila es la dirección a la que escribe. El comando tiene alias /peers. El directorio de trabajo aparece por un motivo práctico: dos sesiones pueden acabar con el mismo nombre, y esa columna es lo que las distingue. El nombre sale de /rename o del flag --name, y si no pones ninguno, Claude Code lo deriva de la carpeta (myapp-3f).

La lista incluye tus subagentes, tus otras sesiones locales (incluidas las de Agent View) y, si tienes Remote Control conectado, tus sesiones en otras máquinas y en la web, etiquetadas como Remote Control.

Si /list-agents no te lo reconoce, no es que falle el envío: es que la sesión no tiene la función. Repasa los requisitos del final antes de seguir.

Cómo se lo pides

No llamas tú a ninguna herramienta. Le dices a Claude qué quieres que sepa la otra sesión:

Pregúntale a la sesión de la otra terminal si ha terminado la migración

Explícale a la sesión que está con la API de pagos lo que acabamos de cambiar

El texto que viaja lo redacta Claude, no tú. Por debajo usa dos herramientas: ListAgents para descubrir a quién puede alcanzar y SendMessage para entregar el mensaje a uno de ellos por su nombre. Y no hace falta que se lo pidas: Claude puede mandar un mensaje por iniciativa propia cuando ve que un cambio suyo afecta a lo que otra sesión está construyendo.

Lo que llega al otro lado es texto plano y nada más:

Schema migration finished: the new column is tenant_id, and rebasing on main is safe now.

Ni tu historial, ni tus archivos, ni el contexto de la conversación. Si lo que quieres es mover la conversación entera a otro terminal, eso es /resume (o claude --resume desde otra terminal), no esto.

En la sesión que recibe, el mensaje aparece con el nombre de quien lo envía. Si Claude está a mitad de turno se encola y lo lee entre llamadas a herramientas, sin cortar nada; si estaba parada, arranca un turno nuevo con él. Una vez leído se colapsa a una línea Message from que Ctrl+O vuelve a desplegar. Y cuenta como consumo igual que un prompt que escribas tú.

Lo que un mensaje no puede hacer

Claude Code le dice a la sesión que recibe que eso viene de otra sesión, no de ti, y con eso se cae un montón de superficie de ataque:

Los permisos siguen siendo de cada sesión. Claude tiene instrucción de no pedirle a otra sesión algo que en la suya está denegado o bloqueado, y de devolvértelo a ti en su lugar. Si nunca has separado modos, reglas y permisos, los tres conceptos están aquí.

Cuándo el mensaje no llega

Esta es la parte que decide si esto te sirve o te frustra. Entre dos sesiones interactivas normales con la configuración por defecto, el mensaje se entrega. Fuera de ese caso hay tres finales posibles:

• Entregado: Claude lo lee.
• Retenido: Claude Code lo aparta sin entregarlo y te enseña un aviso. Solo llega si tú lo apruebas o si un cambio posterior de modo o de ajustes lo permite.
• Rechazado: se descarta sin entregar nada.

Cuando no has configurado nada, la decisión se toma comparando los modos de permisos de las dos sesiones. Claude Code agrupa por un lado las sesiones que se saltan los prompts de permisos y por otro todas las demás (auto, acceptEdits y dontAsk cuentan como que preguntan; plan mode cuenta como que se salta, en sesiones donde bypass está disponible):

Traducido: la sesión más peligrosa, la que corre sin frenos, es precisamente la que se queda sin recibir. Si mandas algo desde una terminal normal a una que dejaste en bypassPermissions, el mensaje no llega hasta que vas a esa ventana y lo apruebas en un diálogo que caduca a los cinco minutos (dialogExpiry, configurable). Pasado el plazo, el mensaje se descarta.

Cuando quien envía está en la misma máquina, recibe aviso de lo que ha pasado: uno cuando el mensaje queda retenido y otro después con el desenlace (entregado, denegado o caducado). Y si la sesión que recibe lo rechaza nada más llegar (por ejemplo, porque tiene crossSessionInbound en refuse), al que envía le llega "refused", no un envío que parece correcto.

Y el caso peor, el que aparece en cuanto automatizas algo: una sesión claude -p no puede enseñar ese diálogo. Un mensaje retenido ahí se queda retenido para siempre. Si quieres que un worker desatendido acepte mensajes, arráncalo con crossSessionInbound en accept dentro de su --settings.

Y su gemelo, por si alguna vez te falta una sesión en la lista: una sesión -p normal sí abre su socket y aparece en /list-agents, pero una arrancada en bare mode no lo abre, así que ni recibe ni sale listada.

{
  "crossSessionInbound": "accept"
}

Los tres valores son accept (entrega), hold (avisa y no entrega) y refuse (descarta). Claude Code lee primero los managed settings, luego el flag --settings y luego tus settings de usuario, y aplica el primer valor que encuentre. Un valor en settings de proyecto o local solo se aplica si es más estricto en la escala accept < hold < refuse que lo que digan esas fuentes. Es decir: un archivo del repositorio puede endurecer la política, nunca aflojarla.

Dos límites más, por si algún día ves mensajes desaparecer: se retienen como mucho 100 y a partir de ahí caen los más antiguos, y en la cola de entrega caben 50 esperando a que Claude los lea. Los repetidos se limitan por emisor y los idénticos seguidos se descartan, que es lo que hace que un bucle de dos sesiones respondiéndose se apague solo.

Fuera de tu máquina, solo puedes responder

La entrega local funciona porque cada sesión se registra en archivos en disco y abre ahí su socket de entrada. De ahí sale una consecuencia práctica: dos sesiones solo se alcanzan si ven los mismos archivos. Un contenedor tiene su propio sistema de archivos, así que una sesión dentro y otra en el host no se ven. Dos sesiones dentro del mismo contenedor sí.

Si quieres que ningún mensaje salga de la máquina sin tu visto bueno:

{
  "isolatePeerMachines": true
}

Con eso, hasta en bypassPermissions te pide aprobación antes de que una respuesta cruce fuera. Un true desde cualquier ámbito de settings manda, así que un archivo del repositorio puede encender la exigencia pero no apagarla.

Dónde encaja esto

La confusión fácil es con Agent Teams, y la línea es limpia: un team son Claudes que Claude lanza y supervisa, con su propio protocolo de mensajes que no sale del equipo. Esto de aquí son sesiones que abres y diriges tú, que no se conocían entre sí, y lo único que se pasan es texto plano.

Apagarlo

Recibir y enviar son controles separados:

• Dejar de recibir: crossSessionInbound en refuse.
• Dejar de enviar y de listar: reglas deny con SendMessage y ListAgents. Las dos van con el nombre pelado de la herramienta, sin especificador.

{
  "permissions": {
    "deny": ["SendMessage", "ListAgents"]
  },
  "crossSessionInbound": "refuse"
}

Ojo con el efecto colateral: denegar SendMessage también te quita los mensajes a subagentes y a compañeros de agent team, porque es la misma herramienta.

Y hay un caso donde esas dos herramientas se separan solas, sin que tú deniegues nada: un subagente que corre en segundo plano conserva SendMessage pero pierde ListAgents, así que puede enviar sin poder descubrir a quién. Lo cuenta el recorte de herramientas del segundo plano.

Referencia

Esa última fila es la que más cuesta diagnosticar. Si eres de los que apaga la telemetría por defecto, tus sesiones locales salen en /list-agents como siempre; si te falta una de otra máquina o de la web, lo primero es comprobar que Remote Control sigue disponible en tu sesión. Esas variables pueden venir de tu shell, del bloque env de un settings o de los managed settings de tu empresa.

Si usas bypass solo para no aprobar cada acción, la guía de permisos ordena alternativas con menos riesgo.

Documentación oficial: Message your other Claude Code sessions