Cette version prolonge la migration du moteur terminal livrée sous Linux avec Paneflow 0.8.0. Paneflow utilise désormais le même cœur VT Ghostty par défaut sous Linux x86_64, Linux ARM64 et Windows x64 MSVC. Alacritty reste disponible sur chaque plateforme comme backend de récupération explicite, et demeure le choix par défaut sur macOS et les cibles non prises en charge.

Le moteur Ghostty fonctionne maintenant sur ConPTY

Paneflow intègre Ghostty au niveau du moteur VT. libghostty-vt analyse les séquences terminal, maintient la grille et l'état du curseur, gère les graphèmes, le retour à la ligne et le reflow, puis encode les entrées clavier et souris. Paneflow reste responsable de la fenêtre, des panneaux, des sessions, du cycle de vie des processus, de la persistance et du rendu GPUI.

Le port Windows ajoute un host natif autour de ce moteur. Paneflow ouvre le pseudoterminal avec portable-pty, qui utilise ConPTY sous Windows, puis transmet sa sortie UTF-8 à libghostty-vt. L'état Ghostty est copié dans des snapshots Rust possédés avant que GPUI ne le peigne. L'application Ghostty, son interface et son moteur de rendu ne sont pas embarqués dans Paneflow.

Cette séparation est importante sous Windows. ConPTY porte la connexion au shell et le contrat de processus du système. Ghostty interprète le terminal. Paneflow contrôle le produit et les pixels. Le même moteur de rendu indépendant du backend peut ainsi afficher des sessions Alacritty ou Ghostty sans chemin de rendu propre à Windows.

Le port exigeait un cycle de vie Windows complet

Une bibliothèque statique qui compile sous Windows ne suffit pas. Les sessions terminal ont aussi besoin d'un démarrage, d'un redimensionnement, d'un drain de sortie, d'un arrêt et d'un nettoyage des processus descendants déterministes avec PowerShell, les invites de commandes, les TUI et les agents de code.

Le host Ghostty Windows regroupe les redimensionnements ConPTY, draine la dernière sortie avant de fermer une session, attend son lecteur avant de quitter et borne la backpressure lorsque plusieurs panneaux produisent de la sortie en même temps. Paneflow 0.8.1 regroupe aussi les redraws Ghostty sous Windows afin d'éviter du travail de rendu inutile.

Les entrées traversent la même frontière. L'intégration couvre l'encodage clavier Ghostty, AltGr, les touches mortes, les commits IME, le collage, le presse-papiers, la souris, le focus et les liens. Deux derniers correctifs de la 0.8.1 préservent les entrées multilignes avec Shift+Enter à travers ConPTY, y compris dans les prompts d'agents de code qui utilisent ce raccourci pour insérer une nouvelle ligne.

Un artefact MSVC statique et épinglé est inclus dans Paneflow

Le build Windows x64 officiel contient une archive ghostty-vt-static.lib épinglée. Son commit source, la chaîne d'outils Zig, les headers, les bindings Rust générés, les symboles, les métadonnées de build, les licences et les sommes de contrôle sont suivis dans le dépôt.

Tu n'as besoin d'installer ni Ghostty, ni Zig, ni DLL, ni runtime supplémentaire. Le MSI standard consomme l'archive vérifiée pendant le build de Paneflow, puis l'exécutable final lie statiquement le moteur. La reconstruction native et le build Windows qui consomme l'archive restent séparés afin que la CI détecte toute dérive de source, d'ABI ou d'artefact avant une release.

Paneflow confine l'ABI C brute dans son crate -sys et expose au-dessus un ownership Rust sûr. Les handles natifs sont libérés par l'allocateur Ghostty correspondant, les panics de callbacks restent derrière la frontière FFI, et aucune ligne ou cellule Ghostty empruntée ne survit au verrou du terminal ni ne franchit la frontière d'une frame.

Ghostty devient automatique, Alacritty reste disponible

terminal.backend accepte trois valeurs sous Windows : auto, ghostty et alacritty. Dans le build x64 officiel de Paneflow 0.8.1, auto et ghostty sélectionnent le moteur Ghostty. Définis alacritty dans paneflow.json pour forcer l'ancien backend dans les nouvelles sessions :

{
  "terminal": {
    "backend": "alacritty"
  }
}

Ce réglage s'applique uniquement aux nouvelles sessions. Paneflow peut revenir une fois à Alacritty si Ghostty échoue avant la création du processus shell. Après le démarrage du processus, la session ne change jamais de backend et Paneflow ne lance jamais un second shell en arrière-plan.

Ce chemin de récupération garde les défaillances du terminal locales et réversibles. Tu peux revenir à Alacritty sans réinstaller Paneflow ni modifier les données de tes workspaces, puis repasser sur auto une fois le problème compris.

Un même cœur terminal sous Linux et Windows

Paneflow 0.8.0 a établi la frontière du moteur sous Linux. La version 0.8.1 montre que cette frontière peut traverser un modèle PTY et processus très différent sans pousser les détails de plateforme dans le moteur de rendu ou le modèle de workspace.

Windows ARM64 reste hors du périmètre de cette release et continue d'utiliser Alacritty. macOS reste également sur Alacritty pendant que son chemin Ghostty est évalué séparément. Sur les builds Linux et Windows pris en charge, auto signifie désormais la même chose : Ghostty pour le cœur terminal, GPUI pour le rendu et Paneflow pour l'espace de travail multi-agent autour.

Installe Paneflow 0.8.1, ouvre un nouveau panneau et lance le PowerShell, shell WSL, TUI ou agent de code que tu utilises habituellement. Si un comportement du terminal régresse, définis terminal.backend sur alacritty pour les nouvelles sessions et indique le shell, la version de Windows, la commande et la séquence de reproduction la plus courte possible.

Cette migration change le moteur qui interprète les données VT et maintient l'état du terminal, pas l'espace de travail autour. Paneflow reste responsable du PTY, du cycle de vie des processus, du moteur de rendu GPUI, des panneaux, des sessions, de l'état des agents, des diffs et de la persistance. macOS et Windows continuent d'utiliser Alacritty.

Ghostty rejoint Paneflow au niveau du moteur VT

Jusqu'à Paneflow 0.7.x, les sessions de terminal reposaient sur le crate Rust alacritty_terminal 0.26. Ce moteur gérait les séquences d'échappement, la grille, le scrollback, les modes d'entrée, la recherche et une partie du modèle de rendu.

Le nouveau chemin Linux utilise libghostty-vt, le moteur de terminal embarquable de Ghostty. Il analyse les séquences VT, suit l'état du curseur et de l'écran, gère les graphèmes, le retour à la ligne et le reflow, encode les entrées clavier et souris, puis expose un état de rendu incrémental à l'application hôte.

Paneflow n'embarque ni l'application Ghostty, ni son interface GTK, ni son moteur de rendu. Ghostty fournit le cœur du terminal. Paneflow transforme cet état en snapshots Rust possédés et les peint avec son moteur de rendu GPUI existant. L'interface du produit et le workflow multi-agent restent donc sous le contrôle de Paneflow.

Une frontière Paneflow sépare maintenant le moteur du produit

Remplacer le parser ne représentait qu'une partie du travail. Les types Alacritty avaient atteint la boucle PTY, le rendu, la recherche, la sélection, les liens, la restauration du scrollback et le cycle de vie des sessions. Changer de dépendance sans retirer d'abord ce couplage aurait simplement déplacé le même problème vers un nouveau moteur.

Paneflow expose maintenant sa propre frontière de session terminal. Alacritty et Ghostty produisent les mêmes commandes, événements, modes, résultats de recherche et snapshots de rendu Paneflow. Le moteur de rendu n'a plus besoin de savoir quel moteur de terminal a créé une cellule.

C'est la partie durable de la migration. Linux peut avancer en premier sans modifier macOS ou Windows, et une future mise à jour du moteur n'oblige plus le reste de l'application à adopter ses types internes.

L'API C instable reste confinée dans un petit wrapper Rust

Ghostty présente libghostty-vt comme fonctionnellement mature, mais ses signatures d'API changent encore. Paneflow épingle donc le commit Ghostty exact ae52f97d, son header C, les bindings générés, la version de Zig, la configuration du build et la somme de contrôle de l'archive.

L'ABI C brute est isolée dans un crate -sys. Un second wrapper sûr possède chaque handle natif, valide la version de l'API et les layouts C avant de créer un terminal, contient les panics des callbacks et libère les allocations Ghostty avec le bon allocateur.

La règle d'ownership compte surtout pendant le rendu. libghostty-vt expose des lignes et cellules empruntées qu'une mutation ultérieure du terminal peut invalider. Paneflow copie les données nécessaires pendant que le terminal est verrouillé, puis transmet à GPUI un snapshot Rust possédé. Aucun pointeur C ni slice emprunté ne franchit la durée du verrou ou la frontière d'une frame.

Cette stratégie coûte plus de maintenance que suivre une dépendance non épinglée. Chaque mise à jour de Ghostty impose de régénérer et relire le header, les bindings, les archives statiques, les sommes de contrôle, les symboles et les licences pour les deux architectures Linux. Ce coût reste explicite et contenu au lieu de devenir une incertitude à l'exécution.

Alacritty reste la référence différentielle et le rollback

Le résultat visible recherché est la continuité. Les shells, agents de code, TUI plein écran, recherches, sélections, opérations de presse-papiers, scrollback, événements OSC, redimensionnements, reflow et arrêts de processus doivent continuer à se comporter comme avant le changement de moteur.

Paneflow envoie les mêmes flux VT déterministes à Alacritty et Ghostty avec plusieurs tailles de fragments, puis compare leurs snapshots normalisés et leurs événements ordonnés. Des cibles de fuzzing séparées couvrent les séquences malformées ou tronquées, l'encodage des entrées, le redimensionnement, le reflow et les frontières où une séquence arrive sur plusieurs lectures du PTY. Les contrôles de paquet refusent aussi un artefact Linux qui dépend d'une libghostty.so à l'exécution, porte une mauvaise identité de build ou omet les notices natives relues.

Alacritty n'a pas été supprimé. Pour l'utiliser dans les nouvelles sessions Linux, configure le backend dans paneflow.json :

{
  "terminal": {
    "backend": "alacritty"
  }
}

Une session active ne change jamais de moteur en mémoire. Ferme-la et ouvre un nouveau panneau après avoir modifié ce réglage. auto sélectionne Ghostty dans les builds Linux standard et Alacritty sur macOS, Windows ou les builds Linux compilés avec --no-default-features.

Une liaison statique, sans installation de Ghostty

Les paquets Linux officiels contiennent une archive statique libghostty-vt épinglée pour x86_64 ou ARM64. Tu n'as besoin d'installer ni Ghostty, ni Zig, ni une bibliothèque partagée sur ta machine. Un cargo build normal depuis un checkout Paneflow propre utilise aussi l'archive vérifiée incluse dans le dépôt et ne télécharge aucune source native depuis build.rs.

Linux est la première plateforme à recevoir ce backend. Son extension à Windows ou macOS, puis le retrait éventuel d'Alacritty, feront l'objet de décisions séparées. Paneflow 0.8.0 limite le périmètre : un nouveau défaut, deux moteurs pris en charge et un rollback immédiat pour les nouvelles sessions.

Mets Paneflow à jour vers la version 0.8.0, ouvre un nouveau panneau et lance le shell, la TUI ou l'agent de code que tu utilises habituellement. Si un comportement du terminal régresse, repasse les nouvelles sessions sur Alacritty et indique la commande, ta distribution Linux et si la session tournait sous Wayland ou X11.

Le problème arrive quand tu en lances plusieurs.

Un agent corrige un bug. Un autre prépare une refactorisation. Un troisième relit un diff. À côté, un serveur de dev tourne, les tests passent ou échouent, et chaque terminal raconte une partie différente de l'histoire. Au bout d'un moment, la difficulté n'est plus de lancer des agents. C'est de savoir lequel fait quoi, lequel attend une réponse, lequel a terminé, et sur quelle branche il travaille.

Paneflow est né de ce point précis : garder plusieurs agents de code visibles, pilotables et compréhensibles dans un seul espace de travail local.

Demo video: /videos/paneflow-landing-demo.mp4

La démo complète est aussi disponible sur YouTube.

La discussion de lancement est sur Hacker News : Show HN: Paneflow.

Le terminal seul ne suffit plus toujours

J'aime les terminaux. tmux, Zellij, Ghostty, Kitty ou WezTerm restent de très bons outils, surtout quand tu travailles en SSH ou sur une machine distante.

Mais quand tu fais tourner plusieurs agents locaux sur le même projet, le problème change. Une grille de terminaux affiche des processus. Elle ne dit pas vraiment quel agent réfléchit, lequel attend ton accord, lequel a produit un diff intéressant, ni lequel est en train de refaire le travail d'un autre.

Avec assez de fenêtres ouvertes, tu finis par reconstruire l'état du projet dans ta tête. Tu passes d'un terminal à l'autre, tu relis du scrollback, tu cherches le bon répertoire, tu vérifies la branche courante, puis tu reviens au diff. Ce n'est pas un gros problème une fois. Ça devient coûteux quand c'est ton mode de travail principal.

Paneflow ne cherche pas à remplacer ton éditeur. Il remplace plutôt cette couche de coordination que beaucoup de développeurs construisent à la main avec des splits, des noms de fenêtres, des conventions de branches et beaucoup de mémoire court terme.

Un espace de travail par tâche, pas seulement un panneau par commande

Dans Paneflow, un panneau reste un vrai terminal. Tu peux y lancer Claude Code, Codex, OpenCode, Grok Builder ou n'importe quel CLI qui tourne dans un shell.

La différence est autour du terminal.

Une tâche peut avoir son agent, ses tests, son serveur de développement, sa branche git, ses diffs et ses sessions précédentes. Paneflow rassemble ces éléments dans le même espace de travail pour que tu n'aies pas à les retrouver manuellement à chaque changement de contexte.

Quand tu veux isoler un travail, chaque tâche peut tourner dans son propre git worktree. La vue Review affiche ensuite les diffs côte à côte, un worktree par colonne. Tu vois ce que chaque agent a produit sans changer de fenêtre, de branche ou d'éditeur.

Cette organisation devient particulièrement utile quand deux agents travaillent sur des zones proches du code. Tu peux garder leurs sorties ouvertes, comparer leurs changements, puis décider lequel mérite d'être gardé, corrigé ou abandonné.

La coordination passe dans l'interface CLI

Le pari le plus important de Paneflow n'est pas l'affichage. C'est la coordination.

J'appelle cette couche Paneflow Conductor. Pour le moment, ce que j'expose aux agents passe volontairement dans l'interface CLI et le socket local. La GUI reste l'endroit où tu supervises, où tu lis, où tu reprends la main sur n'importe quel panneau.

paneflow ps liste les panneaux et agents en cours avec leur état réel. paneflow watch diffuse les changements en JSONL, alimentés par les hooks et l'event bus au lieu d'interroger le terminal en boucle. Un agent peut donc observer ce qui tourne, attendre un événement, préparer un prompt pour un autre panneau et te laisser valider l'envoi.

Par défaut, Paneflow pré-remplit les prompts et c'est encore toi qui appuies sur Entrée. Le mode auto-submit existe, mais il est opt-in. Ce choix est volontaire : quand plusieurs agents peuvent agir dans le même projet, le contrôle humain doit rester visible.

Les agents peuvent lire sans prendre le contrôle

Un autre morceau important est le serveur MCP intégré. Il expose trois outils en lecture seule : list_panes, read_pane et search_pane.

Concrètement, Claude Code dans un panneau peut lire la sortie de test que Codex vient de produire dans un autre. Un agent peut chercher une erreur dans un terminal voisin avant de proposer un correctif. Tu n'as plus besoin de copier-coller la sortie d'un outil dans un autre.

La limite est stricte : cette passerelle ne permet pas d'écrire dans un panneau ni de piloter un agent à ta place. La sortie terminal est traitée comme non fiable, parce qu'un transcript d'agent ou un repo peut contenir du texte hostile. Paneflow rend le partage de contexte plus explicite, mais ne transforme pas chaque terminal en surface d'exécution ouverte.

C'est cette frontière qui m'intéresse : donner assez de contexte aux agents pour qu'ils évitent de travailler à l'aveugle, sans leur donner un pouvoir silencieux sur toute la session.

Pourquoi une app native

Paneflow est écrit en Rust et utilise GPUI, le framework d'interface derrière Zed. Ce choix vient d'une contrainte très simple : les agents peuvent tourner longtemps, parfois en parallèle, et l'espace qui les contient doit rester léger.

Je ne voulais pas d'une app Electron autour de terminaux qui exécutent déjà des processus lourds. Je ne voulais pas non plus d'un outil macOS-only alors que mon propre travail passe par Linux et Windows. Aujourd'hui, Paneflow livre des builds pour Linux, macOS Apple Silicon et Windows x64. macOS Intel et Windows ARM64 ne sont pas encore livrés.

Le résultat n'est pas un IDE. C'est un espace de travail local, open source, pensé pour les développeurs qui savent déjà utiliser leurs agents CLI mais veulent arrêter de piloter toute la coordination à la main.

Essaie Paneflow sur ta prochaine session multi-agent

Si tu lances un seul agent de temps en temps, ton terminal actuel suffit probablement.

Si tu commences à faire travailler plusieurs agents en parallèle, la question devient différente : comment garder leur état lisible, leurs branches séparées, leurs diffs vérifiables et leur contexte partageable sans perdre le contrôle ?

C'est exactement le problème que Paneflow cherche à résoudre.

Télécharge Paneflow, ouvre un projet, lance deux agents dans deux panneaux, puis regarde si l'espace de travail réduit la charge mentale que tu avais fini par accepter comme normale.

Paneflow Conductor arrive avec Paneflow 0.6.0 pour rendre cette coordination explicite. Un agent peut découvrir ses pairs, lire leur sortie, envoyer le prompt suivant et attendre la fin du tour via la CLI publique paneflow.

Demo video: /videos/paneflow-conductor-demo-linkedin.mp4

Une seule CLI pour toute la flotte

Tout passe par le socket local de Paneflow. Le conductor peut être Claude Code, Codex, OpenCode, Gemini ou un script, parce que l'interface reste une suite de commandes shell.

paneflow ps
paneflow status claude-impl
paneflow read claude-impl --lines 120
paneflow send claude-impl "Keep going and finish with REPORT_DONE"
paneflow wait --match claude-impl --pattern '^REPORT_DONE'
paneflow watch

C'est le changement important. Codex peut inspecter ce que Claude Code a produit. Claude Code peut confier une revue à OpenCode. Un script peut lancer le même workflow sans dépendre du harness utilisé dans chaque panneau.

Pour les travaux répétables, paneflow up lance un espace de travail hooké depuis un fichier TOML, et paneflow flow run exécute un pipeline multi-agent avec spawn, attente, transmission de contexte et revue.

Déléguer sans masquer les terminaux

Paneflow Conductor ne remplace pas les agents et ne transforme pas Paneflow en runtime hébergé. Les panneaux restent de vrais terminaux. Vous pouvez les lire, reprendre la main, arrêter une commande ou changer de direction.

L'intérêt est que les agents n'ont plus besoin de contexte copié-collé. Un agent conductor peut lire un panneau voisin, comprendre l'état courant, envoyer un follow-up précis, puis attendre une sentinelle comme REPORT_DONE avant de continuer.

Ce pattern devient utile quand vous séparez implémentation, revue, tests et documentation. L'agent leader n'a pas besoin de deviner depuis des notes périmées. Il inspecte la flotte réelle.

Attendre l'état, pas un timer

Paneflow 0.6.0 ajoute une machine d'état suivie tour par tour pour les agents hookés. Un panneau peut remonter des états comme thinking, waiting_for_input ou finished. paneflow watch diffuse les événements de cycle de vie en JSONL, et paneflow wait bloque sur une condition au lieu de dormir pendant un délai arbitraire.

C'est la différence entre orchestration et screen scraping. Un conductor ne devrait pas poller un terminal toutes les quelques secondes en espérant que la sortie soit stabilisée. Il doit réagir quand l'agent s'arrête vraiment, demande une entrée ou imprime le marqueur promis.

Garder la frontière de contrôle visible

Le modèle de sécurité est volontaire. Le bridge MCP est en lecture seule. paneflow read traite la sortie des pairs comme une donnée non fiable. Par défaut, paneflow send pré-remplit un prompt et un humain appuie encore sur Entrée.

L'auto-submit existe, mais il reste opt-in via la gate de scripting ou le mode AI free access. Cela garde le chemin puissant disponible pour les worktrees isolés et les workflows de confiance, sans faire des écritures silencieuses entre panneaux le comportement par défaut.

Cette frontière est le point central : donner assez de contexte partagé aux agents pour travailler ensemble, tout en gardant les terminaux visibles et la reprise humaine possible.

Commencer avec une petite flotte

La référence complète est dans la documentation Conductor. Commencez avec deux panneaux : un agent d'implémentation, un agent de revue, et un conductor qui lit les deux avant d'envoyer le prompt suivant.

Si vous faites déjà tourner plusieurs agents CLI côte à côte, Paneflow Conductor leur donne une surface commune au lieu d'un protocole privé de plus.

Demo video: /videos/paneflow-diffview.mp4

Relis tous les changements de ta branche

Ouvre la vue Diff depuis la barre latérale ou avec Ctrl+Shift+G. Paneflow affiche tous les fichiers modifiés depuis la divergence avec la branche de base, y compris les changements non commités.

Tu peux parcourir les blocs modifiés, comparer les ajouts et suppressions, puis basculer entre une vue unifiée et une vue côte à côte. Les en-têtes restent visibles pendant le défilement et la coloration syntaxique utilise Tree-sitter, le même parseur que Zed et GitHub.

Compare plusieurs branches sans changer de worktree

La vue projet affiche le diff de la tâche courante. La vue Multi-project réunit les dépôts ouverts dans des onglets. La vue Worktree place les branches voisines côte à côte, un git worktree par branche, pour comparer leur avancement sans les extraire une par une.

Demande une relecture à plusieurs agents

Chaque branche possède un bouton Review. Choisis Claude Code, Codex, OpenCode ou Pi et Paneflow ouvre chaque agent dans un vrai terminal, directement sous le diff et dans le bon répertoire.

Paneflow prépare le prompt de relecture, mais ne l'envoie jamais sans ton accord. Tu peux le vérifier avant d'appuyer sur Entrée. L'agent analyse ensuite le diff et retourne des remarques liées aux fichiers et aux lignes concernées.

Lance deux agents pour obtenir deux lectures différentes du même changement. Le second reçoit une consigne plus critique afin de réduire les réponses trop similaires.

Tu peux aussi envoyer une ligne ou un bloc précis à un agent pour lui poser une question ciblée.

Fais relire ta prochaine branche dans Paneflow

La vue Diff et la relecture par agents sont disponibles dans Paneflow 0.3.7, une version après les sessions d'agents. Télécharge la dernière version, ouvre un projet et sélectionne Diff dans la barre latérale.

Demo video: /videos/sessions-agents.mp4

Retrouve les sessions du bon projet

Paneflow détecte les sessions Claude Code, Codex et OpenCode associées au répertoire de travail actif. Elles sont regroupées par agent, sans mélanger les conversations de tes autres projets.

Choisis une session et Paneflow la reprend dans le panneau courant avec son historique intact.

Reviens à une tâche sans repartir de zéro

Une session contient les échanges, les décisions et le plan déjà construit avec l'agent. Pouvoir la quitter puis la reprendre te permet de passer d'une tâche à l'autre sans perdre ce contexte ni répéter les mêmes explications.

Tu peux fermer un panneau, redémarrer Paneflow ou revenir plus tard sur le projet. Les sessions utiles restent disponibles lorsque tu en as besoin.

Reprends ta prochaine session dans Paneflow

Les sessions d'agents sont disponibles dans Paneflow 0.3.6, la même version que la barre latérale Files. Télécharge la dernière version, lance un agent dans un projet, puis retrouve sa session depuis Paneflow.

Demo video: /videos/paneflow-dock.mp4

Parcours le projet courant

Ouvre la barre latérale depuis le bouton Files pour afficher les dossiers et fichiers du projet. L'arborescence suit automatiquement l'espace de travail actif et se met à jour lorsque les fichiers changent sur le disque.

Les éléments ignorés par .gitignore restent visibles, mais sont atténués pour laisser ressortir les fichiers utiles. Paneflow mémorise aussi les dossiers ouverts entre les redémarrages.

Lis le Markdown dans un panneau

Clique sur un README, un PRD ou un autre fichier Markdown pour l'ouvrir rendu dans un panneau. Tu peux ainsi garder les instructions, le plan et l'agent qui les utilise dans la même disposition.

Le reste des fichiers est affiché pour te permettre de comprendre rapidement la structure du projet, sans transformer Paneflow en gestionnaire de fichiers complet.

Garde la documentation près de tes agents

La barre latérale Files est disponible dans Paneflow 0.3.6, la même version que les sessions d'agents. Télécharge la dernière version, ouvre un projet et utilise le bouton Files pour parcourir son contenu.

Paneflow part de ce problème : plusieurs agents ont besoin d'un espace de travail conçu pour les garder compréhensibles.

Une tâche ne se résume pas à un terminal

Une tâche peut réunir un agent, une branche git, un serveur de développement, des tests, un diff et plusieurs sessions. Si ces éléments sont dispersés, tu dois reconstruire leur contexte chaque fois que tu changes de fenêtre.

Paneflow les regroupe dans un seul espace de travail et restaure cet environnement lorsque tu reviens. Tu ne retrouves pas seulement un terminal ouvert. Tu retrouves la tâche telle que tu l'avais laissée.

Les agents peuvent s'aider sans prendre le contrôle

Le serveur MCP de Paneflow expose trois outils en lecture seule, list_panes, read_pane et search_pane, afin qu'un agent puisse lire la sortie d'un autre panneau. Il peut vérifier un test, rechercher une erreur ou consulter le travail d'un autre agent sans que tu aies à copier-coller son contenu.

Cette passerelle reste volontairement en lecture seule. Les agents peuvent partager du contexte, mais ils ne peuvent pas saisir de commandes les uns chez les autres. Tu gardes le contrôle des décisions et des actions.

Un outil local que tu peux comprendre

Paneflow fonctionne localement, sans compte et sans télémétrie. Son code est disponible sous licence GPL-3.0-or-later.

Ce choix est simple : l'espace qui exécute tes agents et contient le contexte de ton travail doit rester rapide, transparent et sous ton contrôle.

Essaie cette approche sur ton prochain projet

Télécharge Paneflow et rassemble les agents, terminaux et outils de ta prochaine tâche dans un seul espace de travail.

Paneflow rassemble tes agents de code, leurs terminaux et tout ce qui les entoure dans un seul espace de travail local-first.

Un espace de travail par tâche

Lance Claude Code, Codex, OpenCode et 13 autres agents CLI dans des panneaux côte à côte. Ajoute les tests, les serveurs de développement ou les commandes dont la tâche a besoin, puis rattache cet espace à sa branche git.

Chaque espace conserve sa disposition, ses terminaux et ses sessions. Tu peux passer d'une tâche à l'autre ou redémarrer Paneflow sans reconstruire ton environnement.

Le contexte reste visible

• Agents et terminaux : vois tout ce qui tourne et passe d'un panneau à l'autre au clavier.
• Branches et diffs : garde chaque tâche liée à sa branche et relis ses changements sans quitter Paneflow.
• Sessions d'agents : retrouve et reprends les sessions Claude Code, Codex et OpenCode du projet courant.
• Contexte entre panneaux : grâce au serveur MCP intégré, un agent peut lire la sortie d'un test ou rechercher une erreur dans un autre panneau, sans copier-coller.
• Environnement local : aucun compte, aucune télémétrie et aucun service distant imposé.

Une application native conçue pour durer

Paneflow est écrit en Rust et utilise GPUI, le moteur de rendu de Zed. Les panneaux et les terminaux sont rendus directement par l'application, sans navigateur embarqué autour de processus qui peuvent tourner pendant des heures. L'application entière pèse entre 14 et 19 Mo.

Le projet est open source sous licence GPL-3.0-or-later et fonctionne sur Linux, macOS et Windows.

Lance ton prochain agent dans Paneflow

Télécharge Paneflow, ouvre un projet et crée un espace de travail pour la tâche sur laquelle tu veux avancer.