# Git worktree dans Claude Code : sessions parallèles > Comment utiliser --worktree, .worktreeinclude, worktree.baseRef et l’isolation des subagents. Différences avec les branches, nettoyage des worktrees et erreurs fréquentes. Source: https://ailoot.ai/blog/fr/claude-code-git-worktree/ Canonical: https://ailoot.ai/blog/fr/claude-code-git-worktree/ Language: fr Publisher: Ailoot (https://ailoot.ai/) Translation: guide-045 Revision: sha256-68f5851544749490d1ec10279626a1da04f30dd1800da0e87f83f301f6dd4984 [Des informations pratiques sur l’utilisation d’Ailoot sont disponibles dans la documentation](https://ailoot.ai/docs/). ## Qu’est-ce qu’un git worktree dans Claude Code ?
À retenir Un Git worktree est un répertoire de travail distinct pour une autre branche du même dépôt. La commande `claude --worktree ` crée automatiquement un worktree dans `.claude/worktrees//` et y lance Claude Code. Deux terminaux → deux sessions → des fichiers différents sur le disque, sans interférence. Disponible d’emblée dans Claude Code v2.0+, configurable avec `.worktreeinclude` pour les secrets et `worktree.baseRef` pour choisir la branche de base.
Lancer plusieurs agents en parallèle dans le même dossier, c’est le problème fondamental du vibe-coding au rythme de 2026. Les agents d’IA écrivent du code plus vite qu’une personne ne peut suivre qui modifie quoi. Sans isolation des fichiers, lancer deux sessions Claude Code en parallèle dans un même répertoire se termine par l’écrasement du travail de l’une par l’autre. Git worktree règle ce problème au niveau du système de fichiers. Tu as un répertoire principal dans lequel tu travailles. La commande `claude --worktree feature-auth` crée le dossier `.claude/worktrees/feature-auth/` sur une branche distincte et y lance Claude Code. Les fichiers sont isolés. Les changements d’une session ne sont pas visibles dans l’autre tant que tu ne les as pas explicitement fusionnés. La documentation officielle d’Anthropic le formule ainsi :

Exécuter chaque session Claude Code dans son propre worktree signifie que les modifications apportées dans une session n’affectent jamais les fichiers d’une autre. Tu peux développer une fonctionnalité dans un terminal et corriger un bug dans un autre.

— Documentation Anthropic, https://code.claude.com/docs/en/worktrees
Un indice pour faire le point : si tu as déjà reçu un commit dont la moitié des fichiers correspondait au travail de quelqu’un d’autre, tu as besoin d’un worktree. ## En quoi git worktree diffère-t-il d’une branche classique ?
À retenir Un `git checkout` classique change la copie de travail dans le même dossier : les anciens fichiers disparaissent du disque jusqu’à ce que tu reviennes à la branche. `git worktree add` crée un **deuxième dossier** pour une autre branche, à côté du premier. Les deux branches sont présentes sur le disque en même temps ; tu passes de l’une à l’autre avec un simple `cd`. En coulisses, il n’y a qu’un seul dépôt `.git`, avec un historique partagé et un dépôt distant partagé. Simplement plusieurs copies de travail.
Le flux Git standard : tu es sur la branche `main` et exécutes `git checkout feature-x` — Git écrase les fichiers de la copie de travail. Un `npm run dev` en cours d’exécution cesse de fonctionner parce que `package.json` a changé sous ses yeux. Tu mets tes changements non commités en stash et attends que l’IDE réindexe. Tu reviens en arrière et tout est de nouveau écrasé ; tu dois donc refaire un stash et un pop. Git worktree offre une autre possibilité : au lieu de basculer **un** dossier entre les branches, tu crées un **deuxième** dossier pour une autre branche. La commande `git worktree add ../project-feature-x feature-x` crée le répertoire `../project-feature-x/` avec les fichiers de la branche `feature-x`. Ta branche `main` reste dans le dossier d’origine et le serveur de développement continue de fonctionner. | Paramètre | Branche avec `git checkout` | `git worktree add` | |----|----|----| | Fichiers de la copie de travail | Écrasés | Apparaissent dans un nouveau dossier | | Travail en parallèle sur deux branches | Non | Oui | | Changements non commités | `git stash` nécessaire | Rien à faire | | Vitesse de basculement | Dépend de l’ampleur des différences | Un simple `cd` | | Espace disque | 1× | N× (une copie des fichiers par branche) | Auparavant, le mode worktree dans Claude Code devait être configuré manuellement : `git worktree add`, puis `cd`, puis `claude` — et il fallait répéter ces étapes dans chaque terminal. L’option `--worktree` (également `-w`) fait les trois en une seule commande. ## Lancer la première session parallèle : l’option `--worktree`
À retenir La commande `claude --worktree feature-auth` crée un worktree dans `.claude/worktrees/feature-auth/`, crée la branche `worktree-feature-auth` à partir de `origin/HEAD` et lance Claude Code à cet endroit. Pas besoin d’exécuter manuellement `git worktree add` ni `cd`. Dans le terminal voisin, répète la commande avec un autre nom pour obtenir deux sessions indépendantes. Si tu omets le nom (`claude --worktree`), Claude en génère un au hasard, comme `bright-running-fox`.
Exemple minimal. Ouvre le premier terminal à la racine du projet : ```bash claude --worktree feature-auth ``` Claude Code effectue trois opérations : 1. Crée `.claude/worktrees/feature-auth/` avec un instantané de `origin/HEAD` (généralement ta branche par défaut). 2. Crée une nouvelle branche `worktree-feature-auth`. 3. Lance la session dans ce dossier. Ouvre un deuxième terminal à la racine du même dépôt : ```bash claude --worktree bugfix-123 ``` Et voilà. Deux sessions Claude Code, des fichiers différents sur le disque, des branches Git différentes. Si tu écris le code de l’authentification dans la première et corriges un test qui échoue dans la deuxième, elles ne peuvent physiquement pas se gêner. Si tu ne veux pas saisir de nom, Claude en trouvera un : ```bash claude --worktree # → creates something like .claude/worktrees/bright-running-fox/ ``` Un conseil pour les débutants en Git : ajoute `.claude/worktrees/` à `.gitignore`. Sinon, lorsque tu exécutes `git status` dans le dossier principal, tu verras le contenu de tous les worktrees comme des fichiers non suivis : ``` # .gitignore .claude/worktrees/ ``` Piège à éviter : avant le premier lancement de `--worktree` dans un nouveau répertoire, ouvre-le avec un `claude` classique (sans l’option) et accepte la boîte de dialogue de confiance de l’espace de travail. Sinon, l’option échoue avec une erreur « trust not accepted », y compris si tu la combines avec `-p` en mode headless. ## Où se trouvent les worktrees et comment les trouver
À retenir Par défaut, tous les worktrees se trouvent dans `.claude/worktrees//`, à côté de la racine du dépôt. Pour afficher la liste, exécute `git worktree list`. Pour accéder manuellement à un worktree, utilise `cd .claude/worktrees/feature-auth`. Pour changer de worktree au sein d’une session Claude, demande-lui de « passer à un autre worktree » ; il utilise l’outil intégré EnterWorktree. L’ancien worktree reste intact sur le disque.
L’emplacement par défaut est fixe : `.claude/worktrees//` à la racine du dépôt. Si ton projet se trouve dans `~/dev/my-app/`, le worktree `feature-auth` sera dans `~/dev/my-app/.claude/worktrees/feature-auth/`. Pour les configurations non standard (par exemple, si tu veux placer le worktree en dehors du dépôt), il existe le hook `WorktreeCreate` — nous y reviendrons dans la section sur SVN et Mercurial. Au sein d’une session Claude, tu peux passer à un autre worktree existant. Dis simplement dans la conversation : « switch to `.claude/worktrees/bugfix-123` », et Claude appellera l’outil `EnterWorktree`. Le dossier actuel restera intact ; tu pourras revenir de la même façon. La commande Git standard affiche la liste de tous les worktrees, y compris le principal et ceux créés manuellement : ```bash git worktree list ``` Le résultat ressemblera à ceci : ``` /home/user/dev/my-app abc1234 [main] /home/user/dev/my-app/.claude/worktrees/feature-auth def5678 [worktree-feature-auth] /home/user/dev/my-app/.claude/worktrees/bugfix-123 9876fed [worktree-bugfix-123] ``` ## Copier `.env` et les secrets : le fichier `.worktreeinclude`
À retenir Un worktree est un nouveau checkout. Les fichiers de `.gitignore` (`.env`, `.env.local`, les configurations locales) sont absents du nouveau dossier. Sans eux, `npm run dev` ou `prisma db push` ne fonctionnera pas. Le fichier `.worktreeinclude` à la racine du projet utilise la syntaxe de `.gitignore` et indique à Claude Code quels fichiers copier automatiquement dans chaque nouveau worktree. Il est pris en compte pour `--worktree`, les worktrees de subagents et les sessions de l’application de bureau.
Quand `--worktree` crée un nouveau dossier, celui-ci ne contient que ce qui a été committé dans Git. `.env`, qui contient les clés API, et `.env.local`, qui contient la configuration locale, figurent dans `.gitignore` et ne se trouvent donc pas dans le worktree. Le tout premier `npm run dev` échoue alors avec « MISSING DATABASE_URL ». La solution artisanale consiste à copier manuellement `.env` après chaque `--worktree`. Ça marche une fois, puis on oublie. La solution d’Anthropic consiste à créer un fichier `.worktreeinclude` à la racine du projet, qui répertorie les fichiers ignorés par Git à copier automatiquement dans chaque nouveau worktree. Crée un fichier `.worktreeinclude` à la racine du dépôt : ``` .env .env.local config/secrets.json ``` La syntaxe est la même que celle de `.gitignore`. Tu peux utiliser des motifs glob : ``` .env* *.local config/*.json .vscode/settings.json ``` Anthropic énonce une règle claire pour éviter les accidents :

Le fichier utilise la syntaxe gitignore. Seuls les fichiers correspondant au motif et également ignorés par Git sont copiés. Les fichiers suivis par Git ne sont jamais dupliqués.

— Documentation Anthropic, https://code.claude.com/docs/en/worktrees
Autrement dit, tu ne peux pas copier accidentellement `package.json` avec `.worktreeinclude` : il ne figure pas dans `.gitignore`. Tu peux y mettre tous les motifs que tu veux sans risque. Le même fichier `.worktreeinclude` fonctionne dans trois modes : `--worktree` manuel, les worktrees automatiques pour les subagents (voir ci-dessous) et les sessions de l’application de bureau Claude. ## Créer un worktree à partir d’une pull request pour une revue de code
À retenir La commande `claude --worktree "#1234"` récupère la pull request \#1234 depuis origin et crée un worktree dans `.claude/worktrees/pr-1234/` avec la branche de la PR. Tu peux passer l’URL complète : `claude --worktree https://github.com/OWNER/REPO/pull/1234`. Pratique pour les revues de code : ouvre la PR dans son propre dossier, et Claude peut lancer des tests, lire des journaux et rédiger un commentaire pendant que le dépôt principal reste intact.
Scénario classique de revue de code : un collègue t’a envoyé une PR ; tu dois examiner le code, lancer des tests et laisser un commentaire. Avec un `git checkout pull/1234/head` classique, tu bascules une nouvelle fois la copie de travail et interromps ta session active. Avec l’option `--worktree`, une seule commande suffit : ```bash claude --worktree "#1234" ``` Voici ce qui se passe : Claude Code exécute `git fetch origin pull/1234/head`, crée un worktree dans `.claude/worktrees/pr-1234/` et récupère la branche de la PR. La session démarre. Tu peux immédiatement lui demander de « lire le diff, lancer les tests et rechercher les erreurs de logique » ; pendant que Claude travaille, ta session principale sur `main` continue de fonctionner. L’autre syntaxe possible est l’URL complète de la pull request : ```bash claude --worktree https://github.com/OWNER/REPO/pull/1234 ``` Dans un vrai projet, associer `claude --worktree "#N"` à ton propre subagent chargé des revues de code permet d’obtenir une revue automatique en une ou deux minutes. Lance-le en arrière-plan, poursuis ton travail dans la fenêtre principale et consulte le résultat avec `claude agents`. ## Branche de base : `worktree.baseRef` avec `fresh` ou `head`
À retenir Par défaut, un worktree est créé à partir de `origin/HEAD`, le dernier commit synchronisé depuis le dépôt distant. C’est un départ sûr et « propre ». Pour inclure les commits locaux non poussés, définis `worktree.baseRef: "head"`. HEAD désigne un commit : les modifications suivies non commitées restent dans la copie d’origine et exigent un transfert séparé explicite. C’est utile lorsqu’un subagent doit travailler à partir de ta fonctionnalité actuelle sans passer à `main`. Seules les valeurs `fresh` et `head` sont acceptées ; les références arbitraires ne sont pas prises en charge.
Par défaut, chaque nouveau worktree part de `origin/HEAD`. L’avantage est de partir d’une base propre qui correspond avec certitude à ce que verra l’intégration continue. L’inconvénient, c’est que si tu as des changements non commités ou plusieurs commits locaux au-delà de la version distante sur ta branche actuelle, ils ne seront pas inclus dans le nouveau worktree. Pour démarrer depuis ton commit HEAD local actuel, ajoute ceci à `.claude/settings.json` ou aux paramètres globaux : ```json { "worktree": { "baseRef": "head" } } ``` Désormais, `claude --worktree experimental-feature` part du `HEAD` local actuel. Cela convient aux fonctionnalités ayant des commits locaux non poussés, sans inclure les modifications suivies encore non commitées. Si le sous-agent en a besoin, préserve-les, transfère-les explicitement et inspecte le diff cible. Ne confonds pas ce transfert avec `.worktreeinclude`, qui traite les fichiers locaux ignorés. Le paramètre accepte exactement deux valeurs : `"fresh"` (= `origin/HEAD`) et `"head"` (= le HEAD local). Les références arbitraires comme `"feature-branch"` ou un hash de commit ne sont pas acceptées : cette restriction est délibérée et évite une explosion combinatoire des options. ## Isoler automatiquement les subagents : `isolation: worktree`
À retenir Un subagent dans Claude Code est un agent spécialisé qui effectue une tâche (revue de code, refactorisation, recherche). Si tu lances plusieurs subagents en parallèle depuis une même session, ils travaillent par défaut dans le même dossier et peuvent écraser mutuellement leurs fichiers. Ajoute `isolation: worktree` au frontmatter du subagent pour attribuer un worktree temporaire à chacun, qui sera proprement supprimé à la fin s’il n’a rien committé.
Quand tu dis à Claude « lance trois subagents : l’un examine la base de données, le deuxième regarde l’API et le troisième vérifie les tests », tous les trois travaillent par défaut dans ta copie de travail. Si deux d’entre eux seulement modifient le même fichier au même moment, un conflit survient. La solution consiste à attribuer automatiquement un worktree à chacun. Méthode 1 : le demander à l’oral. Écris à Claude dans la conversation : ``` Utilise des worktrees pour tes agents. ``` Claude appliquera l’isolation à tous les subagents lancés par la suite dans cette session. Méthode 2 : le définir explicitement dans le subagent lui-même. Dans le fichier du subagent (par exemple, `.claude/agents/code-reviewer.md`), ajoute un champ au frontmatter : ```yaml --- name: code-reviewer description: Reads the diff and writes code review comments isolation: worktree --- Tu es un réviseur méticuleux. Lis le diff et recherche les erreurs de logique... ``` Désormais, chaque lancement de ce subagent reçoit un worktree temporaire dans `.claude/worktrees/`. Si le subagent n’a rien écrit, le dossier est automatiquement supprimé à la fin. S’il reste des changements non commités, Claude te demandera si tu veux les conserver ou les supprimer. La branche de base des worktrees de subagents est la même que pour `--worktree` : par défaut, `origin/HEAD` ; avec `worktree.baseRef: head`, le `HEAD` local. ## Matrice de décision : worktree, `/bg`, subagent ou Agent View
À retenir Quatre mécanismes de Claude Code souvent confondus. Worktree signifie **isolation des fichiers** (disque). `/bg` signifie **session en arrière-plan** (contexte et jetons). Un subagent est un **agent spécialisé ponctuel** (prompt et outils). Agent View est un **tableau de bord pour toutes les sessions** (interface). Ils peuvent être combinés : `/bg` crée automatiquement un worktree, un subagent avec `isolation: worktree` démarre dans un worktree temporaire et Agent View affiche ces trois éléments sous forme de lignes dans une même liste.
| Outil | Élément isolé | Quand l’utiliser | |----|----|----| | `claude --worktree ` | Fichiers (dossier distinct + branche) | Tu veux garder manuellement N sessions en cours en parallèle dans des terminaux différents | | `/bg` (ou `Ctrl+B`) | Contexte et durée | Une tâche longue que tu ne veux pas laisser bloquer la fenêtre actuelle. Un worktree est créé en coulisses | | Subagent avec `isolation: worktree` | Fichiers au sein d’une session | Un prompt répartit le travail entre N agents et tu veux éviter qu’ils s’écrasent mutuellement | | `claude agents` (Agent View) | Rien, c’est une interface | Tu veux voir toutes les sessions en cours / en pause / terminées dans un seul tableau de bord | | `/goal` | Gestion de l’autonomie | Tu veux que Claude travaille jusqu’à ce qu’une condition soit satisfaite, sans que tu aies à intervenir entre les tours | Combinaisons courantes : - **« 2 fonctionnalités en parallèle, manuellement »** — deux terminaux, chacun exécutant `claude --worktree`. Le cas le plus simple. - **« Lance une refactorisation pendant la nuit ; je ferme l’application »** — `/bg` + `/goal` avec une condition d’achèvement. La session fonctionne indépendamment de ta fenêtre. - **« Un prompt, trois recherches en parallèle »** — trois subagents avec `isolation: worktree`. Chacun dans son propre bac à sable. - **« Qu’est-ce qui tourne en ce moment ? »** — `claude agents`. Un tableau de bord de toutes les sessions avec les filtres « running », « blocked » et « done ». ## 5 pièges à éviter avec les worktrees
À retenir Les problèmes les plus fréquents : oublier `.worktreeinclude`, ce qui rend l’environnement inutilisable ; confondre un worktree avec une branche classique et perdre ses changements non commités ; garder 5+ sessions parallèles et oublier où se trouve quoi ; ne pas configurer `cleanupPeriodDays`, ce qui laisse les dossiers obsolètes s’accumuler ; et oublier la boîte de dialogue de confiance dans un nouveau répertoire, ce qui fait échouer `--worktree` avec une erreur.
**1. Worktree lancé, `.env` manquant, rien ne fonctionne.** Le problème le plus courant. Un worktree est un nouveau checkout sans les fichiers ignorés par Git. Dès que tu configures le mode worktree, ajoute un fichier `.worktreeinclude` avec `.env*` et les configurations locales nécessaires. Vérifie que le fichier se trouve à la racine du dépôt, et non dans `.claude/`. **2. Tu veux revenir à la branche principale, exécutes `cd` vers la racine et perds tes changements non commités dans le worktree.** Le dossier racine et le worktree sont deux copies de travail **différentes**. Tu es revenu avec `cd` ; les changements dans le worktree sont restés sur place, ils ne sont pas partis. Mais si tu t’es trompé et as exécuté `git stash` dans le dossier principal en pensant être dans le worktree, le stash sera créé sur la branche principale et non sur celle à laquelle tu t’attendais. **3. Tu as lancé 5 sessions en parallèle et ne te souviens plus de ce que fait chacune.** La documentation d’Anthropic avertit explicitement que la plupart des développeurs ne peuvent pas gérer cognitivement plus de 2–3 sessions. Un signe de surcharge : ouvrir Agent View et ne pas pouvoir dire immédiatement ce que fait chaque agent. Limite-toi à deux sessions simultanées. Si la tâche en exige davantage, elle devrait être orchestrée avec `/goal` + des subagents, plutôt que manuellement. **4. Les worktrees lancés avec `-p` (mode headless) ne sont pas nettoyés automatiquement.** La commande `claude --worktree feature-x -p "do thing"` n’affiche pas de demande interactive à la fermeture ; Claude ne te demande donc jamais « supprimer le worktree ? ». Ces worktrees s’accumulent. Nettoie-les manuellement : `git worktree remove .claude/worktrees/feature-x`. Tu peux aussi utiliser un script cron qui supprime tout ce qui date de plus de 7 jours. **5. Boîte de dialogue de confiance dans un nouveau dossier.** Si tu ouvres le dépôt pour la première fois et exécutes immédiatement `claude --worktree`, la commande échouera. Exécute `claude` sans options, accepte la confiance de l’espace de travail et quitte ; `--worktree` fonctionnera ensuite. C’est intentionnel, afin que Claude n’accède pas au projet de quelqu’un d’autre sans le consentement de l’utilisateur. ## Nettoyage : ce qui est supprimé automatiquement
À retenir Un worktree créé avec `--worktree` et sans changement (aucun commit, aucun fichier non suivi, aucune modification non commitée) est automatiquement supprimé à la fermeture. En présence de changements, Claude demandera quoi faire. Les worktrees des subagents et de `/bg` sont automatiquement supprimés par le délai `cleanupPeriodDays` défini dans les paramètres, à condition qu’ils soient propres. Les worktrees créés avec `-p` ne sont pas nettoyés du tout : supprime-les manuellement avec `git worktree remove`.
La logique de nettoyage dépend de ce que tu as fait dans le worktree et de la façon dont tu as lancé la session. La documentation d’Anthropic énumère trois scénarios :

Si le worktree ne contient aucune modification non commitée, aucun fichier non suivi ni aucun nouveau commit, le worktree et sa branche sont automatiquement supprimés à la fermeture de la session. Si la session porte un nom, Claude demande plutôt si tu veux conserver le worktree pour plus tard.

— Documentation Anthropic, https://code.claude.com/docs/en/worktrees
Scénario 1 : tu es entré, n’as rien fait et es ressorti — le worktree a été supprimé. Scénario 2 : tu as travaillé sans committer — à la fermeture, Claude te demandera « conserver ou supprimer ? ». « Conserver » garde le dossier et la branche pour plus tard. « Supprimer » efface le répertoire **ainsi que** les changements non commités et les nouveaux commits. C’est destructif : ne clique pas sur « supprimer » par habitude. Scénario 3 : tu as lancé la commande avec `-p` (mode headless), puis elle s’est terminée. Le worktree reste présent. Nettoie-le manuellement : ```bash git worktree remove .claude/worktrees/feature-x ``` En outre, le nettoyage en arrière-plan supprime automatiquement les worktrees issus de subagents et de sessions `/bg` s’ils sont plus anciens que `cleanupPeriodDays` jours (un paramètre généralement défini sur 30 jours par défaut) **et** ne contiennent aucun travail non enregistré. Les worktrees de `--worktree` ne sont pas touchés par le nettoyage automatique : ils sont sous ta responsabilité. ## Alternatives pour SVN, Perforce et Mercurial : le hook `WorktreeCreate`
À retenir Le mode worktree utilise `git worktree` par défaut. Pour SVN, Perforce, Mercurial et les autres VCS, tu peux brancher ton propre mécanisme avec les hooks `WorktreeCreate` et `WorktreeRemove` dans les paramètres de Claude Code. Le hook reçoit le nom sur stdin, doit afficher le chemin du répertoire créé et se terminer avec le code 0. Si tu utilises ton propre hook, `.worktreeinclude` n’est pas traité : tu dois copier toi-même les fichiers locaux dans le hook.
Si le dépôt utilise Subversion ou Mercurial, l’option `--worktree` ne fonctionnera pas directement. Anthropic propose un point d’extension au moyen de deux hooks : `WorktreeCreate` (crée une copie isolée) et `WorktreeRemove` (la supprime). Exemple de hook SVN tiré de la documentation officielle : ```json { "hooks": { "WorktreeCreate": [ { "hooks": [ { "type": "command", "command": "bash -c 'NAME=$(jq -r .name); DIR=\"$HOME/.claude/worktrees/$NAME\"; svn checkout https://svn.example.com/repo/trunk \"$DIR\" >&2 && echo \"$DIR\"'" } ] } ] } } ``` Le hook lit le nom du worktree depuis stdin (`{ "name": "feature-auth" }`), exécute `svn checkout` dans un répertoire prédéfini et affiche le chemin sur stdout ; Claude Code l’utilise comme répertoire de travail de la nouvelle session. Point important : lorsque tu utilises ton propre hook, `.worktreeinclude` n’est pas utilisé. Si tu as besoin de `.env` ou d’autres fichiers ignorés par Git dans le nouveau dossier, copie-les dans le script du hook lui-même. ## Pour la suite : trois mécanismes de parallélisme connexes
À retenir Worktree fournit l’isolation des fichiers. `/bg` fournit l’isolation du contexte et des jetons. Subagent fournit l’isolation des tâches et des outils. `/goal` permet de travailler de façon autonome jusqu’à ce qu’une condition soit satisfaite. Chaque mécanisme résout un problème à lui seul. Ensemble, ils permettent de mener 3–5 tâches en parallèle sans surcharge cognitive. Ensuite, tu peux consulter les guides connexes sur le mode autonome, les subagents personnalisés et les workflows dynamiques en suivant les liens ci-dessous.
Worktree fournit l’isolation des fichiers. `/bg` fournit l’isolation du contexte. Les subagents fournissent l’isolation des tâches. Chaque mécanisme résout un problème à lui seul. Ensemble, ils permettent de mener trois à cinq tâches en parallèle sans surcharge cognitive. Ce sont les compétences qui sous-tendent le vibe-coding avancé en 2026. Ce sujet se prolonge naturellement par trois sujets connexes : [comment configurer un agent autonome à l’aide de `/goal` et d’Agent View](https://ailoot.ai/blog/fr/claude-code-goal-agent-view/), [comment créer tes propres subagents pour tes tâches](https://ailoot.ai/blog/fr/claude-code-subagents/) et [comment lancer des centaines d’agents avec Dynamic Workflows](https://ailoot.ai/blog/fr/claude-code-dynamic-workflows/).
### Sources - [Exécuter des sessions parallèles avec les worktrees - Documentation Claude Code](https://code.claude.com/docs/en/worktrees) - [Créer des subagents personnalisés - Documentation Claude Code](https://code.claude.com/docs/en/sub-agents) - [Journal des modifications de Claude Code (mai-juin 2026)](https://code.claude.com/docs/en/changelog) - [Exécuter des agents en parallèle - Documentation Claude Code](https://code.claude.com/docs/en/agents) - [Agent View - Documentation Claude Code](https://code.claude.com/docs/en/agent-view) - [Page de manuel de git worktree](https://git-scm.com/docs/git-worktree)
[Ouvrir Ailoot](https://ailoot.ai/). ## Questions fréquentes : Git worktree dans Claude Code : sessions parallèles ### baseRef head copie-t-il les changements non commités ? Non. Il part du commit HEAD local, y compris les commits absents du distant. Les modifications suivies non commitées restent à l’origine. Transfère explicitement le travail nécessaire et inspecte le nouveau worktree. ### Pourquoi .env manque-t-il dans le nouveau worktree ? Un worktree est un checkout neuf sans les fichiers ignorés de Git. .worktreeinclude liste ceux à copier ; un hook WorktreeCreate personnalisé doit assurer cette copie lui-même. N’inclus que les fichiers nécessaires. ## Ailoot · L’entreprise et son portefeuille de projets Ailoot s’appuie sur une expérience opérationnelle éprouvée, une large clientèle, un service stable et un suivi continu des KPI. L’entreprise et son portefeuille de projets : des millions de clients ; des ventes qui se chiffrent en milliards chaque mois. Ailoot met cette expérience opérationnelle au service de l’accès API aux fonctions d’IA dans les produits des clients, leurs agents, applications et automatisations.