Checkpoints et `/rollback` — Votre filet de sécurité pour les opérations destructrices

Checkpoints et /rollback — Votre filet de sécurité pour les opérations destructrices

Vous avez déjà regardé un agent IA exécuter une commande comme rm -rf ou écraser un fichier en vous disant : « J’espère vraiment qu’il sait ce qu’il fait » ? Avec Hermes Agent v2, vous disposez désormais d’un vrai filet de sécurité — les checkpoints — qui peuvent figer l’état de votre projet avant une opération risquée et le restaurer en une seule commande.

Le meilleur dans tout ça ? C’est complètement optionnel. La plupart des utilisateurs ne toucheront jamais à /rollback, et comme le stockage shadow peut grossir avec le temps, la fonctionnalité est désactivée par défaut. Mais quand vous en avez besoin, c’est une bouée de sauvetage.

Activer les checkpoints

Vous pouvez activer les checkpoints par session avec un simple flag :

hermes chat --checkpoints

Ou les activer globalement dans ~/.hermes/config.yaml :

checkpoints:
  enabled: true

Et voilà. Une fois activés, Hermes prend automatiquement un instantané de votre projet avant toute action destructrice.

Ce qui déclenche un checkpoint

Hermes prend un checkpoint automatiquement avant :

• Les outils de fichiers — write_file et patch
• Les commandes terminal destructrices — rm, rmdir, cp, install, mv, sed -i, truncate, dd, shred, les redirections de sortie (>), et git reset/clean/checkout

L’agent crée au maximum un checkpoint par répertoire et par tour, afin que les sessions longues ne spamment pas d’instantanés et ne gonflent pas votre stockage.

Comment ça fonctionne sous le capot

La magie opère via un gestionnaire de checkpoints interne qui maintient un dépôt git shadow partagé dans ~/.hermes/checkpoints/store/. Le vrai .git de votre projet n’est jamais touché — tout vit dans ce dépôt séparé.

Voici le flux :

1. Hermes détecte quand des outils s’apprêtent à modifier des fichiers dans votre arbre de travail.
2. Une fois par tour de conversation (et par répertoire), il détermine une racine de projet raisonnable.
3. Il initialise ou réutilise le dépôt shadow partagé.
4. Il indexe les fichiers dans un index par projet, construit un arbre, et commit vers une référence par projet (refs/hermes/<project-hash>).

Comme tous les projets partagent le même dépôt, la base de données d’objets adressables par contenu de git déduplique entre les projets et entre les tours — pas de gaspillage d’espace pour du contenu identique.

Utiliser /rollback en session

Une fois en session avec les checkpoints activés, plusieurs commandes slash sont à votre disposition :

Commande	Description
/rollback	Liste tous les checkpoints avec les statistiques de modifications
/rollback <N>	Restaure le checkpoint N, en conservant vos modifications manuelles (annule aussi le dernier tour de chat)
/rollback <N> --all	Restauration complète — écrase aussi vos modifications manuelles
/rollback diff <N>	Aperçu du diff entre le checkpoint N et l’état actuel
/rollback <N> <file>	Restaure un seul fichier depuis le checkpoint N

Quand vous lancez /rollback, vous voyez une liste formatée comme ceci :

📸 Checkpoints pour /path/to/project :

  1. 4270a8c  2026-03-16 04:36  avant patch  (1 fichier, +1/-0)
  2. eaf4c1f  2026-03-16 04:35  avant write_file
  3. b3f9d2e  2026-03-16 04:34  avant terminal : sed -i s/old/new/ config.py  (1 fichier, +1/-1)

Gérer le dépôt depuis le shell

En dehors d’une session, vous pouvez inspecter et gérer le dépôt de checkpoints avec les commandes CLI :

Commande	Description
hermes checkpoints	Affiche la taille totale, le nombre de projets, le détail par projet
hermes checkpoints status	Identique à checkpoints seul
hermes checkpoints list	Alias de status
hermes checkpoints prune	Force un nettoyage : supprime les orphelins/obsolètes, garbage collect, applique la limite de taille
hermes checkpoints clear	Supprime toute la base de checkpoints (demande confirmation)
hermes checkpoints clear-legacy	Supprime uniquement les archives legacy-* de la migration v1

Options de configuration

Vous pouvez affiner le comportement des checkpoints dans ~/.hermes/config.yaml :

checkpoints:
  enabled: false              # interrupteur principal (défaut : false — opt-in)
  max_snapshots: 20           # nombre max de checkpoints par projet
  max_total_size_mb: 500      # plafond dur sur la taille totale du dépôt
  max_file_size_mb: 10        # ignore tout fichier individuel plus gros que ça
  auto_prune: true            # nettoyage au démarrage (activé par défaut)
  retention_days: 7           # supprime les entrées plus anciennes que ça
  min_interval_hours: 24      # temps minimum entre deux nettoyages automatiques

Point important : le nettoyage automatique ne supprime jamais les entrées « orphelines » (quand le répertoire de travail est introuvable). C’est parce qu’un workdir manquant au démarrage peut signifier un projet supprimé — ou un volume externe ou partage réseau pas encore monté. Le nettoyage des orphelins ne se fait que via la commande explicite hermes checkpoints prune, qui demande confirmation au préalable.

Pour tout désactiver :

checkpoints:
  enabled: false
  auto_prune: false

Quand enabled: false, le gestionnaire de checkpoints est inopérant et ne tente jamais d’opérations git. Quand auto_prune: false, le dépôt grossit jusqu’à ce que vous lanciez manuellement hermes checkpoints prune.

Pour conclure

Les checkpoints vous donnent la confiance nécessaire pour laisser Hermes travailler librement, en sachant que vous pouvez toujours revenir à un état connu et stable. Que vous expérimentiez des refactorisations, testiez des commandes risquées, ou que vous vouliez simplement l’esprit tranquille, la commande /rollback veille sur vous.

Essayez-la lors de votre prochaine session — vous découvrirez peut-être qu’elle devient un élément essentiel de votre flux de travail.