GridBash：複数の coding agent を一つの terminal grid に置く
multi-agent workflow が崩れやすいのは、「terminal をいくつ開けるか」ではない。開いた後に、どの pane が何をしているのか、どの pane が安全に続きの変更をできるのか、どの output を別の agent に渡してよいのか、という管理が急に難しくなる。普通の terminal multiplexer は window を分割できるが、Codex、Claude、Gemini のような CLI agent の launch、auth、project directory、workspace isolation、resume までは理解しない。
今日紹介する jasonsuhari/gridbash は、この問題に絞った小さな tool だ。実 PTY pane で複数の CLI coding agents を並べて動かす local terminal grid で、tmux を置き換えるというより、agent workspace のよくある操作を専用入口にする。profile を選び、project を割り当て、2x3 以上の pane を起動し、必要なら各 pane に独立した git worktree を作り、session を保存して後から戻れる。
2026-07-20 時点で GitHub repository page、README、releases/tags page、public git history、LICENSE、Cargo.toml、package.json、そして scout が返した GitHub search field から確認できる公開情報では、jasonsuhari/gridbash は 137 stars、5 forks。GitHub の primary language は Rust、license は MIT。GitHub embedded data の repository creation time は 2026-07-05 22:46:52 UTC。public git history の最初の commit は 92f1bbb、commit time は 2026-07-05 21:43:36 UTC、message は feat: build rust agent multiplexer。default branch main の current commit は 6be3817、commit time は 2026-07-20 00:26:27 UTC、message は Merge pull request #281 from jasonsuhari/feat/agent-port-inspector。scout が GitHub search result から記録した latest pushed time は 2026-07-20 00:26:29 UTC。GitHub releases page の先頭は v0.3.0-nightly.20260719.21.g6463f7a7c702、tag time は 2026-07-18 17:03:21 UTC。現在の npm/Cargo stable package version は 0.2.0 で、README も npm version が最新 GitHub release に一時的に遅れることがあると説明している。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | jasonsuhari/gridbash |
| 位置づけ | local multi CLI agent terminal grid and coordination workspace |
| Stars | 137 |
| Forks | 5 |
| 主言語 | Rust |
| ライセンス | MIT |
| GitHub 作成時刻 | 2026-07-05 22:46:52 UTC |
| public Git history 起点 | 2026-07-05 21:43:36 UTC、最初の commit 92f1bbb |
| current main commit | 6be3817、2026-07-20 00:26:27 UTC |
| latest pushed | 2026-07-20 00:26:29 UTC |
| 最新 GitHub release/tag | v0.3.0-nightly.20260719.21.g6463f7a7c702、tag time 2026-07-18 17:03:21 UTC |
| stable package version | 0.2.0 |
| キーワード | terminal grid、CLI agents、PTY、worktrees、session restore、local-first |
解いているのは「並列化した後の管理」
多くの人はすでに手動で複数 agent を動かしている。一つの terminal で Codex に test を見せ、別の terminal で Claude に refactor を頼み、さらに別の shell で pnpm test を回し、自分は横で logs を見る。このやり方は使えるが、少し増えるだけで破綻しやすい。各 pane の directory、state、auth profile、同じ file を編集していないか、どの output が別 agent に渡せる fact なのかを覚えておく必要がある。
GridBash はその workflow を launch stage に持ち込む。README の直接例は gridbash 2x3 --profile codex で、six-pane Codex grid を起動できる。--count 12 --layout auto --profile claude のように、より多い pane を自動配置することもできる。さらに重要なのが --worktrees だ。現在の git repo に少なくとも一つの commit があり、tracked modifications がないことを要求し、各 pane に repo-local な independent worktree を割り当てる。複数 agent が同じ working tree を踏み合う確率を下げるためだ。
これは派手な UI idea ではなく、かなり実務的な制約だ。multi-agent で本当に面倒なのは terminal split そのものではなく、parallel code changes の file boundary と state recovery であることが多い。GridBash が worktree isolation を launch path に入れているのは、agent 並列化の主な risk を理解しているからだ。
profiles により agent launcher に近づく
README に並ぶ agent profiles は広い。Codex、Claude、Gemini、Aider、OpenCode、Goose、Amp、Cursor、Copilot、さらに shell と custom commands も扱える。これらの agent 自体を bundle するわけではなく、system の codex や claude command を置き換えるわけでもない。GridBash が行うのは profile detection、auth config selection、project directory setup、そして実 PTY での launch だ。
ここが重要だ。terminal multiplexer は process と window を知っているだけで、普通は「これは managed agent pane である」とは知らない。GridBash は少なくとも startup flow を agent-first にしている。compatible managed auth profile を選び、project、layout、worktree policy を決めてから起動する。複数の codebase と複数の model tools を行き来する人には、tmux scripts を増やすより維持しやすい。
install path も軽い。README は Node.js 18+ を要求し、npm install -g gridbash の後に gridbash を実行する形だ。npm package は current platform の native binary だけを入れる。release は Windows x64、glibc Linux x64/arm64、macOS 13+ の Apple Silicon と Intel を対象にしている。source level では Rust 2024 edition で、Cargo.toml には ratatui、portable-pty、crossterm、vt100、tokio などが並ぶ。terminal UI と PTY management という位置づけに合っている。
session restore は見た目以上に効く
Agent tasks はいつも五分で終わるわけではない。一つの pane に migration plan を考えさせ、別の pane に historical issue を調べさせ、三つ目の pane に tests を直させる。その途中で terminal を閉じたり network が切れたりすることもある。GridBash の README では resume、background panes、crash recovery が比較的前に置かれていて、単なる launcher ではないことが分かる。
gridbash resume は保存済み session を選べる。gridbash resume --latest は直近の session を戻す。settings で UI を閉じた後も terminal processes を保持し、後から reconnect することもできる。unexpected close の後は、次の plain gridbash launch が unfinished agent sessions の recovery を試み、working directory ごとに tabs にまとめる。
これは長い作業に向いている。agent の continuity は脆い。terminal が失われると、その場の output や中間判断も失われやすい。最終的には git diff、logs、tests で確認する必要があるとしても、pane と output を戻せるだけで、同じ説明をやり直す時間をかなり減らせる。
local control API は観察したい部分
GridBash には optional agent control API もある。README の使い方は gridbash --agent-api 2x3 --profile codex で、agent MCP server に gridbash --mcp を実行させる。この API は lightweight grid snapshot、specific pane の bounded recent output、command send、pane capture / continuous logging、status bar update などを提供できる。
境界はかなり慎重に書かれている。API は localhost-only、token-authenticated、default off。discovery metadata には bearer token を含めない。ctl list と ctl panes は read-only で、send、capture、status、focus は token または GRIDBASH_CONTROL_TOKEN が必要になる。README は、agent に返す peer context が untrusted context であることも明記している。
これは「各 agent に他の pane の output を無制限に読ませる」より健全だ。multi-agent coordination で危ないのは、別 pane の draft、誤った reasoning、未検証 log を fact として扱ってしまうことだ。GridBash の pull-based design は、少なくとも境界をはっきりさせている。agent は coordination point で snapshot を要求し、人間または manager がいつ読ませ、いつ行動させるかを決められる。
Gumi で記録する理由
Gumi では最近、agent memory、code search、MCP server を多く見てきた。GridBash はそれらとは違う。agent を賢くするのではなく、agent が動いている現場を整理する。つまり「複数 agent が同じ machine 上でどう秩序立って働くか」を扱っている。
この方向は重要になっていく。single-agent experience が成熟した後、自然な次の段階は task を複数 agent に分けることだ。一つは docs を調べ、一つは code を変更し、一つは tests を書き、一つは review をする。しかし底の layer がただ random に開いた six terminals のままだと、状態の混乱で効率 gains は簡単に消える。GridBash の価値は、この低レベルな friction を専用 tool にしている点にある。
小ささも良い。137 stars、5 forks、repository 作成からまだ半月ほどだが、stable package、nightly tags、Windows/Linux/macOS binary、README、reference docs、release flow、community links が揃っている。大きな trend になる前だが、すでに実際に試せる形がある。Gumi で拾うにはちょうどよい段階だ。
注意したいところ
第一に、project は非常に若い。GitHub creation time は 2026-07-05 で、current main commit は 2026-07-20 まで速く動いている。release page の先頭も nightly だ。README は npm badge が registry の current version を示し、GitHub release に一時的に遅れる場合は matching native artifact を使うよう説明している。install と version selection では stable と nightly の差を意識したい。
第二に、GridBash は agent 本体を install しない。Codex、Claude、Gemini、Aider などの CLI は自分の system に用意しておく必要がある。GridBash が扱うのは profile と pane であり、各 agent の account、permission、model config を解決する tool ではない。
第三に、worktree isolation は automatic merge strategy ではない。各 pane を independent worktree に分ければ上書き事故は減るが、最後は人間が diff を review し、tests を走らせ、merge order を決める必要がある。multi-agent parallelism は conflict を消すのではなく、より制御しやすい場所に移すものだ。
第四に、modern terminal capability に依存する。README では target を UTF-8、ANSI/xterm-compatible terminals とし、SSH や tmux でも remote session が color-capable TERM を advertise すれば動くと説明している。一方で TERM=dumb と Linux kernel console は support されない。mouse forwarding が弱い環境では --no-mouse も必要になる。
まとめ
GridBash の面白さは、「terminal にまた一つ grid が増えた」ことではない。agent parallelism の現実的な問題をまとめて扱う点にある。launch profiles、real PTY、worktree isolation、session restore、background panes、そして optional local control API だ。
日常がすでに「一つの agent にコードを直させる」から「複数 agent に分担させる」へ移っているなら、jasonsuhari/gridbash は試す価値がある。multi-agent を必ず賢くするわけではないが、並列作業の現場を見えやすく、戻りやすく、状態不明の terminal windows だらけになりにくくしてくれる。