Maestro: parallel AI CLI sessions, each in its own git worktree

The problem: assistants that work on one task at a time

The project describes itself as the Bloomberg Terminal for CLI agents, and the reasoning in the Why Maestro section is about serialisation.

The problem is stated plainly. AI coding assistants work on one task at a time. While Claude works on Feature A, you wait. Then you start Feature B, and you wait again. Context switching is expensive, and development velocity is bottlenecked by serial execution.

The solution is to run multiple AI sessions in parallel, and each session gets its own terminal instance with a full shell environment, its own git worktree for complete code isolation, an assigned branch for focused work, and port allocation for web development.

That last item is a small detail with a large consequence. Two agents working on the same repository at the same time will collide, not only through file conflicts but through ports, because two dev servers cannot both bind 3000. The worktree handles the files and the branch handles the git state, and the port allocation handles the third.

The four principles in the table make the intent explicit. Parallel development, launching one to six sessions at once for feature branches, bug fixes and refactoring. True isolation, each session in its own git worktree with no merge conflicts and no stepping on each other's changes. An AI-native workflow built specifically for Claude Code, Gemini CLI, OpenAI Codex and other AI assistants. And cross platform support for macOS, Windows and Linux with native performance.

The licence is MIT, the latest release is v0.2.5 from 2026-04-06, and the last push to the repository was on 2026-04-19. The version number is the thing to notice, because it says how young this is.

Worktree isolation, and how the sessions are laid out

The git worktree is the mechanism that makes the whole thing safe, so it is worth being precise about how it is used.

Worktrees are created automatically at ~/.claude-maestro/worktrees/, keyed by repository and branch, and each session works on its own branch. When a session closes, its worktree is pruned. The sidebar shows the branch assignment visually, and a Worktree badge appears in the terminal header when a session is running inside one.

The badge is a small thing that matters in practice. With six terminals open, each running an agent that may be editing files, knowing which window is backed by a worktree and which is pointed at your main checkout is the difference between a fast recovery and a lost afternoon.

The visual git graph is the other half of the visibility story. It is described as GitKraken-style commit visualisation, with a branch relationship view with coloured rails, a commit detail panel with diffs, and the point that you can see which sessions are working on which branches.

That feature is what turns six parallel agents from a pile of terminals into something you can supervise. When three agents have committed and two are still thinking, the graph tells you at a glance whether the work is converging.

The sessions themselves are laid out in a dynamic grid that goes from 1x1 to 2x3 and adapts to the session count, with iTerm2-style split panes inside each session, vertical with Cmd+D and horizontal with Cmd+Shift+D.

Status reporting through the MCP server

The status feature is the part that makes the grid more than a terminal multiplexer, and it works through the Model Context Protocol.

There is a built-in MCP server for agent status reporting. The AI sessions report their state, and the states are idle, working, needs input, finished and error, and those updates are displayed in the session grid in real time. The communication uses a tool called maestro_status.

The architecture diagram shows how it fits together. The desktop application holds the session grid, and the Rust ProcessManager underneath manages the worktrees at the path in the diagram, with the frontend in React and TypeScript with Tailwind CSS and the backend in Rust with Tauri. Off to the side, connected over the MCP protocol over stdio, is the MCP server, also in Rust, with a StatusManager inside it.

┌─────────────────────────────────────────────────────────────────┐
│                    Claude Maestro (Tauri)                       │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐          │
│  │  Session 1   │  │  Session 2   │  │  Session 3   │   ...    │
│  │ Claude Code  │  │ Gemini CLI   │  │  Terminal    │          │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘          │
│  ┌──────▼─────────────────▼─────────────────▼───────┐          │
│  │              ProcessManager (Rust)               │          │
│  │     ~/.claude-maestro/worktrees/{repo}/{branch}  │          │
│  └──────────────────────────────────────────────────┘          │
│  Frontend: React + TypeScript + Tailwind CSS                    │
│  Backend: Rust + Tauri                                          │
└─────────────────────────────────────────────────────────────────┘
                               │ MCP Protocol (stdio)
                               ▼
┌─────────────────────────────────────────────────────────────────┐
│                    MCP Server (Rust)                            │
│                         StatusManager                           │
└─────────────────────────────────────────────────────────────────┘

Two observations follow. The status channel is stdio, which means the same MCP server that an agent uses for tools can carry the state back, and the server is a separate Rust binary in the workspace rather than a module inside the app, so the agent process can talk to it without going through the desktop process.

The repository contains a .mcp.json.example at the root, which is the configuration an agent needs to find the server, and the server lives in its own directory, maestro-mcp-server, alongside the Tauri application in src-tauri.

The state model is deliberately small. Idle, working, needs input, finished and error, and the needs input state is the important one, because that is the case where an agent is blocked on a question and a human has to answer it.

Multi-AI support, quick actions and the plugin marketplace

Maestro is not tied to one assistant. The per-session mode selection offers Claude Code, Gemini CLI, OpenAI Codex and a plain terminal with no AI at all, and the plain terminal option is a useful one, because it means the grid can hold a log tail or a build watcher next to an agent.

Quick actions are custom buttons per session, and the built-in ones are Run App and Commit and Push, alongside custom prompts. The action is executed via the AI assistant, so the button is a prompt you do not have to type.

The plugin marketplace is the most extensible part. You browse and install plugins from marketplace sources, and the plugin types are Skills, Commands and MCP servers. There is per-session plugin configuration, and automatic symlink management for commands and skills, which is the mechanism that makes a skill available inside a session's working directory rather than only in the application.

The appearance settings are the smaller half of the interface work. Light and dark themes, terminal font customisation with support for system-installed fonts, Nerd Fonts for icons and glyphs, and custom fonts, plus an adjustable text size for the terminal display. Nerd Fonts support matters more than it sounds, because agent output is full of glyphs and box drawing characters, and a font without them renders a wall of replacement characters.

The keyboard shortcuts are a full terminal emulator set, including split panes, jumping to a terminal by number, cycling between terminals, clearing the scrollback, copy with SIGINT when there is no selection, zoom, newline without executing, and jumping to the line start and end. The README notes that Cmd is Ctrl on Windows and Linux, which is a small detail that decides whether the app feels native on Linux.

The build stack and the repository layout

The application is a Tauri app, and the two halves of it are visible in the repository.

The front end is React 18 with TypeScript 5.5, Tailwind CSS 3.4 and Vite, with the state in zustand, icons from lucide-react, markdown rendering through react-markdown with the raw and gfm remark plugins, and drag and drop built on dnd-kit. The terminal itself is xterm.js with a set of addons, and the addon list is the interesting part: canvas, fit, unicode11, web-links and webgl, which is what you need for a terminal that is fast and handles wide characters and links.

The Tauri side is a Rust workspace with two members, src-tauri and maestro-mcp-server, and the shared dependency set is small, with tokio for the async runtime, serde for serialisation, reqwest for HTTP, thiserror for errors and chrono for time. The release profile is tuned for a small binary, with panic set to abort, link time optimisation on, opt-level s and symbols stripped.

The Tauri plugins tell you what the app does outside its own window: dialog for file and folder pickers, opener for opening URLs, store for persisted settings, updater for self updating, and a macOS permissions plugin.

There is also a cli directory, which suggests the project is moving toward having a command line counterpart to the desktop application, and a website directory, a docs directory and an ARCHITECTURE-OVERVIEW.md at the root, next to an AGENTS.md.

The front end package manifest names the package maestro-linux, which is a leftover from the platform it started on, and it is marked private because the desktop application is not published to npm.

The limits, and the state of the project

Three things to weigh before committing to it.

The first is the git assumption. The isolation model is git worktrees, so a project that is not under version control has no isolation, and a repository with uncommitted changes on the main checkout makes worktree creation awkward. The tool solves the case of six agents in one repository, and that is the case it is designed for, but it does not extend to a directory of loose files.

The second is that the parallelism is local. Sessions are terminals on your machine, running agents that need your API credentials, your toolchain and your machine's resources. Six agents editing the same project will use six times the context window and a good deal of memory, and the README mentions port allocation for web development, which is the visible symptom of that contention.

The third is the state of the project. The version is 0.2.5, released in April 2026, with the previous two in March and February of the same year, and the last push was on 2026-04-19. There is a Discord server and an X account in the README header, which is where its community gathers, but a 0.2 version with three releases in a few months is a tool that is still finding its shape.

The alternative is the one you are probably already using. A terminal multiplexer with several panes, with the worktrees created by hand and the status read from the scrollback, gives you the parallelism and the isolation with none of the interface. What Maestro adds is the status channel, the visual git graph, the plugin marketplace and the fact that a session knows which worktree it is in. Whether that is worth an application rather than a multiplexer depends on how many sessions you run and how much you need to know about them.

Editorial conclusion

Adopt Maestro if you regularly have two or more coding tasks in flight at once and the serial waiting is what hurts, because the worktree isolation and the shared status view remove the two reasons people avoid parallel agents. Do not adopt it for a single quick edit or for a project that is not under version control, since the isolation model is built on git worktrees. Before you start, check that the agents you use can be pointed at a specific working directory, and set up a status reporting hook, because the grid is only useful when the sessions report their state back through the MCP server.

Frequently asked questions

Official sources

1. Issues
2. its-maestro-baby/maestro on GitHub
3. License: MIT
4. README
5. Releases