Si votre Hermes exécute deux Profiles en même temps — l’un pour le serveur de votre entreprise, l’autre pour votre NAS domestique — lisez ceci avant toute chose : #92156, fusionnée dans main le 22 août, corrige une fuite qui pourrait vous faire exécuter des commandes sur le mauvais hôte. Cela semble très technique, mais la conséquence est directe : après un changement de Profile, vos commandes de terminal peuvent continuer silencieusement à utiliser l’environnement SSH mis en cache du Profile précédent — autrement dit, une commande que vous pensiez exécuter sur le serveur A s’est en réalité exécutée sur le serveur B.

Comment la fuite s’est produite

Le terminal de Hermes met en cache l’environnement distant de chaque session (comme SSHEnvironment) afin de ne pas rétablir les connexions à chaque commande. Ce cache vit dans un dictionnaire nommé _active_environments, indexé par une clé produite par _resolve_container_task_id().

Le problème venait de cette clé : chaque session WebUI / gateway retombait sur la clé commune "default". Ainsi, dans le même processus, le Profile A (ssh_host=10.0.0.1) et le Profile B (ssh_host=10.0.0.2) partageaient un seul emplacement de cache — après un changement de Profile, le terminal de B pouvait récupérer l’environnement SSH mis en cache de A, et les commandes s’exécutaient silencieusement sur 10.0.0.1 au lieu du 10.0.0.2 que vous visiez.

En SSH, c’est particulièrement dangereux : rm, git push, modifications de configuration — s’exécuter sur le mauvais hôte signifie des actions destructrices sur la mauvaise cible, sans aucun avertissement, car la sortie semble parfaitement normale.

Le correctif : un cache propre à chaque session

Le correctif de #92156 est simple : la clé de cache passe de "default" à session:<key>.

• La couche de streaming WebUI définit une clé de session dédiée pour chaque session ;
• La gateway injecte une clé de session par message via contextvars ;
• Après un changement de Profile (session), la nouvelle session obtient une clé de cache différente et ne peut plus réutiliser le SSHEnvironment du Profile précédent — les commandes ne peuvent donc plus être envoyées au mauvais hôte.

Notez ce que le correctif ne casse pas : les sous-agents partagent toujours le conteneur durable du parent, et les environnements RL / de benchmark (TerminalBench2, etc.) conservent leur isolation par tâche — ces chemins ont leurs propres règles de clés, et les enfants de delegate_task partagent toujours la connexion de la session parente.

Ce que vous devriez faire

1. Utilisateurs multi-Profiles + SSH : mettez à jour vers une build contenant le correctif (hermes update --branch main, ou attendez la prochaine version — la dernière stable est toujours v0.20.5) ;
2. Vérifiez-le : configurez deux Profiles avec des hôtes distants différents, exécutez hostname ou echo $SSH_CONNECTION dans chacun, et confirmez que la sortie correspond à la configuration de chaque Profile ;
3. Conseil général : les configurations multi-Profiles sont couvertes dans Hermes Profiles: Multiple Independent Instances ; les clés de configuration terminal/env sont également évoquées dans 4 Hidden Hermes Tricks.

Statut de la version

Le correctif (#92156) est fusionné dans main (22 août) et n’est pas encore dans une version publiée. Pour l’essayer en avant-première : hermes update --branch main. Il appartient au même lot de durcissement gateway/terminal de fin août que le guide d’ajustement du loop-watchdog.

Conclusion

La fuite d’environnement SSH entre Profiles est un piège invisible : pas une erreur, mais une exécution silencieuse sur le mauvais hôte. La bonne nouvelle, c’est que le correctif est déjà dans main — avec un cache délimité par session, un changement de Profile ne peut plus récupérer l’environnement distant du Profile précédent. Si vous êtes un gros utilisateur multi-Profiles, il vaut la peine de mettre à jour et de vérifier sans attendre.