Hi everyone, I've been working on a few personal projects with coding agents and gradually settled into a workflow that works for me. I wanted to share a small tool I've been building and using myself, Runner. If you use several agents too, I'd appreciate you giving it a try and sharing some feedback.
Runner is a local desktop app for managing agent CLIs like Claude Code and Codex. It works like a terminal multiplexer for agents: you can keep sessions from different providers in one app, arrange them into tabs and split panes, and put a few agents into a crew to work together. Remote control now lets you use the same app to reach chats and missions on another computer.
There are already quite a few tools for managing agents. My main reason for building another one was to make it fit the way I work. I also wanted to try agents from different providers and switch between them easily, while keeping the rest of my workflow. Being able to choose which agent to use, without tying everything to one provider, is something I care about.
I use Runner to develop Runner itself. Below are the parts I use most and how they fit into my day-to-day work.
The workflow I use most
My usual starting point is a coder and a reviewer. The coder owns the implementation and fixes. The reviewer reads the diff, checks it against the task, and sends findings back to the coder. They repeat that loop until the review is clean.
For changes that need live testing, I add QA. In Runner's development workflow, the reviewer checks the code first, then QA builds the reviewed revision and exercises the relevant behavior in the development app. If QA finds a problem, it goes back to the coder.
The roles have specific boundaries. My reviewer is instructed to report findings without editing the implementation. QA records what it tested and the results. I still decide the scope, answer product questions, and review the result before merging.
I also used a coder/reviewer/QA crew to build Runner's website. The role prompts for the coding pair and trio are in the repository if you want to try the same arrangement.
For a small fix, I often just use one chat. A crew adds communication and review time, so I use it when that extra review is useful.
Roles, crews, and missions
A role is a saved agent configuration: its runtime, model settings, and instructions. A crew combines roles and chooses a lead. A mission is one run of that crew with a task and working directory.
For example, I can put Claude Code in the coder slot and Codex in the reviewer slot, or use Codex for both with different instructions. I want to be able to change those choices as I try different agents.
The crew also has shared team conventions. Mine describe when to hand off work, who can change files, which checks to run, and when commits or pull requests are allowed. These are instructions given to the agents, so their behavior still needs supervision.
Members communicate through the bundled runner CLI. Their messages appear in the mission feed, and they can address a particular teammate or ask me a question there. I can answer, send a correction, or change the task's constraints while they work.
The roster can change during a mission too. I can add another role with its own task, remove a member, or stop and resume one session while the others continue.
Every member has a real terminal
Opening a mission member shows its live CLI session. It has the same terminal interface the agent normally provides, and I can type into it, answer a prompt, or interrupt a turn.
That matters when I need to understand a handoff. The feed shows what the agents told each other; the terminal lets me inspect the work behind those messages.
The mission screenshots show a small haiku-generator demo. It includes a coder asking the human to choose a theme, so you can see both agent coordination and the question-and-answer flow. There is a video tour in the README.
Keep working from another computer
Remote control is now in beta. Switch computers from Runner's sidebar to open an existing chat or mission and continue using its live terminals. You can also start new chats and missions there, send messages to the crew, and answer its questions.
Sign both computers into the same Runner account, enable remote access on the computer you want to reach, and pair using its six-digit PIN. The connection is encrypted end to end through Runner's relay; the agents and their sessions stay on the host computer.
Access is currently invite-only and limited to mainland China. Request an invite in the Runner Discord or WeChat user group. The remote-access guide covers setup and pairing.
An everyday workspace for individual chats
I also use Runner for ordinary sessions outside a crew. Chats are organized into tabs and projects, a tab can contain several panes, and panes can be rearranged. You can open multiple windows as well.
Sessions run in a background service called runnerd. When closing the app, I can choose to keep them running. Reopening Runner reconnects to those live terminals. Desktop notifications can bring me back when an agent needs input, finishes a turn, or fails; mission notifications are opt-in.
I recently added Claude Code account switching too. Each account keeps its own sign-in, and the usage menu lets me choose which account to use. For an existing chat, I can stop it, select another account, and resume the same conversation. Sessions already running keep their original account.
There is an option to share the main account's configuration, including skills, MCP servers, and enabled plugins. I use quite a few of these, so setting them up again for every account would be tedious. The account guide covers how sharing and resume work.
Agents can operate Runner too
The desktop app and the bundled CLI use the same background service. An agent can start a mission, read its feed, and send instructions through shell commands, while I can open the resulting sessions in the app.
For example, from a macOS shell, after saving a task in brief.md:
mission=$(runner mission start \
--crew "Pair coding crew" \
--cwd /absolute/path/to/project \
--goal-file brief.md -q)
runner mission feed "$mission" --follow
Use your own crew name and working directory. The CLI guide also has PowerShell examples and the commands for sending messages and answering questions.
Underneath, Runner is written in Rust with GPUI and alacritty_terminal. Its session and mission records stay on your machine. Model requests still go through each agent CLI's configured provider, using your existing accounts or API setup.
Trying it
Install and sign in to at least one supported agent CLI, then download Runner. Start with a direct chat to check your setup. A fresh installation includes a pair-coding crew with two Codex roles; you can change the agents and instructions to suit your workflow.
For a first mission, choose a small task in a folder you are comfortable letting agents edit. Members share the directory you provide, and Runner does not create a Git worktree automatically. In my own development workflow, I prepare a worktree for each feature before starting its mission.
Runner is free and open source under the MIT license. It is still in alpha, and runtime capabilities differ. The support table lists those differences. The production builds currently support macOS Apple Silicon and Windows x64; Linux support is still in development.
If you try it, I would like to hear how you divide work between agents and where the coordination becomes awkward. That is the part I am spending the most time on myself.
Top comments (0)