Lancement de Paneflow sur Show HN

Contexte du lancement. Cet article et la démo ci-dessous décrivent l'interface de juin 2026, dont l'ancienne vue Review avec une colonne par worktree. Pour Paneflow 0.17.4, consulte la présentation de Paneflow et le guide Changes.

Paneflow a été lancé sur Show HN en juin 2026 comme multiplexeur natif pour agents de code. L'objectif était de réunir les agents, le contexte du projet et la revue de code dans une interface locale.

Quand Claude Code corrige un bug, que Codex relit les changements et qu'un serveur de dev tourne à côté, chaque terminal contient une partie de l'état du projet. Passer de l'un à l'autre demande de retrouver le bon répertoire, de vérifier la branche et de lire la sortie pour savoir qui attend une réponse. Paneflow réunissait ces terminaux et leur contexte.

Retrouve la démo complète du lancement de Paneflow sur YouTube ou la discussion Show HN: Paneflow.

Regrouper les terminaux et les changements d'une tâche

Chaque panneau restait un terminal exécutant un processus CLI ordinaire. Claude Code, Codex, OpenCode, les tests et les serveurs de dev pouvaient tourner côte à côte dans le même espace de travail.

Une tâche pouvait utiliser son propre worktree Git pour séparer ses fichiers et sa branche. Dans l'interface du lancement, la vue Review affichait les diffs côte à côte, avec un worktree par colonne. Tu pouvais comparer les changements de deux tâches avant de décider quoi garder ou corriger. Des worktrees séparés demandaient toujours une revue et une résolution des conflits au moment de réunir les branches.

Coordonner les panneaux depuis la CLI

Paneflow Conductor exposait la coordination par la CLI et un socket local. paneflow ps listait les panneaux et les agents ; paneflow watch diffusait les événements en JSONL. Le suivi de l'activité reposait sur les hooks et le bus d'événements, selon l'intégration disponible pour chaque agent.

L'interface te permettait de lire la sortie, d'interrompre un processus ou de reprendre la main sur un terminal. L'envoi d'un prompt pré-remplissait le texte par défaut, en te laissant appuyer sur Entrée. L'envoi automatique demandait une activation explicite.

Partager les sorties avec un bridge MCP en lecture seule

Le serveur MCP exposait trois outils : list_panes, read_pane et search_pane. Un agent connecté au bridge pouvait lire la sortie des tests d'un autre panneau ou y chercher une erreur avant de proposer un correctif.

Le bridge ne pouvait ni saisir du texte dans les panneaux ni piloter les processus. La sortie terminal restait une donnée non fiable : partager le transcript d'un agent ne donnait aucune autorité à ses instructions. L'accès en lecture et le contrôle par la CLI avaient des permissions distinctes.

Une interface native pour des processus locaux

Paneflow était construit en Rust avec GPUI, le framework d'interface utilisé par Zed. Les agents restaient des processus CLI locaux, connectés à leurs propres fournisseurs de modèles.

Le lancement rapprochait le contexte du projet et la revue de ces processus. Attribuer les tâches, répondre aux demandes d'approbation et relire le code produit restaient de ta responsabilité.