Claude Code est le meilleur gestionnaire de worktrees
Les gestionnaires de worktrees intégrés finissent forcément limités. Ils supposent souvent un seul repo, Git, un flux de branches officiel et la vision d’une équipe produit de ce que devrait être la préparation. Les vrais codebases ne restent pas dans ce cadre.
Le Zen de cmux dit que les développeurs doivent construire leurs propres outils et explorer les façons de travailler avec le code. Les worktrees sont une primitive utile, mais les checkouts multiples, les repos backend/frontend séparés, les machines distantes, les projets sans Git, les scripts locaux et parfois le travail direct sur main le sont aussi quand c’est le plus rapide pour la tâche.
Le modèle du super repo
Un super repo est un checkout de contrôle qui sait où vivent les vrais repos, comment créer les worktrees, comment associer les repos liés, quels scripts préparent chaque workspace et comment les PR sont relues puis fusionnées. cmuxterm-hq est un super repo: il contient le checkout principal de cmux, les worktrees cmux par tâche, les checkouts Zed, les scripts hq, les skills réutilisables et les règles que suivent les agents pour ne pas se marcher dessus.
Le but n’est pas que tout le monde copie cette arborescence exacte. Le point important est qu’un repo local de contrôle peut décrire tout votre système d’ingénierie. Un repo backend et un repo frontend peuvent s’ouvrir ensemble. Une app mobile et une API web peuvent être rechargées ensemble. Une branche peut être créée dans un repo avec sa branche sœur dans un autre. Cette forme appartient à votre équipe, pas à un bouton générique de worktree.
Laissez l’agent gérer les worktrees
Claude Code et Codex sont de meilleurs gestionnaires de worktrees que la plupart des fonctions intégrées parce qu’ils peuvent lire les règles du repo, lancer vos scripts, créer des worktrees dans plusieurs repos, nettoyer leurs propres worktrees, résoudre des conflits, pousser des branches, ouvrir des PR et fusionner après CI et revue.
Nos flux les plus utilisés sont task-worktree-pr et autoreview. Ils fonctionnent parce que les agents peuvent lire et écrire des fichiers, exécuter des commandes, inspecter GitHub, attendre la CI, répondre aux commentaires de revue et opérer entre dépôts. Si une tâche touche le cloud et le desktop, vous pouvez demander à l’agent de regarder les deux et laisser le super repo encoder le reste.
Pourquoi le support intégré des worktrees perd
Une fonction de worktree au niveau produit peut être très polie pour le cas commun, mais les cas limites arrivent tout de suite: pas de Git, plusieurs repos, clients générés, scripts privés de setup, branches backend/frontend couplées, politique de merge inhabituelle ou équipe qui pousse volontairement sur main pour de petits changements internes.
Un workflow programmable s’adapte. Demandez à Claude Code de créer un worktree, de lancer Codex à côté, d’exécuter le setup, d’ouvrir le bon panneau navigateur, de surveiller les tests et de supprimer le worktree quand la PR est fusionnée. Puis changez ce workflow demain.
cmux donne une surface au workflow
cmux n’a pas besoin d’un gestionnaire universel de worktrees intégré. Il fournit des commandes personnalisées, une CLI et une API socket programmables, et des skills réutilisables. Le bouton plus peut lancer votre propre commande de worktree, un setup multi-repo, un bac à sable sans Git ou un environnement distant.
C'est pourquoi cmux home est important. Le meilleur gestionnaire d'arbre de travail est celui que vos agents peuvent modifier lorsque votre flux de travail change, et le meilleur terminal pour cette boucle conserve les notifications, Cmd+Shift+U et Cmd+Control+U câblées dans la surface.