Chorus-AIDLC/Chorus: a harness that puts your coding agents behind a human verification gate

The gap Chorus targets: agents that write code but leave no verifiable trail

A coding agent harnesses a model to write code. Chorus positions itself one level up, as the harness for a whole team of those agents plus the humans reviewing them. The problem it names is coordination, not generation: session lifecycle, task state, sub-agent orchestration, observability and failure recovery. Those are the parts that break when more than one agent touches the same project and nobody can say which task is in flight, who approved it, or what happens when a run dies halfway.

It is aimed at teams already running Claude Code, Codex, Kiro CLI, dsh, OpenCode, OpenClaw or Pi and hitting the ceiling of a single interactive session. The design assumption is that a human stays in the loop at defined checkpoints rather than reviewing a diff at the end. The README states the core philosophy as Reversed Conversation: AI proposes, humans verify.

The permission model is the concrete expression of that. The AI-DLC workflow diagram in the README labels each stage with the permission an actor needs: idea:write and elaborate for proposals, proposal:write for drafts, task:write and reports for execution, and *:admin for verification and closing. The README states there are no fixed roles and that any combination of the 5 x 3 permission matrix works, granted to a human, an agent, or both. That is a more unusual claim than it first looks: most agent tooling hardcodes who may do what, and Chorus makes the split a configuration decision.

How the AI-DLC pipeline actually moves: idea to proposal to task DAG to verification

The README lays out a linear pipeline: Idea, Proposal, Document plus Task DAG, Execute, Verify, Done. A human creates the idea. An agent with idea:write elaborates it, then an agent with proposal:write drafts a proposal. That proposal is where the structure appears: the README describes a PM Agent analyzing requirements and generating a PRD plus a task DAG. The DAG is the unit of execution, not a flat task list, so dependencies between tasks are represented rather than implied.

Execution is where the daemon enters. Running chorus daemon turns a local machine into an agent runtime that picks up assigned tasks. The README describes assigning an idea to a directory on a remote agent, then opening the conversation and watching the local Claude Code pick up the work in real time, without a terminal or a manual resume. Since v0.16.1, one chorus daemon can serve multiple independent agents at once, each with its own key, working directories, backend and permissions, configured through an agents[] array. Agents can hand work to each other by @-mention, and each wake lands in that agent's own project directory.

Observability is split across three views the README names: a Project Resource Graph that lays Ideas, Proposals, Documents and Tasks out as one connected tree with live status, a Kanban board where cards move between To Do, In Progress and To Verify, and presence indicators marking whatever is currently being touched. The Graph is the structural view; the Kanban is the flow view. Neither replaces the other, which is why both exist. Reference artifacts, added in v0.14.0, let you attach docs, repos, issues and articles to any idea, proposal or task, readable inline and over MCP.

Installing Chorus from npm and getting to a first verified task

The README gives a two-command quick start and states there is no database, no Docker and no config files required for it. The first command installs the CLI globally at a pinned version. The second starts the server, which brings up an embedded PostgreSQL (PGlite), runs migrations, and serves the app.

npm install -g @chorus-aidlc/[email protected]
chorus

After chorus starts, the app is reachable at http://localhost:8637. The default login in the README is [email protected] with the password chorus. Change that before the instance is reachable from anywhere but your own machine.

The next step is connecting an agent. The README says the fastest path is the in-app wizard at Settings, Setup Guide, which creates the API key and prints the exact commands for your client. API keys are also created manually under Settings, Agents, Create API Key. Supported clients listed in the README are Claude Code, Codex, Kiro, dsh, OpenCode, OpenClaw, Pi, and any MCP-compatible agent.

For the daemon path, the README points at chorus daemon for picking up assigned tasks. A minimal Docker deployment exists too, and the compose file exposes the app on port 8637, PostgreSQL on 5433 and Redis on 6379.

docker compose --profile full up -d

The compose file sets DATABASE_URL to postgresql://chorus:chorus@db:5432/chorus and REDIS_URL to redis://default:chorus-redis@redis:6379. Note the mismatch worth planning around: inside the compose network the app talks to db on 5432, while the host mapping is 5433, so a client running on your host must use 5433.

Where Chorus gets in the way: embedded PGlite, single-instance SSE, and the daemon you must run yourself

The embedded PGlite default is a genuine convenience and a genuine ceiling. The README itself says that if you are running multiple agents or deploying to production, you should use an external PostgreSQL, Docker or AWS instead. So the zero-config path is a local evaluation path, not a deployment path.

The second constraint is event propagation. The .env.example states that Redis is optional and falls back to an in-memory EventBus when unset, and that it is required for multi-instance SSE event propagation. Read that together with the live presence indicators and the Kanban board: with a single instance and no Redis, presence and status updates work because everything shares one process. Add a second instance and the in-memory bus no longer carries events between them. If you plan to scale horizontally, Redis is not optional regardless of what the example file calls it.

Third, the daemon is a process you operate. Nothing in the README suggests Chorus runs your agents for you in the cloud. You run chorus daemon on a machine that has the agent CLI installed and the project checked out, and you bind agents to hosts and working directories. v0.15.0 added project-level agent working directories so each user can bind every agent in a project to a host and cwd and browse only daemon-approved roots. That is a security boundary, and it also means the machine running the daemon needs the right credentials and the right checkout. Get that wrong and the wake lands in the wrong directory.

Chorus is the wrong tool if you want a single agent in a single terminal with no review gate. It is also a poor fit if your workflow has no human available to verify, because the pipeline is built around that checkpoint rather than treating it as optional.

Chorus versus a plain agent CLI or a generic ticket tracker

The honest comparison is two-sided, because Chorus sits between two categories.

Against a plain coding agent CLI, the difference is state and gating. A CLI session holds context in a terminal and ends when you close it. Chorus externalizes that state into tasks, a DAG and a permission matrix, and it survives a crash, with crash-resume listed among the v0.14.0 changes. The trade-off is that you now run a server, a database and a daemon to get work done that a single CLI session could have finished. For a one-file change, that is pure overhead.

Against a generic ticket tracker, the difference is that the tracker has no execution layer. Chorus binds a task to a directory on a specific host and wakes an agent there. A tracker records that something should happen; Chorus is the thing that makes it happen and reports back. The cost is that the tracker does not care which agent backend you use, while Chorus maintains per-client integration paths, currently Claude Code, Codex, Kiro, dsh, OpenCode, OpenClaw and Pi. Each new backend is a maintained surface, and the release notes show that surface moving: Kiro arrived in v0.14.1, dsh in v0.16.4, and v0.17.2 made Pi a published, wakeable agent.

One design choice worth flagging: the README describes the permission model as having no fixed roles. That is flexible, and it also means there is no default that protects you from a misconfiguration. A 5 x 3 matrix that any combination can fill is a matrix someone can fill wrongly.

Licence and upgrade cost under AGPL-3.0

Chorus is licensed AGPL-3.0, per the package manifest and the LICENSE.txt file at the repository root. The practical consequence, stated plainly and not as legal advice: if you modify Chorus and let users interact with it over a network, the AGPL's network clause is the part your legal team will want to read. Running it unmodified as an internal tool is a different situation from forking it into a hosted product. That question belongs with counsel, not with a README.

The upgrade cadence is visible in the release history. v0.17.1 landed on 2026-09-01, v0.17.2 on 2026-09-04, v0.17.3 on 2026-09-07, and the last push to the default branch was on 2026-09-10. That is a fast-moving project: three patch releases inside a week. The README's own quick start pins a version (0.17.1) while the package manifest on the default branch reads 0.18.0, so the documented install command and the repository head are not the same version. Pin deliberately and read CHANGELOG.md before jumping, because the release notes show schema-adjacent and backend changes landing in minor versions, not just patches. There is a Prisma migrations directory in the repository, and the Dockerfile copies prisma and prisma.config.ts into the production image for migrations, so a version jump can involve a migration step.

Editorial conclusion

Adopt Chorus if you already run coding agents and the missing piece is state, permissions and a verification gate between proposal and delivery. Skip it if you want a single-agent autocomplete loop or you cannot accept AGPL-3.0. Before committing, verify the daemon path yourself: run chorus daemon on one machine, create an API key under Settings, Agents, Create API Key, and confirm that an assigned task actually wakes an agent in the working directory you bound to it.

Frequently asked questions

Official sources

1. Chorus-AIDLC/Chorus on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases