Launching a coding agent has become normal. You open a terminal, type a command, and Claude Code, Codex, OpenCode, or another CLI starts working. The problem starts when you launch several of them. One agent fixes a bug. Another prepares a refactor. A third reviews a diff. Next to them, a dev server is running, tests pass or fail, and each terminal tells a different part of the story. At some point, the hard part is no longer starting agents. It is knowing which one is doing what, which one is waiting for input, which one finished, and which branch it is working on. Paneflow grew from that exact problem: keeping multiple coding agents visible, controllable, and understandable inside one local workspace. The full demo is also available on [YouTube](https://www.youtube.com/watch?v=hElqzB2XMn0). The launch thread is on Hacker News: [Show HN: Paneflow](https://news.ycombinator.com/item?id=48735123). ## The terminal alone is not always enough [#the-terminal-alone-is-not-always-enough] I like terminals. tmux, Zellij, Ghostty, Kitty, and WezTerm are all strong tools, especially when you work over SSH or on a remote machine. But when you run several local agents on the same project, the problem changes. A terminal grid shows processes. It does not really tell you which agent is thinking, which one is waiting for your approval, which one produced an interesting diff, or which one is redoing another agent's work. With enough windows open, you end up rebuilding the project state in your head. You move from one terminal to another, reread scrollback, find the right directory, check the current branch, then return to the diff. That is not a big problem once. It becomes expensive when it is your main way of working. Paneflow is not trying to replace your editor. It replaces the coordination layer many developers build by hand with splits, window names, branch conventions, and a lot of short-term memory. ## One workspace per task, not just one pane per command [#one-workspace-per-task-not-just-one-pane-per-command] In Paneflow, a pane is still a real terminal. You can run Claude Code, Codex, OpenCode, Grok Builder, or any other CLI that works in a shell. The difference is what surrounds the terminal. A task can have its agent, tests, dev server, git branch, diffs, and previous sessions. Paneflow keeps those pieces in the same workspace so you do not have to rediscover them every time you switch context. When you want isolation, each task can run in its own `git worktree`. The Review view then shows the diffs side by side, one worktree per column. You can see what each agent produced without changing windows, branches, or editors. That organization becomes especially useful when two agents work on nearby parts of the codebase. You can keep their outputs open, compare their changes, then decide which one deserves to be kept, corrected, or thrown away. ## Coordination happens through the CLI interface [#coordination-happens-through-the-cli-interface] The most important bet in Paneflow is not the display. It is coordination. I call that layer Paneflow Conductor. For now, what I expose to agents intentionally goes through the CLI interface and local socket. The GUI stays where you supervise, read, and take over any pane. `paneflow ps` lists the running panes and agents with their real state. `paneflow watch` streams changes as JSONL, fed by hooks and the event bus instead of repeatedly polling the terminal. An agent can observe what is running, wait for an event, prepare a prompt for another pane, and leave the final send for you to approve. By default, Paneflow pre-fills prompts and you still press Enter. Auto-submit exists, but it is opt-in. That choice is intentional: when several agents can act inside the same project, human control should stay visible. ## Agents can read without taking control [#agents-can-read-without-taking-control] Another important piece is the built-in MCP server. It exposes three read-only tools: `list_panes`, `read_pane`, and `search_pane`. In practice, Claude Code in one pane can read the test output Codex just produced in another. An agent can search for an error in a neighboring terminal before proposing a fix. You no longer need to copy-paste one tool's output into another. The boundary is strict: this bridge cannot write into a pane or drive an agent for you. Terminal output is treated as untrusted because an agent transcript or a repository can contain hostile text. Paneflow makes context sharing more explicit, but it does not turn every terminal into an open execution surface. That boundary is the part I care about: give agents enough context to avoid working blind, without giving them silent power over the whole session. ## Why a native app [#why-a-native-app] Paneflow is written in Rust and uses GPUI, the UI framework behind Zed. That choice comes from a simple constraint: agents can run for a long time, sometimes in parallel, and the place that contains them should stay light. I did not want an Electron app wrapped around terminals that already run heavy processes. I also did not want a macOS-only tool when my own work moves across Linux and Windows. Today, Paneflow ships builds for Linux, macOS Apple Silicon, and Windows x64. macOS Intel and Windows ARM64 are not shipped yet. The result is not an IDE. It is a local, open source workspace for developers who already know how to use their CLI agents, but no longer want to coordinate everything by hand. ## Try Paneflow on your next multi-agent session [#try-paneflow-on-your-next-multi-agent-session] If you launch one agent from time to time, your current terminal is probably enough. If you are starting to run several agents in parallel, the question changes: how do you keep their state readable, their branches separate, their diffs reviewable, and their context shareable without losing control? That is the problem Paneflow is built to solve. Download Paneflow, open a project, launch two agents in two panes, and see whether the workspace reduces the mental load you had started to accept as normal.