Si tienes dos Profile de Hermes abiertos a la vez — uno conectado al servidor de la empresa y otro al NAS de casa — lee esto antes que nada: #92156, integrado en main el 22 de agosto, corrige una fuga que podía hacer que ejecutaras comandos en el host equivocado. Suena profundamente técnico, pero la consecuencia es directa: tras cambiar de Profile, tus comandos de terminal podían seguir usando silenciosamente el entorno SSH en caché del Profile anterior — es decir, un comando que creías que se había ejecutado en el servidor A en realidad se ejecutaba en el servidor B.

Cómo ocurría la fuga

La herramienta de terminal de Hermes guarda en caché el entorno remoto de cada sesión (como SSHEnvironment) para no tener que restablecer la conexión en cada comando. Esa caché vive en un dict llamado _active_environments, indexado por una clave que genera _resolve_container_task_id().

El problema era esa clave: todas las sesiones de WebUI / gateway colapsaban en la clave compartida "default". Así, en el mismo proceso, el Profile A (ssh_host=10.0.0.1) y el Profile B (ssh_host=10.0.0.2) compartían una única ranura de caché — tras cambiar de Profile, la terminal de B podía recoger el entorno SSH en caché de A, y los comandos se ejecutaban silenciosamente en 10.0.0.1 en lugar de en el 10.0.0.2 que querías.

Por SSH esto es especialmente peligroso: rm, git push, edición de configuración — ejecutarse en el host equivocado significa acciones destructivas sobre el objetivo equivocado, sin ninguna advertencia, porque la salida parece perfectamente normal.

La solución: caché con ámbito por sesión

La solución de #92156 es sencilla: la clave de caché pasó de "default" a session:<key>.

• La capa de streaming de WebUI establece una clave de sesión dedicada para cada sesión;
• El gateway inyecta una clave de sesión por mensaje mediante contextvars;
• Tras cambiar de Profile (sesión), la nueva sesión obtiene una clave de caché distinta y ya no puede reutilizar el SSHEnvironment del Profile anterior — así los comandos no pueden enviarse al host equivocado.

Ten en cuenta lo que la solución no rompe: los subagentes siguen compartiendo el contenedor de larga duración del padre, y los entornos de RL / benchmarks (TerminalBench2, etc.) mantienen su aislamiento por tarea — esas rutas tienen sus propias reglas de clave, y los hijos de delegate_task siguen compartiendo la conexión de la sesión del padre.

Qué deberías hacer

1. Usuarios con varios Profile + SSH: actualiza a una build que contenga la solución (hermes update --branch main, o espera a la próxima versión — la última estable sigue siendo v0.20.5);
2. Verifícalo: configura dos Profile con distintos hosts remotos, ejecuta hostname o echo $SSH_CONNECTION en cada uno y confirma que la salida coincide con la configuración de cada Profile;
3. Consejo general: las configuraciones con varios Profile se tratan en Hermes Profiles: Multiple Independent Instances; las claves de configuración de terminal/entorno también se mencionan en 4 Hidden Hermes Tricks.

Estado de la versión

La solución (#92156) está integrada en main (22 de agosto) y aún no está en ninguna versión publicada. Para probarla antes: hermes update --branch main. Forma parte del mismo lote de endurecimiento de gateway/terminal de finales de agosto que la guía de ajuste del loop-watchdog.

Resumen

La fuga de entorno SSH entre Profile es una trampa invisible: no es un error, sino ejecutarse silenciosamente en el host equivocado. La buena noticia es que la solución ya está en main — con el ámbito de caché por sesión, cambiar de Profile ya no puede recoger el entorno remoto del Profile anterior. Si usas mucho varios Profile, merece la pena actualizar y verificar de inmediato.