[Paneflow 0.8.1](https://github.com/arthjean/paneflow/releases/tag/v0.8.1) apporte `libghostty-vt` au build Windows natif. Dans le MSI x64 officiel, chaque nouvelle session de terminal sélectionne maintenant Ghostty lorsque `terminal.backend` est omis ou laissé sur `auto`. 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.
Icône de Ghostty à côté du logo Windows dans un paysage bleu et lavande
## 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 : ```json { "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.