Siempre has querido que Hermes ejecute comandos de terminal en un sandbox en la nube concreto — código más seguro, entornos más limpios y nada de conflictos de dependencias locales. Entonces abres la documentación y solo ves los backends integrados listados. El que quieres significa esperar a que los mantenedores fusionen el código del proveedor en el repositorio principal, o mantener tu propio fork para siempre. PR #94400, fusionado el 25 de agosto, pone fin a esa espera: los backends de terminal son ahora un subsistema de plugins. Un sandbox en la nube de terceros puede registrarse como valor de terminal.backend mediante un plugin independiente — sin cambios en el core, sin fork.

Por qué era «la última gran pieza»

En todo el ecosistema de herramientas de Hermes, la generación de imágenes/vídeo, el scraping web, el navegador, la memoria, TTS/STT y los proveedores de modelos ya soportaban integración mediante plugins desde hace tiempo — excepto los backends de terminal. Las terminales tocan demasiados puntos sensibles: aprobaciones, rutas de contenedores, cachés, eliminación de secretos — el mayor radio de explosión de cualquier subsistema. El PR #94400 cierra esa brecha: los proveedores de sandboxes pueden ahora escribir un plugin y dejar que los usuarios configuren terminal.backend: <nombre-de-tu-backend> directamente.

Hay un primer consumidor real detrás de esto: el backend de sandbox en la nube Sprites (originalmente #93523) fue el primero en migrar a esta interfaz — se mudó a un repositorio privado de plugins independiente en lugar de vivir en el core.

Cómo es un plugin: una clase abstracta + una función de registro

El mecanismo se centra en dos archivos nuevos: agent/terminal_env_provider.py define la clase base abstracta TerminalEnvironmentProvider, y agent/terminal_env_registry.py es un registro seguro para hilos. Lo que hace un autor de plugin (el ejemplo mínimo de la guía oficial para desarrolladores, developer-guide/terminal-environment-plugin.md):

# ~/.hermes/plugins/acmebox/__init__.py
from agent.terminal_env_provider import TerminalEnvironmentProvider

class AcmeBoxEnvironment:
    """Debe cumplir el contrato duck-typed de BaseEnvironment."""
    def __init__(self, cwd, timeout, task_id):
        self.cwd, self.timeout, self.task_id = cwd, timeout, task_id

    def execute(self, command, timeout=None, **kwargs):
        ...  # ejecuta el comando en el sandbox
        return {"output": "...", "exit_code": 0}

    def cleanup(self):
        ...  # derriba / desengancha

class AcmeBoxProvider(TerminalEnvironmentProvider):
    name = "acmebox"
    display_name = "AcmeBox"
    is_remote = True       # los comandos no se ejecutan en el host
    is_container = True    # semántica de ruta/cwd tipo contenedor

    @property
    def cache_path_base(self):
        return "~/.hermes"  # dónde aterrizan los archivos de caché sincronizados, o None

    @property
    def strip_env_keys(self):
        return frozenset({"ACMEBOX_TOKEN"})  # secretos eliminados de los subprocesos

    def create_environment(self, *, cwd, timeout, task_id="default",
                           image=None, container_config=None, **kwargs):
        return AcmeBoxEnvironment(cwd, timeout, task_id)

def register(ctx):
    ctx.register_terminal_environment_provider(AcmeBoxProvider())

El directorio del plugin también lleva un plugin.yaml (nombre, versión, kind: backend). Luego lo habilitas y lo seleccionas:

hermes plugins enable acmebox
hermes config set terminal.backend acmebox

Los nombres de los backends integrados (local, docker, singularity, modal, daytona, vercel_sandbox, ssh) están reservados — los plugins amplían el conjunto, nunca eclipsan a un backend integrado.

Seis flags de clasificación que eliminan la clase de bugs «al nuevo backend le faltó un sitio»

En el pasado, añadir un backend significaba sincronizar la lógica de decisión en siete u ocho sitios del código — qué backends son remotos, cuáles son contenedores, cuáles se saltan las aprobaciones, cómo se traducen las rutas de caché — y perderse uno era un bug difícil de encontrar (el issue #30112 necesitó un barrido de siete sitios). El nuevo diseño lo declara todo:

• is_remote: los comandos se ejecutan en un lugar distinto del host. Suprime las pistas de OS/home/cwd del host, la sonda de entorno Python del host y el manejo de skills sensible a remoto;
• is_container: se comporta como un contenedor/sandbox con su propio sistema de archivos — la configuración de recursos del contenedor pasa, los cwd con apariencia de host se sanean, las herramientas de archivos usan la resolución de rutas del contenedor;
• skip_container_guards: el sandbox está lo bastante aislado como para omitir las peticiones de aprobación de comandos peligrosos (por defecto es is_container; los backends que pueden montar rutas del host deberían sobreescribirlo a False);
• cache_path_base: dónde aterrizan dentro del backend los archivos auto-sincronizados de ~/.hermes/cache (p. ej. ~/.hermes o /root/.hermes), o None cuando no hay nada que traducir;
• strip_env_keys: las variables de entorno de credenciales que pertenecen a este backend (tokens de API del proveedor), eliminadas de cada subproceso que el agente lanza para que los comandos escritos por el modelo nunca puedan leerlas;
• session_isolated_when_nonpersistent: el modo no persistente da a cada sesión su propia identidad de sandbox en lugar de compartir una.

Dónde aparece el plugin una vez registrado

Un backend registrado no es solo un valor en el archivo de configuración — cada superficie lo recoge automáticamente:

• El selector de backends de hermes setup muestra la nueva opción con configuración guiada por el proveedor;
• hermes status / hermes doctor listan el backend del plugin y su estado de salud;
• El selector de backend de terminal del dashboard soporta backends de plugins y se recalcula por petición — un plugin instalado a mitad de sesión aparece de inmediato.

La guía oficial para desarrolladores explica paso a paso cómo escribir un backend plugin desde cero.

Qué significa esto para los usuarios habituales

Si solo usas los backends integrados (terminal local, Docker, Modal, SSH), este cambio es invisible en el comportamiento — es una puerta arquitectónica, no un interruptor de comportamiento. Lo que importa es el impacto en el ecosistema: cuando un proveedor de sandboxes dice «soporta Hermes», ahora significa «instala el plugin», no «espera a un merge en el core»; la calidad del plugin es responsabilidad del proveedor, y hermes doctor te dice si está sano. Para lo básico de los plugins, consulta la referencia del comando hermes plugins; para el mecanismo de punto de entrada detrás de los proveedores instalados por pip, nuestra guía de plugins de proveedores de modelos por pip cubre el linaje. La selección de backend en el día a día está documentada en la guía de instalación.

Resumen

Los backends de terminal con plugins convierten «conseguir que Hermes use mi sandbox en la nube» de «suplicar un merge en el core» a «escribe un plugin, declara seis flags, regístralo, listo». Es la última pieza del ecosistema de herramientas de Hermes en volverse nativa de plugins — los backends de terceros ahora están desacoplados del core, con la política de seguridad aplicada de forma uniforme mediante flags declarativos.