Commencer
La CLI Orchyst : vos agents, toujours à l'écoute
Un petit programme fait tourner tout le groupe d'agents de votre projet. La CLI Orchyst garde en marche le terminal propre à chaque agent, lui remet chaque message qui lui est adressé sous forme d'une seule ligne saisie, et prouve chaque livraison par l'accusé de réception de l'agent lui-même — pendant que vous listez, démarrez, arrêtez, rejoignez et surveillez le tout depuis un seul menu.
Prérequis
Quatre choses, et vous les avez probablement déjà toutes :
- Un compte Orchyst avec au moins un agent que vous avez créé — vous approuvez l'appareil de la CLI en tant que propriétaire de cet agent.
- Votre outil de développement installé sur la machine où vit votre code — Claude Code, Codex, Cursor ou OpenCode (n'importe quel outil en terminal fonctionne via une commande personnalisée).
- tmux, sur Linux et macOS uniquement — il porte le terminal de chaque agent. Windows n'a besoin de rien de plus : la CLI apporte son propre serveur de sessions de terminal.
- Un dossier de projet. Le groupe que la CLI fait tourner est défini par le dossier depuis lequel vous la lancez.
Rien d'autre n'est installé et rien ne touche à votre dépôt : la CLI garde sa configuration et ses journaux dans un dossier .orchyst ignoré par git à l'intérieur du projet.
Ce que la CLI apporte, et comment vous la pilotez
Un seul binaire, lancé depuis la racine du projet, constitue toute la surface. Il autorise de nouveaux agents par une approbation d'appareil que vous confirmez en tant que propriétaire, garde un terminal par agent faisant tourner l'outil propre à cet agent, livre dans son terminal chaque message Orchyst qui lui est adressé, et journalise chaque livraison et chaque accusé. Vous pilotez tout cela depuis un seul menu — voici exactement comment il s'ouvre :
Six options, une touche chacune. Les sections qui suivent les prennent une par une, puis viennent toutes les commandes que la CLI accepte.
Option 1 — Lister les agents
Une ligne par agent, et tout le groupe d'un coup d'œil. Un agent en marche affiche un point plein, son outil, le fait qu'il est à l'écoute et le nom de son terminal ; un agent arrêté affiche un point vide, la raison de l'arrêt et un rappel que l'option 2 le démarre.
Lorsqu'un agent a reçu quelque chose pendant cette exécution, sa ligne porte aussi la livraison la plus fraîche : il y a combien de temps elle est arrivée, qui l'a envoyée, et si sa confirmation est déjà revenue.
Option 2 — Démarrer ou arrêter un agent
Les agents ne démarrent jamais d'eux-mêmes — cette option est l'interrupteur. Elle liste chaque agent avec son état et attend un numéro : un agent arrêté démarre (son messager se lève, son terminal s'ouvre, et la ligne confirme les deux), et il est demandé à un agent en marche de s'arrêter.
L'arrêt est volontairement doux : le messager finit ce qu'il fait et s'éteint à son prochain moment sûr, et le terminal de l'agent reste exactement tel qu'il était — l'option 3 peut encore l'ouvrir, et un redémarrage reprend là où l'outil s'était arrêté.
La liste se rafraîchit sur place après chaque action, vous pouvez donc en démarrer ou en arrêter plusieurs à la suite ; Entrée revient au menu.
Option 3 — Ouvrir la session d'un agent
Vous remet le vrai terminal d'un agent en marche. Le rappel de la touche de sortie est imprimé avant le sélecteur à dessein : le terminal prend tout l'écran dès que vous choisissez un numéro, trop vite pour lire quoi que ce soit imprimé après.
À l'intérieur, vous êtes dans l'outil propre à l'agent : regardez-le travailler, ou écrivez-lui directement — ce que vous tapez et les livraisons du messager partagent un seul champ de saisie, donc rien n'entre en collision et l'agent se souvient des deux. Tant que vous êtes là et actif, le messager retient ses rappels.
Appuyez sur Ctrl-] pour sortir et vous revenez au menu ; sous Linux et macOS, le Ctrl-b puis d de tmux fait la même chose. Entrée au sélecteur annule.
Option 4 — Ajouter un agent
Autorise une identité de plus dans le groupe, par la même approbation d'appareil que la première : la CLI affiche un code court et un lien, vous l'approuvez en tant que propriétaire — depuis le web ou votre téléphone — et l'identifiant est délivré directement à cette machine. Échap (ou q, ou Ctrl-C) annule l'attente proprement.
Le nouvel agent rejoint le groupe autorisé mais pas en marche — fidèle à la règle selon laquelle rien ne démarre tout seul. L'option 2 le démarre quand vous êtes prêt.
Option 5 — Journaux
Le propre relevé de la CLI pour cette exécution — démarrages, livraisons, confirmations, rappels, avertissements — avec un compteur dans le menu indiquant combien de lignes sont nouvelles depuis votre dernier regard :
Tout est aussi écrit dans .orchyst/cli.log à l'intérieur du projet, pour être relu plus tard. Depuis la vue, f puis Entrée suit le journal en direct à mesure que de nouvelles lignes arrivent ; Entrée revient au menu.
Option 6 — Quitter
Pose une seule question — fermer aussi les terminaux des agents ? — et les deux réponses sont deux sorties différentes.
Non (la valeur par défaut) n'arrête que les livraisons : chaque terminal reste vivant exactement tel qu'il était, orchyst attach s'y reconnecte, et orchyst stop les ferme plus tard. Oui ferme correctement : il est d'abord demandé à chaque outil de quitter avec sa propre commande de sortie, avec un instant pour s'exécuter, puis son terminal est fermé — et sous Windows le serveur de terminal de la CLI s'éteint après le dernier.
Ctrl-C n'importe où dans le menu est la version rapide du non — les messagers s'arrêtent, les terminaux restent.
Toutes les commandes que la CLI accepte
Tout ce que fait le menu existe aussi en commande, pour les scripts, les shells distants et l'automatisation. Chaque combinaison, et exactement ce qu'elle fait :
| Commande | Ce qu'elle fait |
|---|---|
orchyst |
La commande simple, depuis la racine du projet : ouvre le menu du groupe montré plus haut. Rien ne tourne tant que vous ne l'avez pas démarré depuis là. Dans un shell non interactif (un tube ou une CI), elle ne démarre rien et le dit — l'automatisation doit le demander explicitement avec --all. |
orchyst --all |
L'exécution non interactive : démarre tous les agents du groupe d'un coup et émet une ligne par événement de livraison au lieu d'un menu. Ctrl-C arrête les messagers ; les terminaux restent. |
orchyst add |
Autorise une autre identité dans le groupe de ce projet — le même parcours code-et-approbation que l'option 4 du menu, en autonome. Se termine proprement, que ce soit approuvé ou annulé. |
orchyst attach <agent> |
Rejoint le terminal de cet agent, exactement comme l'option 3 : le même champ de saisie partagé, le même Ctrl-] pour sortir. |
orchyst start <agent> |
Fait tourner le messager d'un agent au premier plan du shell courant, en imprimant une ligne par événement — utile en SSH ou sous un superviseur. Ctrl-C arrête le messager ; le terminal reste. |
orchyst stop [agent] |
Avec un nom : arrête le messager de cet agent et ferme son terminal. Sans nom : fait cela pour tout le groupe et, sous Windows, éteint aussi le serveur de terminal de la CLI. |
orchyst status |
Une ligne par agent : si son messager tourne, quel terminal il occupe (le cas échéant), et si l'identité est déjà à l'écoute depuis ailleurs. |
orchyst listen --agent <username> |
L'écoute en session, pour une session qui est l'agent lui-même : imprime une ligne par message adressé et ne gère aucun terminal. --once vérifie une fois et sort. |
orchyst mcp --agent <username> |
Le pont de messagerie que l'installation branche dans la configuration de chaque outil. Les outils le lancent eux-mêmes — il n'est pas destiné à être tapé par une personne. L'entrée ne nomme aucun agent : une session lancée par la CLI se voit indiquer son identité à l'ouverture, un projet avec un seul agent s'y rattache, et une session ouverte à la main dans un projet qui en compte plusieurs se voit proposer use_agent pour dire laquelle elle est. |
orchyst version · orchyst help |
Affiche la version de la CLI, ou ce même aperçu des commandes. |
Options communes à toutes les commandes
| Option | Ce qu'elle fait |
|---|---|
--dir <project> |
S'exécute sur un autre dossier de projet que le dossier courant. |
--host <origin> |
Vise un autre hôte Orchyst pour l'autorisation. |
--backend native|tmux |
Change la façon dont les terminaux sont portés (Windows utilise le mode natif par défaut, ailleurs tmux). |
--fresh |
Démarre l'outil à neuf au lieu de reprendre sa session précédente. |
--no-ws |
Utilise une interrogation simple au lieu du réveil par push. |
--no-page |
N'avertit jamais le propriétaire depuis l'échelle de rappels. |
--config <path> |
Pointe listen et mcp vers un fichier d'agent explicite. |
--once |
Fait vérifier listen une seule fois, puis sortir. |
--no-menu |
Saute le menu même dans un terminal — associez-la à --all pour faire tourner le groupe sans menu. |
Les valeurs par défaut de chaque agent — outil, modèle, répertoire de travail, nom du terminal et minutages des rappels — vivent dans un bloc courier facultatif du fichier de configuration de l'agent, et chacune peut être remplacée par une option. Un modèle épinglé est transmis à l'outil à chaque lancement.
Livraison avec accusé de réception
Le messager ne devine jamais à partir de ce qui est à l'écran. Un message ne compte comme livré que lorsque l'agent lui-même le confirme — en le marquant comme lu, ou en y répondant. Tant que cette confirmation n'arrive pas, la livraison reste ouverte, et les messages suivants attendent leur tour, du plus ancien au plus récent, un à la fois.
Quand une confirmation tarde, le messager insiste doucement, et uniquement devant un vrai silence : rien qui se passe dans le terminal, personne qui y tape, aucun signe que l'agent travaille. Il envoie d'abord un rappel, formulé de sorte qu'un agent qui a déjà répondu mais a oublié de confirmer se contente de confirmer, au lieu de répondre deux fois. Si le silence persiste, il avertit une fois le propriétaire de l'agent, dans le même espace, en indiquant exactement comment atteindre ce terminal — et laisse passer les messages suivants, pour qu'un agent en bonne santé ne soit jamais retenu. Et il ne rouvre le terminal de l'agent que si ce terminal s'est réellement fermé, en reprenant là où l'outil s'était arrêté.
La seule chose que le messager ne fait jamais, c'est répondre à la place de l'agent. Si quelque chose d'inattendu apparaît dans le terminal en demandant un choix ou une approbation, il n'appuie sur rien — une touche à l'aveugle pourrait accepter ce que personne n'a accepté — donc tout ce qu'un rappel ne peut résoudre va à une personne, jamais au clavier.
Livrer → rappeler (une fois) → avertir le propriétaire (une fois) → ne rouvrir qu'un terminal fermé. Et tant qu'une personne est dans le terminal et active, le messager se retient entièrement : le silence pendant qu'un humain tape signifie que c'est pris en charge.
Invites devant le champ de saisie
Un outil fraîchement lancé place parfois une boîte de dialogue devant sa saisie — une proposition de mise à jour, une question de confiance sur l'espace de travail, une connexion. Le messager n'écrit que dans le champ de saisie qu'il attend et, par conception, ne répond pas aux boîtes de dialogue : une livraison faite pendant qu'une telle invite est affichée attend donc simplement — le pointeur reste en file dans la saisie du terminal, l'accusé ne vient pas, et l'échelle se termine en vous prévenant plutôt que par une touche devinée.
On vous le signale aussi : quelques secondes après chaque démarrage, la CLI regarde une fois l'écran et, lorsque l'outil n'a pas atteint son champ de saisie, elle lève un avertissement — compté dans l'en-tête du menu, écrit dans les journaux, et nommant la raison lorsqu'elle la reconnaît :
Ce sont deux sortes d'invites, et elles ne se comportent pas de la même façon. La question de confiance de l'espace de travail est posée une fois par projet et par outil : répondez-y et elle ne revient jamais pour ce projet. La proposition de mise à jour arrive dès que l'outil publie une nouvelle version, elle peut donc surgir à n'importe quelle exécution, longtemps après la mise en place du projet — la plupart des CLI ont une option ou un réglage qui saute cette vérification. Dans les deux cas le remède est la même visite unique : attachez-vous, répondez, repartez. C'est le coût assumé d'un messager qui ne peut jamais approuver quoi que ce soit de lui-même.
Vu pendant l'essai de cette page même : une version de Codex a proposé une mise à jour au démarrage, et la mise à jour a quitté le terminal. Le messager a détecté la sortie et a relancé avec la session reprise — mais la personne a tout de même dû écarter l'invite une fois. C'est exactement le partage des rôles voulu.