OpenRig : réunir Claude Code et Codex en une équipe d'agents définie en YAML

À qui ça s'adresse

OpenRig s'adresse aux développeurs qui veulent organiser plusieurs agents de code en une équipe figée : un rig enveloppe vos harness, l'équipe d'agents se définit en YAML et se lance d'une seule commande. Sa capacité la plus remarquable est de faire tourner Claude Code et Codex dans le même rig, pilotés comme un seul système. Sa valeur tient au « collectif » : plutôt que de veiller sur chaque agent dans des fenêtres de terminal séparées, inscrivez les membres dans un même fichier YAML et laissez une commande unique et des vérifications de préparation unifiées s'en occuper.

Avant de commencer, vérifiez l'environnement et ne poursuivez que lorsque les quatre points sont réunis : Node.js 22 ou 24 (22 sur Apple silicon), tmux, macOS ou Linux (Windows passe par WSL2) et un Claude Code ou Codex connecté. Comblez tout manque d'abord : c'est ce qui épargnera la plupart des erreurs à venir. Si vous n'utilisez que d'autres agents, restez sous Windows natif ou employez une autre version de Node, le support n'est pas précisé officiellement : considérez cela comme non confirmé.

À l'inverse, trois situations doivent vous faire attendre : l'utilisateur qui ne jure que par l'interface graphique et ne veut pas écrire de configuration ; celui qui doit tourner directement sous Windows natif (pas WSL2) ; celui qui vise des clients autres que Claude Code et Codex — la documentation officielle ne couvre pas ces usages. Autrement dit, si vous ne lancez qu'un seul client au quotidien et n'avez pas besoin de démarrage unifié, la structure d'équipe du rig apporte un bénéfice limité.

Une première tentative en 3 minutes

Le chemin principal recommandé est unique : installez le skill rigs dans Claude Code avec la commande officielle, à condition que l'environnement de la section précédente soit prêt. Exécutez dans un terminal :

npx skills add https://github.com/mvschwarz/openrig/tree/v0.7.0/skills/rigs --skill rigs --agent claude-code

Le v0.7.0 de la commande est le chemin de version figé donné par la page officielle : copiez-le tel quel. Une fois l'installation faite, écrivez la définition de votre équipe d'agents en YAML ; l'ordre est : installer le skill, écrire le YAML, initialiser si besoin (rig setup), lancer (rig up). Officiellement, il est seulement dit que l'équipe se définit en YAML et se lance d'une commande ; ni champs, ni exemples, ni emplacements de fichiers ne sont fournis. Pour les détails de configuration, tenez-vous aux instructions fournies avec le skill après installation, sans rien inventer.

Vient ensuite l'initialisation. Avant d'exécuter rig setup, connaissez ses effets de bord : il ajoute un bloc OpenRig à ~/.tmux.conf ; sous macOS, il peut installer tmux via Homebrew ; et, sauf si vous passez --no-herdr, il installe aussi Herdr. Voilà le point de confirmation avant exécution — si Herdr ne vous convient pas, ajoutez --no-herdr avant de lancer.

Enfin, le lancement : exécutez rig up ; il soulève les sessions tmux, chaque harness et les fichiers de démarrage, puis exécute les vérifications de préparation. Signaux de succès observables : les sessions correspondant à votre équipe apparaissent dans tmux, chaque harness démarre, et les vérifications rendent leur verdict point par point. Si aucune session n'apparaît ou si une vérification échoue, revenez à la liste d'environnement et contrôlez la version de Node et tmux. Rien n'indique officiellement si rig up modifie des fichiers ou accède au réseau : non confirmé. À ce stade, aucun membre n'a encore fait de vrai travail ; confirmez d'abord un démarrage sain avant de lui confier de vraies tâches.

Cas d'usage

Cas 1 : faire collaborer Claude Code et Codex dans la même équipe. Scénario : vous utilisez les deux clients et voulez les réunir dans un même système piloté. Méthode : après l'installation du skill rigs, définissez les deux harness dans le YAML d'équipe, puis exécutez rig up. Résultat attendu : les deux démarrent comme un seul système, leurs sessions apparaissent dans tmux, les vérifications rendent leur verdict point par point, et les deux membres restent visibles dans tmux, ce qui facilite la comparaison.

Cas 2 : condenser la préparation quotidienne en une commande. Scénario : vous ne voulez plus ouvrir tmux à la main et démarrer les membres un par un chaque jour. Méthode : une fois le YAML d'équipe écrit, exécutez rig up à chaque début de journée et laissez-lui les sessions tmux, les harness, les fichiers de démarrage et les vérifications de préparation. Résultat attendu : la préparation répétitive se réduit à une commande, et le verdict des vérifications vous dit directement si l'équipe est prête.

Les deux cas s'enchaînent bien : confirmez d'abord avec le cas 1 que la formation elle-même fonctionne, puis transformez-la en point d'entrée quotidien fixe comme au cas 2. Les deux cas s'arrêtent où s'arrête la documentation officielle : la répartition du travail après démarrage et les tâches réellement exécutées ne donnent lieu à aucun exemple officiel ; ici, on n'invente rien.

Limites d'usage

• Environnement et clients : la liste officielle se limite à Node.js 22 ou 24 (22 sur Apple silicon), tmux, macOS/Linux (WSL2) et un Claude Code ou Codex connecté ; les autres clients, le Windows natif et les autres versions de Node restent non confirmés.
• Surface d'installation et version : l'installation passe par npx skills add, et la commande officielle est explicitement liée à --agent claude-code ; aucun marketplace de plugins ni équivalent pour d'autres clients n'est documenté, ne généralisez pas de vous-même. Le chemin d'installation est figé sur v0.7.0 ; le mode de mise à niveau n'est pas précisé.
• Effets de bord et point de confirmation : rig setup ajoute un bloc OpenRig à ~/.tmux.conf, peut installer tmux via Homebrew et installe Herdr sauf si vous passez --no-herdr ; confirmez avant d'exécuter que vous acceptez ces modifications.
• Définition d'équipe : champs YAML précis, exemples et emplacements de fichiers ne figurent pas dans la documentation officielle ; n'écrivez pas la configuration au hasard.
• Vérifications de préparation : exécutées par rig up, mais leur contenu précis et leur comportement en cas d'échec ne sont pas documentés ; fiez-vous à la sortie de la commande, sans supposer de relance automatique ni de retour arrière.
• Comportement en tâche : OpenRig orchestre des équipes ; la documentation officielle ne dit rien d'une réécriture de textes ou d'une modification de vos fichiers. Le comportement fichiers, commandes et réseau des membres à l'exécution dépend du client que vous choisissez ; cet article ne tire aucune conclusion de sécurité supplémentaire.
• Points non confirmés : licence et tarification, désinstallation, comportement de sortie et nettoyage de rig up, nombre maximal de membres par rig — rien de tout cela n'a été trouvé dans la documentation officielle.