Tienes tres Profiles de Hermes: uno para el trabajo, uno para proyectos personales y uno para experimentos. Cada Profile está configurado con el backend de terminal Docker, así que cada vez que te pones en marcha se levantan varios contenedores en tu máquina — más disco, arranques más lentos, dependencias instaladas por separado en cada uno, y cambios de entorno que hay que sincronizar contenedor a contenedor. PR #94633, fusionado el 25 de agosto, ofrece una solución elegante: los Profiles de confianza pueden compartir un único contenedor Docker persistente, controlado por una sola clave de configuración.

Antes: un contenedor por Profile

Primero, el comportamiento por defecto. El backend Docker de Hermes (terminal.backend: docker) da a cada Profile su propio contenedor — la regla de aislamiento establecida el mismo día por PR #94560: los contenedores se nombran y acotan por Profile (profile:<nombre>), sin interferencias cruzadas. La ventaja es un aislamiento limpio; el inconveniente, recursos duplicados: tres Profiles significan tres conjuntos de dependencias, tres cachés, tres entornos.

Si usas Docker principalmente para tareas aisladas puntuales, ese comportamiento por defecto está bien — no necesitas cambiar nada. Pero si varios de tus Profiles son de «familia de confianza» — digamos un Profile de trabajo y uno de experimentos que en realidad usan el mismo entorno de desarrollo — la duplicación es puro desperdicio.

Ahora: una clave, un contenedor

El PR #94633 introduce una nueva clave de configuración: terminal.docker_shared_container_key. Las reglas son simples:

• Sin configurar (cadena vacía por defecto): comportamiento actual, cada Profile mantiene su propio contenedor;
• Varios Profiles con el mismo valor: comparten un contenedor persistente, identificado como shared:<tu-clave>;
• Las ejecuciones directas por CLI (sin contexto de Profile) con la misma clave configurada también aterrizan en ese contenedor compartido.

Configuración:

hermes config set terminal.docker_shared_container_key team/ws

O edita el archivo de configuración directamente (hermes config path muestra su ubicación):

terminal:
  backend: docker
  docker_shared_container_key: "team/ws"

Una vez que los Profiles work y research usan ambos team/ws, sus comandos aterrizan en el mismo contenedor: instala las dependencias una vez y todos las ven, las cachés se mantienen calientes, los cambios de entorno se aplican en un solo lugar. En las pruebas oficiales, los dos Profiles resuelven a la misma clave de contenedor shared:team/ws.

Casos en los que el uso compartido se ignora deliberadamente

Esto no es una fusión a ciegas — hay tres límites que conviene conocer:

• Los backends SSH no participan: terminal.docker_shared_container_key solo afecta al backend Docker; los entornos SSH lo ignoran por completo;
• El modo no persistente sigue aislado: si usas sesiones Docker desechables (no persistentes), la clave compartida no meterá dos sesiones efímeras en un mismo contenedor — el aislamiento por sesión se mantiene;
• Claves diferentes = sin compartir: la clave es la frontera de aislamiento; los Profiles con valores distintos usan cada uno su propio contenedor.

Además, los archivos producidos en el contenedor compartido (por ejemplo, adjuntos MEDIA) siguen siendo recuperables desde las sesiones — las pruebas oficiales cubrieron específicamente la entrega de medios desde el sandbox compartido.

Cuándo activarlo y cuándo dejarlo como está

Buenos candidatos: Profiles que en realidad son puntos de entrada distintos al mismo entorno de desarrollo; un «contenedor de entorno» compartido para un equipo; usuarios personales con varios Profiles que quieren ahorrar disco y tiempo de arranque.

Mantén el valor por defecto: Profiles con poca confianza mutua (por ejemplo, que alojen automatización no fiable); entornos que necesitan aislamiento estricto de auditoría; Profiles experimentales cuyas versiones de dependencias puedan chocar. El aislamiento siempre es más seguro que compartir — la clave compartida es para Profiles «de confianza», que es exactamente lo que significa «trusted profiles» en el título del PR.

Resumen

Una clave de configuración convierte «un contenedor Docker por Profile» en «un contenedor para toda la familia»: terminal.docker_shared_container_key vacía mantiene el aislamiento por defecto, mientras que varios Profiles con el mismo valor comparten un contenedor persistente. Para saber más sobre flujos de trabajo con varios Profiles, consulta nuestra guía de múltiples instancias de Profile; para operaciones con archivos de configuración, la referencia del comando hermes config cubre el resto. ¿Aún estás decidiendo si Docker es el backend adecuado? La guía de instalación repasa todas las opciones de backend.