Votre cron job est mort à 3 h du matin. Pas d’erreur, pas de notification — le panneau du planificateur affichait « tout va bien », et vous ne vous en êtes aperçu qu’à 9 h, quand les données étaient déjà périmées. Ce n’est pas une hypothèse : le 2026-08-14, la propre flotte hébergée de Hermes a manqué 4 exécutions nocturnes consécutives, et la seule trace était un simple WARNING sans éclat, noyé dans un fichier de log. v0.20.3 (tag v2026.8.16.2) est le patch exactement conçu pour cette classe de problèmes : il apprend à Hermes à constater ses propres échecs et à les réparer au lieu de vous laisser le désordre.

Cette fenêtre de développement a fusionné environ 125 PR et 250 commits. Les notes officielles promettent une documentation complète et soignée avec v0.21.0 — mais les parties les plus précieuses de ce patch s’expliquent dès maintenant, en quelques mots.

Cron : de « mourir en silence » à « s’auto-réparer »

Commençons par ce qui fait le plus mal. Le planificateur de Hermes avait plusieurs façons de mourir « en bonne santé » — chacune pouvait arrêter les jobs pendant des heures ou des jours pendant que le système semblait impeccable :

• Épuisement des descripteurs de fichiers (EMFILE) : le ticker traitait chaque erreur de verrou comme « quelqu’un d’autre tient le verrou », si bien qu’une exhaustion de fd sur le fichier de verrou était enregistrée comme un tick réussi — et plus aucun job ne tourna jamais ;
• Jobs bloqués : un job qui avait échoué une fois voyait son next_run_at parqué dans le futur, invisible pour toutes les passes de nettoyage, et il survivait même aux redémarrages du gateway ;
• Déclenchements manqués d’un provider externe : quand un cron hébergé comme Chronos ne délivrait jamais le déclenchement, le job restait parqué dans le passé pour toujours.

v0.20.3 corrige les trois. L’EMFILE est désormais signalé honnêtement, et le ticker tente une récupération des fd au mieux (backoff exponentiel, plafonné à 15 minutes) ; les jobs bloqués se réarment automatiquement au tick suivant — en respectant l’expression cron, pour qu’un planning réservé à la semaine ne se déclenche jamais un samedi ; et les déclenchements manqués par les providers externes sont rattrapés localement par le gateway après une fenêtre de grâce.

La fenêtre de rattrapage est configurable :

cron:
  misfire_grace_minutes: 10   # défaut : 10 ; 0 ou négatif désactive le rattrapage

Tout aussi important : les exécutions manquées sont enfin visibles. Chaque déclenchement échoué appose un last_fire_error sur l’enregistrement du job, affiché sous la forme d’une ligne rouge ⚠ Missed scheduled fire: dans hermes cron list, ainsi que dans le dashboard et dans la sortie de l’outil cronjob list de l’agent ; la prochaine exécution réussie l’efface. Fini de fouiller les logs pour savoir si un job a tourné : il suffit de lancer :

hermes cron list

Si vous utilisez un provider cron externe (Chronos / cron managé hébergé), lancez cette commande une fois après la mise à niveau pour confirmer qu’il ne reste rien en attente. Pour le tableau complet — planification, supervision et vérifications préalables — consultez notre guide complet de la cron automation.

MCP : à l’écoute du protocole sans état du 2026-07-28

Cette fenêtre a aussi vu la migration vers le SDK MCP 2.x et le support de bout en bout du protocole sans état publié le 2026-07-28 — en clair, la nouvelle génération de serveurs MCP n’exige plus de poignée de main initialize, et Hermes s’y connecte sans aucune configuration supplémentaire.

Chaque serveur MCP peut déclarer une clé protocol :

mcp:
  servers:
    my-server:
      url: https://example.com/mcp
      protocol: auto   # auto (défaut) : essayer la poignée de main héritée, sinon repli sur server/discover

auto ne coûte aucun aller-retour supplémentaire à la flotte existante, stateless explore en premier (discover-first), et legacy désactive complètement le repli. Deux détails de la spec sont également gérés : les indices de cache ttlMs/cacheScope renvoyés par tools/list alimentent un cache de schéma avec TTL, et l’enregistrement OAuth suit la nouvelle spec (native application_type + validation iss selon RFC 9207). Plus de profondeur sur la configuration MCP dans notre guide des variables de contexte MCP.

Nouveaux providers : CommandCode et Muse Spark

Deux providers rejoignent la liste dans cette fenêtre :

CommandCode (commandcode.ai) devient un provider de première classe — une seule clé couvre plus de 30 modèles ouverts et fermés à travers les offres GOAT/Pro/Max/Provider :

hermes setup   # ou configuration manuelle
export COMMANDCODE_API_KEY="your-key"
hermes --provider commandcode

Vous préférez l’API Messages d’Anthropic ? Le profil commandcode-anthropic la parle avec la même clé. Et sur main (pas encore inclus dans aucun tag de release), la Meta Model API (Muse Spark) rejoint le jeu comme plugin intégré — --provider meta-ai fonctionne directement avec l’authentification MODEL_API_KEY (l’alias META_API_KEY marche aussi), et propose muse-spark-1.2 ainsi que muse-spark-1.2-contributor.

Des boutons « annuler » pour les modifications de l’agent : /worktree et /rollback

Deux commandes inspirées de Copilot CLI sont arrivées pour apaiser l’angoisse du « l’agent a saccagé mon dépôt ».

/worktree new ouvre un worktree git isolé en pleine session, sans redémarrer :

/worktree new my-experiment

Hermes crée .worktrees/my-experiment/ dans le dépôt (branche basée sur le pointeur remote fraîchement récupéré) et redirige vers lui les opérations terminal et fichiers de la session. Une fois terminé, l’arbre n’est conservé que s’il contient des commits non poussés, exactement comme avec hermes -w. /worktree seul affiche l’arbre actif ; /worktree list les liste tous.

/rollback adopte désormais par défaut une restauration sûre : Hermes tient un registre par projet de chaque fichier qu’il a écrit (sha256 de chaque écriture posée), si bien qu’un rollback ne révoque que les modifications écrites par l’agent, supprime les fichiers créés par l’agent et préserve vos modifications manuelles. Passez --all ou --force pour tout restaurer ; les fichiers ignorés sont signalés avec une indication. Si l’agent a massacré un fichier que vous aviez aussi édité à la main, c’est la différence entre un sauvetage et une catastrophe.

Mise à jour

hermes update

Ensuite, lancez hermes doctor pour vérifier l’installation, puis redémarrez le gateway (hermes gateway). Si vous utilisez un provider cron externe, vérifiez une fois hermes cron list — assurez-vous qu’il n’y a pas d’arriéré.

La liste complète des changements figure dans les notes de version v0.20.3 ; les points forts du patch précédent — registre de connexions et deep-links MCP — sont dans notre analyse de v0.20.2.