Vous passez de Claude Code à Codex, de Gemini CLI à Cursor, ou vous confiez la même session à plusieurs assistants selon les tâches ? Sur le papier, le changement d'outil paraît simple. Puis, très vite, une partie du contexte disparaît : une décision d'architecture n'est plus connue, une règle locale n'est pas appliquée, ou l'assistant repart sur un résumé trop incomplet.
Le cœur du problème, c'est la compaction. Quand la fenêtre de contexte approche de sa limite, l'assistant résume (ou remplace) une portion de l'historique. Sauf que tous les outils ne le font pas pareil. Certains réinjectent des consignes depuis les fichiers du projet ; d'autres gardent certains messages, filtrent le raisonnement, ou créent un point de reprise calibré.
La version 0.5 de session-handover propose une matrice pour comparer ces comportements sur huit environnements. On y trouve quoi est comparé, comment utiliser l'outil et, surtout, comment lire les résultats sans les prendre pour une promesse de conservation.
Pourquoi la compaction complique le passage d'un outil à l'autre
Un assistant de développement ne se limite pas au code visible dans l'éditeur. Il s'appuie aussi sur l'historique de la conversation, les consignes liées au projet, les fichiers consultés, et les décisions prises pendant la session. Quand tout ça devient trop volumineux, le système doit gérer la limite de contexte. La compaction est l'un des leviers utilisés pour réduire ou réorganiser ce qui reste.
Pour une équipe, le vrai point n'est pas juste « est-ce que l'outil oublie ? ». La question pratique est plutôt : quelles informations restent accessibles, par quel mécanisme, et sous quelle forme. Un résumé peut garder l'objectif général tout en faisant sauter une contrainte précise. À l'inverse, une règle stockée dans un fichier du dépôt peut ressortir après compaction, mais seulement si l'assistant la relit vraiment au bon moment, et si elle s'applique à la tâche.
On voit souvent deux questions qui se mélangent :
- L'assistant peut-il continuer ?
- L'assistant a-t-il conservé ce dont il a besoin pour bien continuer ?
La première peut être vraie alors que la seconde reste franchement incertaine.
Un résumé n'est pas une sauvegarde complète
Dans un projet réel, des détails « secondaires » en conversation peuvent devenir cruciaux plus tard : une migration volontairement reportée, une API à ne pas toucher, une exception métier, un choix fait pour respecter une contrainte de production. Un résumé sert à rendre le contexte exploitable, pas à rejouer mot pour mot chaque élément de l'historique.
Le changement d'outil rend l'écart plus visible
Les équipes n'utilisent rarement un environnement de façon parfaitement uniforme. Un développeur peut demander un changement dans Cursor, vérifier ensuite dans un terminal avec Codex, puis reprendre une investigation dans Claude Code. Et chaque outil a ses conventions : gestion de session, façons de conserver ou non des éléments, et règles implicites.
Résultat : une information conservée par un assistant peut ne pas être relue par un autre. Les noms de fichiers peuvent changer ; le mécanisme de reprise aussi. Et plus les passages entre outils sont fréquents, plus le risque opérationnel s'accumule - d'où l'importance de distinguer le contexte conversationnel temporaire et les informations durables du projet.
C'est exactement le point de départ de session-handover. L'outil ne cherche pas à « uniformiser » les assistants : il veut rendre leurs différences visibles pour que l'équipe sache quoi stocker où, pour que ça survive à une compaction.
Ce que compare la matrice de session-handover
La version 0.5 élargit l'audit : au lieu de se limiter à Claude Code, elle le fait sur huit environnements : Claude Code, Codex CLI, Gemini CLI, Aider, OpenCode, Copilot CLI, Cursor et Cline. Pour chacun, la matrice documente quatre dimensions : le déclencheur de compaction, le mécanisme utilisé, ce qui a des chances de rester ou de disparaître, et les emplacements d'ancrage recommandés.
L'objectif n'est pas de déclarer un « meilleur outil ». Ces assistants n'ont pas forcément les mêmes objectifs, formats de conversation, ni mécanismes internes. La comparaison sert surtout à répondre à une question simple : avant qu'un contexte soit résumé ou remplacé, où faut-il écrire l'info pour qu'elle soit encore disponible après ?
Des ancrages propres à chaque environnement
La matrice pointe vers des fichiers ou emplacements de référence selon les outils. On retrouve par exemple CLAUDE.md pour Claude Code, GEMINI.md pour Gemini CLI, AGENTS.md pour OpenCode, copilot-instructions.md pour Copilot CLI, ainsi que .cursor/rules et .clinerules pour Cursor et Cline. Pour Aider, l'ancrage mentionné correspond aux fichiers du projet suivis dans le dépôt.
Attention : ce sont des repères, pas une règle universelle. Il faut vérifier la configuration et les conventions réellement utilisées par votre version de l'outil. Le nom d'un fichier ne suffit pas : il faut aussi qu'il soit au bon endroit, versionné si nécessaire, et pertinent pour le répertoire concerné.
Le rapport distingue aussi ce qui est réinjecté et ce qui risque de disparaître. Par exemple, selon l'étude citée par le projet, le CLAUDE.md à la racine du projet a été réinjecté lors de huit compactions mesurées sur huit avec Claude Code. En revanche, les règles attachées à un chemin particulier et les CLAUDE.md imbriqués peuvent ne pas revenir tant que le fichier correspondant n'a pas été relu. Les corps de compétences invoqués sont revenus dans six cas sur huit, parfois avec un texte devenu obsolète après modification.
Le message sous-jacent est important : ce n'est pas seulement « est-ce que la consigne existe dans le dépôt ? ». C'est aussi « où est-elle », et « est-elle relue au moment où l'assistant en a besoin ? »
Générer une vue d'ensemble ou isoler un cas
Après installation depuis PyPI, la commande principale est :
pip install session-handover
session-handover compact-matrix
Pour produire un rapport complet dans un fichier Markdown :
session-handover compact-matrix --out MATRIX.mdLa comparaison de deux environnements se fait avec --compare, par exemple :
session-handover compact-matrix --compare claude-code codex-cliEt pour examiner un seul environnement :
session-handover compact-matrix --harness codex-cliEn pratique, cette progression aide : commencez par la vue d'ensemble si vous devez définir une convention d'équipe. Puis passez à une comparaison ciblée si vous voulez comprendre un passage précis - par exemple entre l'outil principal d'un développeur et celui utilisé en intégration continue.
Ce que la version 0.5 apporte à l'audit de Codex
La version 0.5 améliore aussi la détection des compactions de Codex CLI dans la commande audit-compact. Les versions précédentes s'appuyaient sur des chaînes marqueurs assez simples. D'après le projet, cette approche couvrait moins bien les formes de points de reprise observées en vrai.
Désormais, l'audit reconnaît plusieurs structures décrites dans la publication : un message assistant distant de type CONTEXT CHECKPOINT, le préfixe utilisé par le mécanisme local de repli - « another language model started to solve this problem... » - et des éléments de réponse de type compaction.
Pourquoi reconnaître la vraie frontière compte
Pour analyser une compaction, il faut distinguer le déclencheur de l'événement qui remplace ou réorganise réellement le contexte. Une ligne de commande /compact peut signaler une intention de compaction, mais ce n'est pas suffisant à elle seule pour prouver qu'un point de reprise a été produit.
Avec la version 0.5, une ligne isolée /compact n'est plus traitée comme frontière de compaction. C'est une correction utile : elle évite de compter un événement qui n'a pas été confirmé par la structure correspondante. Dans un audit, une frontière mal identifiée peut fausser ce qu'on pense « perdu » : on attribue alors à une compaction des changements qui ne se sont peut-être pas produits.
Le cas Codex illustre bien que les comportements internes importent. Le rapport décrit un mécanisme distant v2 qui renvoie un bloc chiffré avec des messages utilisateur conservés. Il distingue aussi un mécanisme local de repli : il supprime les messages assistant et transforme le résumé en message utilisateur CONTEXT CHECKPOINT. Les éléments de raisonnement sont filtrés avant la synthèse. Le prompt de compaction est configurable depuis la version 0.50, selon les informations publiées par le projet.
Tout ça ne veut pas dire qu'un mode est « meilleur » en toutes circonstances. Ça change plutôt ce que l'audit peut observer et ce que vous devrez vérifier sur place. Si un détail de comportement vous dépend réellement, confirmez-le avec la version et la configuration déployées dans votre environnement, plutôt que de généraliser.
Mettre en place un audit sans surinterpréter les résultats
Une matrice de compaction est utile si elle sert à prendre une décision. Par contre, elle ne remplace ni vos tests, ni une procédure de passation claire entre développeurs. Voici une manière pragmatique de l'intégrer.
1. Repérer les passages entre outils
Commencez par lister les environnements réellement utilisés, pas ceux qui pourraient être adoptés « un jour ». Puis repérez les moments où une session change de mains : reprise après une longue investigation, usage d'un assistant différent pour les tests, transfert vers un poste de travail distinct.
Cette cartographie évite de perdre du temps sur des comparaisons sans enjeu. Si votre équipe travaille presque toujours dans un seul outil, auditer huit environnements n'a probablement pas beaucoup de valeur. En revanche, si les développeurs alternent plusieurs interfaces, l'effort vaut le coup pour identifier les écarts les plus risqués.
2. Identifier les informations à forte valeur de reprise
Tentez de classer les éléments de contexte selon leur durée de vie :
- Durables : conventions du projet, décisions d'architecture, contraintes métier, commandes de validation, règles de sécurité.
- Temporaires : hypothèses encore ouvertes, pistes de débogage, résultats d'une commande ou prochaine action immédiate.
- À vérifier : informations susceptibles de devenir obsolètes, comme une consigne modifiée ou un résultat obtenu avant une mise à jour du code.
Tout ne doit pas finir dans un fichier de consignes. Un fichier de règles qui se transforme en journal de session est généralement vite ignoré. L'idée est de déplacer ce qui mérite d'être réutilisé vers des emplacements versionnés et lisibles, puis de garder les détails transitoires dans la conversation ou dans un rapport de tâche.
3. Choisir des ancrages explicites et maintenables
Utilisez les fichiers documentés par vos outils, mais gardez une source de vérité facile à comprendre pour l'équipe. Si plusieurs assistants lisent des fichiers différents, évitez de recopier manuellement les mêmes règles un peu partout. À la cinquantième modification, les divergences deviennent un vrai problème de maintenance.
Une convention qui marche souvent : placer les règles générales dans une documentation centrale du dépôt, puis réserver les fichiers spécifiques aux assistants aux instructions qui ne peuvent pas être partagées directement. Et vérifiez que chaque outil lit effectivement les fichiers concernés. La matrice donne des pistes ; un essai sur votre dépôt confirme le comportement utile.
4. Tester la reprise, pas seulement la détection
L'audit de la compaction aide à repérer une frontière et à comparer ce qui semble survivre ou disparaître. Mais la validation réelle, c'est de vérifier que l'assistant reprend correctement une tâche après cette frontière.
Choisissez un scénario reproductible : une contrainte pas évidente, une décision à respecter, et une action attendue. Lancez la session, déclenchez ou observez la compaction, puis vérifiez la reprise.
Cette approche met au jour des problèmes que la présence d'un mot-clé ne suffit pas à révéler. Elle sert aussi à confirmer que les fichiers « durables » sont bien relus et ne contiennent pas une consigne dépassée.
Comprendre les limites de l'outil
Le projet précise que l'extraction est une heuristique de rappel. La correspondance repose sur le chevauchement de jetons, pas sur une compréhension sémantique. En clair : deux formulations équivalentes peuvent ne pas être reconnues comme identiques ; à l'inverse, une correspondance lexicale ne garantit pas que le sens soit préservé.
Les entrées attribuées à « la communauté » sont largement rapportées, mais pas formellement vérifiées. Il faut les traiter comme des indications à confirmer, pas comme des spécifications garanties. Le projet recommande de tester les comportements avant d'en faire des règles d'équipe.
Autre point pratique : par défaut, l'audit ne bloque pas le processus et rend un code de sortie nul. L'option --fail-on-drop permet de faire échouer un contrôle en intégration continue quand des pertes sont détectées. C'est pertinent pour des informations critiques, mais ça mérite d'être testé avec vos données : si l'heuristique est trop sensible, vous allez vite produire du bruit et rendre le contrôle pénible à maintenir.
Enfin, session-handover reste un outil léger, sans dépendances autres que la bibliothèque standard de Python, et ne vise pas à remplacer un processus complet de spécification. Son périmètre est plus ciblé : observer la frontière de compaction et comparer ce qui semble survivre ou être perdu. La version 0.5 ajoute 18 tests, annoncés comme réussis par le projet, mais ça ne remplace pas une validation dans votre propre configuration.
Pour consulter l'annonce d'origine, vous pouvez lire la publication sur la matrice de compaction. Le code et les informations de distribution sont à rechercher sur PyPI.
Conclusion : rendre le contexte durable
La version 0.5 de session-handover apporte surtout une vue comparative sur un problème très concret : dès qu'une équipe change d'assistant, une session n'est pas un format de mémoire « universel ». Le même travail peut être résumé, filtré ou repris différemment selon l'outil.
La bonne réponse n'est pas de tout archiver dans un fichier, ni de croire qu'un résumé suffit. Il faut plutôt repérer les décisions qui doivent survivre, les placer dans des emplacements versionnés, puis vérifier qu'elles sont relues après compaction. La matrice sert à cibler les essais ; elle ne remplace pas ces essais.
Si votre équipe utilise plusieurs assistants, commencez par exécuter session-handover compact-matrix, puis testez un scénario de reprise représentatif de votre dépôt. Au final, ce qui compte n'est pas un classement des outils : c'est une convention de passation suffisamment simple pour être réellement appliquée.