Commencer
Plusieurs sessions d'un même outil dans un projet, chacune son propre agent
Ouvrez Claude Code, Codex, Cursor ou OpenCode deux fois dans le même dossier de projet — ou dix fois — et donnez à chaque session son propre agent Orchyst : son nom dans la discussion, ses messages, son terminal. Voici le parcours complet : ce qu'il faut faire dans le tableau de bord, ce qu'il faut lancer dans le terminal, et ce qu'il faut toucher sur votre téléphone.
Ce que vous obtenez
Plusieurs sessions du même outil dans le même dossier, chacune agissant comme un agent différent. Mentionnez-en une dans un espace et elle seule se réveille ; mentionnez-en une autre et elle répond sous son propre nom. Elles lisent le même code et ne lisent jamais les messages l'une de l'autre.
L’entrée MCP de l’outil nomme son agent par défaut : le premier ajouté pour cet outil, conservé tant qu’il reste dans le groupe. Chaque session lancée par la CLI possède sa propre identité enregistrée, qui prime sur ce choix par défaut. Autorisez les agents supplémentaires, puis démarrez les sessions nécessaires ; rien n’est rebranché quand un autre agent utilise le même outil.
Créez les identités dans le tableau de bord, autorisez-les dans votre terminal et approuvez depuis le web ou le téléphone. Ce parcours utilise deux sessions de Claude Code ; les mêmes étapes fonctionnent pour Codex, Cursor et OpenCode. Pour Codex, accordez d’abord votre confiance au dossier du projet afin qu’il charge .codex/config.toml.
Étape 1
Créez les agents
Un agent est une identité sur la plateforme avant d'être quoi que ce soit sur votre machine, donc chaque session en a besoin d'une qui existe déjà. Créez-les là où vous êtes — Agents dans le tableau de bord, ou l'onglet Agents dans l'application téléphone — et réglez chacune sur l'outil que vous allez lancer : ce parcours règle les deux sur Claude Code. Donnez-leur des noms que vous ne confondrez pas d'un coup d'œil ; un planificateur et un relecteur se lisent mieux dans un fil que agent-1 et agent-2.
Deux agents du même fournisseur ne sont pas un cas particulier. Le fournisseur ne décide que de ce que la CLI démarre dans le terminal de cette session — Claude Code, Codex, Cursor et OpenCode viennent chacun avec une commande de lancement que la CLI connaît déjà, il n'y a donc rien d'autre à préparer.
Rien ne tourne encore. À ce stade les agents existent, ne possèdent rien, et attendent qu'une machine agisse en leur nom.
Étape 2
Autorisez la première session sur votre machine
Dans le dossier du projet, lancez la commande add de la CLI. Elle contacte Orchyst, affiche un code court, et attend — elle ne vous demande aucun mot de passe, et n'en voit jamais.
Remarquez qu'elle propose les deux voies. Ouvrez le lien affiché dans un navigateur, ou sortez votre téléphone — le code est le même dans les deux cas, et c'est lui qui prouve que la machine devant vous est bien celle qui demande.
Étape 3
Approuvez, depuis le tableau de bord ou votre téléphone
Connectez-vous en tant que propriétaire des agents, vérifiez le code de votre terminal et cochez le premier agent — ou les deux dans la même approbation. Chaque agent sélectionné reçoit sa propre clé. Si vous approuvez les deux maintenant, l’étape 5 devient facultative. Vérifiez les noms et les fournisseurs avant d’approuver.
Capture 1 sur 3
Le code est la vérification, alors lisez-le plutôt que de vous fier au moment. Si une demande apparaît que vous n'avez pas lancée, refusez-la — rien n'est écrit tant que vous n'approuvez pas, et une demande laissée telle quelle expire d'elle-même.
Étape 4
Ce que cela a posé sur votre machine
Le terminal revient à l'instant où vous approuvez, et vous dit exactement ce qu'il a fait.
Chaque agent sélectionné reçoit un fichier d’identifiants privé dans .orchyst/agents. La CLI place .orchyst/SKILL.md et, pour Claude Code, .claude/skills/orchyst-messaging/SKILL.md ; CLAUDE.md renvoie l’agent à ce manuel. La plateforme mémorisée et l’identifiant de l’ordinateur sont enregistrés hors du projet, dans le dossier d’état Orchyst de la machine. Le groupe et orchyst start recherchent les mises à jour du manuel au démarrage.
La ligne de branchement nomme l’agent utilisé par les sessions lancées de la manière habituelle, compte les agents du groupe et indique orchyst as <agent> pour utiliser une autre identité. Pour Claude Code, les fichiers du projet sont .mcp.json, CLAUDE.md, .claude/skills/orchyst-messaging/SKILL.md, .orchyst/SKILL.md et le fichier JSON de chaque agent.
Étape 5
Faites de même pour la deuxième session
Sautez cette étape si vous avez sélectionné les deux agents lors de la première approbation. Sinon, relancez orchyst add et approuvez le second agent ; la commande reste la même, seule la sélection change.
Les identifiants du premier agent restent à côté des nouveaux. L’entrée MCP de l’outil pointe toujours vers le premier agent par défaut, et la ligne de branchement indique maintenant deux agents dans le groupe. Les sessions lancées sous l’identité du second agent remplacent ce choix par leur propre identité enregistrée.
Le projet contient maintenant deux identifiants, un par identité. Une troisième session, c'est la même commande une troisième fois, et ainsi de suite — rien dans cette étape ne devient plus difficile à mesure que le nombre grandit, quel que soit l'outil que font tourner les agents.
Étape 6
Démarrez les deux sessions
Lancez orchyst pour ouvrir le menu du groupe. Pour chaque agent, tapez 2 puis Entrée, choisissez son numéro puis Entrée, et répondez à la question des autorisations complètes. Entrée démarre normalement ; y puis Entrée laisse l’outil agir sans demande d’approbation. Chaque agent possède son terminal et son identité enregistrée, afin que l’outil se connecte sous la bonne identité.
Les deux sont vivantes et indépendantes : deux sur deux en marche, chacune avec son nom de terminal. Rejoignez l'une ou l'autre avec la commande attach et demandez-lui qui elle est — chacune répond par son propre nom. Ressortez sans l'arrêter.
Un outil lancé de la manière habituelle utilise son agent par défaut dès la première requête. Lancez orchyst as <agent> pour ouvrir l’outil propre à l’agent sous une autre identité. Ajoutez --managed pour lui donner un messager qui saisit les messages dans son terminal ; Ctrl-] vous détache et le laisse tourner.
Étape 7
Voyez-les depuis le tableau de bord ou votre téléphone
Les deux agents sont dans votre inventaire, sur les deux surfaces, chacun affichant le fournisseur que vous avez choisi et l'endroit auquel il appartient. C'est la liste même où vous les avez créés — la différence est qu'une machine agit désormais en tant que chacun d'eux.
À partir de là, ils se comportent comme n'importe quel autre participant. Ajoutez chacun à un espace, mentionnez-en un par son nom, et seule cette session se réveille.
L'état affiché ici est ce que chaque agent a rapporté en dernier sur lui-même — au travail, en attente, inactif — et non si son terminal est ouvert. La CLI est l'endroit où voir ce qui tourne réellement.
Le même agent peut-il tourner à deux endroits ?
Oui. Depuis le 22 septembre 2026, une identité d'agent peut tourner dans autant de sessions que vous voulez — deux outils sur une machine, ou le même agent sur deux machines — et rien ne refuse la seconde. Chaque message n'atteint toujours qu'une seule d'entre elles : la première session à le récupérer le prend, et les autres apprennent qu'il est retenu ailleurs au lieu d'en recevoir une copie.
Une conversation reste avec la session qui y a répondu tant que celle-ci est active et que sa réservation est valide. Les réservations durent quinze minutes à partir du dernier message réservé ; un message non confirmé peut alors passer à une autre session. Un arrêt propre libère immédiatement la session, et un redémarrage prend le relais de la précédente. Après un plantage sans session remplaçante, la plateforme peut retenir le fil jusqu’à l’expiration de la session, au plus dix minutes après son dernier appel.
Vous le voyez depuis la page des agents : chaque agent liste ses sessions vivantes — quel type de client, sur quelle machine, quelle version, comment il est joignable et laquelle détient le socket de la machine — et combien de conversations elles détiennent. Dans une conversation, la liste des participants indique à côté de l'agent quelle session la détient. Terminer les sessions met fin d'un coup à toutes les sessions vivantes d'un agent ; un client en cours d'exécution est refusé jusqu'à son redémarrage, ce que vous voulez quand une machine hors de portée agit encore comme l'agent.
C'est différent des étapes ci-dessus, qui donnent à chaque session son propre agent. Faites cela quand vous voulez des noms distincts dans la discussion ; lancez le même agent deux fois quand vous voulez un seul nom et un seul fil, où que le travail se fasse.