# Agent Tower: a Kanban command center for Claude Code, Codex and Gemini CLI

> Agent Tower is a TypeScript dashboard that runs multiple coding agents in parallel, gives each task its own Git worktree, and exposes an MCP server so agents can read the board themselves. It is a self-hosted control plane, not a hosted service, and it is still in beta.

**agent-tower/core** — The command center for AI agents such as Claude Code, Codex, and Gemini-Cli, making your agents ten times more efficient.

- Repository: https://github.com/agent-tower/core
- Stars: 403 · Forks: 23
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-15 · Updated: 2026-09-15 · Language: en
- Canonical page: https://hysenlabs.com/projects/agent-tower-core

## The terminal sprawl problem Agent Tower was built to fix

The README's own origin story is unusually specific. The author opened several terminals, ran different tasks at once, and then hit four problems: windows he could no longer map to tasks, edit conflicts when two agents touched the same files, no way to check progress away from the desk, and token bills that grew with the number of parallel tasks. Agent Tower is the answer to those four, in that order. The target user is someone who already runs Claude Code, Codex or Gemini CLI and has started running more than one at a time. It is not a replacement for those agents and it does not call a model of its own. It is a supervisor: a Fastify server, a React dashboard, and a set of services that own the lifecycle of a task. The advertised benefit, agents that are "ten times more efficient", is a marketing line rather than a measured figure. The concrete claims worth judging are narrower: one page for all projects and tasks, automatic Git worktree isolation per task, per-task provider selection, remote access through a Cloudflare tunnel, and an MCP server. If you run a single agent against a single repository, none of those claims apply to you.

## How the server, the worktree service and the agent pipeline fit together

The architecture diagram in the README shows three layers. A React browser client holds the Kanban board, a terminal, a code editor and a Git changes view, with TanStack Query caching server state and Zustand holding UI state. It talks to a Fastify server over HTTP REST and Socket.IO on the /events namespace. Inside the server, the diagram lists a REST API of 16 routes, a Socket.IO channel for realtime updates, and an MCP server for agent integration, all feeding a Services layer that covers session management, workspace handling, Git and worktree operations, and notifications and tunneling. Below that sits an AgentPipeline component built from a PTY, a parser and a message store. That last piece is the interesting one. Agents are driven through a pseudo-terminal and their output is parsed rather than consumed as structured JSON, which is what lets Agent Tower wrap third-party CLIs it does not control. The cost is that parsing terminal output is inherently brittle when an upstream CLI changes its formatting. The workspace service is what creates the per-task Git branch, so isolation is a repository-level mechanism, not a container-level one. Team mode adds a shared group chat where each agent stays an independent member; the README argues this keeps one agent's long context from contaminating the others, and notes that in the author's own testing teams ran for as long as 48 hours. That is an anecdote from the author, not a benchmark, and it should be read as such.

## Installing Agent Tower and running a first task

The README recommends a global install as the simplest path, and labels it "Recommended: global install (simplest, one command and you're done)". It requires Node.js 22.19.0 or newer, which the package.json engines field also enforces. These two commands install the CLI and start it:

```bash
npm install -g agent-tower
agent-tower
```

After that, the README says to open http://localhost:12580 and start using it. The README does not document a flag for changing the port on the global install path; the Docker Compose file uses the AGENT_TOWER_PORT variable with a default of 12580 instead. If you prefer to run from source, the README gives this sequence, where pnpm setup installs dependencies and builds the shared package before pnpm dev starts all services in development mode:

```bash
git clone https://github.com/agent-tower/core.git
cd agent-tower
pnpm setup          # Install deps + build shared package
pnpm dev            # Start all services in dev mode
```

## Wiring the MCP server so agents can claim tasks themselves

The optional MCP step is what separates Agent Tower from a plain terminal multiplexer. Adding the server to your MCP client lets an agent read the task board, claim work and report progress without a human relaying messages. The README gives this configuration example, which goes in your MCP client's config:

```json
{
  "mcpServers": {
    "agent-tower": {
      "command": "agent-tower-mcp",
      "args": [],
      "env": {
        "AGENT_TOWER_INTERNAL_TOKEN": "${env:AGENT_TOWER_INTERNAL_TOKEN}"
      }
    }
  }
}
```

Two details matter here. First, if you have enabled the access password, MCP calls authenticate with AGENT_TOWER_INTERNAL_TOKEN rather than browser cookies. Second, the README explicitly warns against hard-coding a real token in shared config and suggests copying the generated config from Agent Tower's settings or passing the variable through your MCP client's secret mechanism. If you skip this step entirely, the dashboard still works; you just do the task assignment by hand.

## Running it in Docker, and what the container does not give you

The Compose file maps host port 12580 to container port 12580, sets AGENT_TOWER_DATA_DIR to /data on a named volume, and mounts your working directory at /workspace through AGENT_TOWER_WORKSPACE_DIR. Provider API keys are passed through commented environment entries. The repository pins pnpm 11.18.0 in package.json, while the Dockerfile takes a PNPM_VERSION argument defaulting to 10.24.0 and docker-compose.yml passes 10.24.0 as well. That mismatch between the local toolchain and the image is worth knowing before you assume the two environments behave identically. The part that trips people up is authentication: the Compose file comments out the bind mounts for ~/.codex, ~/.claude, ~/.claude.json, ~/.gemini and ~/.cursor, with the instruction to mount them after you have logged in on the host. A container that has no agent CLI auth mounted will start fine and fail the moment a task tries to run.

## Where Agent Tower is the wrong tool

The isolation model is Git worktrees, and that has a boundary. If your project is not a Git repository, or if your work spans several repositories that must change together, per-task branch isolation does not describe your problem. The README states that one-click merge back to main exists, but it does not document rollback, nor what happens when a worktree merge conflicts after an agent has edited files for hours. Treat merge conflict resolution as your responsibility. The second limitation is the release channel. The most recent published release is v0.6.0-beta.4 from 2026-08-03, preceded by v0.5.4-beta.10 and v0.5.4-beta.9 from 2026-07-17. Every recent tag is a beta, so if your team needs a versioned, stable artifact with a support promise, this is not that yet. The last push to the repository was on 2026-08-11, roughly a month before this writing, which is recent but does not by itself tell you the project is stable. Third, the PTY-and-parser design means an upstream CLI changing its output format can break task state detection until Agent Tower ships a fix. Finally, remote access goes through a Cloudflare tunnel, which means your task board is reachable from outside your network by design. If that is unacceptable in your environment, the phone-monitoring feature is simply off the table.

## Agent Tower compared with plain Git worktrees and a task runner

The obvious alternative is what the README's author was doing before: a shell script that creates a worktree per task, launches an agent in each, and leaves you to track state in your head or in a notes file. That approach has real advantages. It has no server, no database, no port, and nothing to update. Git worktrees are a first-class Git feature, so the isolation mechanism is identical to Agent Tower's; the difference is everything around it. A script does not give you a Kanban state machine with Review, Running and Done, does not stream agent output into a browser, does not notify you on a Lark webhook, and does not expose an MCP endpoint that lets an agent claim its own next task. What you trade for those is a long-running Node.js process, a Prisma-backed data directory, and the upgrade treadmill of a project whose current releases are all betas. The honest framing is that Agent Tower is worth its operational cost once you are running enough concurrent tasks that losing track of one costs more than maintaining a server. Below that threshold, worktrees plus discipline win.

## Licence, maintenance and the cost of upgrading

Agent Tower is licensed under Apache-2.0, stated in both the README and package.json. That is a permissive licence with an explicit patent grant, and it permits commercial use and modification. It does not tell you anything about the project's stability, and nothing here is legal advice; if you plan to redistribute a modified version, read the licence text and your own obligations rather than relying on a summary. On maintenance, the repository is not archived and the last push was on 2026-08-11. The release cadence visible in the tags is rapid: three beta releases between 2026-07-17 and 2026-08-03. Rapid beta cadence cuts both ways. Fixes for a broken terminal parser arrive quickly, and so do behaviour changes you did not ask for. The upgrade cost is concentrated in two places. The data directory, mounted at /data in the container, holds state you will want to back up before pulling a new image. And the agent CLI versions are build arguments in the Dockerfile, with defaults of 0.142.4 for Codex, 2.1.196 for Claude Code and 0.23.0 for Gemini CLI, so a rebuild can silently move your agents to different versions unless you pin those arguments.

## Conclusion

Adopt Agent Tower if you already run two or more coding agents locally and the pain is coordination rather than model quality: the per-task worktree isolation and the Kanban state machine address a real problem that a shell script does not. Skip it if you need a stable, versioned release, since the newest published tag is v0.6.0-beta.4, or if you only ever run one agent against one repository, where the dashboard adds a server, a database and a port without removing any work. Before committing, verify three things yourself: that your Node.js is at least 22.19.0, that the agent CLIs you plan to use are installed and already authenticated, and that a task's worktree merges back to main cleanly in your repository's branching model.

## FAQ

### What is Agent Tower and which AI agents does it support?

It is a self-hosted dashboard for running and tracking multiple coding agent tasks in one place. The README lists Claude Code, Gemini CLI, Cursor Agent, Codex, Kimi CLI and Pi among the supported backends, and notes that each supports custom Profile variants.

### How do I install Agent Tower?

The README recommends a global install with npm install -g agent-tower followed by running agent-tower, which serves the dashboard at http://localhost:12580. It requires Node.js 22.19.0 or newer. A Docker Compose file is also present in the repository.

### How does Agent Tower isolate tasks from each other?

Each task gets its own Git branch automatically through a worktree, so agents work in separate working directories and cannot edit the same files at the same time. The README describes a one-click merge back to main with line-by-line review in the diff viewer.

### What is the Agent Tower MCP server for?

The built-in MCP server lets agents read the task board, claim tasks and report progress directly instead of waiting for a human to assign work. If you enable the access password, MCP calls authenticate with the AGENT_TOWER_INTERNAL_TOKEN environment variable rather than browser cookies.

### Can I check Agent Tower tasks from my phone?

Yes, the README describes a one-click Cloudflare tunnel for remote access, so the dashboard opens in a phone browser. Notifications when a task reaches Review come through desktop notifications or a Lark webhook. Note that the tunnel makes the board reachable from outside your network.

### Is Agent Tower stable enough for production use?

The most recent published releases are all betas, with v0.6.0-beta.4 dated 2026-08-03. The repository is not archived and the last push was on 2026-08-11, so development is ongoing, but there is no stable release tag to point at.

## Sources

- [agent-tower/core on GitHub](https://github.com/agent-tower/core)
- [Issues](https://github.com/agent-tower/core/issues)
- [License: Apache-2.0](https://github.com/agent-tower/core/blob/main/LICENSE)
- [README](https://github.com/agent-tower/core/blob/main/README.md)
- [Releases](https://github.com/agent-tower/core/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/agent-tower-core