Launching Paneflow on Show HN

Launch context. This article and the demo below describe the June 2026 interface, including the former Review view with one column per worktree. For Paneflow 0.17.4, see the Paneflow introduction and the Changes guide.

Paneflow launched on Show HN in June 2026 as a native terminal multiplexer for coding agents. The goal was to bring agents, project context, and code review into one local interface.

With Claude Code fixing a bug, Codex reviewing changes, and a dev server running alongside them, each terminal holds part of the project state. Switching between them means finding the right directory, checking the branch, and reading output to see who needs a response. Paneflow brought those terminals and their context together.

Watch the full Paneflow launch demo on YouTube or read the Show HN: Paneflow discussion.

Keep a task's terminals and changes together

Each pane remained a terminal running an ordinary CLI process. Claude Code, Codex, OpenCode, tests, and dev servers could run alongside each other in the same workspace.

A task could use its own Git worktree to keep its files and branch separate. The launch interface's Review view displayed diffs side by side, one worktree per column. You could compare the changes from two tasks before deciding what to keep or revise. Separate worktrees still required review and conflict resolution when combining the branches.

Coordinate through the CLI

Paneflow Conductor exposed coordination through the CLI and a local socket. paneflow ps listed panes and agents; paneflow watch streamed events as JSONL. Agent activity came from hooks and the event bus, with tracking depending on the available integration.

The interface let you read output, interrupt a process, or take over a terminal. Prompt sending pre-filled text by default, leaving you to press Enter. Automatic submission required an explicit opt-in.

Share output through a read-only MCP bridge

The MCP server exposed three tools: list_panes, read_pane, and search_pane. An agent connected to the bridge could read test output from another pane or search for an error before proposing a fix.

The bridge could not type into panes or control processes. Terminal output was treated as untrusted data: sharing an agent's transcript did not make its instructions authoritative. Read access and CLI control had separate permission boundaries.

A native interface for local processes

Paneflow was built in Rust with GPUI, the UI framework used by Zed. The agents remained CLI processes running locally and connecting to their own model providers.

The launch brought project context and review closer to those processes. Assigning tasks, answering approval requests, and reviewing the resulting code remained your responsibility.