Un gestionnaire de worktrees git
pour Claude Code, Codex et tous les CLI d'agents

Un worktree git est un deuxième checkout du même dépôt, dans son propre dossier et sur sa propre branche, qui partage l'historique et le remote avec ton checkout principal. En donner un à chaque agent de code IA, c'est laisser chaque agent modifier, compiler et commiter sa propre copie des fichiers : deux agents qui travaillent en même temps ne s'écrasent jamais et ne changent jamais de branche sous les pieds l'un de l'autre. Notre blog a un guide plus long sur la partie git : Git worktrees, la base pour faire coder plusieurs agents sans conflit.

Oui. claude --worktree <nom> (ou -w) crée .claude/worktrees/<nom> sur une branche nommée worktree-<nom>, copie les fichiers ignorés par git listés dans .worktreeinclude, et demande s'il faut garder ou supprimer le worktree quand tu quittes ; les subagents peuvent tourner dans leur propre worktree avec isolation: worktree. Il n'installe pas tes dépendances. Dans AgentsRoom, tu peux continuer à t'en servir, ou laisser le ticket ou l'agent demander le worktree, ce qui le prépare aussi et l'affiche dans l'onglet Changements (vérifié sur Claude Code 2.1.299).

L'app Codex, oui : elle crée des worktrees gérés dans $CODEX_HOME/worktrees, en HEAD détachée, copie les fichiers ignorés listés dans .worktreeinclude, peut lancer les scripts de setup d'un environnement local, garde les 15 plus récents et déplace une conversation entre Local et un worktree avec Handoff. codex-cli 0.162.1 a un drapeau --worktree qui lance une session dans un nouveau worktree géré. AgentsRoom donne un worktree à un agent Codex de la même façon qu'à n'importe quel autre agent, depuis le ticket ou la fenêtre Ajouter un agent.

Tous : le worktree est simplement le dossier de travail de l'agent, quel que soit le CLI qui y tourne, donc Claude, Codex, GitHub Copilot CLI, Cursor et 10 autres CLI d'agents y travaillent de la même façon. Kimi Code et Antigravity CLI font confiance à un dossier par son chemin exact ; AgentsRoom enregistre un nouveau worktree comme dossier de confiance pour eux avant le lancement, pour qu'ils ne s'arrêtent pas sur une question de confiance.

Non. Avant que le premier agent démarre dans un nouveau worktree, AgentsRoom copie les fichiers ignorés par git du checkout principal qui correspondent à Fichiers copiés depuis ce checkout (tous les fichiers .env par défaut) et lance la commande d'installation détectée depuis le lockfile à la racine. Les deux se règlent dans Paramètres du projet > Git > Préparer les nouveaux worktrees, où tu peux remplacer la commande, par exemple pnpm install && pnpm build:deps. Un fichier déjà présent dans le worktree n'est jamais écrasé.

Ouvre l'onglet Changements et choisis le worktree dans le sélecteur Worktree en haut : la liste des fichiers, les diffs, la relecture, Commit, Pull et Push agissent alors sur ce checkout. Pour un ticket, Fusionner automatiquement dans la branche courante quand la tâche est terminée fusionne sa branche quand tu le passes en Terminé, et Commiter automatiquement à la fin du travail (Réglages > Backlog) commite d'abord ce que l'agent a laissé, pour que la fusion emporte tout le travail.

Dans le projet, sous .worktrees/<branche>/, créés depuis la branche par défaut du remote sauf si tu règles une Branche de base des worktrees dans les paramètres du projet. Le dossier est ajouté au .git/info/exclude du clone, jamais à ton .gitignore, donc il reste hors de tes commits. Les worktrees ne sont jamais supprimés automatiquement : supprime-en un avec git worktree remove quand tu en as fini.

Oui pour les deux. Sur le téléphone, l'écran Changements a le même sélecteur Worktree, et un ticket qui demande un worktree tourne dedans quand tu le démarres depuis le téléphone, préparé par l'ordinateur comme n'importe quel autre. Un projet ouvert sur un serveur SSH a ses worktrees sur le serveur, sans l'étape d'installation. Un checkout local dont les agents tournent sur une machine distante ne peut pas utiliser de worktrees, et le ticket te le dit au lieu de démarrer.