Imagina una máquina que carga con varios profiles: el tuyo, uno compartido con el equipo y un profile de demo para clientes. Alguien instala un plugin de la comunidad — una cosa pequeña que conecta un sistema de tickets con el chat. Desde el momento en que se importa, ese plugin vive en el mismo proceso de Python que cada sesión, cada credencial de provider y cada clave de API en memoria. Un autor de plugins con buenas intenciones puede igualmente publicar una variable global, un monkeypatch o un hilo que no se cierra nunca, y todo eso puede alcanzar cosas que nunca debía tocar.

Hermes ahora te da un interruptor para eso: sacar los plugins de terceros del proceso principal. La configuración es una sola línea, plugins.isolation: host, y el plugin en sí no cambia en absoluto.

El valor por defecto no ha cambiado; el nuevo modo es un host por profile

Seamos precisos, porque nada cambia hasta que lo pides. El valor por defecto sigue siendo in_process: los plugins se importan en el proceso de Hermes, exactamente como antes. Solo un host explícito cambia el comportamiento.

plugins:
  isolation: host        # por defecto: in_process
  host:
    launcher: []         # prefijo argv opcional para el host, p. ej. un sandbox runner

Con host, cada profile obtiene un proceso de Python independiente que se arranca bajo demanda — el plugin host —, que importa solo los plugins instalados por el usuario de ese profile y habla con Hermes a través de una tubería privada. Los plugins incluidos (bundled) no se ven afectados y siguen ejecutándose en proceso.

Hay un detalle de diseño fácil de pasar por alto y que importa mucho: el proceso host arranca con solo el entorno y los secretos de ese profile. Antes un plugin veía las credenciales que llevara el proceso; ahora ve las de su propio profile. En un despliegue multiinquilino (multi-tenant), ese es el significado práctico de “el código de plugins de un inquilino nunca comparte memoria con los datos de otro”.

Los plugins no cambian: el mismo ctx, serializado a través de la tubería

La parte molesta de casi todas las historias de aislamiento es que hay que reescribir código. Aquí no.

Dentro del host, un plugin recibe el mismo ctx de siempre. Las herramientas, los hooks, los comandos de barra, los comandos de CLI, las skills y los objetos de provider (generación de imagen y vídeo, búsqueda web, navegador, TTS/STT, memoria, motores de contexto, cron) se registran exactamente como antes. Hermes registra en su lado proxies equivalentes que llaman al host cuando hace falta; la documentación llama al objeto que se entrega a los plugins RemotePluginContext.

También es reentrante: mientras atiende una llamada a herramienta, un plugin puede volver a llamar a Hermes a través de ctx.dispatch_tool, ctx.get_config o ctx.llm, y Hermes lo espera, igual que si el plugin siguiera siendo local. Para los autores de plugins es, en esencia, aislamiento gratis.

Hay un precio, y está publicado en vez de descubrirse. Un puñado de superficies necesitan de verdad código en proceso, y bajo host esos plugins se rechazan con una razón clara en lugar de perder funciones en silencio. La lista documentada: adaptadores de plataforma del gateway (register_platform), transportes de aprobación, manejadores de Telegram y de otras plataformas, profiles de model provider que construyen su propio cliente SDK (create_client), endpoints de dashboard en streaming, y plugins que aplican monkeypatch a módulos de Hermes. Ejecuta esos con isolation: in_process.

Los fallos se quedan dentro del host

El primer beneficio del aislamiento no es la seguridad, es la estabilidad. Bajo host:

• el módulo de un plugin nunca entra en el proceso de Hermes, así que no puede leer de la memoria los datos de otro profile ni parchear las interioridades de Hermes;
• un plugin que falla o termina mata su host, no a Hermes. La llamada en curso devuelve un error de herramienta y luego Hermes reinicia el host y recarga sus plugins (con reintentos acotados) mientras todas las demás sesiones siguen funcionando.

Si alguna vez has instalado un plugin y has visto caer con él todo el gateway, esta sección es para ti.

Activarlo, comprobarlo, fijarlo

Actívalo con el bloque de configuración de arriba. Dos comandos te dicen la verdad de inmediato:

# Comprueba si un plugin puede ejecutarse en modo host; explica cualquier rechazo
hermes plugins validate <dir>

# Mira dónde se ejecuta un plugin concreto
hermes plugins show <name>

host.launcher existe para configuraciones más estrictas: acepta un prefijo argv que envuelve el proceso host en tu propio sandbox runner. La documentación también recomienda ejecutar la terminal del agente en un backend aislado (Docker, SSH, etc.): aislar el plugin mientras la propia terminal del agente todavía puede leer los archivos del operador solo te da la mitad del aislamiento.

Y luego está el problema más práctico en los despliegues compartidos: plugins.isolation es config ordinaria del profile, así que cualquiera que pueda editar el config.yaml de un profile puede desactivarlo. Cuando los profiles pertenecen precisamente a las personas de las que te estás aislando, fija el valor en el ámbito gestionado (managed scope): un /etc/hermes/config.yaml propiedad de root que todos los profiles leen. El valor gestionado prevalece sobre la config de cada profile, y hermes config set se niega a cambiarlo:

# /etc/hermes/config.yaml (propiedad de root; lo lee cada profile de la máquina)
plugins:
  isolation: host
  host:
    launcher: [...]

Cuánto del catálogo está listo

La preocupación obvia: si lo activo, ¿seguirán funcionando los plugins que tengo instalados?

La documentación da la cifra del momento de escribir esto: 299 de las 348 entradas del catálogo de plugins se ejecutan en el host sin cambios. Ese es el valor real de la lista de no soportados de arriba: convierte “¿esto se romperá?” en una lista corta y comprobable, en lugar de un experimento que haces en tu propia máquina.

Cuándo puedes tenerlo

La función se fusionó en la rama main el 3 de octubre de 2026. La última release es la v0.21.5 (tag v2026.9.24), así que de momento solo vive en main y aún no está en ninguna release etiquetada. Las instalaciones que siguen main la reciben en su siguiente hermes update; quienes usan releases la tendrán en el próximo tag.

Para el sistema de plugins en general — orígenes de instalación, la allow-list de habilitación, directorios de subcategoría — mira la guía del catálogo de plugins. Las retiradas del catálogo y las reglas de cadena de suministro se cubren en el artículo sobre el gate CI del catálogo, y si tu dolor es “tengo que reiniciar para que un cambio de plugin surta efecto”, la guía de rewire en vivo de plugins encaja mejor.

La versión corta

Instalar un plugin solía significar invitar al código de otra persona a tu proceso. Ahora puedes mantenerlo fuera, y el plugin ni siquiera nota la diferencia. En un portátil de un solo usuario, probablemente nunca tocarás esta línea. En una máquina que carga con varias personas o inquilinos, pertenece a esa categoría de interruptores que desearías haber activado antes del incidente, no después.

Si gestionas un despliegue compartido, haz dos cosas: ejecuta hermes plugins validate sobre todo lo que tienes instalado y luego escribe plugins.isolation: host en el ámbito gestionado, en vez de dejar que cada profile decida.