En lançant simultanément des agents de codage IA comme Claude Code et Codex dans plusieurs sessions tmux, j’ai fini par rencontrer des problèmes. Je ratais quelles sessions étaient terminées, lesquelles étaient bloquées en m’attendant, et je ne découvrais les agents tournant en arrière-plan qu’une fois leur usage limit atteint.
tmux atteignait ses limites, alors j’ai créé comux.
comux est un multiplexeur de style tmux conçu pour faire tourner des agents IA.
- Il affiche en temps réel dans une barre latérale l’état des agents de toutes les sessions (working / ready / blocked)
- Il envoie immédiatement une notification desktop lorsqu’un agent termine son tour ou attend une saisie
- Même si vous tuez le serveur ou redémarrez, au redémarrage chaque agent est restauré au point où se trouvait la conversation (contrairement à tmux-resurrect, la session est relancée)
- Vous pouvez suivre en temps réel dans la barre de statut l’usage des agents et les notifications en attente
C’est un binaire statique unique sans dépendances, il fonctionne donc partout, y compris sur des serveurs headless via SSH.
Il fait partie d’un projet de terminal plus vaste (copad), mais comux peut être installé séparément :
# Installer uniquement Comux
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/… | bash
# Installer aussi Copad (Linux et MacOS)
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/master/install.sh | bash
Récit de 4 mois de développement : https://marshallku.com/dev/road-to-making-my-own-terminal/
Les retours de celles et ceux qui font tourner plusieurs agents sont les bienvenus.
3 commentaires
J’ai aussi beaucoup apprécié l’article de blog.
Comme je développe moi-même un terminal avec une motivation similaire, quelques questions me sont venues.
Personnellement, j’ai l’impression qu’il y a rarement eu une époque où l’environnement DX évoluait aussi vite qu’aujourd’hui, avec des différences aussi marquées d’un développeur à l’autre.
Je ne sais pas si le créateur l’a ressenti aussi, mais je me suis dit que, dans ces moments-là, il est d’autant plus avantageux d’avoir le contrôle entre ses propres mains.
Et en me demandant quelle était la base de la DX à l’ère de l’IA, j’en suis arrivé à penser qu’elle était centrée sur le terminal.
J’ai essayé tous les terminaux récemment à la mode, mais la saisie du coréen est médiocre dans la plupart d’entre eux, et la DX/UX pour utiliser des agents était peu pratique. J’en ai donc conclu qu’il fallait que je le développe moi-même, et je pense avoir ainsi obtenu une meilleure productivité que d’autres avec mon propre terminal.
Dans mon cas, pour obtenir un contrôle total,
je me suis dit qu’il fallait aussi minimiser les dépendances à des bibliothèques externes, et j’ai donc choisi de tout développer moi-même en Zig (à l’exception de cas inévitables comme la webview).
En lisant l’article de blog et le code, j’ai vu que vous aviez choisi Rust et des bibliothèques externes existantes dans l’écosystème Rust, comme rataui, plutôt que de tout développer vous-même. Je serais curieux de savoir pourquoi.
D’après l’article, il semble aussi qu’il y ait eu des problèmes liés aux dépendances à des bibliothèques externes.
Et comme la webview est une webview native, la plupart des environnements web n’étant pas des environnements Safari, il me semble difficile de faire de vrais tests E2E complets sur cette partie. Est-ce que vous déléguez simplement cela à des outils de test externes ? Ou bien prévoyez-vous aussi d’intégrer CEF plus tard ?
De mon côté, j’utilise maintenant mon terminal dans une certaine mesure et je suis entré dans une phase de stabilisation, où je réfléchis beaucoup à l’ajout de fonctionnalités, à la planification ou à l’UX. Mais pendant le développement, il a dû y avoir beaucoup de crashes et divers bugs.
Je serais donc aussi curieux de savoir au bout de combien de temps après le début du développement il a été suffisamment stable pour que vous puissiez l’utiliser directement dans votre propre terminal, plutôt que de l’exécuter depuis un terminal externe.
Bonjour !
Merci d’avoir partagé votre expérience et vos réflexions.
Bien sûr, à mesure que le coût de production du code baisse, la voie du développement en interne s’est ouverte, mais personnellement, indépendamment de l’arrivée de l’ère de l’IA, j’envisage l’adoption de bibliothèques externes selon les critères suivants.
Je ne développe moi-même quelque chose que lorsque je pense que ces deux conditions sont réunies.
Il y a plusieurs raisons à cela, mais au final, dès lors que je commence à gérer moi-même le moindre morceau de code, il entre dans un périmètre dont je dois assurer la revue, les tests, la maintenance, etc., et je considère qu’il y a toujours un coût qui dépasse largement la simple écriture du code.
Les problèmes rencontrés pendant le développement venaient aussi de nombreux conflits avec des programmes assez centraux comme le window manager ; je pense donc que si j’avais même dû tout construire from scratch, j’aurais dû consacrer bien plus de temps à l’implémentation et à la validation qu’au débogage et aux tests liés aux conflits avec les dépendances externes.
Par ailleurs, depuis le début du développement, j’ai continué à utiliser, non sans douleur, l’outil que j’avais moi-même créé, et je me dis que cela n’a peut-être été possible que parce que j’ai commencé le développement en m’appuyant dans une certaine mesure sur des dépendances.
Comme dans le cas où SwiftTerm a été retiré sur macOS, j’intègre d’abord une dépendance externe pour vérifier si le concept que je veux fonctionne, puis, lorsqu’un élément doit être implémenté par mes soins, je commence à le développer moi-même ; mais même à ce stade, mes programmes fonctionnent toujours grâce à ces dépendances externes, ce qui me permet de continuer à me concentrer sur la stabilisation et l’ajout de fonctionnalités par-dessus.
De plus, si on intègre WebKit, la plupart des web apps fonctionnent de la même manière que lorsqu’on ouvre un navigateur classique !
Ces derniers temps, j’utilise aussi activement des outils qui permettent de piloter un headless browser en CLI, ainsi que Claude dans Chrome, et comme je veux éviter de superposer Chromium jusqu’au terminal au prix d’une consommation mémoire excessive, sauf changement majeur je ne pense pas modifier en profondeur la stack technique de la webview intégrée au terminal.
Merci de m’avoir lu !
Le lien d’installation du multiplexeur semble être tronqué… Si vous consultez cette section du README, vous pourrez installer uniquement le multiplexeur.