Vous avez toujours rêvé que Hermes exécute ses commandes terminal dans un sandbox cloud bien précis — du code plus sûr, des environnements plus propres, et plus de conflits de dépendances locaux. Puis vous ouvrez la documentation et ne voyez que les backends intégrés. Celui que vous voulez signifie attendre que les mainteneurs fusionnent le code du fournisseur dans le dépôt du core, ou maintenir votre propre fork pour toujours. Le PR #94400, fusionné le 25 août, met fin à cette attente : les backends terminal sont désormais un sous-système à plugins. Un sandbox cloud tiers peut s’enregistrer comme valeur terminal.backend via un plugin autonome — aucun changement dans le core, aucun fork.

Pourquoi c’était le « dernier gros morceau »

Dans tout l’écosystème d’outils de Hermes, la génération d’images/vidéos, le web scraping, le navigateur, la mémoire, les providers TTS/STT et de modèles prenaient tous en charge l’intégration par plugin depuis longtemps — sauf les backends terminal. Le terminal touche trop de zones sensibles : approbations, chemins de conteneurs, caches, nettoyage des secrets — le plus grand rayon d’impact de tous les sous-systèmes. Le PR #94400 comble cette lacune : les fournisseurs de sandbox peuvent désormais écrire un plugin et laisser les utilisateurs définir directement terminal.backend: <your-backend-name>.

Il y a un vrai premier utilisateur derrière tout ça : le backend sandbox cloud Sprites (à l’origine #93523) a été le premier à migrer vers cette interface — il a rejoint un dépôt de plugin privé autonome au lieu de vivre dans le core.

À quoi ressemble un plugin : une classe ABC + une fonction d’enregistrement

Le mécanisme s’articule autour de deux nouveaux fichiers : agent/terminal_env_provider.py définit la classe de base abstraite TerminalEnvironmentProvider, et agent/terminal_env_registry.py est un registre thread-safe. Voici ce que fait l’auteur d’un plugin (l’exemple minimal du guide développeur officiel, developer-guide/terminal-environment-plugin.md) :

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

class AcmeBoxEnvironment:
    """Doit satisfaire le contrat 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):
        ...  # exécute la commande dans le sandbox
        return {"output": "...", "exit_code": 0}

    def cleanup(self):
        ...  # démonte / détache

class AcmeBoxProvider(TerminalEnvironmentProvider):
    name = "acmebox"
    display_name = "AcmeBox"
    is_remote = True       # les commandes ne s'exécutent pas sur l'hôte
    is_container = True    # sémantique de chemin/cwd de type conteneur

    @property
    def cache_path_base(self):
        return "~/.hermes"  # où atterrissent les fichiers de cache synchronisés, ou None

    @property
    def strip_env_keys(self):
        return frozenset({"ACMEBOX_TOKEN"})  # secrets retirés des sous-processus

    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())

Le répertoire du plugin contient aussi un plugin.yaml (name, version, kind: backend). Ensuite, activez-le et sélectionnez-le :

hermes plugins enable acmebox
hermes config set terminal.backend acmebox

Les noms de backends intégrés (local, docker, singularity, modal, daytona, vercel_sandbox, ssh) sont réservés — les plugins étendent l’ensemble, ils ne remplacent jamais un backend intégré.

Six flags de classification qui éliminent la classe de bugs « nouveau backend, emplacement oublié »

Par le passé, ajouter un backend signifiait synchroniser la logique de décision sur sept ou huit emplacements du code — quels backends sont distants, lesquels sont des conteneurs, lesquels sautent les approbations, comment les chemins de cache se traduisent — et en rater un était un bug difficile à trouver (l’issue #30112 a nécessité un balayage de sept emplacements). Le nouveau design déclare tout cela :

• is_remote : les commandes s’exécutent ailleurs que sur l’hôte. Supprime les indices d’OS/home/cwd de l’hôte, la sonde d’environnement Python de l’hôte et la gestion des skills tenant compte du distant ;
• is_container : se comporte comme un conteneur/sandbox avec son propre système de fichiers — la configuration de ressources du conteneur transite, les cwd qui ressemblent à l’hôte sont assainis, les outils de fichiers utilisent la résolution de chemins du conteneur ;
• skip_container_guards : le sandbox est assez isolé pour que les invites d’approbation des commandes dangereuses soient sautées (défaut : is_container ; les backends capables de monter des chemins de l’hôte doivent le passer à False) ;
• cache_path_base : où atterrissent les fichiers ~/.hermes/cache auto-synchronisés dans le backend (par ex. ~/.hermes ou /root/.hermes), ou None quand rien n’a besoin d’être traduit ;
• strip_env_keys : les variables d’environnement d’identification appartenant à ce backend (tokens API du fournisseur), retirées de chaque sous-processus lancé par l’agent pour que les commandes écrites par le modèle ne puissent jamais les lire ;
• session_isolated_when_nonpersistent : le mode non persistant donne à chaque session sa propre identité de sandbox au lieu d’en partager une.

Où le plugin apparaît une fois enregistré

Un backend enregistré n’est pas qu’une valeur de fichier de configuration — chaque surface le détecte automatiquement :

• Le sélecteur de backends de hermes setup affiche la nouvelle option avec une configuration guidée par le fournisseur ;
• hermes status / hermes doctor listent le backend du plugin et son état de santé ;
• Le sélecteur de backend terminal du dashboard prend en charge les backends à plugins et recalcule à chaque requête — un plugin installé en pleine session apparaît immédiatement.

Le guide développeur officiel détaille pas à pas l’écriture d’un plugin de backend à partir de zéro.

Ce que cela signifie pour les utilisateurs ordinaires

Si vous n’utilisez que les backends intégrés (terminal local, Docker, Modal, SSH), ce changement est invisible au niveau du comportement — c’est une porte architecturale, pas un interrupteur de comportement. C’est l’impact sur l’écosystème qui compte : quand un fournisseur de sandbox annonce « compatible Hermes », cela signifie désormais « installez le plugin », pas « attendez une fusion dans le core » ; la qualité du plugin relève de la responsabilité du fournisseur, et hermes doctor vous dit s’il est en bonne santé. Pour les bases des plugins, voir la référence de la commande hermes plugins ; pour le mécanisme de point d’entrée des providers installés via pip, notre guide du plugin de model-provider pip couvre la filiation. La sélection du backend au quotidien est documentée dans le guide d’installation.

Résumé

Les backends terminal à plugins transforment « faire utiliser mon sandbox cloud par Hermes » de « supplier pour une fusion dans le core » en « écrire un plugin, déclarer six flags, enregistrer, terminé ». C’est la dernière pièce de l’écosystème d’outils de Hermes à passer en natif-plugin — les backends tiers sont désormais découplés du core, avec une politique de sécurité appliquée uniformément via des flags déclaratifs.