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 fragmento de texto sin formato que un Claude escribe para otro. No contiene 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 llamar manualmente a ninguna de las dos herramientas. 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 necesita 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á activa 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.

Un VPS es donde esta función resulta útil, porque es donde 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 todavía sigue ejecutándose el jueves y conserva 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 enviado cuenta para el uso exactamente igual que una instrucción que escriba usted. La coordinación no es gratuita, y el trabajo que en realidad consiste en una secuencia de pasos se vuelve más lento y caro cuando lo divide entre varias sesiones.

Los casos en los que una segunda sesión compensa 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 información 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 que usted tenga que 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 larga devuelve su resultado a la sesión que está supervisando.
• Una sesión de desarrollo y otra de revisión, donde la sesión de revisión lee lo que ha producido la de desarrollo y envía sus conclusiones.

Cuando el trabajo es secuencial o cuando ambas sesiones modificarí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 sirve para sesiones independientes que usted inicia y dirige.

Compruebe que la función está disponible antes de basar el diseño en ella

Primero, 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 llegar, junto con el nombre al que responde cada uno. Si el comando no se reconoce en absoluto, esta sesión no admite mensajería entre sesiones y ningún archivo de configuración cambiará esa situación. 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 se enfrentan específicamente a un problema. La mensajería entre sesiones depende de la evaluación de indicadores de funciones, y varias variables de privacidad desactivan esa evaluación, por lo que la función permanece desactivada de forma predeterminada. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC y DISABLE_GROWTHBOOK hacen esto. Los administradores suelen reforzar un servidor recién instalado pegando esas variables en ~/.bashrc y después se preguntan por qué no existe /list-agents. Los mismos valores pueden proceder del mapa env de un archivo de configuración o de la configuración administrada, así que compruebe primero el shell.

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

Anule la variable que aparezca. En DISABLE_TELEMETRY y CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, cualquier valor no vacío activa el comportamiento, incluida la cadena 0, por lo que 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 o Claude no podrá dirigirse a ellas

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

claude --name builder-api

También puede establecerlo con /rename dentro de una sesión en ejecución. Si no establece ningún nombre, Claude Code lo genera a partir 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 acabar 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, y el listado de Claude añade un identificador corto a la dirección cuando los nombres coinciden. Asignarles nombres usted mismo requiere menos trabajo que consultar los identificadores.

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

Esta es una sesión de construcción y una sesión de revisión sobre un repositorio. La sesión de revisión trabaja en un worktree independiente de git, por lo que las dos nunca escriben en el mismo archivo. git worktree add con HEAD crea un checkout separado, que es lo adecuado para una sesión que lee en lugar de hacer commits. Como las dos sesiones realizan tareas distintas, conviene dar a la revisión un estilo de salida propio. Esto cambia el indicador del sistema de esa sesión y se mantiene en todos los turnos, en lugar de desaparecer como una instrucción escrita una sola vez.

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 construcción, 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 sección siguiente. Después, envíe algo en lenguaje claro:

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 de inmediato un turno nuevo en ella. Si está en mitad de 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 construcción mantiene pequeños sus cambios, porque un diff reducido produce una entrega más breve 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 existe para imponer.

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

La entrega entre procesos del mismo equipo 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 acceder entre sí 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 a través del límite del contenedor.

Las sesiones en otros equipos y en la web aparecen en el listado sólo 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é su mensaje nunca llegó

La razón habitual no tiene nada que ver con la red. La sesión receptora decidió qué hacer con el mensaje y decidió no entregarlo. Todo mensaje entrante termina en uno de tres estados: entregado, retenido (se aparta sin entregar hasta que usted lo aprueba) o rechazado (se descarta sin entregarlo).

Cuando no se aplica ningún valor crossSessionInbound, Claude Code decide el resultado de cada mensaje comparando los modos de permisos de las dos sesiones. Agrupa en una clase las sesiones que omiten las solicitudes de permisos y coloca todas las demás en la otra. auto, acceptEdits y dontAsk cuentan como modos que solicitan permisos. El modo de planificación cuenta como omisión de solicitudes en una sesión que tiene permisos para omitirlas. Si no está seguro de en qué clase se encuentra una sesión, conviene leer primero qué hace realmente cada modo de permisos, porque auto es el modo con el que comienzan actualmente la mayoría de las sesiones y pertenece al lado de las solicitudes de esa división. La regla es simétrica:

• Una sesión receptora que solicita permisos recibe todos los mensajes. Solo retiene un mensaje 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 usted los apruebe. Solo entrega un mensaje cuando el emisor también omite las solicitudes.

Por eso, el primer flujo de trabajo que crea la mayoría de las personas es precisamente el que no funciona. Inicia un builder con --permission-mode bypassPermissions porque quiere que funcione sin supervisión, deja el reviewer con los valores predeterminados y cada mensaje que envía el builder queda esperando en un cuadro de diálogo de aprobación que nadie está observando. Ese cuadro se cierra después del plazo 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 rechaza o deja que caduque. Por tanto, revise la pantalla del emisor antes de culpar al socket.

Para que una sesión acepte mensajes sin supervisión, establezca crossSessionInbound en accept. El lugar donde lo establezca 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óquelo en ~/.claude/settings.json o páselo para una sola sesión:

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

Un worker claude -p sin interfaz interactiva enlaza un socket de entrada igual que una sesión interactiva y aparece en la lista, pero no puede mostrar un cuadro de diálogo de aprobación. Un mensaje retenido allí permanece retenido hasta que un cambio posterior de modo o de configuración permita entregarlo. La línea --settings anterior es la forma de permitir que dicho worker acepte 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 quedan bloqueadas

Los bucles de mensajes se gestionan automáticamente. Claude Code limita la frecuencia de los mensajes repetidos de cada emisor, 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 lo que dos sesiones no pueden enviarse mensajes indefinidamente. Los mensajes retenidos están limitados a 100; los más antiguos se descartan cuando se supera ese límite.

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

Escriba transferencias de trabajo 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 de la que depende el emisor para continuar. 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 esa regla por su cuenta. Si una sesión no puede avanzar sin una respuesta, usted debe responderle. Mantener el contexto también ayuda, porque una sesión que ha perdido el hilo escribe mensajes imprecisos; la gestión del contexto en Claude Code cubre ese aspecto.

Trate los mensajes entrantes como datos no confiables

Claude Code informa al Claude receptor de que el mensaje procede de otra sesión y no de usted, y limita las acciones que ese mensaje puede realizar. Esta aplicación se ejecuta en el programa que envuelve al modelo, no en la disposición del modelo a obedecer. Esa es la diferencia práctica que aporta un agente de ejecución. Un mensaje no puede responder en su nombre a una solicitud de permiso 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 slash incluido en el 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 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 eso, una sesión que omite controles retiene los mensajes entrantes de forma predeterminada en lugar de confiar en ellos.

Esto cubre los permisos, pero no 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. Cualquier contenido leído puede influir en el texto que escriba para la otra sesión. El mensaje son datos. Debe tratarlo con la misma cautela que cualquier otro texto que haya entrado en una sesión desde el exterior. Esta es la disciplina descrita en mantener los secretos fuera de los agentes de IA: suponga que todo lo que haya cruzado un límite de confianza puede ser incorrecto y no permita que se autorice a sí mismo.

Si desea reducir este comportamiento, existen dos controles. Establecer crossSessionInbound en refuse descarta los mensajes entrantes entre pares sin entregarlos. Desde la configuración del proyecto o local, ese valor prevalece sobre cualquier otra fuente porque es el más restrictivo de la jerarquía. Para impedir que esta sesión envíe o enumere mensajes, añada reglas de denegación de permisos que incluyan SendMessage y ListAgents. Ambos deben escribirse como nombres de herramienta sin especificador. Establecer isolatePeerMachines en true exige su aprobación explícita antes de que cualquier mensaje llegue a una sesión situada fuera de esta máquina. Esta aprobación también es obligatoria en el modo bypassPermissions.

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

Denegar SendMessage también elimina la mensajería con subagentes, porque ambas funciones usan la misma herramienta. Una sesión que rechaza mensajes no muestra ningún cambio visible en su propio /status ni en las listas de otras sesiones. Por tanto, confirme la configuración desde la configuración de la sesión y no desde la pantalla.

Puentes y servidores MCP de 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 (model context protocol) que proporcionan a varios agentes un almacén compartido para leer y escribir. Evalúelos como una arquitectura diferente, no como competidores, y compruebe cualquier comando de instalación en el README del propio proyecto antes de ejecutarlo. La mensajería usa un modelo push porque el emisor coloca el texto en el turno del receptor. Un almacén compartido usa un modelo pull porque no interrumpe ninguna sesión y una sesión ve la nota la próxima vez que la consulta. El modelo pull es más adecuado para estados que cambian lentamente y sólo funciona cuando una sesión realiza esa consulta.

Si elige este enfoque, las preguntas importantes deben centrarse en el proceso, no en 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 esta configuración. Compartir habilidades de agentes entre repositorios cubre el caso más sencillo, en el que lo que quiere compartir entre sesiones son instrucciones y no un estado en tiempo real. Esto 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 necesita 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 ambas comprobaciones son correctas, revise si su shell define DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC o DISABLE_GROWTHBOOK, porque cada una de esas variables impide evaluar la marca de función de la que depende esta capacidad 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 bloqueó 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 la sesión emisora muestra el aviso de retención. 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 al ser un valor menos restrictivo.

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

No. Las sesiones se encuentran 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 normalmente. 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 es su propietario.

¿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 una incidencia escrito por otra persona. Claude Code ya impide que el mensaje actúe por sí solo: no puede aprobar una solicitud de permiso pendiente, no puede cambiar la configuración de permisos ni CLAUDE.md a petición, y un comando de barra incluido en el texto llega como texto plano y nunca se ejecuta. Estas protecciones cubren los permisos, pero no el criterio. 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 en el mismo equipo, no. El mensaje viaja por un socket específico de la sesión en ese equipo y nunca pasa por los servidores de Anthropic. Sólo se envía el texto que escribió Claude, nunca el historial de la conversación ni los archivos. Los mensajes dirigidos a una sesión de 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 iniciar uno. Establezca isolatePeerMachines en true para exigir su aprobación antes de que salga cualquier dato del equipo.