An agent-ready development environment for a change. Corvi is a local dashboard for a change: the work spanning one or more repositories, plus the worktrees, pull requests, tickets and builds around it — and the terminals where you and your agents do the work. Everything is read live from the vendors' own CLIs — and, for Jira, from its REST API — so Corvi owns no copy of their data. The one secret it can hold is a Jira token you choose to type into the settings page: kept in your own config file, masked in the interface, and readable from the file only by you.
A change begins as an idea — a title, a plan, and a conversation with an agent — and becomes
work when you start it: Corvi cuts a branch and worktree per repository and moves the ticket. Its
state lives in one directory per change (~/corvi/changes/<id>/), and the archive keeps the
finished ones.
Corvi runs on macOS and Linux. It needs git, gh and az for the integrations, and
Bun plus Node 24+ to build the page. The terminal host Corvi starts needs Node,
which the application already bundles.
git clone https://github.com/wwbakker/corvi.git
cd corvi
bun install
bun run app:installapp:install puts a real window on your machine — ~/Applications/Corvi.app on macOS; a desktop
entry, an icon and a corvi launcher on Linux — that starts its own server on a fresh port and
stops it when the window closes. Quitting it never touches a server you started yourself.
To run it from the checkout instead:
bun run dev # http://127.0.0.1:4000There is no account and no cloud: Corvi is your machine, your CLIs and your credentials. The
first run has the settings page at /settings for the paths and integrations, and
the manual has the details.
Corvi can also run across more than one machine. An off-by-default external listener, published
on your tailnet with tailscale serve and authenticated with paired-device tokens, lets another
client reach this server; and a workspace can be remote, so one Corvi shows its own work and
another machine's side by side. See remote access and
workspaces.
The terminals show what an agent is doing — working or waiting, its session name, its last answer — when pi or opencode runs a small bundled reporter inside it. Install them into the agents (one symlink per agent; they install nothing into Corvi) from the checkout:
bun run extension:install:pi # into pi's extensions directory
bun run extension:install:opencode # into opencode's plugin directoryEach has a matching bun run extension:uninstall:<agent>. pi picks a changed reporter up with
/reload or a new session; opencode takes a restart. The terminals manual
documents the protocol the reporters speak.
- Installing and running — requirements, the app, Linux, updating, uninstalling.
- Configuration — the config file, environment variables, settings, workspaces.
- Changes — ideas, repositories, worktrees, states, completing.
- The interface and terminals.
- Integrations — Jira, Azure DevOps, GitHub, review.
- Architecture, API design, and the other contributor guides.
The architecture guides define the accepted layout, and the implementation matches it: the
application is apps/server, apps/web and apps/desktop, shared capabilities are packages/*,
provider integrations are integrations/*, and bun run boundaries enforces the graph. There is
no third-party extension platform.
bun run dev # the server, with the page built first
bun run dev:web # watch the page and rebuild as you edit
bun run test # the full suite with isolated data and owned-resource cleanup
bun run typecheck && bun run lintThe page is built ahead of time: bun run build:web writes apps/web/dist, and the server
serves it (bun run dev builds first).
CONTRIBUTING.md and AGENTS.md hold the working rules;
docs/ explains how the documentation is split.
MIT — see LICENSE.