CLI reference

One binary serves every role. vincent with no arguments opens the TUI; the subcommands are thin clients over the same localhost API.

• Exit codes
• Global behavior
• vincent
• vincent version
• vincent doctor
• vincent daemon
• vincent service
• vincent project
• vincent task
• vincent workflow
• vincent gc

Exit codes

vincent daemon status overloads them usefully: 0 healthy, 1 not running, 2 running but unresponsive. vincent doctor follows the same shape: 0 healthy, 1 problems found, 2 no daemon answered.

Global behavior

• --json is available on every subcommand that prints anything. Empty results render as [], never null. Advisory warnings go to stderr so stdout stays pipeable.
• No subcommand auto-starts a daemon. Only the TUI does. A subcommand that cannot reach one exits 2 with a pointer to vincent daemon start — except vincent doctor, which prints its whole report first, because the daemon being down is one of the things it is there to tell you.
• Clients discover the daemon by reading {data_dir}/daemon.json and then health-probing it, so a stale file from an unclean shutdown produces the same “no daemon” answer rather than a transport error later.
• --help works at every level.

vincent

vincent

Opens the TUI, starting a daemon in the background if none is reachable.

vincent version

vincent version

Prints one line: version, commit and build date. A binary built with the plain go build toolchain falls back to debug.ReadBuildInfo, so the fields are never empty.

vincent doctor

vincent doctor [--json] [--fix [--force]]

One report answering “why is nothing running?”. Seven groups:

Exit 0 when everything checked is healthy, 1 when problems were found (they are listed under PROBLEMS), 2 when no daemon answered.

Unhealthy is a closed set: config.yaml exists and does not parse, the daemon is alive but not answering, integrity_check is not ok, the database is at a schema version newer than this binary understands, orphaned worktrees are present, or a task is unreconciled — queued (or finished) while one of its step runs is still marked running, which means crash recovery could not close the previous attempt and admission will not run that task until it does (Troubleshooting). A missing or logged-out agent CLI is reported and deliberately does not set the exit code — most machines have one of three adapters installed, and a doctor that exits 1 almost everywhere is no use in a script. Neither do task counts: twelve blocked tasks is information, not a defect.

A permissions row names a config path whose mode grants group or other access, the mode it should have, and the exact chmod. It is a warning: the daemon tightens both paths on every start, so a row means no daemon has started on this config or something widened it since — not a reason to exit 1. There are no such rows on Windows, where modes carry no access control.

The database rows measure and change nothing. total on disk is the file plus its WAL and SHM sidecars, which is the honest figure — the store runs in WAL mode, so the file alone understates the footprint between checkpoints. rows lists every table in the schema, biggest first, so whichever one is growing is the first thing you read; the set comes from the database itself, so a table a later version adds appears without this command being taught about it. workflow snapshots totals the per-task workflow YAML, the second growth driver beside events. oldest event is how far back history reaches, which is what makes a row count extrapolable. There is no threshold, no warning and no retention window: rows are kept indefinitely, and --fix is the only thing that touches the file at all.

Without a daemon the report is still printed in full — paths, whether the config parses, adapter detection, the log tail, disk free and the worktree count — and the database and task rows read unknown — daemon not running. They are not read from a second process: only the daemon opens the database. The byte figures, the row counts and the span are unknown together, for that reason and no other.

--json emits the whole report for scripting and for pasting into a bug report.

vincent doctor --fix

Reclaims orphaned directories and compacts the database. Both are writes, so the daemon performs them: --fix without a running daemon is refused, and the report is printed anyway.

• An orphan is an entry under a data root that no task row claims — the residue of a forced project delete or of a removal that failed partway. This is the same scan and the same removal vincent gc runs, so the two commands cannot disagree; gc is the one to reach for when reclaiming is the whole point. A non-directory there is reported and never removed.
• A worktree with local changes (untracked files included) is skipped unless you add --force. An orphan whose dirty check cannot run at all — the project repo is gone, so the directory is just files — counts as dirty for this purpose: nothing is deleted on the strength of a check that did not happen.
• vincent does not run git worktree prune in your repositories. A stale registration can therefore survive there; the report says so and names the command.
• Compaction is a real VACUUM, and it is skipped while any task is running or awaiting input — the rewrite takes an exclusive lock, and stalling a step mid-write is worse than declining. The skip is reported with its reason.

vincent doctor --json | jq '.problems[]'
vincent doctor --fix --force

vincent daemon

vincent daemon [--config-dir DIR] [--data-dir DIR] [--hide-console]

Runs the daemon in the foreground, logging to stderr as well as the log file. This is what a service manager invokes.

vincent daemon start

vincent daemon start

Starts the daemon detached in the background and returns once it is answering.

vincent daemon stop

vincent daemon stop [--force]

Graceful shutdown: admission stops, a daemon.shutting_down event is emitted, running processes get 15 seconds to exit before being killed, and their step runs are marked interrupted — the same resume path as a crash, so nothing is lost.

--force kills the process if the graceful stop fails.

vincent daemon status

vincent daemon status [--json]

Reports whether the daemon is running, its identity, and which agent CLIs it resolved. Exit 0 healthy, 1 not running, 2 unresponsive.

vincent daemon backup

vincent daemon backup <path.tar.gz> [--json]

Writes one .tar.gz holding the database, every transcript, config.yaml and the global workflows. The database copy is taken with SQLite’s own VACUUM INTO, so it is consistent even while tasks are running — unlike copying vincent.db, which under WAL is missing whatever has not been checkpointed.

Needs a running daemon, and exits 2 without one: only the daemon opens the database, the same rule doctor --fix follows. The destination must be a path that does not exist yet; vincent never overwrites a backup.

Transcripts are included in full, so the archive is as large as your history is. The command prints the bytes it wrote:

wrote /home/you/vincent-2026-08-25.tar.gz (1.4GB: database 8.2MB, transcripts 1.4GB)

What the archive does not carry, and why, is in Files.

vincent daemon restore

vincent daemon restore <path.tar.gz> [--force] [--json]

Unpacks an archive into the config and data directories in effect. This is the one command that touches the data directory directly rather than through the API — the daemon it would overwrite has to be down for the restore to be safe.

Refused, exit 1, when:

--force moves each of those aside as <name>.bak-<timestamp> and restores over the gap. Nothing is deleted on any path, and the command prints where everything went.

Worktrees are not in a backup and are not restored; the branches they held are in your repositories. A fresh API token is minted at next start, so every client re-reads it.

vincent service

Registers the daemon with the OS so it starts at login. Always as the invoking user; no elevation needed on any platform. See Running at login.

vincent service install      # register and start; idempotent
vincent service uninstall    # stop and remove
vincent service status       # installed? running?

Backends: a launchd user agent (macOS), a systemd user unit (Linux), a Scheduled Task (Windows).

vincent project

vincent project add

vincent project add <path> [--name NAME] [--default-branch BRANCH]
                           [--workflow NAME] [--max-parallel N] [--json]

Registers a local git repository.

Registration is refused if no default branch can be determined (a detached or unborn HEAD); pass --default-branch explicitly.

vincent project ls

vincent project ls [--json]

Lists registered projects with their ids, paths and defaults.

vincent task

vincent task add

vincent task add --project ID --title TITLE
                 [--workflow NAME] [--description TEXT] [--base-branch BRANCH]
                 [--branch NAME] [--priority N] [--agent NAME] [--model M]
                 [--effort E] [--field NAME=VALUE]... [--json]

Creates a task. It is queued immediately — there is no draft state.

Declared workflow fields are validated by the daemon, while additional names remain valid and are recorded on the same open field map:

vincent task add --project 1 --workflow release --title "Release 2.0" \
  --field ticket=OPS-42 --field owner=ana

Model and effort only inherit from a level whose agent matches, so switching agent without setting them resets them to the new adapter’s default rather than leaking a claude alias onto a codex step.

A value no catalog knows is accepted with a warning on stderr (the CLI is the final authority); a value belonging to a different adapter’s catalog is rejected with exit 1.

vincent task ls

vincent task ls [--project ID] [--state STATE] [--archived] [--limit N] [--json]
                [--include-children] [--parent ID]

Lists tasks. Archived tasks are excluded unless --archived is passed. The table carries ID, STATE, PROJECT, WORKFLOW, STEP (the k/n cursor), BRANCH and TITLE; --json adds the rest of the board fields, including the cost and token totals rolled up across every attempt.

BRANCH is the task’s own branch, which is how you find what vincent made once branch_template has moved branch names off the vincent/ prefix a glob would look for.

Fan-out lanes are excluded too: the list is the work you asked for, and a 64-task tree would bury it. --parent ID lists one fan-out task’s lanes in merge order, and --include-children lists everything flat.

Valid states: queued, running, awaiting_gate, awaiting_input, awaiting_children, blocked, paused, done, aborted, archived — see Task lifecycle.

vincent task show

vincent task show <id> [--json]

Shows one task with its step runs, the actions valid right now, and any pending input request.

vincent task cancel

vincent task cancel <id> [--json]

Aborts the task, killing any running process (graceful termination, then a kill after 10 seconds). Valid from queued, running, awaiting_input, awaiting_gate, blocked and paused; anything else exits 1 with the state it actually found.

vincent task follow-up

vincent task follow-up <id> (--prompt TEXT | --run CMD | --workflow NAME)
                            [--agent NAME] [--model M] [--effort E] [--json]

Runs one more piece of work in a finished task’s existing worktree and branch, before it is archived — recorded in that task’s own ledger, with a step run, a transcript and cost accounting. Valid from done and aborted only; anything else exits 1 with the state it actually found.

Exactly one of the three run flags is required, and they are mutually exclusive:

--agent, --model and --effort apply to this run and outrank the task’s own overrides and the workflow’s defaults:; a value no catalog recognizes is a warning on stderr, not a failure.

The command returns as soon as the run is queued — the scheduler admits it like anything else. When it ends the task returns to the state it came from: done to done, aborted to aborted, whatever the run did. A follow-up never changes a task’s verdict, and it is repeatable.

This is the one human action with a command line, and it has one because batches want one:

for id in 41 42 43 44 45 46; do
  vincent task follow-up "$id" --run 'git rebase origin/main'
done

The remaining human actions — approve, reject, retry, repair, skip, pause, resume, answer, archive — are TUI and API operations; see the API reference.

vincent workflow

Aliased as vincent wf.

vincent workflow ls

vincent workflow ls [--project ID] [--json]

Lists the merged registry — built-in plus global, with scope badges and validation status. Add --project to include that repository’s .vincent/workflows/, with shadowing applied; without it you see global scope only.

The PLATFORMS column is the workflow’s platform restriction; status unsupported means this host is not in it, so the workflow is listed but cannot back a task here.

Needs a daemon: only the daemon knows which projects exist.

vincent workflow validate

vincent workflow validate <file> [--json]

Validates a workflow file. This is the one command that needs no daemon — no network, no agent CLI installed — which makes it usable from a pre-commit hook or a CI job. (vincent daemon restore also runs without one, but it refuses to run while a daemon is up rather than merely tolerating its absence.)

Exit 0 valid, 1 invalid. Warnings (a model in no catalog) print but do not fail the command.

vincent gc

vincent gc [--dry-run] [--force] [--json]

Reclaims directories under the data dir that no task claims. Two things produce one: deleting a project whose worktree removal failed (the task rows go regardless, so nothing can name the directory again), and a crash between creating a worktree and recording its path.

KIND       PATH                                  SIZE     STATUS
worktree   ~/.local/share/vincent/worktrees/41   12.4MB   removed
worktree   ~/.local/share/vincent/worktrees/58   3.1MB    skipped: dirty_unknown
transcript ~/.local/share/vincent/transcripts/41 88.2KB   removed
reclaimed 2 of 3 orphan(s), 12.5MB freed

Skip reasons. A worktree with local changes — untracked files included, the same rule git worktree remove uses — is worktree_dirty. One whose repository has been deleted, or in which git worktree prune has run, is dirty_unknown: git status fails there, so nobody can say what is inside. That is the common case for a real orphan, so expect a plain vincent gc to skip most of what it lists and to need --force once you have looked at the paths. A file sitting directly under a data root is not_a_directory and is never removed.

What it never does. It never deletes a branch, never touches a directory any task row claims, never removes anything outside {data_dir}/worktrees and {data_dir}/transcripts, and never modifies a task row. A task pointing at a worktree that is gone is reported at the end of the output and left alone — recover that one with a retry, which recreates the worktree from the branch.

An entry that could not be removed (a file locked by another process, a permissions problem) is reported on its own line and the run continues; the reclaimed totals count only what actually went.

The daemon reports the same orphans at startup — one warning per directory in daemon.log, plus a count on GET /v1/info and in the TUI daemon view — but it never deletes anything by itself.

See also

• Scripting vincent — patterns built on these commands.
• HTTP API — what every subcommand calls.
• Configuration.