これは 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 バージョン、コマンド、最短の再現手順を報告してください。

この移行で変わるのは、VT データを解釈してターミナル状態を管理するエンジンです。周囲のワークスペースは変わりません。PTY、プロセスのライフサイクル、GPUI レンダラー、ペイン、セッション、エージェントの状態、diff、永続化は引き続き Paneflow が管理します。macOS と Windows は Alacritty のままです。

Ghostty が VT エンジンとして Paneflow に加わる

Paneflow 0.7.x までのターミナルセッションは、Rust crate の alacritty_terminal 0.26 を基盤としていました。このエンジンがエスケープシーケンス、グリッド、スクロールバック、入力モード、検索、レンダリングモデルの一部を担っていました。

新しい Linux パスは、Ghostty の組み込み可能なターミナルエンジンである libghostty-vt を使用します。VT シーケンスを解析し、カーソルと画面の状態、書記素、折り返し、リフローを管理します。さらにキーボードとマウスの入力をエンコードし、ホストアプリケーションへ差分レンダリング状態を公開します。

Paneflow は Ghostty アプリ本体、GTK UI、レンダラーを組み込んでいません。Ghostty がターミナルのコアを提供し、Paneflow がその状態を所有権のある Rust スナップショットへ変換して、既存の GPUI レンダラーで描画します。製品 UI とマルチエージェントのワークフローは Paneflow の管理下に残ります。

Paneflow 固有の境界でエンジンと製品を分離

パーサーの置き換えは作業の一部にすぎませんでした。Alacritty の型は PTY ループ、レンダリング、検索、選択、リンク、スクロールバックの復元、セッションのライフサイクルまで入り込んでいました。先にこの結合を外さず依存関係だけを交換すると、同じ問題を新しいエンジンへ移すことになります。

Paneflow は独自のターミナルセッション境界を持つようになりました。Alacritty と Ghostty は、同じ Paneflow のコマンド、イベント、モード、検索結果、レンダリングスナップショットを生成します。レンダラーは、どちらのエンジンがセルを作成したか知る必要がありません。

この境界が移行の長期的な成果です。macOS と Windows を変更せず Linux から先に移行でき、将来エンジンを更新してもアプリケーション全体が内部型を採用する必要はありません。

不安定な C API を小さな Rust ラッパーに閉じ込める

Ghostty は libghostty-vt の機能を成熟したものと説明する一方で、API シグネチャはまだ変更中としています。そのため Paneflow は、Ghostty の正確なコミット ae52f97d、C ヘッダー、生成済み bindings、Zig のバージョン、ビルド構成、アーカイブのチェックサムを固定しています。

生の C ABI は 1 つの -sys crate に隔離されています。もう 1 つの安全なラッパーが各ネイティブハンドルを所有し、ターミナル作成前に API バージョンと C レイアウトを検証します。コールバックの panic を封じ込め、Ghostty の割り当ては対応するアロケーターで解放します。

所有権のルールはレンダリング時に特に重要です。libghostty-vt が公開する行とセルは借用データであり、その後のターミナル変更で無効になる可能性があります。Paneflow はターミナルをロックしている間に必要なデータをコピーし、所有権のある Rust スナップショットだけを GPUI に渡します。C ポインターや借用 slice がロックやフレームの境界を越えることはありません。

この方式は、固定しない依存関係を追うより保守コストがかかります。Ghostty を更新するたびに、2 つの Linux アーキテクチャ向けにヘッダー、bindings、静的アーカイブ、チェックサム、シンボル、ライセンスを再生成してレビューする必要があります。ランタイムの不確実性を受け入れず、コストを明示して狭い範囲に閉じ込める選択です。

Alacritty は差分検証の基準とロールバックとして残る

ユーザーから見た目標は継続性です。シェル、コーディングエージェント、フルスクリーン TUI、検索、選択、クリップボード、スクロールバック、OSC イベント、リサイズ、リフロー、プロセス終了は、エンジン変更前と同じように動作する必要があります。

Paneflow は同じ決定的な VT ストリームを複数のチャンクサイズで Alacritty と Ghostty に入力し、正規化したスナップショットと順序付きイベントを比較します。別の fuzzing ターゲットでは、不正または途中で切れたシーケンス、入力エンコード、リサイズ、リフロー、複数の PTY read に分割されたシーケンス境界を検査します。パッケージ検証は、ランタイムで libghostty.so に依存する、不正なビルド ID を持つ、またはレビュー済みのネイティブ通知を含まない Linux アーティファクトを拒否します。

Alacritty は削除されていません。新しく作成する Linux セッションで使用するには、paneflow.json の backend を設定します。

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

実行中のセッションがメモリ上でエンジンを切り替えることはありません。設定を変更した後、そのセッションを閉じて新しいペインを開いてください。auto は標準 Linux ビルドで Ghostty を選択し、macOS、Windows、または --no-default-features でコンパイルした Linux ビルドでは Alacritty を選択します。

Ghostty のインストールを必要としない静的リンク

公式 Linux パッケージには、x86_64 または ARM64 向けに固定された静的 libghostty-vt アーカイブが含まれます。マシンに Ghostty、Zig、共有ライブラリをインストールする必要はありません。クリーンな Paneflow checkout で通常の cargo build を実行した場合も、リポジトリに含まれる検証済みアーカイブを使用し、build.rs からネイティブソースをダウンロードしません。

この backend は Linux から導入します。Windows や macOS への拡張と、将来 Alacritty を削除するかどうかは別の判断です。Paneflow 0.8.0 は影響範囲を限定しています。新しいデフォルトは 1 つ、サポートするエンジンは 2 つ、新規セッションはすぐにロールバックできます。

Paneflow 0.8.0 に更新し、新しいペインを開いて、普段使っているシェル、TUI、コーディングエージェントを実行してください。ターミナルの動作にリグレッションがあれば、新しいセッションを Alacritty に戻し、コマンド、Linux ディストリビューション、Wayland と X11 のどちらで動かしていたかを報告してください。

問題は、それを複数起動したときに始まります。

あるエージェントはバグを直しています。別のエージェントはリファクタリングを準備しています。さらに別のエージェントはdiffをレビューしています。その横で開発サーバーが動き、テストが通ったり落ちたりし、それぞれのターミナルが違う部分の状況を伝えています。ある時点で難しいのは、エージェントを起動することではなくなります。どのエージェントが何をしているのか、どれが入力待ちなのか、どれが完了したのか、どのブランチで作業しているのかを把握することです。

Paneflowは、まさにこの問題から生まれました。複数のコードエージェントを、1つのローカルワークスペースの中で見える、操作できる、理解できる状態に保つためのものです。

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

完全なデモはYouTubeでも見られます。

ローンチスレッドはHacker Newsにあります: Show HN: Paneflow。

ターミナルだけでは足りないことがある

私はターミナルが好きです。tmux、Zellij、Ghostty、Kitty、WezTermはどれも優れたツールです。SSH越しやリモートマシンで作業するときは特にそうです。

ただし、同じプロジェクトで複数のローカルエージェントを動かすと、問題は変わります。ターミナルのグリッドはプロセスを表示します。しかし、どのエージェントが考えているのか、どれが承認待ちなのか、どれが面白いdiffを出したのか、どれが別のエージェントの作業をやり直しているのかまでは教えてくれません。

ウィンドウが増えるほど、プロジェクトの状態を頭の中で再構築することになります。ターミナルを移動し、スクロールバックを読み直し、正しいディレクトリを探し、現在のブランチを確認し、またdiffに戻ります。一度なら大きな問題ではありません。主な働き方になると、負担になります。

Paneflowはエディタを置き換えようとしているわけではありません。多くの開発者がsplit、ウィンドウ名、ブランチの命名規則、短期記憶で手作りしている調整レイヤーを置き換えます。

コマンドごとのペインではなく、タスクごとのワークスペース

Paneflowでは、ペインは今でも本物のターミナルです。Claude Code、Codex、OpenCode、Grok Builder、またはシェルで動く任意のCLIを実行できます。

違うのは、ターミナルの周りにあるものです。

1つのタスクには、エージェント、テスト、開発サーバー、gitブランチ、diff、過去のセッションが含まれることがあります。Paneflowはそれらを同じワークスペースにまとめ、コンテキストを切り替えるたびに探し直さなくてよいようにします。

作業を分離したいときは、各タスクを専用のgit worktreeで動かせます。Reviewビューはそのdiffを横並びに表示し、1つのworktreeを1列として扱います。ウィンドウ、ブランチ、エディタを切り替えずに、各エージェントが何を作ったのか確認できます。

この構成は、2つのエージェントがコードベースの近い場所を触っているときに特に役立ちます。出力を開いたままにし、変更を比較し、何を残し、何を直し、何を捨てるかを判断できます。

調整はCLIインターフェースを通る

Paneflowで最も重要な賭けは表示ではありません。調整です。

このレイヤーをPaneflow Conductorと呼んでいます。現時点では、エージェントに公開するものは意図的にCLIインターフェースとローカルソケットを通します。GUIは、あなたが監視し、読み、任意のペインを引き継ぐ場所として残ります。

paneflow psは、実行中のペインとエージェントを実際の状態とともに一覧表示します。paneflow watchは、ターミナルを繰り返しポーリングするのではなく、hooksとevent busから送られる変更をJSONLとしてストリームします。エージェントは何が動いているかを見て、イベントを待ち、別のペイン向けのpromptを準備し、最後の送信はあなたの承認に任せることができます。

デフォルトでは、Paneflowはpromptを事前入力し、Enterを押すのはあなたです。Auto-submitはありますが、opt-inです。この選択は意図的です。同じプロジェクト内で複数のエージェントが動けるなら、人間のコントロールは見える場所に残るべきです。

エージェントは制御せずに読める

もう1つ重要なのが、組み込みのMCPサーバーです。list_panes、read_pane、search_paneという3つの読み取り専用ツールを公開します。

実際には、あるペインのClaude Codeが、別のペインでCodexが出したテスト出力を読むことができます。エージェントは修正案を出す前に、隣のターミナルでエラーを検索できます。あるツールの出力を別のツールにコピー&ペーストする必要が減ります。

境界は厳格です。このブリッジはペインに書き込めず、あなたの代わりにエージェントを操作することもできません。ターミナル出力は信頼できないものとして扱われます。エージェントのtranscriptやリポジトリには、敵対的なテキストが含まれる可能性があるからです。Paneflowはコンテキスト共有をより明示的にしますが、すべてのターミナルを開いた実行面に変えるわけではありません。

私が重視しているのはこの境界です。エージェントが盲目的に作業しないだけのコンテキストを与えつつ、セッション全体を静かに支配する力は与えない。

なぜネイティブアプリなのか

PaneflowはRustで書かれ、Zedの背後にあるUIフレームワークであるGPUIを使っています。この選択は単純な制約から来ています。エージェントは長時間、時には並列で動きます。それらを入れる場所は軽く保つ必要があります。

すでに重いプロセスを実行しているターミナルを、さらにElectronアプリで包みたくありませんでした。また、自分の作業がLinuxとWindowsをまたぐのに、macOS専用のツールにもしたくありませんでした。現在、PaneflowはLinux、macOS Apple Silicon、Windows x64向けのbuildを提供しています。macOS IntelとWindows ARM64はまだ出荷していません。

結果としてできたのはIDEではありません。CLIエージェントをすでに使いこなしている開発者が、すべての調整を手作業で行わなくて済むようにする、ローカルでオープンソースのワークスペースです。

次のマルチエージェント作業でPaneflowを試す

たまに1つのエージェントを起動するだけなら、今のターミナルで十分かもしれません。

複数のエージェントを並列で動かし始めると、問いは変わります。状態を読みやすく保ち、ブランチを分け、diffをレビューでき、コンテキストを共有できるようにしながら、どうやって制御を失わずにいるのか。

Paneflowが解こうとしているのは、まさにその問題です。

Paneflowをダウンロードし、プロジェクトを開き、2つのペインで2つのエージェントを起動してみてください。そのワークスペースが、当たり前だと思い始めていた認知負荷を減らすかどうかを見てください。

Paneflow 0.6.0で入ったPaneflow Conductorは、この調整を明示的にします。1つのエージェントが公開CLIのpaneflowを通じて、他のエージェントを見つけ、出力を読み、次のpromptを送り、turnの完了を待てます。

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

フリート全体を1つのCLIで扱う

すべてはPaneflowのローカルソケットを通ります。ConductorはClaude Code、Codex、OpenCode、Gemini、またはscriptになれます。インターフェースがただのshell commandだからです。

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

重要なのはここです。CodexはClaude Codeが作った結果を確認できます。Claude CodeはOpenCodeにレビュータスクを渡せます。scriptは各ペインでどのharnessが動いているかを気にせず、同じworkflowを開始できます。

繰り返し使う作業では、paneflow upがTOMLファイルからhook済みのワークスペースを起動し、paneflow flow runがspawn、wait、feed、reviewを含むマルチエージェントpipelineを実行します。

ターミナルを隠さずに委任する

Paneflow Conductorはエージェントを置き換えません。Paneflowをhosted runtimeに変えるものでもありません。ペインは本物のターミナルのままです。読めます。引き継げます。コマンドを止められます。方針も変えられます。

価値は、エージェントがコピー&ペーストされたcontextに頼らなくてよくなることです。Conductorエージェントは隣のペインを読み、現在の状態を理解し、絞ったfollow-upを送り、REPORT_DONEのようなsentinelを待ってから続行できます。

実装、レビュー、テスト、ドキュメントを分けるとき、このpatternが効きます。leaderエージェントは古いメモから推測する必要がありません。実際のフリートを見に行けます。

タイマーではなく状態を待つ

Paneflow 0.6.0は、hook済みエージェント向けにturn単位で追跡される状態マシンを追加します。ペインはthinking、waiting_for_input、finishedのような状態を返せます。paneflow watchはlifecycle eventをJSONLとしてstreamし、paneflow waitは任意のsleepではなく条件でblockします。

これはオーケストレーションとscreen scrapingの違いです。Conductorは数秒ごとにターミナルをpollして、出力が落ち着いたことを期待すべきではありません。エージェントが本当に止まったとき、入力を求めたとき、約束したmarkerを出したときに反応すべきです。

制御の境界を見える場所に置く

安全性のモデルは意図的です。MCP bridgeはread-onlyです。paneflow readはpeerの出力を信頼できないデータとして扱います。デフォルトでは、paneflow sendはpromptを事前入力するだけで、人間がEnterを押します。

Auto-submitはありますが、scripting gateまたはAI free access modeで明示的に有効化する必要があります。隔離したworktreeや信頼できるworkflowでは強い経路を使える一方で、無音のcross-pane writeはデフォルトになりません。

この境界が本質です。エージェントには協調に必要な共有contextを渡す。ただしターミナルは見えるままにし、人間がいつでも引き継げるようにする。

小さなフリートから始める

完全なリファレンスはConductor docsにあります。まずは2つのペインから始めてください。実装エージェント、レビューエージェント、そして次のpromptを送る前に両方を読むconductorです。

すでに複数のCLIエージェントを横に並べて動かしているなら、Paneflow Conductorは別のprivate protocolではなく、共通の操作面を渡します。

Demo video: /videos/paneflow-diffview.mp4

ブランチのすべての変更をレビューする

サイドバーから、あるいは Ctrl+Shift+G で Diff ビューを開きます。Paneflow は、ベースブランチから分岐して以降に変更されたすべてのファイルを、まだコミットしていない変更も含めて表示します。

変更されたハンクをたどり、追加と削除を見比べ、統一表示と左右並列表示を切り替えられます。スクロール中もヘッダーは固定され、シンタックスハイライトは Tree-sitter で動きます。Zed と GitHub が使っているのと同じパーサーです。

worktree を切り替えずに複数のブランチを比較する

プロジェクトビューは、現在のタスクの差分を表示します。Multi-project ビューは、開いているリポジトリをタブにまとめます。Worktree ビューは、隣り合うブランチを左右に並べ、ブランチごとに git worktree を一つ割り当てて、ひとつずつチェックアウトせずに進み具合を比較できるようにします。

複数のエージェントにレビューを依頼する

各ブランチには Review ボタンがあります。Claude Code、Codex、OpenCode、Pi から選ぶと、Paneflow は各エージェントを本物のターミナルで、差分のすぐ下に、正しいディレクトリで開きます。

Paneflow はレビュー用のプロンプトを用意しますが、あなたの了承なく送信することは決してありません。Enter を押す前に内容を確認できます。エージェントはそのあと差分を解析し、対象のファイルと行に紐づいた指摘を返します。

二つのエージェントを起動すれば、同じ変更について二通りの読みが得られます。二つめには、似たような回答が重ならないよう、より批判的な指示が渡されます。

特定の一行やハンクをエージェントに送り、的を絞った質問をすることもできます。

次のブランチを Paneflow でレビューさせる

Diff ビューとエージェントによるレビューは Paneflow 0.3.7 から利用できます。エージェントのセッションの次のリリースです。最新版をダウンロードし、プロジェクトを開いて、サイドバーから Diff を選んでください。

Demo video: /videos/sessions-agents.mp4

正しいプロジェクトのセッションを見つける

Paneflow は、アクティブな作業ディレクトリに紐づく Claude Code、Codex、OpenCode のセッションを検出します。それらはエージェントごとにまとめられ、ほかのプロジェクトの対話と混ざることはありません。

セッションを選べば、Paneflow は履歴をそのままに、現在のペインの中でそれを再開します。

ゼロからやり直さずにタスクへ戻る

セッションには、エージェントとすでにやり取りした会話、決定、組み立てた計画が含まれています。一度離れてからまた再開できるということは、その文脈を失わず、同じ説明を繰り返すこともなく、タスクからタスクへ移れるということです。

ペインを閉じても、Paneflow を再起動しても、後日そのプロジェクトに戻ってきても構いません。役に立つセッションは、必要になったときにそこで待っています。

次のセッションを Paneflow で再開する

エージェントのセッションは Paneflow 0.3.6 から利用できます。Files サイドバーと同じリリースです。最新版をダウンロードし、プロジェクトの中でエージェントを起動して、そのセッションを Paneflow から見つけてください。

Demo video: /videos/paneflow-dock.mp4

現在のプロジェクトを見渡す

Files ボタンからサイドバーを開くと、プロジェクトのフォルダーとファイルが表示されます。ツリーはアクティブなワークスペースに自動で追従し、ディスク上でファイルが変われば更新されます。

.gitignore で無視される項目も表示されますが、控えめに描かれ、役に立つファイルが際立ちます。Paneflow は、再起動をまたいでどのフォルダーを開いたままにしたかも覚えています。

Markdown をペインで読む

README や PRD、ほかの Markdown ファイルをクリックすると、レンダリングされた状態でペインに開きます。これにより、指示や計画と、それを使うエージェントを同じレイアウトの中に保てます。

ほかのファイルは、プロジェクトの構造をすばやく把握できるように表示されますが、Paneflow を本格的なファイルマネージャーに変えることはありません。

ドキュメントをエージェントのそばに置いておく

Files サイドバーは Paneflow 0.3.6 から利用できます。エージェントのセッションと同じリリースです。最新版をダウンロードし、プロジェクトを開いて、Files ボタンから中身を見渡してください。

Paneflow はこの問題から出発します。複数のエージェントには、それらを理解できる状態に保つために設計されたワークスペースが必要だ、という考え方です。

タスクはターミナル一つには収まらない

一つのタスクは、エージェント、git ブランチ、開発サーバー、テスト、差分、そして複数のセッションをまとめて抱えることがあります。これらが散らばっていると、ウィンドウを切り替えるたびにその文脈を組み直さなければなりません。

Paneflow はそれらを一つのワークスペースにまとめ、戻ってきたときにその環境を復元します。開きっぱなしのターミナルが見つかるだけではありません。離れたときのままのタスクが見つかるのです。

エージェントは主導権を握らずに助け合える

Paneflow の MCP サーバーは、list_panes、read_pane、search_pane という三つの読み取り専用ツールを公開しており、あるエージェントが別のペインの出力を読めるようになっています。テストを確かめたり、エラーを検索したり、別のエージェントの作業を参照したりできます。あなたがその内容をコピー&ペーストする必要はありません。

このブリッジは、意図して読み取り専用にしてあります。エージェントは文脈を共有できても、互いの環境にコマンドを打ち込むことはできません。決定と操作の主導権は、あなたが握り続けます。

あなたが理解できるローカルなツール

Paneflow はローカルで動き、アカウントもテレメトリもありません。そのコードは GPL-3.0-or-later ライセンスで公開されています。

この選択は単純です。あなたのエージェントを動かし、作業の文脈を抱える場所は、速く、透明で、あなたの管理下にあり続けるべきだからです。

次のプロジェクトでこの考え方を試す

Paneflow をダウンロードし、次のタスクのエージェント、ターミナル、ツールを一つのワークスペースにまとめてください。

Paneflow は、コーディングエージェントと、そのターミナル、そして周辺のすべてを、一つの local-first なワークスペースにまとめます。

タスクごとに一つのワークスペース

Claude Code、Codex、OpenCode、そしてほかの 13 のエージェント CLI を、横並びのペインで動かせます。テスト、開発サーバー、タスクに必要なコマンドを加え、そのワークスペースを git ブランチに紐づけます。

各ワークスペースは、レイアウト、ターミナル、セッションを保持します。環境を組み直さずに、タスクからタスクへ移ることも、Paneflow を再起動することもできます。

文脈が見えたままになる

• エージェントとターミナル： 動いているものをすべて見渡し、キーボードでペインからペインへ移れます。
• ブランチと差分： 各タスクをそのブランチに紐づけたまま、Paneflow を離れずに変更をレビューできます。
• エージェントのセッション： 現在のプロジェクトの Claude Code、Codex、OpenCode のセッションを見つけて再開できます。
• ペイン間の文脈： 組み込みの MCP サーバーにより、エージェントは別のペインのテスト出力を読んだり、エラーを検索したりできます。コピー&ペーストは不要です。
• ローカルな環境： アカウントも、テレメトリも、押しつけられるリモートサービスもありません。

長く使うために作られたネイティブアプリ

Paneflow は Rust で書かれ、Zed のレンダラーである GPUI を使っています。ペインとターミナルはアプリ自身が直接描画し、何時間も動き続けるプロセスのまわりに組み込みブラウザを抱えることはありません。アプリ全体のダウンロードサイズは 14〜19 MB です。

このプロジェクトは GPL-3.0-or-later ライセンスのオープンソースで、Linux、macOS、Windows で動作します。

次のエージェントを Paneflow で起動する

Paneflow をダウンロードし、プロジェクトを開いて、進めたいタスクのためのワークスペースを作ってください。