Paneflow 0.8.1: Windows でも libghostty-vt が Alacritty を置き換え
Paneflow 0.8.1 では、ネイティブ Windows ビルドに libghostty-vt が導入されました。公式 x64 MSI では、terminal.backend を省略するか auto のままにすると、新しいターミナルセッションで Ghostty が選択されます。
これは Paneflow 0.8.0 で Linux 向けにリリースしたターミナルエンジン移行の続きです。Paneflow は Linux x86_64、Linux ARM64、Windows x64 MSVC で、同じ Ghostty VT コアをデフォルトで使用するようになりました。Alacritty は明示的な復旧用バックエンドとして各プラットフォームに残り、macOS と非対応ターゲットでは引き続きデフォルトです。
Ghostty エンジンが ConPTY 上で動作
Paneflow は VT エンジン層で Ghostty を統合しています。libghostty-vt はターミナルシーケンスを解析し、グリッドとカーソル状態を維持し、書記素、折り返し、リフローを処理して、キーボードとマウス入力をエンコードします。ウィンドウ、ペイン、セッション、プロセスのライフサイクル、永続化、GPUI レンダリングは引き続き Paneflow が管理します。
Windows への移植では、このエンジンを動かすネイティブホストを追加しました。Paneflow は Windows で ConPTY を使用する portable-pty を通じて擬似ターミナルを開き、その UTF-8 出力を libghostty-vt に渡します。Ghostty の状態は GPUI が描画する前に、所有権を持つ Rust スナップショットへコピーされます。Ghostty アプリケーション、その UI、レンダラーは Paneflow に組み込まれていません。
Windows では、この境界の分離が重要です。ConPTY はシェルとの接続と OS のプロセス契約を担い、Ghostty はターミナルを解釈します。製品とピクセルは Paneflow が管理します。そのため、同じバックエンド中立なレンダラーで、Windows 専用の描画経路を増やさずに Alacritty と Ghostty のセッションを表示できます。
必要だったのはライブラリだけでなく Windows のライフサイクル
Windows で静的ライブラリをコンパイルできるだけでは、実用的なターミナルにはなりません。PowerShell、コマンドプロンプト、TUI、コーディングエージェントを動かすには、起動、リサイズ、出力のドレイン、終了、子孫プロセスのクリーンアップを決定的に扱う必要があります。
Windows の Ghostty ホストは ConPTY のリサイズをまとめ、セッションを閉じる前に最終出力を読み切り、終了前にリーダーの完了を待ち、複数ペインが同時に出力してもバックプレッシャーを制限します。Paneflow 0.8.1 では、不要な描画処理を避けるため Windows の Ghostty 再描画もまとめています。
入力も同じ境界を通ります。この統合は Ghostty のキーボードエンコード、AltGr、デッドキー、IME 確定、ペースト、クリップボード、マウス、フォーカス、リンクを扱います。0.8.1 の最後の 2 つの修正では、ConPTY を通る複数行の Shift+Enter 入力を保持しました。改行の挿入にこのショートカットを使うコーディングエージェントのプロンプトも対象です。
ピン留めした静的 MSVC アーティファクトを同梱
公式 Windows x64 ビルドには、ピン留めされた ghostty-vt-static.lib アーカイブが含まれます。ソースコミット、Zig ツールチェーン、ヘッダー、生成済み Rust バインディング、シンボル、ビルドメタデータ、ライセンス、チェックサムをリポジトリで追跡しています。
Ghostty、Zig、DLL、追加のランタイムをユーザーがインストールする必要はありません。標準 MSI は Paneflow のビルド時に検証済みアーカイブを使用し、最終実行ファイルへエンジンを静的リンクします。ネイティブの再ビルドとアーカイブを利用する Windows ビルドを分離し、CI がリリース前にソース、ABI、アーティファクトのずれを検出できるようにしています。
Paneflow は生の C ABI を -sys crate 内に閉じ込め、その上に安全な Rust の所有権を提供します。ネイティブハンドルは対応する Ghostty アロケーターで解放され、コールバックの panic は FFI 境界の内側に留まり、借用した Ghostty の行やセルがターミナルのロック期間やフレーム境界を越えることはありません。
Ghostty を自動選択し、Alacritty へすぐ戻せる
Windows の terminal.backend は auto、ghostty、alacritty の 3 つの値を受け付けます。Paneflow 0.8.1 の公式 x64 ビルドでは、auto と ghostty の両方が Ghostty エンジンを選択します。新しく作成するセッションで以前のバックエンドを強制するには、paneflow.json に alacritty を設定します。
{
"terminal": {
"backend": "alacritty"
}
}この設定は新しいセッションだけに適用されます。シェルプロセスが存在する前に Ghostty が失敗した場合、Paneflow は 1 回だけ Alacritty にフォールバックできます。プロセス起動後にセッションがバックエンドを切り替えたり、裏側で 2 つ目のシェルを起動したりすることはありません。
この復旧経路により、ターミナルの障害は局所的で元に戻せます。Paneflow の再インストールやワークスペースデータの変更なしで Alacritty に戻し、原因が分かったら auto に戻せます。
Linux と Windows で共通のターミナルコア
Paneflow 0.8.0 は Linux でエンジン境界を確立しました。0.8.1 では、プラットフォーム固有の詳細をレンダラーやワークスペースモデルへ持ち込まずに、大きく異なる PTY とプロセスモデルをこの境界が越えられることを示しています。
Windows ARM64 は今回のリリース対象外で、引き続き Alacritty を使用します。macOS も Ghostty 対応を別途評価している間は Alacritty のままです。対応する Linux と Windows のビルドでは、auto の意味が共通になりました。ターミナルコアに Ghostty、描画に GPUI、その周囲のマルチエージェントワークスペースに Paneflow を使います。
Paneflow 0.8.1 をインストールして新しいペインを開き、普段使っている PowerShell、WSL シェル、TUI、コーディングエージェントを実行してください。ターミナルの挙動に問題が出た場合は、新しいセッションの terminal.backend を alacritty に設定し、シェル、Windows バージョン、コマンド、最短の再現手順を報告してください。