Runner Multi-Agent Terminal
Coordinate multiple coding agents on one mission while each keeps its native terminal interface.
- Source repo
- yicheng47/runner
- Stars
- ★ 171
- Last updated
- today
- License
- MIT
- Primary language
- Rust
- FA score
- 82/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free, no paid service needed
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A developer who wants one coding agent to implement changes and another to review the working-tree diff until no must-fix findings remain.
- Not a fit if
- Teams requiring Linux, Intel Mac, or Windows ARM64 support
- Teams requiring production-grade stability; the project is currently alpha
- Users unwilling to install and configure agent CLIs separately
- Source review
- 82/100 · Some gaps
What does this agent do, and when should you use it?
Runner is a native desktop application for coordinating Claude Code, Codex, GitHub Copilot CLI, and pi around one development goal rather than leaving them isolated in separate terminals. Users define Roles with a runtime, system prompt, and working directory, combine them into a Crew with one lead, and launch that Crew as a Mission. Every Mission slot runs in its own real PTY, while an append-only, persistent event feed carries messages, signals, and questions that need a human decision. Runner also provides single-agent Chats, split terminal panes, project grouping, session recovery, MCP and skill configuration views, and a `runner` CLI covering the same core objects. It is built in Rust with gpui-ce, `alacritty_terminal`, and SQLite, uses no webview, and keeps its application state, chats, and missions on the user's machine.
Runner reads and manages Role, Crew, Project, Chat, Session, and Mission records. Starting a Mission creates one live PTY for each Crew slot and leaves every agent inside its own TUI; members coordinate through the append-only feed and commands such as runner msg post, runner signal, and runner ask. A lead can invoke ask_human to surface a decision in the feed, and the user can answer through the interface or runner mission answer. Individual slots can be stopped, resumed, or restarted without restarting the entire Mission, while surviving sessions can be reattached after an application quit or crash. Settings → MCP and Settings → Skills read each agent's existing configuration files, expose per-agent toggles, and change only the selected entry. The runner command can also create and maintain projects, roles, and crews; launch, inspect, stop, and archive missions; and return JSON for scripts or other agents.
- A developer who wants one coding agent to implement changes and another to review the working-tree diff until no must-fix findings remain.
- A team assigning Claude Code and Codex different roles on the same task to get cross-provider implementation and review.
- An individual running many terminal agents who needs one place to see activity, completion indicators, and human-decision requests.
- An engineering team dividing a complex repository among architect, implementer, and reviewer roles while retaining a replayable coordination log.
- An automation user who wants to launch missions, follow their feeds, and message a lead from a shell or another agent.
- A user who wants a native interface for inspecting and toggling MCP servers and skills across supported agent configurations.
How do you install or deploy this agent?
Download the latest platform installer from GitHub Releases. The macOS build is a signed and notarized .dmg for Apple Silicon; Windows uses a signed Runner-Setup-…-x64.exe for Windows 10 version 1809 or later. Intel Macs, Windows ARM64, and Linux are unsupported.
Install each agent CLI separately and make it available on PATH, or configure an executable override under Settings → Agents. On Windows, Claude Code and pi's bash tool require Git for Windows; npm-based CLI installations require Node.js.
On first launch, macOS installs runner into ~/.local/bin or a writable /usr/local/bin when that location is already on the login PATH; otherwise, install it from Settings → General → Command line. Windows adds Runner's sidecar directory to the user PATH. Runner also installs its agent skill into ~/.claude/skills/ for Claude Code and ~/.agents/skills/ for Codex, GitHub Copilot CLI, and pi.
How do you use this agent?
In the desktop application, create or select Roles and assign them to named Crew slots; each Crew must have exactly one lead. Enter a goal and start a Mission, then switch between its shared feed and the live terminal for each slot. The seeded pair-coding Crew uses @coder for implementation and fixes and @reviewer for read-only inspection of the working-tree diff.
First check that the CLI can reach the running application:
runner statusList available crews:
runner crew list --jsonStart a Mission from a goal file and follow its feed:
mission=$(runner mission start --crew <crew> --goal-file - -q < brief.md)
runner mission feed "$mission" --follow --json
runner mission show "$mission" --jsonMessage the lead, answer a human question, then stop and archive the Mission:
runner msg post --mission "$mission" --to <lead_handle> "message"
runner mission answer "$mission" <question_id> <choice>
runner mission stop "$mission"
runner mission archive "$mission"Inside a Mission, agents can use the inherited mission and handle context directly:
runner msg post --to <handle> "message"
runner signal <type>
runner ask --human <prompt> --choices <a,b,...>Use --json for automation. Exit status 0 means success, 1 means Runner refused the operation, 2 indicates a usage or reference error, 3 means the application is not running, and 5 means a sandbox blocked the local connection.
What are this agent's strengths and limitations?
- Each agent retains a real PTY and its native TUI instead of being reduced to a generic chat adapter.
- The Mission feed is an append-only, persistent, replayable event log, and running sessions can survive an application quit or crash.
- Claude Code, Codex, GitHub Copilot CLI, and pi can participate in the same Crew, allowing mixed-runtime workflows.
- The desktop interface and
runnerCLI cover Roles, Crews, Missions, Sessions, Chats, and Projects for use by people, scripts, and agents. - The MCP and Skills panes work with agents' existing configuration files and are documented to modify only the selected entry.
- Its local native stack uses Rust, gpui-ce,
alacritty_terminal, and SQLite without a webview.
- The project is explicitly labeled alpha and actively shipping, so adopters must accept pre-release stability and change risk.
- Platform support is limited to Apple Silicon macOS and Windows x64; Linux, Intel Macs, and Windows ARM64 are unsupported.
- Agent CLIs must be installed separately, and some runtimes bring additional account requirements; GitHub Copilot CLI requires a Copilot subscription.
- GitHub Copilot CLI and pi run natively on Windows but have not yet been smoke-tested there.
- Runner does not surface approval and question dialogs for Codex; pi provides that capability only through extensions.
- Missions use Bypass permission mode by default, which teams may need to change to meet their security policy.
How does this agent compare with similar options?
Compared with opening unrelated terminals for several agents, Runner adds reusable Roles, Crews with a designated lead, a shared event feed, persistent Missions, and an ask_human decision path while preserving each agent's real terminal UI. It is not tied to one model vendor: Claude Code, Codex, GitHub Copilot CLI, and pi can share a Crew, although their supported features are not identical.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Runner Multi-Agent Terminal This agent | 82 · Some gaps | Desktop appFree | ★ 171 | today | Rust | Codex · Claude Code |
| amux Agent Control Plane | 77 · Good | Self-hosted serviceFree + model costs | ★ 503 | today | Rust | Codex · Claude Code |
| zerostack | 57 · Major gaps | CLIFree + model costs | ★ 1.7k | 3d ago | Rust | OpenAI API · Claude API |
| Vigil Multi-Agent Terminal Orchestrator | 69 · Some gaps | Desktop appFree + model costs | ★ 28 | 19d ago | Swift | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
The supplied sources describe local SQLite persistence, real PTYs, narrowly targeted configuration edits, CLI side effects, signed publication, and author attribution. CI uses read-only contents permission, and downloaded Sparkle tooling is pinned and hash-checked. Deductions apply because missions default to Bypass permission mode, many create/delete/stop/archive operations show no per-action confirmation, provider network and credential lifecycles are not comprehensively documented, and stop/resume/restart is not a data-level undo or backup facility.
The README, Cargo workspace, CI, release workflow, and fixture present a coherent product structure and platform story. CI covers macOS and Windows, formatting, Clippy, tests, lockfile integrity, installer behavior, and resources; scripts provide explicit errors and the CLI documents exit codes. Dependency availability is reduced because agent CLIs, Node.js, Git for Windows, subscriptions, and update services remain external, while some Windows agent combinations are expressly not smoke-tested.
The sources clearly distinguish roles, crews, missions, chats, projects, and sessions, and document several crew shapes, human decision points, machine-readable output, and a cross-agent capability matrix. Platform boundaries, command context, PATH detection, executable overrides, and macOS/Windows constraints are unusually specific, justifying high scores, although static documentation cannot validate every combination.
The README has clear navigation and dedicated installation, platform, CLI, example, community, author, and licensing sections; terminology is stable across the supplied files. The MIT text, copyright holder, and historical license interval are explicit. Deductions reflect the absence of a dedicated FAQ and the lack of a complete stable-release changelog in the supplied evidence beyond the current version, release links, and nightly-note generation.
Outputs serve both people and automation through tables, summaries, JSON, an event feed, and inspectable terminals, while copyable crew examples make the workflow actionable. Persistent coordination, role separation, and human escalation offer clear marginal value over unrelated terminal sessions. Cost-benefit loses a point because CPU, memory, token, subscription, and multi-agent concurrency costs are not quantified.
Major structural claims are corroborated across Cargo metadata, CI, nightly publication logic, and the database fixture. The README also separates assertions from caveats by labeling the product alpha and identifying unsupported or untested combinations. Deductions apply because several UI, crash-recovery, minimal-config-editing, and end-to-end behavior claims appear only in the README, while referenced architecture, examples, and production implementation files were not supplied.
- Missions default to Bypass permission mode; use a stricter mode and review agent commands for untrusted code or sensitive workspaces.
- Runner launches multiple external agents with real terminal and working-directory access; their network, telemetry, credential, and subscription behavior is not fully described by these sources.
- The product is explicitly alpha; Linux, Intel Macs, and Windows ARM64 are unsupported, and some Windows agent combinations have not been smoke-tested.
- Stop, resume, restart, and archive are not file or database rollback mechanisms; retain independent backups before deletions or configuration changes.