Piloter plusieurs terminaux Claude Code en même temps · Guide complet

🎁 Ce que tu reçois : le prompt d'installation à copier-coller, les garde-fous à poser avant tout le reste, la façon dont deux terminaux se parlent sans serveur ni cloud, et la version minimale à deux sessions pour démarrer aujourd'hui.

Le résultat : plusieurs sessions Claude Code ouvertes sur le même projet, chacune avec un rôle (une qui code, une qui vérifie, une qui fait les ops, une qui cherche), qui se parlent entre elles et qui te préviennent par un son quand elles ont fini.

Installation : 20 minutes pour la version à deux terminaux. Gratuit, zéro ligne de code à écrire toi-même : Claude Code configure tout.

🎬 Ce guide est un retour d'expérience. Sur un de mes projets client, j'ai six sessions Claude Code qui tournent en même temps dans le même dossier depuis une semaine. Je te montre comment c'est réellement câblé, et comment le refaire depuis zéro.

Ce qui tourne vraiment chez moi

Le point de départ n'est pas une théorie : c'est ps et lsof. Six process claude ont pour dossier courant celui du projet. Chacun a pris un rôle de fait, visible dans son historique d'outils.

⚡ Le détail qui compte : tous partagent le même dossier. Pas de worktree, pas de branche par terminal. C'est ce qui rend la coordination nécessaire, et c'est exactement pour ça qu'on va leur apprendre à se parler.

Ce que ça fait exactement

• Chaque terminal Claude Code a un rôle et un seul : coder, contrôler, faire les ops, chercher.
• Les terminaux se voient (ListAgents) et s'écrivent (SendMessage), sans serveur ni cloud : le message arrive dans la conversation de l'autre comme si tu l'avais tapé.
• Un son te prévient quand une session a fini, un autre quand elle a besoin de toi.
• Une session peut se mettre en veille et revenir plus tard sur sa tâche (ScheduleWakeup), par exemple pour attendre un déploiement.
• Des garde-fous dans ~/.claude/settings.json empêchent n'importe quelle session de faire une bêtise, même quand elles tournent sans te demander la permission.

Ce qu'il te faut

• Claude Code installé et déjà utilisé sur au moins un projet.
• macOS pour les sons (afplay est déjà sur ta machine). Sur Linux, remplace par paplay ou aplay.
• Un terminal qui gère les onglets ou les panneaux (Terminal, iTerm, Warp, tmux, peu importe).
• Un projet dans un dossier, avec ou sans git.

La seule règle d'or : un rôle, un terminal

🚫 Cause n°1 des dégâts : deux terminaux sur la même tâche dans le même dossier. Ce sont deux sessions qui s'écrasent l'une l'autre, et le dernier qui écrit gagne, sans avertissement.

N'ouvre pas quatre terminaux « au cas où ». Ouvre-en un par métier distinct : celui qui code, celui qui contrôle, celui qui fait les ops, celui qui cherche.

Le prompt à copier-coller dans Claude Code

Ouvre un seul terminal Claude Code dans ton dossier de projet, colle ce prompt, et laisse-le faire. Il pose les garde-fous et les sons avant d'ouvrir les autres terminaux : c'est l'ordre qui compte.

TON RÔLE : tu fais tout le travail technique. Je ne veux écrire aucune ligne de code ni de config moi-même. Pose-moi tes questions une par une, attends ma réponse avant de passer à la suivante, et vérifie sur ma machine avant d'affirmer quoi que ce soit.

OBJECTIF : préparer ma machine pour faire tourner plusieurs sessions Claude Code en parallèle sur ce projet, chacune avec un rôle, qui se parlent entre elles et qui me préviennent par un son.

ÉTAPE 1 — État des lieux
- Vérifie la version de `claude`, le système (macOS ou Linux), et si `~/.claude/settings.json` existe déjà. Si oui, fais-en une copie de sauvegarde datée avant de le modifier.
- Liste les process `claude` déjà en cours et leur dossier courant. Dis-moi s'il y en a déjà sur ce projet.

ÉTAPE 2 — Les garde-fous (avant tout le reste)
Dans `~/.claude/settings.json`, ajoute dans `permissions.deny` les règles qui interdisent : les suppressions récursives, l'élévation en sudo, l'exécution directe de scripts téléchargés (curl ... | sh, wget ... | sh), et la lecture des fichiers .env du projet. Utilise la syntaxe officielle des règles de permission de Claude Code (Bash(...), Read(...)). Montre-moi le bloc avant d'écrire, et fusionne avec ce qui existe déjà sans rien supprimer.

ÉTAPE 3 — Les sons
Toujours dans settings.json, ajoute deux hooks :
- un hook `Stop` qui joue un son court quand une session finit son tour ;
- un hook `Notification` qui joue un son différent quand une session a besoin de moi.
Sur macOS, utilise `afplay` avec deux sons système différents de /System/Library/Sounds. Sur Linux, propose-moi l'équivalent. Teste chaque son une fois pour que je les entende.

ÉTAPE 4 — La statusline
Propose-moi une statusline simple qui affiche en bas du terminal : le nom du projet, la branche git si elle existe, et le modèle. Utilise la commande /statusline de Claude Code ou le champ statusLine de settings.json, au choix de ce qui est disponible dans ma version.

ÉTAPE 5 — La procédure de lancement
Écris-moi un petit fichier TERMINAUX.md à la racine du projet avec :
- la liste des rôles que je vais ouvrir (je te dirai combien : commence par proposer deux, « chantier » et « contrôle ») ;
- la commande exacte pour lancer chaque terminal dans ce dossier ;
- la commande shell qui liste les sessions claude en cours, leur dossier et leur ancienneté ;
- un exemple de message SendMessage pour qu'un terminal prévienne l'autre du fichier qu'il prend.

ÉTAPE 6 — Vérification
Relis settings.json, confirme qu'il est valide (JSON parsable), relance un `claude --version`, et récapitule en 5 lignes ce qui a été mis en place et ce que je dois faire à la main : ouvrir les terminaux.

Le montage, étape par étape

1. Lancer chaque terminal dans le dossier du projet

cd ~/chemin/vers/ton-projet
claude

⚠️ Chez moi, les sessions tournent avec le drapeau qui saute toutes les demandes de permission. Ça va vite, et ça n'a de sens qu'avec les garde-fous de l'étape 2 du prompt. Si tu démarres, démarre sans ce drapeau. Tu l'ajouteras quand tu auras vu tes sessions tourner une semaine sans surprise.

2. Savoir qui est en ligne

Chaque session ouvre une socket Unix dans /tmp/cc-socks/, nommée d'après son PID. Depuis n'importe quel terminal Claude Code, l'outil ListAgents les liste avec leur nom court et leur état. Et depuis le shell :

# quels terminaux, depuis quel dossier, depuis combien de temps
for p in $(pgrep -f '^claude'); do
  echo "$p $(ps -o etime= -p $p) $(lsof -a -p $p -d cwd -Fn | grep ^n | cut -c2-)"
done

3. Les faire se parler

✅ C'est le cœur du montage, et c'est plus simple qu'il n'y paraît : pas de serveur, pas de cloud. Un terminal écrit à un autre par son nom, et le message arrive dans sa conversation comme un tour utilisateur.

Tu le demandes en langage naturel à la session, ou tu lui donnes la forme exacte :

SendMessage({ to: "nom-court-de-l-autre-session", message: "Coordination : je prends les corrections de relances.ts, ne touche pas au fichier." })

Dans mon terminal chantier, 39 messages de ce type ont été échangés en cinq jours. C'est ce qui remplace la branche git : la répartition des fichiers se fait à la voix.

4. Superviser sans regarder l'écran

💡 Contre-intuitif : dans tout l'historique de mon projet, aucun cron, aucun déclencheur distant. Le « remote » de ce montage est entièrement local. Tu n'as besoin de rien installer d'autre que Claude Code.

5. Charger les skills, pas les réexpliquer

Les skills réellement invoqués sur mon projet, par terminal :

📦 Superpowers et les skills de revue ont leurs propres guides dans cette même bibliothèque.

Pour commencer : la version minimale

🎯 Si tu démarres aujourd'hui, ne monte pas six terminaux. Monte-en deux, et ajoute le reste quand la gêne se fait sentir.

Les deux se parlent par SendMessage, le hook sonore prévient quand l'un des deux a fini. C'est déjà 80 % de ce que fait ma flotte de six : le reste n'est que de la spécialisation ajoutée au fil des besoins.

Dépannage rapide

• ListAgents ne voit pas l'autre terminal : vérifie que /tmp/cc-socks/ existe et contient une socket par session ; sinon relance la session concernée.
• Pas de son à la fin d'un tour : lance la commande du hook à la main dans un terminal (afplay /System/Library/Sounds/Glass.aiff). Si elle marche, c'est le JSON de settings.json qui est invalide, demande à Claude de le valider.
• Deux terminaux ont modifié le même fichier : c'est la règle d'or qui a sauté. Un des deux reprend le fichier, l'autre lui envoie un SendMessage pour se le répartir. Et pense à commit souvent, ça reste ton filet.
• Une session tourne depuis des jours et devient illisible : ferme-la et rouvres-en une par chantier. Le contexte survit, la lisibilité non.
• Une règle deny bloque une commande légitime : demande à Claude de l'affiner (par exemple autoriser la suppression du seul dossier node_modules tout en gardant le reste interdit) plutôt que de la retirer.

📓 Source : relevé fait sur ma propre machine à partir de ps, lsof, ~/.claude/settings.json et des transcripts .jsonl du projet. Les chiffres d'usage sont des comptages sur ces historiques, pas des estimations. ListAgents, SendMessage, ScheduleWakeup, les hooks et les règles de permission sont des fonctions natives de Claude Code (Anthropic).