Hermes v0.20.6 : l'agent apprend à naviguer comme vous, un catalogue MCP de plus de 50 serveurs, et des secrets sans le harcèlement du keychain

Vous demandez à votre agent de vérifier quelque chose dans le dashboard de votre entreprise — « ouvre la page de déploiement et dis-moi quelle version est en ligne » — et il revient avec un mur de connexion, parce que le browser qu’il pilote démarre chaque session déconnecté. Alors vous copiez l’URL dans votre propre browser, vous vous connectez, et vous faites tout à la main. Cette petite friction est exactement ce que vise la v0.20.6 (tag v2026.8.27, publiée le 27 août 2026) : l’agent peut désormais naviguer comme vous, avec vos identifiants réels, sous consentement explicite et désactivé par défaut.
Depuis la v0.20.5, la fenêtre a fusionné environ 525 PR et ~1 313 commits sur ~1 557 fichiers. Le titre, c’est la navigation avec profil réel sous consentement explicite, mais la version enchaîne ensuite : un Browser de bureau qui obtient enfin sa propre fenêtre système, un moteur de mise à jour distante managé par SSH pour les fleets, un catalogue MCP distant dépassant les 50 serveurs d’éditeurs vérifiés en conditions réelles, la mise en cache TTL pour la recherche web, la compression lean-tail par défaut, un tool_search multi-requêtes, et le chiffrement opt-in via le keychain de l’OS pour les secrets stockés. Passons-les en revue.
L’agent navigue comme vous — sous consentement explicite, désactivé par défaut
La navigation avec profil réel est le titre pour une bonne raison. Lorsqu’elle est activée (browser.use_real_profile: true, ou Réglages → Browser → Utiliser mon profil de browser réel dans l’application de bureau), Hermes copie le profil actif de votre browser par défaut — celui avec lequel vous naviguez réellement, avec ses cookies, identifiants enregistrés et préférences — dans un snapshot managé sous ~/.hermes/browser-profile/, et pilote ce snapshot avec son Chromium intégré (#1f4d095fd8, #830e4a29be).
Trois détails comptent :
- Votre profil en cours n’est jamais ouvert directement. Le snapshot est un répertoire séparé, il ne se dispute donc pas le verrou de profil avec votre browser en cours d’exécution, et il contourne le blocage de Chrome 136+ sur le débogage distant du répertoire de profil par défaut.
- L’authentification se resynchronise. Les cookies et identifiants sont recopiés à chaque lancement d’une nouvelle session, si bien qu’une connexion effectuée dans votre propre browser apparaît dans la session suivante de l’agent.
- Révoquer le consentement supprime tout. Désactivez l’option et le stockage de snapshots est supprimé à la prochaine utilisation du browser — les identifiants copiés ne subsistent pas après le retrait de votre consentement.
Windows a une particularité : Chrome/Edge/Brave verrouillent leurs bases de cookies avec un verrou tout-refus pendant qu’ils tournent, le browser doit donc être entièrement quitté avant que le profil puisse être copié (Hermes échoue rapidement avec un message clair plutôt que de rester bloqué). Définir browser.real_profile_autoclose: true permet à l’agent de proposer de le fermer à votre place — il ne le ferme jamais de lui-même, et si le profil est toujours verrouillé après cela, il reste bloqué et vous demande de quitter le browser. Les browsers par défaut non-Chromium (Firefox) échouent en mode fermé avec un message clair. Dans l’outil browser_exec, un argument local apparaît lorsque l’option est activée, forçant une session avec profil réel même sur un backend de browser cloud.
Est-ce sûr ? C’est une commodité sous consentement, pas une frontière d’isolation : une page visitée par l’agent s’exécute avec vos identifiants réels. C’est exactement pour cela que c’est désactivé par défaut — activez-le quand vous voulez que l’agent agisse comme vous. Pour les mécanismes du fonctionnement des outils de browser, voir notre guide du Browser Use CLI et l’article sur le budget de snapshot du browser.
Le Browser de bureau grandit : sa propre fenêtre système + des mises à jour SSH managées
Le Browser de bureau était un panneau intégré ; il peut désormais s’ouvrir dans sa propre fenêtre système — redimensionnez-la, déplacez-la entre vos écrans, gardez-la épinglée à côté de votre éditeur. Si vous avez déjà souhaité que le panneau d’aperçu ait plus de place, c’est maintenant.
L’autre histoire du bureau, c’est un moteur de mise à jour distante managé par SSH : les mises à jour peuvent désormais être pilotées par connexion SSH pour les gateways distants, si bien qu’une fleet de machines reste à jour depuis une seule application de bureau. Le rail de profil de fleet suit : changez de profil et les cibles de mise à jour changent avec vous. Combiné aux améliorations de mise à jour ci-dessous, « tout mettre à jour » devient une opération en un clic et vérifiable. Pour l’histoire complète des mises à jour, voir notre guide de mise à niveau gracieuse.
Un catalogue MCP distant de plus de 50 serveurs vérifiés
Le catalogue MCP distant intégré continue de grandir : plus de 50 serveurs hébergés par des éditeurs, vérifiés en conditions réelles — Cloudflare, Grafana Cloud, Better Stack, Railway, Canva, Dropbox, GitLab, Strava et bien d’autres. Chaque entrée est vérifiée contre l’endpoint live de l’éditeur, et ?codemode=false est verrouillé pour que tool_search voie toute la surface d’endpoints. Si vous n’avez pas regardé le contenu du catalogue récemment, cela vaut le coup d’œil :
hermes mcp catalog list --remote
Pour un regard plus approfondi sur le catalogue lui-même, voir notre guide du catalogue MCP distant officiel.
Caching, compression et recherche d’outils plus intelligente
Trois améliorations plus discrètes qui économisent des tokens et de l’argent chaque jour :
- Mise en cache TTL des résultats pour
web_search/web_extract: les recherches répétées dans la fenêtre TTL renvoient le résultat en cache au lieu de refacturer le fournisseur. Une nouvelle tentative, une réexécution, un job cron qui vérifie la même URL — tout coûte moins cher. (Configurable viaweb.cache_ttl; voir notre article sur le cache de recherche web pour l’histoire complète.) - La compression lean-tail est désormais le mode par défaut : après compression, l’agent conserve un résumé compact plus une courte traîne de haute valeur au lieu d’une longue traîne de faible valeur — moins de choses à renvoyer à chaque tour, coût réduit. Notre guide de compression couvre les réglages.
tool_searchmulti-requêtes avec racinisation :tool_searchaccepte désormaisqueries: string[], en cherchant chacune indépendamment (limite par requête, 5 par défaut / 25 maximum), ettool_describeacceptenames: string[]en renvoyant une carte indexée par nom — un seul mauvais nom ne fait plus échouer tout l’appel. La racinisation Snowball fait correspondre « browsing » à « browser ».
{ "queries": ["browser snapshot", "web search cache", "read pdf"] }
Résultat : moins d’allers-retours quand l’agent cherche le bon outil, et une découverte moins coûteuse. Nous avons détaillé tout cela dans notre guide tool_search multi-requêtes.
Des secrets sans le harcèlement du keychain
Si vous utilisez le bureau Hermes sur macOS, vous avez peut-être rencontré la boîte de dialogue « Keychain Not Found » — le safeStorage d’Electron dépose une clé par application dans le keychain de connexion, et sur les machines avec un keychain verrouillé, manquant ou corrompu, chaque lancement se transformait en invite de mot de passe bloquante. La v0.20.6 fait du chiffrement adossé au keychain un opt-in explicite (Réglages → Gateway) : le chemin par défaut ne touche jamais à safeStorage, et une migration en un seul passage convertit les blobs chiffrés existants en fichiers 0600 en clair au premier lancement. Activez l’option et chaque magasin de secrets stocké est ré-encodé sur place. Plus d’invite, et un chiffrement complet si vous le souhaitez. Configuration complète dans notre guide de chiffrement des secrets par keychain.
Des mises à jour qui ne tuent pas votre gateway
Les programmes de mise à jour mettent désormais les gateways en pause via la socket de contrôle au lieu de les tuer en cascade : les services se mettent en veille, la mise à jour est appliquée, les gateways reprennent — les tours en cours et les connexions de messagerie survivent à la mise à niveau. Les installations gérées par image/paquet refusent également les mises à jour sur place dangereuses via une porte partagée unique (#91277 Phase 3), et les fichiers utilisateur gitignored bloquent l’écrasement destructif par ZIP (#96440). Le programme de mise à jour continue de prouver son résultat, poursuivant la trajectoire couverte dans les notes de version de maintenance v0.20.5.
Autres points notables
- Cron : accusés de réception durables pour les incidents — accusez une fois l’incident d’un job et l’accusé persiste ; échecs de dérive de code plus clairs lorsque le planificateur et le gateway ne s’accordent pas.
- Slack : contrôles de dépliage des liens pour que les équipes puissent empêcher les liens de l’agent de se déployer en cartes.
- Docker : les profils de confiance peuvent opter pour un conteneur persistant partagé unique ; les sandbox tiers se branchent en tant que backends de terminal sans toucher au cœur.
- Modèles : GLM-5.3-Flash arrive dans les sélecteurs z.ai + OpenCode, MiniMax M3 free rejoint OpenRouter, MiniMax H3 Max rejoint le sélecteur vidéo FAL.
- Fiabilité du gateway : vivacité de boucle à deux témoins — le battement de cœur du watchdog ne peut plus geler ni tuer un gateway sain (#92315) ; le double kill de launchd
--replaceest corrigé via un redémarrage gracieux SIGUSR1 (#96427).
Pour le détail complet point par point, y compris les listes complètes des améliorations et corrections, voir nos notes de version v0.20.6. La mise à niveau est simple :
hermes update
Après la mise à niveau, exécutez hermes doctor et redémarrez le gateway (hermes gateway) afin que les changements de plateforme prennent effet. La v0.20.6 n’a pas besoin d’un seul titre spectaculaire — c’est une avancée régulière où l’agent vous rejoint enfin sur votre propre web authentifié, et où les corvées quotidiennes (caching, compression, keychain, mises à jour) se retirent discrètement de votre chemin.