Agent of Empires (AoE): a tmux session manager for Claude Code and other CLI agents

The problem AoE solves for people running several CLI agents

A single Claude Code or OpenCode session is easy to manage. Five of them are not. Each one wants a terminal, each one blocks that terminal while it works, and closing the window or losing an SSH connection kills the process. The usual workaround is to keep a pile of terminal tabs open and hope you remember which one was waiting for input.

Agent of Empires, usually shortened to AoE, is a session manager for exactly that situation. The README describes it as "A session manager for AI coding agents on Linux and macOS" and lists the supported tools as Claude Code, OpenCode, Mistral Vibe, Codex CLI, Gemini CLI, Pi.dev, Copilot CLI and Factory Droid Coding. The audience is narrow on purpose: developers who already drive these agents from a shell and want several of them running in parallel across branches, not people looking for a chat interface.

The repository metadata classifies it as a command-line utility and development tool written in Rust, with a workspace split across the main crate, an xtask crate, a settings derive crate and a plugin API crate. The last push was on 2026-09-09, and the most recent release listed is v1.15.3 on 2026-09-02, while Cargo.toml on main carries version 1.16.0. That gap between the released version and the version in the manifest is worth knowing about if you build from source.

How AoE works: one tmux session per agent, wrapped in status detection

The mechanism is not a custom process supervisor. Every agent AoE manages runs inside its own tmux session, which is why the README can say that closing the TUI changes nothing: the sessions are running in the background, and they are only removed when you explicitly delete them. Reopening aoe reattaches you to the same state. If you already know tmux, the mental model transfers immediately, and the README notes you can still run tmux attach on any AoE session directly.

What AoE adds on top of tmux is awareness of what the agent inside is doing. The feature list names status detection with the states running, waiting, idle and error, plus notifications. That is the part plain tmux cannot give you: a session list that tells you which agent is blocked on a prompt rather than merely which pane exists.

The rendering path is more involved than a tmux wrapper usually is. Cargo.toml documents an in-process VT emulator using the vt100 crate for the default live-preview path, which parses a pane's raw byte stream into an owned grid instead of scraping capture-pane snapshots. That behaviour can be turned off with the AOE_VT_LIVE=0 environment variable. The structured transcript view is rendered by mapping events to ratatui lines through pulldown-cmark, with the HTML renderer disabled.

Around the sessions sit the features that make this more than a launcher: git worktrees and multi-repo workspaces, Docker, Podman and Apple Containers sandboxing, diff review, profiles, repo hooks and custom agent commands. Surfaces include the TUI, a web dashboard, a CLI and an HTTP API, so the same session set is reachable from a terminal or a browser.

Installing AoE and starting a first session

tmux is a required prerequisite and Docker is optional, only for sandboxing. The README gives four installation routes. The quick install script for Linux and macOS is the shortest path.

curl -fsSL \
  https://raw.githubusercontent.com/agent-of-empires/agent-of-empires/main/scripts/install.sh \
  | bash

Homebrew users can install the formula instead, and Nix users can run it straight from the flake. Building from source is also documented.

brew install aoe
nix run github:agent-of-empires/agent-of-empires
git clone https://github.com/agent-of-empires/agent-of-empires
cd agent-of-empires && cargo build --release

The manifest pins rust-version to 1.85, so a source build needs a toolchain at least that new. Once installed, the README's quick start is three commands.

aoe                          # Launch the TUI
aoe add --cmd claude         # Create a session running Claude Code
aoe serve                    # Start the web dashboard

Running aoe with no arguments opens the TUI, where pressing ? shows help and the bottom information bar lists the keybindings available in the current context. The one shortcut the README singles out is Ctrl+b d, which detaches from a session and returns you to the TUI. aoe add --cmd claude creates a session whose command is Claude Code. aoe serve starts the web dashboard, which is the piece that makes the phone view possible. To check which agent binaries AoE can actually see on your machine, the FAQ points at aoe agents.

Where AoE stops being the right tool

The clearest boundary is the operating system. The README states that Windows works only through WSL2, because AoE depends on tmux and POSIX process handling, and that native Windows is not supported. If your workflow is PowerShell and native Windows tooling, this project is not for you, and no amount of configuration will change that.

The second boundary is scope. AoE manages sessions; it does not host models, provide API keys, or decide what your agents do. It is a layer over binaries you have already installed and authenticated. The FAQ's answer to which AI tools are supported is simply to run aoe agents for the current list and availability on your machine, which implies the supported set is discovered rather than fixed in advance. That is convenient, but it also means the list can shift between versions, so a workflow built around one agent's integration is worth re-checking after an upgrade.

The third is the sandboxing story. Docker, Podman and Apple Containers are listed as isolation options, and Docker is described as optional in the prerequisites. Isolation is therefore opt-in rather than the default, and an agent running without it has the same filesystem access as any other process you started. If your reason for wanting a session manager is containment rather than convenience, the container path is the part you have to configure deliberately.

Finally, the README does not document rollback or downgrade for the install script, and it does not describe what happens to existing sessions when the binary is replaced under a running set of tmux sessions. That is a real gap for anyone planning to track releases closely.

Agent of Empires vs agent-deck and plain tmux

The README credits agent-deck, a Go and Bubble Tea project, as the inspiration for AoE. The two occupy the same niche: a terminal UI that manages multiple AI coding agents. The difference visible in the repository is implementation language and breadth. AoE is Rust, and its feature list goes past session management into git worktrees, multi-repo workspaces, three container runtimes, a diff viewer, profiles, repo hooks and an HTTP API, with a web dashboard as a first-class surface alongside the TUI.

The more common comparison is against tmux itself, and the README answers it directly. tmux gives persistent sessions. AoE adds agent-aware status detection with running, waiting, idle and error states, worktree management, Docker sandboxing, a web dashboard, phone access and a diff viewer, while leaving the underlying tmux workflow intact. If all you want is a session that survives a disconnect, tmux alone is smaller and has nothing to upgrade. If you want to glance at a list and see which of six agents is waiting on you, that list is the feature you are actually paying for.

Against a hosted or editor-integrated agent runner, the trade-off runs the other way: AoE keeps everything local and terminal-native, and in exchange you manage the prerequisites, the agent binaries and their authentication yourself.

Maintenance, releases and licence cost

The project is not archived, and the last push was on 2026-09-09. Releases listed in the repository are v1.15.3 on 2026-09-02, v1.15.2 on 2026-09-02 and v1.15.1 on 2026-08-28, which shows a cadence of small patch releases rather than long gaps, though the manifest version of 1.16.0 on main sits ahead of the newest tagged release. If you install from Homebrew or the install script you get a tagged build; if you build from source you get main, and those are not the same thing.

Maintenance cost for the user is mostly upgrade cost. There is a CHANGELOG.md at the repository root and a cliff.toml, which suggests changelog generation is automated, so release notes are the place to check before upgrading. Because every agent runs in a tmux session, upgrading the binary does not by itself stop running agents, but the README does not describe how a new version interacts with sessions created by an older one.

On licensing, the README says MIT and the repository ships a LICENSE file. Cargo.toml is more precise: the package declares "MIT AND Apache-2.0", with a comment explaining that the OSC 8 emission state machine in src/tui/hyperlink.rs is derived from herdr under Apache-2.0, and there is a THIRD_PARTY_NOTICES.md plus a licenses directory. For most users this changes nothing, but if you redistribute AoE or bundle it into a product, the Apache-2.0 portion carries its own notice requirements. That is a description of what the files say, not legal advice; check the notices yourself if redistribution matters to you.

Editorial conclusion

Adopt AoE if you already run several CLI agents on Linux or macOS and want them to survive terminal crashes, SSH drops and laptop lids, with a browser view for checking on them from a phone. Skip it if you work on native Windows, if one agent in one terminal is enough, or if you want a hosted multi-user service rather than a local tool. Before committing, run aoe agents on your machine to confirm which agent binaries AoE recognises, and check whether the optional Docker sandboxing path is something you actually need, because it is the only prerequisite beyond tmux.

Frequently asked questions

Official sources

1. agent-of-empires/agent-of-empires on GitHub
2. License: MIT
3. Project website
4. README
5. Releases