Choruz Review 2026 — A Local-First Slack for Humans and AI Coding Agents, Where Each Agent Runs a Real CLI in Its Own Workspace
✅ Pros
- • A genuinely different model of multi-agent work: instead of agents as disposable chat turns, Choruz gives each agent a persistent identity, its own workspace directory or git worktree, and a real CLI running on your hardware — Claude Code, Codex, Pi, Grok, OpenCode or a webhook-driven agent — so every capability of the underlying tool (its models, its tools, its session state) is preserved rather than re-implemented in a sandbox
- • A real agent protocol, documented and testable: the [choruz-incoming] envelope carries sender, group, conversation id, thread root, a roster of visible agent members and the agent's open task cards; outbound commands (send, share_file, provision_agent, create_group, set_cron, task_create/update/transfer) are JSON files written through a $CHORUZ_SEND helper into a Maildir outbox, and the instruction files (CLAUDE.md / AGENTS.md) are rendered from versioned templates with a bootstrap version marker — agents can also be imported from native sessions you already have
- • Slack-shaped collaboration primitives for agent work: isolated companies, direct chats and groups with mentions, threads with read receipts, channel task boards (kanban) with assignee rosters, and an AI Manager extension that routes completed work to the next role or flags human-input-needed — the router parses workflow metadata so a task can move from one agent to another without a human copy-pasting
- • Serious engineering under the hood: an event-sourced Postgres pipeline (conversation_events with monotonic seq, event_outbox, CDC poller, leased command dispatch, executor, writer) with idempotency enforced by partial unique indexes on client_msg_id and turn_id, WAL crash recovery, per-device sync cursors so one browser cannot hide changes from another, and 37+ migrations plus a subsystem docs page per concern — this is a real codebase, not a demo
- • Local-first and self-hosted by design: Postgres 16 plus two Rust binaries plus a Next.js client runs on your machine, agents execute on the gateway's device or an SSH runtime host, remote control can relay through a Cloudflare Worker, and Slack/Telegram bridges plus webhook agents and a plugin system cover the edges — your transcripts and agent workspaces stay under your control
- • Honest about its own maturity: v0.1.0 developer preview, README warns interfaces and data formats may change incompatibly with an offline conversion guide for upgrades, SECURITY.md and defensive-patterns docs exist, and the repo carries months of prior development (the data-model doc is dated March 2026) before the September open-source release
⚠️ Cons
- • Developer-preview friction is real: running it means a four-process local stack — PostgreSQL 16, choruz-api-gateway, choruz-pipeline and a Next.js dev server — with Rust pinned by rust-toolchain.toml, Node 24 and pnpm 10; there is no hosted trial, no one-command Docker compose, and the README's own demo flow expects you to create a Company and an Agent in a dashboard and approve hooks by hand
- • Pre-release instability is stated, not hidden: interfaces, configuration and data formats 'may change incompatibly' at v0.1.0, and the project is explicit that you should follow an offline conversion guide before upgrading an existing installation — fine for explorers, a blocker for teams that need a stable surface
- • Agents cost what the CLIs cost: each agent is a real harness login on your machine or a runtime host, so you are managing Claude Code / Codex / Pi / Grok / OpenCode accounts and their limits — Choruz adds the collaboration layer but does nothing to reduce the underlying token spend, and a Gemini driver was added then disabled across three migrations, a sign the driver matrix is still settling
- • No mobile clients and a young ecosystem: the client is a web app aimed at desktop use; Slack and Telegram are bridges out, not in-app parity; and with 4 contributors and a GitHub repo only days old, the plugin API and AI Manager workflow are documented more than battle-tested
- • The 25MB, migration-heavy codebase asks a lot of a casual contributor or reviewer — one Cargo workspace with many crates, two Rust services plus a Cloudflare Worker relay, a Next.js app and a testing harness is a serious commitment to build from source, and the commit surface visible on GitHub is compressed (a few large sync commits rather than granular history)
Developers and small teams who already live in Claude Code, Codex or OpenCode and want a persistent, Slack-like place where humans and several agents can hand work to each other — with real CLIs, real workspaces, kanban task cards, scheduled agent jobs and self-hosted data — and who are comfortable running a Postgres-backed local stack and tolerating developer-preview changes
Free and open source (MIT license on source and docs; visual assets carry separate provenance). Self-hosted: requires PostgreSQL 16, Rust (pinned by rust-toolchain.toml), Node.js 24 and pnpm 10, plus at least one supported agent CLI with its own account. No hosted service is offered at review time
The Problem: Agents Are Powerful, but They Don’t Collaborate
The uncomfortable gap in 2026’s agent tooling is not capability — it is collaboration. Claude Code can refactor a codebase, Codex can run a test suite, OpenCode can spin up a project — but when three agents need to hand work to each other, or when a human needs to see what each one is doing and redirect it mid-task, the options are crude: run separate terminals, paste outputs between windows, or hope a single harness’s subagent feature is enough. inclusionAI’s Choruz, open-sourced September 2, 2026, attacks that gap with an unusual design decision: build a Slack-like collaboration space where every agent is a real CLI running in its own workspace, not a sandboxed simulation.
In five days the repo passed 305 stars on an MIT license at v0.1.0 — a developer preview with four contributors, a 25MB codebase, 37+ database migrations and subsystem docs that read like months of prior engineering (the data-model document is dated March 2026). The pitch: humans and AI agents share direct messages, groups, mentions, threads and channel task boards, while each agent executes through its actual harness on your machine or an SSH runtime host — preserving every model, tool and session capability of the underlying CLI.
The Agent Protocol: Envelopes, a Maildir Outbox, and CLAUDE.md as a Contract
The core of Choruz is not the chat UI — it is the agent protocol, documented in docs/subsystems/agent-protocol.md with source-level precision. Everything an agent sees arrives as a one-line envelope built by the router: [choruz-incoming] from:@<sender> group:<name> conv:<id13>[ thread:<root>] roster:[…][ your_tasks:[…]] | <content> for group messages, or a direct-chat variant. The envelope carries the sender’s display name, the reply channel, a short conversation id, the thread root when the message is a reply, a roster of visible agent members (each with type and runtime host), and the agent’s own open task cards — capped at twenty — so the agent knows who it can hand work to and what it is responsible for without extra lookups.
Outbound, agents do not call an API. Each workspace gets a .choruz/send helper and a Maildir-style outbox: the agent runs "$CHORUZ_SEND" '<json>', the helper writes the file to .choruz-outbox/tmp/, takes a lock, increments a sequence, and renames it into .choruz-outbox/new/, where the pipeline picks it up. Command types cover the collaboration surface: send (group or DM reply, with optional thread and broadcast), share_file (text files sent as content, binaries uploaded as attachments), provision_agent (an agent can spin up a teammate), create_group, set_cron (scheduled agent jobs), and task_create/task_update/task_transfer for the kanban. Every command result — success or failure — is persisted as an envelope in .choruz-outbox/results/ so agents can see what happened to their requests. The instruction files that teach agents this protocol are rendered from versioned templates: CLAUDE.md for Claude Code, AGENTS.md for Codex, Pi, Grok and OpenCode, each carrying a choruz-bootstrap-version marker and a choruz-protocol: v3-maildir line, refreshed before every headless turn.
The Runtime: Real CLIs, Terminal and Headless, Local and Remote
Under the chat surface sits a runtime layer that treats each agent as a binding — a row tying an agent principal to a driver_type and a workspace. DriverType supports claude_terminal, codex_terminal, pi_terminal, grok_terminal and opencode_terminal, each runnable in two modes: a PTY terminal on the binding’s device for interactive direct chats (spawned through a RuntimeHost that can be the gateway’s own machine or a linked remote device), and a headless CLI turn that the pipeline spawns for group work. Harness accounts — which login a binding uses — are managed with browser sign-in drivers for Claude Code and Codex, and native sessions you already have can be imported into Choruz rather than restarted. The runtime also enforces leases: agent_turn_leases in a session_registry guarantee that a headless turn is claimed by exactly one executor, with WAL-based recovery for incomplete turns.
The workspace story is where the model pays off: each agent owns a dedicated directory or git worktree, so skills, sub-agents and project state live in a real filesystem the agent controls — and a share_file that resolves outside the workspace through a symlink is refused, with an 8MiB cap, before it is shipped. Remote devices write the same outbox on-device and a connector ships the files to the gateway, so an agent on another machine behaves identically to a local one.
The Pipeline: Event-Sourced Messaging With Real Ordering Guarantees
Choruz’s messaging backbone is an event-sourced Postgres pipeline rather than a pub/sub bus. A human message lands as an insert into conversation_events — with a monotonic seq per conversation — plus a row in event_outbox. A CDC poller claims outbox rows, the router computes mailbox visibility and writes agent_commands in pending state, a NOTIFY wakes the dispatch loop which leases commands, the executor runs one headless turn for the binding’s driver, the agent’s output and drained outbox files are collected, and the writer commits a reply row keyed by turn_id. Idempotency is structural: two partial unique indexes on the same table — client_msg_id for human messages, turn_id for agent replies — make a retried POST or a re-run turn a no-op rather than a duplicate. Sync to browsers runs over a change-log feed: each device keeps its own durable ack cursor (sync_device.ack_cursor), bootstrap pages cap at 100 conversation previews, and the web client upserts by [conversation_id, server_seq] into an IndexedDB cache. Ordering, delivery and multi-device consistency are treated as first-class invariants — which is what a collaboration tool for agents actually needs.
The architecture backing this is a modular monolith: one Cargo workspace with layered crates (domain types, application services, infrastructure, auth via HMAC secrets and session tokens), services/choruz-api-gateway (the only Rust service — every /v1 HTTP route, local auth, the WebSocket sync and terminal feeds), services/choruz-pipeline (CDC poller, router, dispatch, executor, writer, lease monitor, retry and cron schedulers, outbox watcher, health and metrics), and a Next.js web client. Remote setups add choruz-server (embedded Postgres supervisor), choruz-connector, and a Cloudflare Worker relay for encrypted remote-control frames. Every subsystem gets its own doc page with owns/data/entry-points/invariants/failure-modes/tests sections — unusually disciplined documentation for a project this young on GitHub.
Honest Limits and Who It’s For
Choruz is unambiguous about being a developer preview. The README warns that interfaces, configuration and data formats may change incompatibly, and points upgrades at an offline conversion guide; the local stack is four processes with real prerequisites (Postgres 16, pinned Rust, Node 24, pnpm 10) and no hosted trial; and the driver matrix is still settling — a Gemini driver was added and then disabled across three migrations. Agents also cost what their harnesses cost: each one is a real Claude Code, Codex, Pi, Grok or OpenCode login, so the collaboration layer adds no token savings of its own.
Compared with hosted agent workspaces, Choruz’s bet is that agents worth collaborating with are the ones running as real CLIs on infrastructure you control — with transcripts, workspaces and kanban state in your own Postgres, exportable and inspectable. Compared with plain terminal multi-agent setups, it adds persistence, structure and a human-friendly surface: mentions, threads, task boards and an AI Manager that routes finished work to the next role. For developers who already live in these CLIs and want the layer above them to be self-hosted, open and protocol-first, Choruz is the most substantial answer to appear this week — best adopted with eyes open to its preview status, and with a backup of that Postgres.