Chorus Agent Harness
A self-hosted AI-DLC harness for coordinating people and coding agents from idea through verified delivery.
- Source repo
- Chorus-AIDLC/Chorus
- Stars
- ★ 1.2k
- Last updated
- today
- License
- AGPL-3.0
- Primary language
- TypeScript
- FA score
- 55/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free software; you pay for model usage
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- A software team wants to turn an early product idea into reviewed requirements, a proposal, documents, and an executable task dependency graph.
- Not a fit if
- Users who want a zero-setup tool with no server or daemon to run
- Multi-user teams unwilling to operate PostgreSQL and Redis
- Source review
- 55/100 · Major gaps
What does this agent do, and when should you use it?
Chorus is a self-hosted agent harness that turns AI-driven development into a tracked workflow across ideas, proposals, documents, task DAGs, execution, and verification. Its product surface combines a Next.js web application, REST endpoints, SSE updates, and a permission-gated streaming MCP endpoint at /api/mcp. Approved proposals can materialize document and task drafts into workflow entities, while Kanban and dependency-DAG views expose progress and parallel work. The Chorus Daemon connects a local Claude Code, Codex, or Kiro CLI runtime to a Chorus server, with live transcripts and controls to inject instructions, interrupt, and resume. It can run locally with embedded PGlite or be deployed with PostgreSQL and Redis through Docker Compose or AWS CDK.
A team creates an Idea, performs structured requirements elaboration, drafts a Proposal, and produces documents plus a Task DAG before execution and verification. Actors receive permissions such as idea:write, proposal:write, task:write, or *:admin; Chorus exposes 50+ permission-gated MCP tools through /api/mcp. The Web UI and the chorus_search MCP tool use the same search backend. Running chorus daemon registers one or more local --cwd directories and wakes the chosen claude-code, codex, or kiro backend when Chorus dispatches work to that instance. The system records sessions, heartbeats, activity with session attribution, acceptance-criteria evidence, and real-time task and agent presence.
- A software team wants to turn an early product idea into reviewed requirements, a proposal, documents, and an executable task dependency graph.
- A Codex or Claude Code user needs a browser-based control plane that dispatches work to a precise local repository directory and streams the run.
- An engineering lead coordinating dependent implementation work needs both Kanban status and a DAG showing execution order and parallel paths.
- A team with review requirements wants agents to self-check acceptance criteria while administrators independently verify pass/fail evidence.
- An organization operating multiple coding agents needs resource-and-action-level permissions rather than fixed agent roles.
How do you install or deploy this agent?
For the simplest local install, run npm install -g @chorus-aidlc/chorus and then chorus. It automatically migrates embedded PGlite and opens http://localhost:8637; the documented default login is [email protected] / chorus. For local Docker deployment, run: [email protected] DEFAULT_PASSWORD=changeme docker compose -f docker-compose.local.yml up -d. Local development requires Node.js 22+ and pnpm 9+; without Docker, run cp .env.example .env, pnpm install, and pnpm dev:local.
How do you use this agent?
Sign in to the Web UI and use Settings → Setup Guide to connect an agent client, or create a cho_-prefixed API key in Settings → Agents. To attach a local runtime, run chorus login and then chorus daemon; for Codex, use chorus daemon --agent codex. To serve multiple repositories, run chorus daemon --cwd ~/work/repo-a --cwd ~/work/repo-b. Create an Idea, review its Proposal, assign resulting tasks to a connected agent instance, and monitor or verify the work from the Kanban, DAG, and session views.
What are this agent's strengths and limitations?
- It models the full AI-DLC path—idea, proposal, documents, task DAG, execution, and verification—in one product workflow.
- Its daemon addresses individual agent/host/cwd instances and provides multi-directory serving, streaming transcripts, instruction injection, interruption, and resume.
- The 5-resource by 3-action permission model supports granular custom combinations instead of requiring fixed roles.
- It has documented paths from an embedded local database to Docker Compose and AWS CDK deployment.
- Embedded PGlite is intended for local single-user use; concurrent agents or users require external PostgreSQL or the full Docker Compose stack.
- The documented native daemon backends are Claude Code, Codex, and Kiro, so other coding CLIs do not have equivalent documented daemon support.
- daemon install relies on systemd --user on Linux; macOS and Windows receive a template for manual installation.
- A production multi-replica deployment adds PostgreSQL and Redis infrastructure to operate.
How does this agent compare with similar options?
For local execution backends, Chorus directly documents Claude Code, Codex, and Kiro CLI. OpenCode support is provided through the community-maintained opencode-chorus plugin; no broader competitor comparison is documented.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Chorus Agent Harness This agent | 55 · Major gaps | CLIFree + model costs | ★ 1.2k | today | TypeScript | Codex · Claude Code |
| Delegatus Agent Workbench | 55 · Major gaps | CLI | ★ 36 | today | TypeScript | Codex · Claude Code |
| Oh My OpenAgent | 49 · Major gaps | Agent plugin / skillFree + model costs | ★ 71k | today | TypeScript | Claude Code |
| Rovai AI | 49 · Major gaps | — | ★ 251 | today | Rust | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows a fine-grained permission matrix (5x3) and permission-gated MCP tools, but the default daemon permission mode is yolo (full access) and there is no explicit user confirmation mechanism. Data flow transparency is limited, sensitive data handling (e.g., API keys) is mentioned but not deep. Dependency security is not explicitly audited, external effects (e.g., daemon executing code) are documented but not fully discussed. Rollback mechanism is not explicit. Source attribution (e.g., OpenCode plugin) is mentioned but not verified. Thus, most criteria score 1 or 2.
Self-consistency is good, README aligns with code structure, tests cover key lifecycle scenarios. Dependency availability is documented (e.g., PGlite, external PostgreSQL) but not verified. Failure messages are covered by tests (e.g., retry on close failure), but overall reliability evidence is limited.
Audience is clear (AI-Human collaboration), scenarios are diverse (local, Docker, AWS). Capability boundaries are defined by permission matrix and docs, but trigger precision (e.g., daemon yolo mode) may be too broad. Environment fit has multiple deployment options but not verified.
Information architecture is clear, with multiple docs (PRD, architecture, MCP tools). Install notes are detailed, naming is stable (version numbers). Examples and FAQ are partial, known limitations are mentioned (e.g., PGlite concurrency). License is clear (AGPL-3.0), version changelog exists. Maintenance responsibility is not explicit, but community contributions are mentioned.
Output usability has UI and MCP tools, marginal value is high (AI-DLC workflow), cost-benefit is reasonable (local run without DB). But actual effectiveness is not verified.
Claims are traceable (README corresponds to code), cross-source verification is limited (only internal tests), fact-inference separation is good (docs distinguish design intent and implementation).
- Default daemon permission mode is yolo (full access), which may be too broad; users should explicitly configure permissions.
- No explicit user confirmation mechanism found; consider adding confirmation steps for high-risk operations (e.g., code execution).
- Dependency security is not explicitly audited; recommend checking for dependency vulnerabilities.
- Rollback mechanism is not explicit; consider providing data backup and recovery options.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
Added - Agent Teams: Added owner-scoped private team templates with fixed role eligibility, per-project application, drift-aware membership management, explicit Idea handoff to a lead with a preview of what moves, and a shared avatar-based agent selector reused across Teams and task/idea assignment. (#641) …View on GitHub ↗ -
Release notes excerpt
Added - Workspace-local users: Added workspace bootstrap, local account management, unified identifier-first login, and bounded access revocation. (#624) - Shared auth rate limits: Added Redis-backed authentication throttling across instances with bounded timeouts and in-memory fallback. (#625) - User profiles: Added persistent Personas avatars with preview/save and customizable display names. (#628, #632) …View on GitHub ↗ -
Release notes excerpt
Added - Local self-hosting: Added Linux/macOS installation with Docker Compose, PostgreSQL 17, repeatable redeployment, optional LAN HTTPS, and Cloudflare Tunnel guidance. (#616) - TRAE CLI integration: Added agent setup, daemon execution, shared Codex-family plugin support, and plugin upgrades for TRAE CLI. (#621) Changed - Deployment documentation: Linked all four README translations to localized self-hosting and Cloudflare Tunnel guides. - Realtime documentation: Clarified daemon SSE authentication and pending-turn recovery. (#618) Fixed …View on GitHub ↗