Mensajería entre sesiones de Claude Code en un VPS

Qué significa que las sesiones de Claude Code se envíen mensajes entre sí

Dos sesiones de Claude Code pueden enviarse mensajes cuando se ejecutan en la misma máquina y con el mismo usuario del sistema operativo. Un mensaje es un texto sin formato que una sesión de Claude escribe para otra. No incluye el historial de la conversación ni archivos. Claude encuentra la otra sesión con la herramienta ListAgents y entrega el texto con SendMessage, por lo que nunca debe invocar ninguna de las dos herramientas manualmente. Usted indica qué necesita saber la otra sesión y Claude escribe el mensaje.

Esta función se denomina mensajería entre sesiones. En agosto de 2026 requiere Claude Code v2.1.224 o posterior y funciona en macOS y Linux, incluido Linux dentro de WSL 2. No existe compatibilidad nativa con Windows y no está disponible en Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform ni Microsoft Foundry. Cuando una sesión cumple estos requisitos, la mensajería ya está activada y no hay nada que habilitar. El comportamiento descrito a continuación procede de la documentación de Anthropic sobre la mensajería entre sesiones.

Esto resulta útil en un VPS, porque las sesiones permanecen activas el tiempo suficiente para que tenga sentido dirigirse a ellas. En un portátil se cierra la tapa. En un servidor con tmux, una sesión iniciada el lunes puede seguir ejecutándose el jueves y conservar el contexto de un repositorio. Cuando tiene dos sesiones de ese tipo, la forma en que se comunican deja de ser una cuestión teórica. Si todavía no lo ha configurado, empiece por ejecutar Claude Code en un VPS con tmux, donde se explica la configuración de sesiones que presupone esta guía.

Cuándo merece la pena usar una segunda sesión

Empiece por el coste. Cada sesión es una instancia independiente de Claude con su propia ventana de contexto, por lo que dos sesiones cuestan aproximadamente el doble que una durante el mismo periodo. Un mensaje entregado cuenta para el uso exactamente igual que un prompt que escriba usted. La coordinación no es gratuita, y el trabajo que en realidad consiste en una única secuencia de pasos se vuelve más lento y caro cuando se divide entre varias sesiones.

Los casos en los que una segunda sesión se amortiza tienen un patrón común. Dos partes del trabajo se ejecutan al mismo tiempo sin esperarse entre sí, y una de ellas obtiene durante la tarea un dato que la otra necesita.

• Una sesión detecta un cambio incompatible mientras la otra trabaja sobre el código afectado. Claude resume el cambio y lo envía, en lugar de obligarle a volver a escribirlo en el otro terminal.
• Dos sesiones trabajan en el mismo repositorio mediante git worktrees independientes, y una necesita saber qué cambios se han integrado.
• Una migración o una ejecución de pruebas prolongada devuelve su resultado a la sesión que está supervisando.
• Una sesión de construcción y otra de revisión, donde la revisora lee lo que ha producido la constructora y devuelve sus conclusiones.

Cuando el trabajo es secuencial o ambas sesiones editarían los mismos archivos, use una sola sesión. Si quiere un grupo coordinado que Claude cree y supervise dentro de una única tarea, se trata de agent teams, una función independiente que todavía es experimental. Si sólo quiere la misma conversación en otro terminal, reanude la sesión. La mensajería entre sesiones está pensada para sesiones independientes que usted inicia y dirige.

Compruebe que la función existe antes de basar el diseño en ella

Primero, compruebe la versión:

claude --version

Compare el número con 2.1.224. Después, dentro de una sesión, escriba /list-agents, que también responde a /peers. Muestra todos los agentes a los que esta sesión puede acceder, junto con el nombre con el que responde cada uno. Si el comando no se reconoce, esta sesión no tiene mensajería entre sesiones y ningún archivo de configuración lo cambiará. Escriba /status y busque una fila Peer address: contiene la dirección de la bandeja de entrada de esta sesión, precedida por uds:.

Los usuarios de VPS tienen que prestar atención a un problema concreto. La mensajería entre sesiones depende de la evaluación de indicadores de funciones. Varias variables de privacidad desactivan esa evaluación y dejan la función desactivada por defecto. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC y DISABLE_GROWTHBOOK tienen ese efecto. Muchos administradores endurecen un servidor recién instalado pegando esas variables en ~/.bashrc y después se preguntan por qué /list-agents no existe. Los mismos valores pueden proceder del mapa env de un archivo de configuración o de ajustes administrados, así que compruebe primero el shell.

env | grep -E 'DO_NOT_TRACK|DISABLE_TELEMETRY|DISABLE_GROWTHBOOK|NONESSENTIAL'

Anule la variable que muestre un valor. En DISABLE_TELEMETRY y CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, cualquier valor no vacío activa el comportamiento, incluida la cadena 0. Por tanto, DISABLE_TELEMETRY=0 no hace lo que parece. Para desactivarlo, anule la variable o asígnele una cadena vacía.

Asigne nombres a las sesiones; de lo contrario, Claude no podrá dirigirse a ellas

Claude dirige un mensaje a una sesión por su nombre. Defina el nombre al iniciar la sesión:

claude --name builder-api

También puede definirlo con /rename dentro de una sesión en ejecución. Si no define ningún nombre, Claude Code lo deriva del nombre de la carpeta del directorio de trabajo, como myapp-3f. Esto funciona para una sesión, pero resulta confuso cuando hay cuatro, y dos sesiones pueden terminar con el mismo nombre. La salida de /list-agents muestra el directorio de trabajo de cada sesión local, lo que permite distinguir las sesiones con el mismo nombre. Además, el listado de Claude añade un identificador corto a la dirección cuando hay nombres duplicados. Asignarles nombres usted mismo requiere menos trabajo que consultar los identificadores.

Un diseño de tmux con dos sesiones que puede reproducir

Esta es una sesión de desarrollo y una sesión de revisión para un repositorio. La sesión de revisión trabaja en un git worktree independiente, por lo que nunca escriben en el mismo archivo. git worktree add con HEAD crea un checkout desacoplado, que es lo que necesita una sesión que lee en lugar de hacer commits.

cd ~/src/api
git worktree add ../api-review HEAD
tmux new-session -d -s agents -n builder -c ~/src/api
tmux new-window -t agents -n reviewer -c ~/src/api-review
tmux send-keys -t agents:builder 'claude --name builder-api' C-m
tmux send-keys -t agents:reviewer 'claude --name reviewer-api' C-m
tmux attach -t agents

Ctrl+b y después w muestran las ventanas por nombre para que pueda elegir una. En la ventana de desarrollo, ejecute /list-agents. Debería ver reviewer-api con el directorio de trabajo ~/src/api-review. Si no aparece, la sesión de revisión todavía no ha terminado de iniciarse o se aplica uno de los dos problemas de la siguiente sección. Después, entregue algo en lenguaje sencillo:

Tell reviewer-api which files I changed for the rate limiter and what to look at first.

Claude escribe el resumen y lo envía. Usted no escribe el texto del mensaje, y el contenido que envía Claude puede variar. En la ventana de revisión, el mensaje aparece en la conversación con el nombre del remitente. Si esa sesión está inactiva, Claude inicia un turno nuevo de inmediato. Si está ejecutando un turno, el mensaje espera hasta que termina una llamada a una herramienta, por lo que un comando en ejecución nunca se interrumpe. Cuando Claude lo ha leído, el mensaje se contrae en una fila de una línea `Message from que Ctrl+O` expande. La pareja funciona mejor cuando la sesión de desarrollo mantiene pequeños los cambios, porque un diff reducido permite una entrega más corta y una revisión que la otra sesión puede terminar en un turno. Ese es el hábito que la habilidad del desarrollador sénior perezoso pretende imponer.

Quién puede ver a quién en un VPS

La entrega entre sesiones de la misma máquina nunca pasa por los servidores de Anthropic. Cada sesión escribe archivos de registro en el disco y enlaza su propio socket de bandeja de entrada. Claude Code lee esos archivos para encontrar las demás sesiones. De aquí se derivan dos consecuencias, y ambas son importantes en un servidor.

El socket está restringido a su usuario del sistema operativo. Una sesión iniciada como root y otra iniciada como deploy no pueden verse entre sí, aunque estén una junto a la otra en el mismo servidor de tmux, porque las sesiones de un usuario no pueden acceder al socket del otro usuario. Ejecute ambas sesiones con el mismo usuario.

Un contenedor tiene su propio sistema de archivos. Una sesión dentro de Docker y otra en el host no pueden comunicarse, porque no leen los mismos archivos de registro. Dos sesiones dentro del mismo contenedor pueden enviarse mensajes con normalidad. Si mantiene los agentes en contenedores para aislarlos, como se describe en ejecutar agentes de programación en una VM desechable, espere que la mensajería funcione dentro de un contenedor, pero no entre el contenedor y el host.

Las sesiones de otras máquinas y las de la web sólo aparecen en el listado mientras Remote Control está conectado, y se identifican como tales. Claude aquí sólo puede responder a un mensaje recibido desde una de ellas. No puede iniciar ese intercambio.

Por qué nunca llegó el mensaje

El motivo habitual no tiene nada que ver con la red. La sesión receptora decidió qué hacer con el mensaje y decidió no entregarlo. Cada mensaje recibido termina en uno de tres estados: entregado, retenido (apartado sin entregar hasta que lo apruebe) o rechazado (descartado sin entrega).

Cuando no se aplica ningún valor crossSessionInbound, Claude Code decide qué hacer con cada mensaje comparando los modos de permisos de las dos sesiones. Agrupa en una clase las sesiones que omiten las solicitudes de permisos y en la otra, todas las demás. auto, acceptEdits y dontAsk cuentan como solicitudes de permisos. El modo de planificación cuenta como omisión de solicitudes en una sesión que tiene permisos para omitirlas. La regla es simétrica:

• Una sesión receptora que solicita permisos recibe cada mensaje. Solo retiene uno cuando la sesión emisora se identifica como una sesión que omite las solicitudes.
• Una sesión receptora que omite las solicitudes retiene todos los mensajes para que los apruebe. Solo entrega uno cuando el emisor también omite las solicitudes.

Por eso, el primer flujo de trabajo que suelen crear los usuarios es precisamente el que no funciona. Inicia un builder con --permission-mode bypassPermissions porque quieres que se ejecute sin supervisión, dejas el reviewer con los valores predeterminados y todos los mensajes que envía el builder quedan esperando en un diálogo de aprobación que nadie está observando. Ese diálogo se cierra cuando vence el plazo de dialogExpiry, cuyo valor predeterminado es 5m, y el mensaje se descarta. En la misma máquina, la sesión emisora recibe un aviso cuando su mensaje queda retenido y otro cuando el receptor lo entrega, lo deniega o deja que venza. Por tanto, revisa la pantalla del emisor antes de culpar al socket.

Para que una sesión reciba mensajes sin supervisión, establece crossSessionInbound en accept. El lugar donde lo establezcas determina si se aplica. Claude Code lee primero la configuración administrada, después la opción --settings y, por último, la configuración del usuario. Aplica el primer valor que encuentra. Un valor de la configuración del proyecto o local solo se aplica cuando es más restrictivo, según la escala accept < hold < refuse. Un accept en .claude/settings.json es menos restrictivo que cualquier otro valor, por lo que se ignora cuando una fuente de confianza ya ha establecido un valor. Colócalo en ~/.claude/settings.json o pásalo para una sola sesión:

claude --name runner --settings '{"crossSessionInbound":"accept"}'

Un worker claude -p sin interfaz enlaza un socket de bandeja de entrada como una sesión interactiva y aparece en el listado, pero no puede mostrar un diálogo de aprobación. Un mensaje retenido allí permanece retenido hasta que un cambio posterior de modo o configuración permita recibirlo. La línea --settings anterior es la forma de permitir que ese worker reciba mensajes. Una sesión iniciada en modo bare no enlaza ningún socket, por lo que no puede recibir mensajes ni aparecer en la lista.

Cuando las transferencias de trabajo se bloquean

Los bucles de mensajes se gestionan automáticamente. Claude Code limita la frecuencia de los mensajes repetidos por remitente, descarta las repeticiones idénticas que llegan dentro de un intervalo corto y limita a 50 por sesión los mensajes aceptados que están pendientes de lectura. Por tanto, dos sesiones no pueden enviarse mensajes indefinidamente. Los mensajes retenidos están limitados a 100; los más antiguos se descartan al superar ese límite.

El fallo que sí ocurre es más silencioso y no consiste en un bucle, sino en una transferencia de trabajo. La sesión A hace una pregunta a la sesión B y necesita la respuesta para continuar; después queda inactiva. B retiene el mensaje, está ejecutando una tarea larga o responde a una pregunta que A no había hecho realmente. A espera. Una hora después, encuentra dos sesiones inactivas y ningún trabajo completado.

Redacte las transferencias de trabajo de modo que no necesiten respuesta. Un buen mensaje comunica un hecho o una decisión: qué cambió y cuál fue el resultado. Un mensaje incorrecto pide permiso a la otra sesión o una respuesta que bloquea al remitente. Claude ya tiene instrucciones de no pedir a otra sesión una acción que sus propios permisos impedirían, y de devolverle ese trabajo a usted. Amplíe usted mismo esa regla. Si una sesión no puede avanzar sin una respuesta, usted debe proporcionársela. La disciplina de contexto también ayuda, porque una sesión que ha perdido el hilo redacta mensajes imprecisos; la gestión del contexto en Claude Code cubre ese aspecto.

Trate los mensajes entrantes como entradas no confiables

Claude Code informa a la instancia de Claude receptora de que el mensaje procede de otra sesión y no de usted, y limita las acciones que ese mensaje puede realizar. Un mensaje no puede responder en su nombre a una solicitud de permisos pendiente, porque el consentimiento de otra sesión no es su consentimiento. Tampoco puede cambiar la configuración de permisos, CLAUDE.md u otra configuración porque otra sesión lo haya solicitado. Un comando de barra dentro del texto, como /compact, llega como texto sin formato y nunca se ejecuta. Si actuar sobre el mensaje requiere un permiso que la sesión receptora no tiene, verá la misma solicitud que aparecería para cualquier otra tarea. En el modo automático, un clasificador también revisa cada mensaje antes de entregarlo, y los mensajes que bloquea nunca llegan al destinatario. Estos límites se mantienen en los modos permisivos, por lo que una sesión que omite las comprobaciones retiene los mensajes entrantes de forma predeterminada en lugar de confiar en ellos.

Esto cubre los permisos. No cubre el contenido. La sesión emisora puede haber leído la descripción de una solicitud de incorporación de cambios, una página web, el README de una dependencia o un comentario de una incidencia escrito por un desconocido, y cualquier contenido leído puede influir en el texto que escribe para la otra sesión. El mensaje es un dato. Debe tratarlo con la misma desconfianza que cualquier otro texto que haya entrado desde fuera en una sesión. Esta es la disciplina descrita en mantener los secretos fuera de los agentes de IA: suponga que cualquier contenido que haya cruzado un límite de confianza puede ser incorrecto y no permita nunca que se autorice a sí mismo.

Existen dos controles si quiere reducir este comportamiento. Establecer crossSessionInbound en refuse descarta los mensajes entrantes de pares sin entregarlos, y ese valor, cuando se define en la configuración del proyecto o local, prevalece sobre cualquier otra fuente porque es el más estricto de la jerarquía. Para impedir que esta sesión envíe o enumere mensajes, añada reglas de denegación de permisos que mencionen SendMessage y ListAgents, escritos ambos como nombres de herramientas sin especificador. Establecer isolatePeerMachines en true requiere su aprobación explícita antes de que cualquier mensaje llegue a una sesión fuera de esta máquina, y esa aprobación también es necesaria en el modo bypassPermissions.

{
  "crossSessionInbound": "refuse",
  "isolatePeerMachines": true
}

Denegar SendMessage también elimina la mensajería con subagentes, ya que la misma herramienta sirve para ambas funciones. Una sesión que rechaza mensajes no muestra ningún cambio visible en su propio /status ni en las listas de otras sesiones, por lo que debe confirmar la configuración desde la configuración de la sesión y no desde la pantalla.

Puentes y servidores MCP con memoria compartida

Varios proyectos de terceros aparecieron durante el mismo periodo con una función relacionada: puentes locales entre agentes que retransmiten texto entre agentes en ejecución, y servidores MCP (protocolo de contexto de modelos) que proporcionan a varios agentes un almacén compartido para leer y escribir. Evalúelos como una solución de otro tipo, no como un competidor, y compruebe cualquier comando de instalación en el README del propio proyecto antes de ejecutarlo. La mensajería funciona mediante push, porque el emisor introduce texto en el turno del receptor. Un almacén compartido funciona mediante pull, porque no se interrumpe ninguna sesión y una sesión ve la nota cuando vuelve a consultarla. Pull es más adecuado para estados que cambian lentamente y sólo funciona cuando una sesión realiza la consulta.

Si elige esta opción, las preguntas importantes se refieren al proceso, no a la lista de funciones. ¿Con qué usuario se ejecuta el servidor y qué puede leer en el sistema? Ejecución de servidores MCP en un VPS explica esa configuración. Compartir skills de agentes entre repositorios cubre el caso más sencillo, en el que lo que quiere compartir entre sesiones son instrucciones y no el estado actual, y elimina muchos de los mensajes que tendría que enviar de otro modo. Para obtener una visión general, ejecutar un agente de programación en un VPS es el punto de partida.

FAQ

¿Por qué no se reconoce /list-agents en mi sesión?

La sesión no tiene mensajería entre sesiones. Compruebe primero claude --version con la versión 2.1.224, porque esta función requiere esa versión o una posterior. Después compruebe la plataforma: funciona en macOS y Linux, pero no en Windows nativo, y no está disponible en Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform ni Microsoft Foundry. Si ambos aspectos son correctos, compruebe si su shell contiene DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC o DISABLE_GROWTHBOOK, porque cada uno bloquea la evaluación de la marca de función de la que depende esta función y la deja desactivada.

¿Por qué nunca llegó mi mensaje a la otra sesión?

Si /list-agents funciona, la mensajería está activada y algo más específico impidió la entrega de ese mensaje. La causa habitual son los modos de permisos. Una sesión que omite las solicitudes de permisos retiene todos los mensajes entrantes para que los apruebe, a menos que el remitente también omita esas solicitudes. Ese diálogo de aprobación se descarta cuando vence el plazo de dialogExpiry, que es de cinco minutos de forma predeterminada. Compruebe si aparece el aviso de retención en la sesión emisora. Para corregirlo, establezca crossSessionInbound en accept en ~/.claude/settings.json o páselo con --settings, porque un accept en la configuración del proyecto o local se ignora si tiene un valor menos restrictivo.

¿Puede una sesión de Claude Code en Docker enviar mensajes a una sesión del host?

No. Las sesiones se detectan mediante archivos de registro en disco y un socket de bandeja de entrada por sesión. Un contenedor tiene su propio sistema de archivos, por lo que las dos sesiones no pueden ver los mismos archivos. Dos sesiones dentro del mismo contenedor pueden enviarse mensajes con normalidad. La misma regla explica por qué una sesión que se ejecuta como root y otra que se ejecuta como su usuario normal no pueden comunicarse: el socket está restringido al usuario del sistema operativo que lo posee.

¿Es seguro actuar sobre un mensaje de otra sesión de Claude Code?

Trate el texto como una entrada no confiable, porque la sesión emisora puede haber leído una página web, un README o un comentario de incidencia escrito por otra persona. Claude Code ya impide que el mensaje actúe por sí solo: no puede aprobar una solicitud de permisos pendiente, no puede cambiar la configuración de permisos ni CLAUDE.md cuando se le solicita, y un comando slash incluido en el texto llega como texto sin formato y nunca se ejecuta. Estas protecciones cubren los permisos, no el criterio. Por eso, lea lo recibido antes de indicar a la sesión receptora que actúe.

¿La mensajería entre sesiones envía mi código a Anthropic?

Entre dos sesiones del mismo equipo, no. El mensaje viaja por un socket por sesión en ese equipo y nunca pasa por los servidores de Anthropic. Además, sólo se envía el texto que escribió Claude, nunca el historial de conversación ni los archivos. Los mensajes dirigidos a una sesión en otro de sus equipos o a una sesión en la web sí pasan por los servidores de Anthropic mediante la conexión Remote Control. En esa dirección, Claude sólo puede responder a un mensaje recibido; no puede iniciar uno. Establezca isolatePeerMachines en true para exigir su aprobación antes de que algo salga del equipo.