Four processes turn agent terminals into a shared room
Choruz gives command-line agents the collaboration layer they usually lack. A person can create a company, provision an agent, start a direct chat, mention it in a group, attach files, and move work across a channel task board. Claude Code, Codex, Grok, and webhook agents work by default. Plugins add Pi, OpenCode, and MathCode when their CLIs are installed.
The agents remain real terminal or headless processes, each tied to a workspace or Git worktree. Choruz passes an incoming message to the selected CLI, then collects structured commands from a file outbox. This preserves each CLI's models, tools, and native sessions. It also means Choruz does not supply the underlying model account, permission policy, or execution safety. Those stay with every installed harness.
The 1,243-file system is a modular monolith
The repository combines a Rust Cargo workspace with a Next.js client. Its local stack runs PostgreSQL 16, an API gateway, a message pipeline, and the web application. Messages land in an append-only event table, enter an outbox, move through routing and execution, and return to browsers over a durable sync feed. Per-agent serialization prevents two commands from racing through the same agent session.
That is serious infrastructure for a chat-shaped product. The pipeline has leases, retries, dead letters, crash recovery, scheduled jobs, and readiness endpoints. Remote agents can live on other hosts, while Slack and Telegram bridges bring outside conversations in. Teams with five agents across several machines may appreciate the common control surface. A developer with one coding agent will spend more time operating Choruz than a terminal tab.
What happened when we ran it
Our fresh Node 22 sandbox installed commit e3a0369 in 26 seconds. Pnpm pulled 559 packages and the installed tree occupied 954 MB. The checkout itself contained 1,243 files, roughly 212,206 source lines, and 37.6 MB. We found 2 CI workflow files, a workspace monorepo, no Dockerfile, and no tests directory.
Our harness found no supported build script or target, so it skipped the build. It also found no supported test script or target and skipped tests. Those are findings about the standardized run, not claims that the repository contains no checks: the current documentation names migration smoke, API smoke, web checks, and end-to-end paths. We did not run those project-specific commands, so they cannot be counted as passes here.
Node 24 and PostgreSQL 16 are only the starting line
Source setup asks for the pinned Rust toolchain, Node.js 24, pnpm 10, PostgreSQL 16, and at least one supported agent CLI. pnpm dev:all starts the database plus two Rust services and waits for readiness. pnpm dev:web starts the client separately, usually on port 3100. Agent accounts, model access, and local CLI installation remain operator responsibilities.
Release v0.2.3 packages five executables, migrations, the standalone web application, manifests, and license notices. The Linux archive uses Ubuntu 24.04 as its runtime baseline and does not promise compatibility with older glibc systems or NAS distributions. The macOS arm64 archive is unsigned and unnotarized. Operator-managed deployments use PostgreSQL, while choruz-server offers a separate embedded-PostgreSQL bootstrap route.
Remote control encrypts traffic but does not broker approvals
Choruz pairs another machine through a one-time credential and keeps a reverse connector on that host. Dashboard calls and terminal streams cross the gateway as encrypted frames; the documentation says the gateway does not see workspace paths, prompts, account data, or results in plaintext. Hosted relay is the default, while advanced users can deploy the Cloudflare Worker themselves and manage matching secrets.
The approval boundary is less complete. Choruz can transport approval_required and human_input_needed events, but its guide says an approval is genuine only when the chosen harness exposes a broker and returns a successful result. Harnesses launched with auto-approval provide observation and control, not per-tool remote consent. A security review must follow the exact CLI driver, not the reassuring shape of the dashboard.
The plugin system trusts compiled code
Built-in plugins cover the task board, a pixel-world view, workspace Git, remote SSH, agent skills, and extra CLI drivers. Host and client manifests must match before controls appear. Disabling a route-providing plugin prevents its routes from registering, which is cleaner than hiding only the button. Pi and OpenCode require explicit opt-in; enabling either plugin does not install its CLI.
This is a build-time system. The documentation explicitly says Choruz does not execute downloaded third-party plugins and that a future marketplace would need signing, permissions, isolation, migrations, and rollback design. That limit is sensible for a developer preview. It also means extending the product today requires trusted code in the application rather than installing a loosely isolated community package.
The September release is active and still pre-release
GitHub showed 908 stars, 0 open issues and pull requests, and a last push on September 25, 2026. Version 0.2.3 shipped four days earlier and separated evaluation, community, learning, and agent-runtime functions into reusable libraries. Its release notes say required main CI and Linux packaging verification passed, while Jev integration was research only and absent from the release.
The README still calls Choruz a developer preview and warns that interfaces, configuration, and data formats may change incompatibly. Believe that warning. The project has unusually specific architecture and operations documentation, but our 954 MB install did not yield a standard build or test result. Choruz is most convincing when terminal sprawl has already become a team problem. Before that point, its collaboration layer is an expensive room to keep open.