Paneflow 0.8.1: libghostty-vt ersetzt Alacritty unter Windows

Paneflow 0.8.1 bringt libghostty-vt in den nativen Windows-Build. Im offiziellen x64-MSI wählt jede neue Terminalsitzung jetzt Ghostty, wenn terminal.backend nicht gesetzt ist oder auf auto bleibt.

Die Version setzt die mit Paneflow 0.8.0 unter Linux begonnene Migration der Terminal-Engine fort. Paneflow verwendet nun standardmäßig denselben Ghostty-VT-Kern unter Linux x86_64, Linux ARM64 und Windows x64 MSVC. Alacritty bleibt auf jeder Plattform als expliziter Wiederherstellungs-Backend verfügbar und ist weiterhin der Standard unter macOS und auf nicht unterstützten Zielsystemen.

Die Ghostty-Engine läuft jetzt auf ConPTY

Paneflow integriert Ghostty auf Ebene der VT-Engine. libghostty-vt verarbeitet Terminalsequenzen, verwaltet Raster und Cursorzustand, behandelt Grapheme, Zeilenumbruch und Reflow und kodiert Tastatur- und Mauseingaben. Paneflow kontrolliert weiterhin Fenster, Panes, Sitzungen, Prozesslebenszyklus, Persistenz und GPUI-Rendering.

Der Windows-Port ergänzt einen nativen Host um diese Engine. Paneflow öffnet das Pseudoterminal über portable-pty, das unter Windows ConPTY verwendet, und leitet dessen UTF-8-Ausgabe an libghostty-vt weiter. Der Ghostty-Zustand wird in Rust-Snapshots mit eigenem Besitz kopiert, bevor GPUI ihn zeichnet. Die Ghostty-Anwendung, ihre Oberfläche und ihr Renderer sind nicht in Paneflow eingebettet.

Diese Trennung ist unter Windows entscheidend. ConPTY übernimmt die Verbindung zur Shell und den Prozessvertrag des Betriebssystems. Ghostty interpretiert das Terminal. Paneflow kontrolliert das Produkt und die Pixel. Derselbe Backend-neutrale Renderer kann dadurch Alacritty- und Ghostty-Sitzungen ohne eigenen Windows-Renderpfad darstellen.

Der Port brauchte einen vollständigen Windows-Lebenszyklus

Eine statische Bibliothek, die unter Windows kompiliert, ist nur der Anfang. Terminalsitzungen benötigen auch einen deterministischen Start, Größenänderungen, Ausgabedrain, Beendigung und die Bereinigung von Kindprozessen für PowerShell, Eingabeaufforderungen, TUIs und Coding-Agenten.

Der Windows-Ghostty-Host fasst ConPTY-Größenänderungen zusammen, liest die letzte Ausgabe vor dem Schließen einer Sitzung aus, wartet vor dem Beenden auf seinen Reader und begrenzt den Rückstau, wenn mehrere Panes gleichzeitig Ausgaben erzeugen. Paneflow 0.8.1 bündelt außerdem Windows-Ghostty-Neuzeichnungen, um unnötige Renderarbeit zu vermeiden.

Eingaben durchlaufen dieselbe Grenze. Die Integration deckt Ghosttys Tastaturkodierung, AltGr, Tottasten, IME-Commits, Einfügen, Zwischenablage, Maus, Fokus und Links ab. Zwei abschließende Korrekturen in 0.8.1 erhalten mehrzeilige Shift+Enter-Eingaben über ConPTY hinweg, einschließlich Prompts von Coding-Agenten, die mit diesem Kürzel eine neue Zeile einfügen.

Paneflow enthält ein gepinntes statisches MSVC-Artefakt

Der offizielle Windows-x64-Build enthält ein gepinntes ghostty-vt-static.lib-Archiv. Quell-Commit, Zig-Toolchain, Header, generierte Rust-Bindings, Symbole, Build-Metadaten, Lizenzen und Prüfsummen werden im Repository nachverfolgt.

Nutzer müssen weder Ghostty noch Zig, eine DLL oder eine weitere Runtime installieren. Das Standard-MSI verwendet beim Paneflow-Build das verifizierte Archiv, und die fertige ausführbare Datei linkt die Engine statisch. Der native Rebuild und der konsumierende Windows-Build bleiben getrennt, damit die CI Abweichungen bei Quelle, ABI oder Artefakt vor einem Release erkennt.

Paneflow kapselt die rohe C-ABI in seinem -sys-Crate und stellt darüber sichere Rust-Besitzverhältnisse bereit. Native Handles werden über den passenden Ghostty-Allokator freigegeben, Callback-Panics bleiben hinter der FFI-Grenze, und ausgeliehene Ghostty-Zeilen oder -Zellen überleben weder die Terminalsperre noch eine Frame-Grenze.

Ghostty ist automatisch, Alacritty bleibt einen Schalter entfernt

terminal.backend akzeptiert unter Windows drei Werte: auto, ghostty und alacritty. Im offiziellen x64-Build von Paneflow 0.8.1 wählen sowohl auto als auch ghostty die Ghostty-Engine. Setze in paneflow.json den Wert alacritty, um den bisherigen Backend für neu erstellte Sitzungen zu erzwingen:

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

Die Einstellung gilt nur für neue Sitzungen. Paneflow kann einmalig auf Alacritty zurückfallen, wenn Ghostty fehlschlägt, bevor ein Shell-Prozess existiert. Nach dem Prozessstart wechselt die Sitzung niemals den Backend, und Paneflow startet dahinter keine zweite Shell.

Dieser Wiederherstellungspfad hält Terminalfehler lokal und umkehrbar. Du kannst ohne Neuinstallation von Paneflow und ohne Änderung deiner Workspace-Daten zu Alacritty zurückkehren und nach der Klärung des Problems wieder auf auto wechseln.

Ein Terminalkern für Linux und Windows

Paneflow 0.8.0 etablierte die Engine-Grenze unter Linux. Version 0.8.1 zeigt, dass diese Grenze ein deutlich anderes PTY- und Prozessmodell überqueren kann, ohne Plattformdetails in den Renderer oder das Workspace-Modell zu verschieben.

Windows ARM64 gehört nicht zu diesem Release und verwendet weiterhin Alacritty. Auch macOS bleibt auf Alacritty, während sein Ghostty-Pfad separat geprüft wird. Auf unterstützten Linux- und Windows-Builds bedeutet auto nun dasselbe: Ghostty für den Terminalkern, GPUI für das Rendering und Paneflow für den Multi-Agent-Workspace darum herum.

Installiere Paneflow 0.8.1, öffne ein neues Pane und starte die PowerShell, WSL-Shell, TUI oder den Coding-Agenten, den du gewöhnlich verwendest. Falls sich das Terminalverhalten verschlechtert, setze terminal.backend für neue Sitzungen auf alacritty und melde Shell, Windows-Version, Befehl und die kürzeste reproduzierbare Abfolge.