marver

A TUI workspace for AI agent sessions — tmux orchestration, git worktree management, and repo control in one place.

Start a task, describe it, and marver opens a tmux session with an agent already working in its own worktree. Inspired by k9s, cmux, and Warp.

Status: early development. Every subsystem exists and the loop closes — describe a task, an agent runs it, review the diff, commit — but nothing has been used in anger yet. The published crate is still a name reservation.

marver                  open the interface, starting a daemon if none is running
marver status           report whether a daemon is running, and what it holds
marver restart          stop the running daemon and start this version
marver upgrade          install the newest published marver
marver cleanup          remove the worktrees left by finished tasks
marver daemon           run the scheduler and hook receiver in the foreground
marver scan [root]      list the git repos it can see
marver --version        print the version (-v, -V)
marver --help           print usage (-h)

Every command takes --data-dir for where the database, socket, and log live, --scan-root for the directory searched for repos, and --cap for how many agents may run at once. The interface and the daemon find each other through those paths, so a --data-dir given to one must be given to the other.

Just run marver. If no daemon is listening it starts one, detached, the way a tmux client starts the server it needs — and that daemon keeps running after you close the interface. It owns the queue: it creates a worktree per repo, opens a tmux session, starts Claude Code with hooks pointing back at itself, and notifies you when a task finishes or gets stuck. Its output goes to daemon.log beside the database.

Run marver daemon yourself to watch it in the foreground or to put it under a supervisor. Starting a second one is refused rather than allowed to displace the first.

Keys

Two rules hold everywhere:

• esc leaves the screen you are on. On the task list there is nothing underneath, so leaving is quitting.
• x discards. A task on the list, a diff in review. It is never c, which means commit.

The footer of every screen shows its own keys; the whole set is below.

Task list

New task

↵ inserts a newline in the prompt rather than queueing. A prompt is what the agent is told to do and is routinely several paragraphs, so the only way to type a newline is worth more there than the shortcut; ctrl-s is how you submit without leaving the field.

Agent terminal

Every key goes to the agent, which is the point of the screen, so leaving takes a chord.

esc is not a way out here: it is how Claude is interrupted, and the agent needs it. ctrl-esc is the binding this screen would like to have, but a terminal can only report it under the kitty keyboard protocol, which marver does not enable — turning it on changes how every key is reported, and this screen forwards every key through a hand-built encoding table. In Terminal.app and iTerm2 it will not arrive at all. ctrl-q is the one that always works, in every terminal, because raw mode clears IXON and so nothing upstream takes it for flow control.

Review

Rejecting types your instructions into the agent's live session and returns the task to running. Instructions containing control characters are refused: send-keys -l stops tmux reading them, but the agent still sees the bytes, and \r would submit half a sentence while \x03 would interrupt the very turn being asked for.

Upgrading

marver upgrade              # cargo install marver --force
marver upgrade --restart    # and swap the daemon too

marver upgrade drives cargo, because that is how the crate is distributed. If you installed marver some other way it says so rather than guessing, and you upgrade it however you installed it.

Installing a new marver does not replace a daemon that is already running: it keeps executing the old binary, and since it still holds the socket, nothing starts a replacement. This is deliberate — that daemon is supervising live agents, and restarting it underneath them would fail every task it was watching.

marver status reports both versions and says so when they differ, and marver restart does the swap when you are ready:

marver restart

It refuses while any task is running or blocked, because that is the one thing a restart can cost. marver hook always exits 0 — marver being down must never interfere with an agent — so a hook arriving while nothing is listening is simply lost, and the task is left running behind an agent that has already finished. Wait for those tasks to reach awaiting-review, or accept it with marver restart --force.

Nothing restarts the daemon on your behalf. It is supervising live agents, and the moment to interrupt that belongs to whoever knows what they are in the middle of. Agents already running in tmux survive a restart either way.

Cleaning up

A task keeps its worktrees after it ends. Cancelling kills the agent's session and stops there, deliberately — git worktree remove --force discards uncommitted changes, and losing unreviewed work as a side effect of pressing cancel would be worse than a directory left on disk.

marver cleanup is where that gets undone, as a separate act:

marver cleanup              remove the worktrees of finished tasks
marver cleanup --dry-run    list what would go, change nothing
marver cleanup --branches   delete their branches too, where merged
marver cleanup --force      remove work that was never committed

Only committed, failed, and cancelled tasks are offered. Anything else is in use: a running agent is working in its worktree, and an awaiting-review task is what the review screen reads its diff from.

A worktree still holding changes is listed and left alone, because "finished" is a state marver recorded and not a promise about what is in the directory. It says which ones and what to type if you meant it.

Branches are kept by default. marver commits onto marver/<id>-<slug> and merges it nowhere, so for a committed task that branch holds the only copy of the work. --branches deletes with git branch -d, which refuses any branch whose commits exist nowhere else — so the branch of a task that did nothing is tidied away and the branch of one that did something survives, and cleanup says how many it kept. --force --branches deletes those too.

Nothing runs this on a schedule.

See ARCHITECTURE.md for the design and the reasoning behind it.

Known gaps

Written down because finding them yourself is worse.

The whole loop has never been run end to end. Every part is tested — 380-odd tests, several driving real tmux servers, real git repos, and the real binary — and the library has been exercised from outside. But describe a task → agent works → review the diff → commit has not been completed in one pass by a person. Expect to be the first.

Nothing reclaims a worktree unless you ask. marver cleanup exists — see Cleaning up — but there is no key for it inside the interface and nothing runs it on a schedule, so a marver left alone accumulates directories and branches until you type the command.

Task ids name tmux sessions, and a tmux server is machine-wide. Two data directories that each hold a task 1 both want the session marver-1, so the second one to launch is refused with "session already exists" and its task fails. Cleanup no longer kills across that boundary — it checks the session's working directory first — but launching is still first-come-first-served. One data directory per machine is the supported arrangement.

A hook that arrives while the daemon is down is lost. marver hook always exits 0, deliberately, so marver being unavailable never interferes with an agent — which means a Stop landing in the gap is simply gone, and the task is left running behind an agent that has already finished. Startup reconciliation does not rescue it, because it only fails tasks whose tmux session has died and that session is still there. This is why marver restart refuses while anything is running or blocked.

An old daemon keeps serving after an upgrade. By design — it is supervising live agents. marver status warns and marver restart swaps it, but nothing forces the issue, and a future schema migration could have a new interface migrating a database an old daemon still has open.

ctrl-esc does not arrive in most terminals. See Keys. ctrl-q always does.

A multi-repo commit is not atomic. One message becomes one commit per repo, and if the second fails the first still stands. The task then stays in awaiting-review with part of its work committed.

Status messages last 500ms, errors included, which is not long to read one.

Invalid option values are ignored silently. Unknown options are refused, but --cap notanumber falls back to the default without saying so.

list_events cannot reach events with no task. Scans log against no task id, and the only query takes one — so those rows are written and never read back.

Two things on the list are not built at all, both because they need a decision first rather than an implementation:

• Context, cost, and model per task. None of it is in the hook payloads. It would have to come from parsing Claude Code's transcript JSONL, an undocumented internal format that can change underneath us.
• Todos, and pausing a task from outside it. paused is not in the state machine, and what it should mean — stop the agent mid-turn, or only hold the queue slot — decides the whole shape of it.

Requirements

tmux 3.x, git, and Claude Code.

Name

A marver is the polished steel table a glassblower rolls hot glass across — shaping the piece and controlling its temperature between trips to the furnace. It is the surface where work takes form.

License

MIT OR Apache-2.0, at your option.