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.

Die Migration ändert die Engine, die VT-Daten interpretiert und den Terminalzustand verwaltet, nicht den Workspace darum herum. Paneflow bleibt für PTY, Prozesslebenszyklus, GPUI-Renderer, Panes, Sessions, Agent-Status, Diffs und Persistenz verantwortlich. macOS und Windows verwenden weiterhin Alacritty.

Ghostty kommt auf der Ebene der VT-Engine zu Paneflow

Bis Paneflow 0.7.x basierten Terminal-Sessions auf dem Rust-Crate alacritty_terminal 0.26. Diese Engine verarbeitete Escape-Sequenzen, Grid, Scrollback, Eingabemodi, Suche und einen Teil des Rendering-Modells.

Der neue Linux-Pfad verwendet libghostty-vt, Ghosttys einbettbare Terminal-Engine. Sie parst VT-Sequenzen, verwaltet Cursor- und Bildschirmzustand, verarbeitet Grapheme, Zeilenumbruch und Reflow, kodiert Tastatur- und Mauseingaben und stellt der Host-Anwendung einen inkrementellen Renderzustand bereit.

Paneflow bettet weder die Ghostty-App noch ihre GTK-Oberfläche oder ihren Renderer ein. Ghostty liefert den Terminalkern. Paneflow wandelt diesen Zustand in eigene Rust-Snapshots um und zeichnet sie mit dem bestehenden GPUI-Renderer. Produktoberfläche und Multi-Agent-Workflow bleiben damit unter Paneflows Kontrolle.

Eine Paneflow-Grenze trennt Engine und Produkt

Den Parser zu ersetzen war nur ein Teil der Arbeit. Alacritty-Typen reichten bis in PTY-Schleife, Rendering, Suche, Auswahl, Links, Scrollback-Wiederherstellung und Session-Lebenszyklus. Eine Abhängigkeit ohne vorherige Entkopplung auszutauschen, hätte dasselbe Problem nur in eine neue Engine verschoben.

Paneflow stellt jetzt eine eigene Terminal-Session-Grenze bereit. Alacritty und Ghostty erzeugen dieselben Paneflow-Befehle, Events, Modi, Suchergebnisse und Render-Snapshots. Der Renderer muss nicht mehr wissen, welche Engine eine Zelle erzeugt hat.

Diese Grenze ist der dauerhafte Teil der Migration. Linux kann zuerst umgestellt werden, ohne macOS oder Windows zu verändern. Künftige Engine-Updates zwingen den Rest der Anwendung nicht mehr dazu, deren interne Typen zu übernehmen.

Die instabile C-API bleibt in einem kleinen Rust-Wrapper

Ghostty bezeichnet libghostty-vt als funktional ausgereift, während sich die API-Signaturen weiterhin ändern. Paneflow pinnt deshalb den exakten Ghostty-Commit ae52f97d, den C-Header, generierte Bindings, die Zig-Version, Build-Konfiguration und Archiv-Prüfsumme.

Die rohe C-ABI ist in einem einzelnen -sys-Crate isoliert. Ein zweiter sicherer Wrapper besitzt jeden nativen Handle, validiert API-Version und C-Layouts vor dem Erzeugen eines Terminals, fängt Panics aus Callbacks ab und gibt Ghostty-Allokationen mit dem passenden Allocator frei.

Die Ownership-Regel ist vor allem beim Rendering wichtig. libghostty-vt stellt geliehene Zeilen und Zellen bereit, die eine spätere Terminalmutation ungültig machen kann. Paneflow kopiert die benötigten Daten unter dem Terminal-Lock und übergibt GPUI danach einen eigenen Rust-Snapshot. Kein C-Zeiger und kein geliehener Slice überlebt den Lock oder eine Frame-Grenze.

Diese Strategie verursacht mehr Wartungsarbeit als eine ungepinnte Abhängigkeit. Jedes Ghostty-Update erfordert neue und geprüfte Header, Bindings, statische Archive, Prüfsummen, Symbole und Lizenzdaten für beide Linux-Architekturen. Dieser Aufwand bleibt explizit und eingegrenzt, statt zur Laufzeit Unsicherheit zu erzeugen.

Alacritty bleibt Referenz und Rollback

Das beabsichtigte sichtbare Ergebnis ist Kontinuität. Shells, Coding-Agents, Vollbild-TUIs, Suche, Auswahl, Clipboard, Scrollback, OSC-Events, Größenänderung, Reflow und Prozessende müssen sich nach dem Engine-Wechsel weiterhin wie zuvor verhalten.

Paneflow speist dieselben deterministischen VT-Streams in mehreren Chunk-Größen in Alacritty und Ghostty ein und vergleicht anschließend normalisierte Snapshots und geordnete Events. Separate Fuzzing-Ziele prüfen fehlerhafte und abgeschnittene Sequenzen, Eingabekodierung, Resize und Reflow sowie Sequenzgrenzen über mehrere PTY-Lesevorgänge. Paketprüfungen lehnen außerdem Linux-Artefakte ab, die zur Laufzeit libghostty.so benötigen, eine falsche Build-Identität enthalten oder geprüfte Native Notices auslassen.

Alacritty wurde nicht entfernt. Um es für neu erstellte Linux-Sessions zu verwenden, setze den Backend-Wert in paneflow.json:

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

Eine aktive Session wechselt ihre Engine nie im Speicher. Schließe sie und öffne nach der Änderung einen neuen Pane. auto wählt Ghostty in Standard-Linux-Builds und Alacritty unter macOS, Windows oder Linux-Builds mit --no-default-features.

Statische Verknüpfung ohne Ghostty-Installation

Die offiziellen Linux-Pakete enthalten ein gepinntes statisches libghostty-vt-Archiv für x86_64 oder ARM64. Auf dem System müssen weder Ghostty noch Zig oder eine Shared Library installiert sein. Auch ein normaler cargo build aus einem sauberen Paneflow-Checkout verwendet das geprüfte mitgelieferte Archiv und lädt während build.rs keinen nativen Quellcode herunter.

Linux ist die erste Plattform für dieses Backend. Die Erweiterung auf Windows oder macOS und eine mögliche spätere Entfernung von Alacritty sind getrennte Entscheidungen. Paneflow 0.8.0 hält den Wirkungsbereich klein: ein neuer Standard, zwei unterstützte Engines und ein sofortiger Rollback für neue Sessions.

Aktualisiere auf Paneflow 0.8.0, öffne einen neuen Pane und starte deine übliche Shell, TUI oder deinen Coding-Agent. Falls ein Terminalverhalten regressiert, stelle neue Sessions auf Alacritty zurück und nenne den Befehl, deine Linux-Distribution und ob die Session unter Wayland oder X11 lief.

Das Problem beginnt, wenn du mehrere davon startest.

Ein Agent behebt einen Bug. Ein anderer bereitet ein Refactoring vor. Ein dritter prüft einen Diff. Daneben läuft ein Dev-Server, Tests schlagen fehl oder laufen durch, und jedes Terminal erzählt einen anderen Teil der Geschichte. Irgendwann ist das Schwierige nicht mehr, Agenten zu starten. Es ist zu wissen, welcher Agent woran arbeitet, welcher auf Eingabe wartet, welcher fertig ist und auf welchem Branch er unterwegs ist.

Paneflow ist genau aus diesem Problem entstanden: mehrere Coding-Agenten in einem lokalen Workspace sichtbar, steuerbar und verständlich zu halten.

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

Die vollständige Demo ist auch auf YouTube verfügbar.

Der Launch-Thread ist auf Hacker News: Show HN: Paneflow.

Das Terminal allein reicht nicht immer

Ich mag Terminals. tmux, Zellij, Ghostty, Kitty und WezTerm sind starke Werkzeuge, besonders wenn du per SSH oder auf einer entfernten Maschine arbeitest.

Wenn du aber mehrere lokale Agenten am selben Projekt laufen lässt, ändert sich das Problem. Ein Terminal-Raster zeigt Prozesse. Es sagt dir nicht wirklich, welcher Agent nachdenkt, welcher auf deine Zustimmung wartet, welcher einen interessanten Diff erzeugt hat oder welcher gerade die Arbeit eines anderen wiederholt.

Mit genug offenen Fenstern rekonstruierst du den Zustand des Projekts im Kopf. Du wechselst von Terminal zu Terminal, liest Scrollback, suchst das richtige Verzeichnis, prüfst den aktuellen Branch und gehst zurück zum Diff. Einmal ist das kein großes Problem. Als täglicher Arbeitsmodus wird es teuer.

Paneflow versucht nicht, deinen Editor zu ersetzen. Es ersetzt die Koordinationsschicht, die viele Entwickler von Hand aus Splits, Fensternamen, Branch-Konventionen und viel Kurzzeitgedächtnis bauen.

Ein Workspace pro Aufgabe, nicht nur ein Pane pro Befehl

In Paneflow bleibt ein Pane ein echtes Terminal. Du kannst Claude Code, Codex, OpenCode, Grok Builder oder jedes andere CLI starten, das in einer Shell läuft.

Der Unterschied liegt um das Terminal herum.

Eine Aufgabe kann ihren Agenten, Tests, Dev-Server, Git-Branch, Diffs und frühere Sessions haben. Paneflow hält diese Teile im selben Workspace, damit du sie nicht bei jedem Kontextwechsel neu suchen musst.

Wenn du Arbeit isolieren willst, kann jede Aufgabe in einem eigenen git worktree laufen. Die Review-Ansicht zeigt die Diffs dann nebeneinander, ein Worktree pro Spalte. Du siehst, was jeder Agent erzeugt hat, ohne Fenster, Branches oder Editor zu wechseln.

Diese Organisation wird besonders nützlich, wenn zwei Agenten an nah beieinanderliegenden Stellen im Code arbeiten. Du kannst ihre Ausgaben offen halten, ihre Änderungen vergleichen und dann entscheiden, was behalten, korrigiert oder verworfen wird.

Koordination läuft über die CLI-Oberfläche

Die wichtigste Wette in Paneflow ist nicht die Darstellung. Es ist die Koordination.

Ich nenne diese Schicht Paneflow Conductor. Vorerst läuft das, was ich Agenten bereitstelle, bewusst über die CLI-Oberfläche und den lokalen Socket. Die GUI bleibt der Ort, an dem du beaufsichtigst, liest und jedes Pane übernehmen kannst.

paneflow ps listet die laufenden Panes und Agenten mit ihrem echten Zustand. paneflow watch streamt Änderungen als JSONL, gespeist von Hooks und dem Event-Bus statt durch wiederholtes Abfragen des Terminals. Ein Agent kann sehen, was läuft, auf ein Ereignis warten, einen Prompt für ein anderes Pane vorbereiten und dir das eigentliche Senden überlassen.

Standardmäßig füllt Paneflow Prompts vor, und du drückst weiterhin Enter. Auto-submit existiert, ist aber opt-in. Diese Entscheidung ist bewusst: Wenn mehrere Agenten im selben Projekt handeln können, muss menschliche Kontrolle sichtbar bleiben.

Agenten können lesen, ohne die Kontrolle zu übernehmen

Ein weiterer wichtiger Baustein ist der integrierte MCP-Server. Er stellt drei schreibgeschützte Tools bereit: list_panes, read_pane und search_pane.

Praktisch kann Claude Code in einem Pane die Testausgabe lesen, die Codex gerade in einem anderen Pane erzeugt hat. Ein Agent kann in einem benachbarten Terminal nach einem Fehler suchen, bevor er einen Fix vorschlägt. Du musst die Ausgabe eines Tools nicht mehr in ein anderes kopieren.

Die Grenze ist strikt: Diese Brücke kann nicht in ein Pane schreiben und keinen Agenten für dich steuern. Terminalausgabe wird als nicht vertrauenswürdig behandelt, weil ein Agent-Transcript oder ein Repository feindlichen Text enthalten kann. Paneflow macht das Teilen von Kontext expliziter, verwandelt aber nicht jedes Terminal in eine offene Ausführungsfläche.

Genau diese Grenze interessiert mich: Agenten genug Kontext geben, damit sie nicht blind arbeiten, ohne ihnen stille Macht über die ganze Session zu geben.

Warum eine native App

Paneflow ist in Rust geschrieben und nutzt GPUI, das UI-Framework hinter Zed. Diese Wahl kommt aus einer einfachen Einschränkung: Agenten können lange laufen, manchmal parallel, und der Ort, der sie enthält, sollte leicht bleiben.

Ich wollte keine Electron-App um Terminals herum, die bereits schwere Prozesse ausführen. Ich wollte auch kein macOS-only-Werkzeug, wenn meine eigene Arbeit zwischen Linux und Windows wechselt. Heute liefert Paneflow Builds für Linux, macOS Apple Silicon und Windows x64. macOS Intel und Windows ARM64 werden noch nicht ausgeliefert.

Das Ergebnis ist keine IDE. Es ist ein lokaler, quelloffener Workspace für Entwickler, die ihre CLI-Agenten bereits beherrschen, aber nicht mehr alles von Hand koordinieren wollen.

Probiere Paneflow in deiner nächsten Multi-Agent-Session

Wenn du ab und zu einen einzelnen Agenten startest, reicht dein aktuelles Terminal wahrscheinlich aus.

Wenn du beginnst, mehrere Agenten parallel laufen zu lassen, ändert sich die Frage: Wie bleiben ihr Zustand lesbar, ihre Branches getrennt, ihre Diffs prüfbar und ihr Kontext teilbar, ohne die Kontrolle zu verlieren?

Genau dieses Problem soll Paneflow lösen.

Lade Paneflow herunter, öffne ein Projekt, starte zwei Agenten in zwei Panes und prüfe, ob der Workspace die mentale Last reduziert, die du schon als normal akzeptiert hattest.

Paneflow Conductor kommt mit Paneflow 0.6.0, um diese Koordination explizit zu machen. Ein Agent kann seine Peers finden, ihre Ausgabe lesen, den nächsten Prompt senden und über die öffentliche paneflow CLI warten, bis der Turn fertig ist.

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

Eine CLI für die ganze Flotte

Alles läuft über den lokalen Socket von Paneflow. Der Conductor kann Claude Code, Codex, OpenCode, Gemini oder ein Script sein, weil die Oberfläche nur aus Shell-Befehlen besteht.

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

Das ist die wichtige Verschiebung. Codex kann prüfen, was Claude Code erzeugt hat. Claude Code kann OpenCode eine Review-Aufgabe geben. Ein Script kann denselben Workflow starten, ohne sich darum zu kümmern, welches Harness in welchem Pane läuft.

Für wiederholbare Arbeit startet paneflow up einen gehookten Workspace aus einer TOML-Datei, und paneflow flow run führt eine Multi-Agent-Pipeline mit Spawn, Wait, Feed und Review aus.

Delegieren, ohne die Terminals zu verstecken

Paneflow Conductor ersetzt die Agenten nicht und macht Paneflow nicht zu einer gehosteten Runtime. Die Panes bleiben echte Terminals. Du kannst sie lesen, übernehmen, einen Befehl stoppen oder die Richtung ändern.

Der Wert liegt darin, dass Agenten keinen kopierten Kontext mehr brauchen. Ein Conductor-Agent kann ein benachbartes Pane lesen, den aktuellen Zustand verstehen, einen gezielten Follow-up senden und dann auf eine Sentinel-Zeile wie REPORT_DONE warten, bevor er weitermacht.

Dieses Muster zählt, wenn du Implementierung, Review, Tests und Dokumentation trennst. Der Leader-Agent muss nicht aus veralteten Notizen raten. Er inspiziert die echte Flotte.

Auf Zustand warten, nicht auf Timer

Paneflow 0.6.0 fügt für gehookte Agenten eine Turn-getrackte Zustandsmaschine hinzu. Ein Pane kann Zustände wie thinking, waiting_for_input und finished melden. paneflow watch streamt Lifecycle-Events als JSONL, und paneflow wait blockiert auf eine Bedingung statt auf eine beliebige Pause.

Das ist der Unterschied zwischen Orchestrierung und Screen Scraping. Ein Conductor sollte ein Terminal nicht alle paar Sekunden pollen und hoffen, dass die Ausgabe stabil ist. Er sollte reagieren, wenn der Agent wirklich stoppt, nach Eingabe fragt oder den vereinbarten Marker druckt.

Die Kontrollgrenze sichtbar halten

Das Sicherheitsmodell ist bewusst gesetzt. Die MCP-Bridge ist read-only. paneflow read behandelt Peer-Ausgabe als nicht vertrauenswürdige Daten. Standardmäßig füllt paneflow send nur einen Prompt vor, und ein Mensch drückt weiterhin Enter.

Auto-submit existiert, ist aber opt-in über das Scripting-Gate oder den AI-free-access-Modus. So bleibt der mächtige Pfad für isolierte Worktrees und vertrauenswürdige Workflows verfügbar, ohne stille Cross-Pane-Schreibzugriffe zum Standard zu machen.

Genau diese Grenze zählt: Agenten genug gemeinsamen Kontext geben, damit sie zusammenarbeiten, während die Terminals sichtbar bleiben und der Mensch jederzeit übernehmen kann.

Mit einer kleinen Flotte starten

Die vollständige Referenz steht in den Conductor-Dokumenten. Starte mit zwei Panes: ein Implementierungsagent, ein Review-Agent und ein Conductor, der beide liest, bevor er den nächsten Prompt sendet.

Wenn du bereits mehrere CLI-Agenten nebeneinander laufen lässt, gibt Paneflow Conductor ihnen eine gemeinsame Oberfläche statt eines weiteren privaten Protokolls.

Demo video: /videos/paneflow-diffview.mp4

Prüfe alle Änderungen deines Branches

Öffne die Diff-Ansicht über die Seitenleiste oder mit Ctrl+Shift+G. Paneflow zeigt alle Dateien, die seit der Abzweigung vom Basis-Branch geändert wurden, einschließlich nicht committeter Änderungen.

Du kannst durch die geänderten Hunks navigieren, Hinzufügungen und Entfernungen vergleichen und zwischen einer vereinheitlichten Ansicht und einer Nebeneinanderansicht wechseln. Die Datei-Header bleiben beim Scrollen sichtbar, und die Syntaxhervorhebung verwendet Tree-sitter, denselben Parser, den Zed und GitHub verwenden.

Vergleiche mehrere Branches ohne Worktree-Wechsel

Die Projektansicht zeigt das Diff der aktuellen Aufgabe. Die Multi-Projekt-Ansicht bündelt die geöffneten Repositories in Tabs. Die Worktree-Ansicht stellt benachbarte Branches nebeneinander, ein git worktree pro Branch, um ihren Fortschritt zu vergleichen, ohne sie einzeln auszuchecken.

Lass mehrere Agenten prüfen

Jeder Branch besitzt einen Review-Button. Wähle Claude Code, Codex, OpenCode oder Pi, und Paneflow öffnet jeden Agenten in einem echten Terminal, direkt unter dem Diff und im richtigen Verzeichnis.

Paneflow bereitet den Review-Prompt vor, schickt ihn aber nie ohne deine Bestätigung ab. Du kannst ihn prüfen, bevor du Enter drückst. Der Agent analysiert dann das Diff und gibt Anmerkungen zu den betroffenen Dateien und Zeilen zurück.

Starte zwei Agenten, um zwei verschiedene Lesarten derselben Änderung zu erhalten. Der zweite bekommt eine kritischere Instruktion, um zu ähnliche Antworten zu reduzieren.

Du kannst auch eine einzelne Zeile oder einen einzelnen Hunk an einen Agenten schicken, um eine gezielte Frage zu stellen.

Lass deinen nächsten Branch in Paneflow prüfen

Die Diff-Ansicht und die Agenten-Review sind ab Paneflow 0.3.7 verfügbar, eine Version nach Agent-Sessions. Lade die neueste Version herunter, öffne ein Projekt und wähle Diff in der Seitenleiste.

Demo video: /videos/sessions-agents.mp4

Finde die Sessions des richtigen Projekts

Paneflow erkennt die Claude Code-, Codex- und OpenCode-Sessions, die zum aktiven Arbeitsverzeichnis gehören. Sie sind nach Agent gruppiert, ohne die Gespräche deiner anderen Projekte zu vermischen.

Wähle eine Session aus, und Paneflow nimmt sie im aktuellen Pane wieder auf, mit intaktem Verlauf.

Kehre zu einer Aufgabe zurück, ohne von vorne anzufangen

Eine Session enthält die Austausche, die Entscheidungen und den Plan, den du mit dem Agenten bereits erarbeitet hast. Sie verlassen und wieder aufnehmen zu können ermöglicht es dir, zwischen Aufgaben zu wechseln, ohne diesen Kontext zu verlieren oder dieselben Erklärungen zu wiederholen.

Du kannst ein Pane schließen, Paneflow neu starten oder später zum Projekt zurückkehren. Die nützlichen Sessions sind verfügbar, wenn du sie brauchst.

Nimm deine nächste Session in Paneflow wieder auf

Agent-Sessions sind ab Paneflow 0.3.6 verfügbar, derselben Version wie die Files-Seitenleiste. Lade die neueste Version herunter, starte einen Agenten in einem Projekt und finde seine Session dann in Paneflow.

Demo video: /videos/paneflow-dock.mp4

Durchsuche das aktuelle Projekt

Öffne die Seitenleiste über den Files-Button, um die Ordner und Dateien des Projekts anzuzeigen. Der Baum folgt automatisch dem aktiven Workspace und aktualisiert sich, wenn sich Dateien auf der Platte ändern.

Von .gitignore ausgeschlossene Elemente bleiben sichtbar, werden aber abgedunkelt, damit die nützlichen Dateien hervortreten. Paneflow merkt sich außerdem die geöffneten Ordner über Neustarts hinweg.

Lies Markdown in einem Pane

Klicke auf eine README, ein PRD oder eine andere Markdown-Datei, um sie gerendert in einem Pane zu öffnen. So kannst du die Anweisungen, den Plan und den Agenten, der sie nutzt, in derselben Anordnung behalten.

Die restlichen Dateien werden angezeigt, damit du die Struktur des Projekts schnell erfassen kannst, ohne Paneflow in einen vollständigen Dateimanager zu verwandeln.

Halte die Dokumentation nah bei deinen Agenten

Die Files-Seitenleiste ist ab Paneflow 0.3.6 verfügbar, derselben Version wie Agent-Sessions. Lade die neueste Version herunter, öffne ein Projekt und nutze den Files-Button, um dessen Inhalt zu durchsuchen.

Paneflow geht von diesem Problem aus: Mehrere Agenten brauchen einen Workspace, der dafür gebaut ist, sie nachvollziehbar zu halten.

Eine Aufgabe ist mehr als ein Terminal

Eine Aufgabe kann einen Agenten, einen Git-Branch, einen Dev-Server, Tests, ein Diff und mehrere Sessions vereinen. Wenn diese Elemente verstreut sind, musst du ihren Kontext jedes Mal neu aufbauen, wenn du das Fenster wechselst.

Paneflow bündelt sie in einem einzigen Workspace und stellt diese Umgebung wieder her, wenn du zurückkommst. Du findest nicht nur ein offenes Terminal vor. Du findest die Aufgabe so, wie du sie verlassen hast.

Agenten können sich helfen, ohne die Kontrolle zu übernehmen

Der MCP-Server von Paneflow stellt drei schreibgeschützte Tools bereit, list_panes, read_pane und search_pane, damit ein Agent die Ausgabe eines anderen Panes lesen kann. Er kann einen Test prüfen, nach einem Fehler suchen oder die Arbeit eines anderen Agenten einsehen, ohne dass du seinen Inhalt kopieren und einfügen musst.

Diese Brücke bleibt bewusst schreibgeschützt. Agenten können Kontext teilen, aber sie können keine Befehle füreinander eingeben. Du behältst die Kontrolle über Entscheidungen und Aktionen.

Ein lokales Werkzeug, das du verstehen kannst

Paneflow läuft lokal, ohne Konto und ohne Telemetrie. Sein Code ist unter der GPL-3.0-or-later-Lizenz verfügbar.

Diese Entscheidung ist einfach: Der Workspace, der deine Agenten ausführt und den Kontext deiner Arbeit enthält, muss schnell, transparent und unter deiner Kontrolle bleiben.

Probiere diesen Ansatz bei deinem nächsten Projekt aus

Lade Paneflow herunter und bringe die Agenten, Terminals und Werkzeuge deiner nächsten Aufgabe in einem einzigen Workspace zusammen.

Paneflow bündelt deine Coding-Agenten, ihre Terminals und alles, was dazugehört, in einem einzigen local-first-Workspace.

Ein Workspace pro Aufgabe

Starte Claude Code, Codex, OpenCode und 13 weitere Agenten-CLIs in nebeneinander angeordneten Panes. Füge Tests, Dev-Server oder Befehle hinzu, die die Aufgabe braucht, und verknüpfe diesen Workspace mit seinem Git-Branch.

Jeder Workspace behält seine Anordnung, seine Terminals und seine Sessions. Du kannst zwischen Aufgaben wechseln oder Paneflow neu starten, ohne deine Umgebung neu aufzubauen.

Der Kontext bleibt sichtbar

• Agenten und Terminals: sieh alles, was läuft, und wechsle per Tastatur zwischen den Panes.
• Branches und Diffs: halte jede Aufgabe mit ihrem Branch verknüpft und prüfe ihre Änderungen, ohne Paneflow zu verlassen.
• Agent-Sessions: finde und nimm Claude-Code-, Codex- und OpenCode-Sessions wieder auf für das aktuelle Projekt.
• Kontext zwischen Panes: dank des integrierten MCP-Servers kann ein Agent die Ausgabe eines Tests lesen oder in einem anderen Pane nach einem Fehler suchen, ohne Copy-Paste.
• Lokale Umgebung: kein Konto, keine Telemetrie und kein aufgezwungener Remotedienst.

Eine native Anwendung, die Bestand hat

Paneflow ist in Rust geschrieben und verwendet GPUI, die Render-Engine von Zed. Panes und Terminals werden direkt von der Anwendung gerendert, ohne eingebetteten Browser um Prozesse, die stundenlang laufen können. Die gesamte Anwendung ist 14 bis 19 MB groß.

Das Projekt ist Open Source unter der GPL-3.0-or-later-Lizenz und läuft auf Linux, macOS und Windows.

Starte deinen nächsten Agenten in Paneflow

Lade Paneflow herunter, öffne ein Projekt und erstelle einen Workspace für die Aufgabe, an der du weiterarbeiten möchtest.