Un worktree Git donne à chaque agent un checkout distinct, c’est-à-dire sa propre copie de travail liée à une branche. Les fichiers de deux agents ne se retrouvent donc pas dans le même répertoire de travail, mais leurs changements doivent encore être intégrés.

Cette séparation permet de faire avancer plusieurs tâches en parallèle. Le point de friction arrive ensuite : quand les branches sont réunies, Git doit combiner leurs modifications, et le résultat mérite une revue.

Donnez à chaque agent un espace de travail distinct, puis relisez et testez le résultat de la fusion.

Les worktrees séparent les fichiers, pas les étapes d’intégration

Deux agents peuvent modifier des versions différentes du même fichier sans écrire dans le même checkout. Si leurs changements portent sur des lignes distinctes, Git peut les combiner ; s’ils se chevauchent, il peut demander de résoudre un conflit. La documentation Git sur les conflits de fusion précise aussi qu’une fusion sans conflit textuel ne garantit pas que le code fonctionne : par exemple, un appel peut encore viser le nom d’une fonction qui a été renommée.

La fusion est donc une étape à part entière. Il faut examiner le code combiné et lancer les tests du projet, même si Git n’a signalé aucun conflit. Dans Cursor, /best-of-n suit la même logique : les propositions sont produites dans des worktrees séparés et comparées, mais elles ne sont pas fusionnées automatiquement. Il faut choisir un résultat et l’appliquer.

Dans Cursor, l’interface dépend du flux choisi

Cursor propose ses worktrees natifs dans l’Agents Window. Dans l’IDE, la documentation décrit plutôt les commandes Worktree Skills, dont /worktree, /best-of-n, /apply-worktree et /delete-worktree. Les deux parcours donnent accès à des worktrees, mais ne passent pas par la même interface. La documentation de Cursor sur les worktrees détaille ces options.

Pour préparer un worktree, le fichier .cursor/worktrees.json accepte des clés de configuration génériques, Unix ou Windows. Elles peuvent lancer une suite de commandes, exécutées l’une après l’autre, ou désigner un script. Cursor cherche ce fichier dans le chemin du worktree, puis à la racine du projet. Cela permet de définir une préparation adaptée au système ou au projet sans confondre cette configuration avec la fusion des branches.

Le nettoyage peut inclure les worktrees créés avec Git

Pour Cursor 3.5 et les versions suivantes, la documentation indique une limite par défaut de 25 worktrees par machine. Les worktrees créés manuellement avec git worktree add peuvent eux aussi être nettoyés automatiquement. Un worktree manuel n’est donc pas à l’abri du mécanisme de nettoyage de Cursor ; vérifiez les paramètres de nettoyage avant d’y laisser du travail à conserver. Cursor donne également six heures comme exemple d’intervalle de nettoyage, pas comme réglage appliqué à toutes les installations.

Une réponse datée de Cursor sur les interruptions d’agent

Le 10 septembre 2026, un membre de l’équipe Cursor a attribué une interruption signalée à la création d’un worktree puis au changement de racine de l’agent en cours de tâche. Sa réponse conseillait de lancer l’agent directement dans le dossier où le travail devait se faire, plutôt que de le laisser changer de dossier en cours de route. Elle indiquait aussi que la commande continue permettait de reprendre une tâche arrêtée. (Réponse de l’équipe Cursor)