CCCC: A Durable Group Ledger for Coding Agents That Outlive the Terminal
Coordinate your coding agents like a group chat — read receipts, delivery tracking, and remote ops from your phone. One pip install, zero infrastructure. A production‑minded orchestrator for 24/7 workflow
At a glance
- What is it?
- CCCC (ChesterRa/cccc) is an Apache-2.0 Rust daemon plus Web UI that coordinates multiple coding-agent runtimes through one append-only ledger. It solves the lost-context problem of parallel terminal sessions, but it is a local-first tool with a single-machine daemon and no published Intel Mac artifacts after v0.4.37.
- Who is it for?
- Adopt CCCC if you already run two or more coding-agent CLIs on one machine and need message delivery, read, and reply facts to survive a terminal restart. Do not adopt it if you need a distributed control plane, run Intel macOS, or want a hosted service.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem CCCC Solves: Terminal Scrollback Is Not a Coordination Layer
Running several coding agents at once usually means several terminal windows and a mental model held together by scrolling. The README names the failure directly: lost context in scrollback, no distinction between a stored message, a runtime handoff, an Inbox consumption, and a reply, and start/stop/recover operations scattered across tools. That last point is the practical one. If a Codex CLI session dies, nothing in the terminal tells you which messages it had received and which it had actually read.
CCCC targets engineers who already run more than one agent runtime and want the coordination state to live somewhere other than a shell buffer. The README frames the goal as a persistent, coordinated team across runtimes, machines, and trusted working groups, rather than a pile of disconnected terminal sessions. It is not a framework for building agents. It is a control layer that sits above runtimes you already have.
The intended user is specific: someone with Claude Code, Codex CLI, and a couple of other CLIs installed locally, who wants to check on a long-running group from a phone without SSH. If you run one agent in one terminal, the ledger, the role model, and the Web UI are overhead with no payoff.
One Daemon, One Ledger, Four Delivery Facts
The architecture in the README is a single daemon that owns all state, with Web UI, CLI, MCP tools, and IM bridges as clients. There is no database, message broker, or Docker container. State lives in an append-only ledger file named ledger.jsonl, which the README describes as replayable and auditable.
The messaging model is the part worth reading closely. CCCC separates routing from delivery: a message has a stored fact, a runtime-delivery fact, a read fact, and a reply fact. The README states that runtime handoff never pretends a message was read. That matters because a runtime can accept a payload and then fail before the model sees it. A single ack would mark that message delivered and hide the loss; four separate facts leave the gap visible.
Recipients are addressed by role rather than by session. The README lists @all, @peers, and @foreman, with a Foreman plus peer model and permission boundaries. There is also a Mail-only Inbox consumed in ledger order. Inbox consumption being ordered and separate from runtime delivery is what makes the four-fact model coherent: a message can be stored and routed without being pulled into a runtime yet.
The README claims 13 or more first-class runtimes, naming Claude Code, Codex CLI, ChatGPT Web, GitHub Copilot CLI, Cursor CLI, Devin CLI, Kiro CLI, Kilo Code CLI, Antigravity CLI, Grok Build, and OpenCode, plus a custom option. Which of those actually attach on your machine is something cccc setup decides, not something the README guarantees.
Install, Attach, Setup: The Three Commands That Matter
There are two install channels and they do not mix. The website installer is the recommended path on macOS and Linux:
curl -fsSL https://chesterra.github.io/cccc/install.sh | sh
On Windows the README gives a PowerShell one-liner that sets Tls12 and pipes install.ps1 into Invoke-Expression. The pip channel installs the same native executable for package-manager compatibility:
python -m pip install -U "cccc-pair>=0.4.36"
The README is explicit that the pip package is not a Python daemon, launcher, or fallback. Supported targets are Linux x86-64 with glibc 2.28 or newer, Apple Silicon macOS 11 or newer, and Windows x86-64.
Once installed, cccc brings up the daemon and the local Web UI together on http://127.0.0.1:8848. Loopback use is passwordless and creates no Access Token. Admin Access Tokens are required only when you enable LAN, Reach, a public URL, or reverse-proxied access. That default is the right call, and it also means the first time you expose the UI you are changing the security posture, not just the network setting.
To bind a working directory as a scope and configure runtimes:
cd /path/to/your/repo cccc attach . cccc setup
For diagnostics the README lists cccc status for product, daemon, groups, actors, and agent runtimes, and cccc doctor for installation and environment diagnostics. cccc daemon status covers daemon lifecycle. The old cccc python, cccc rust, and ccccd alias are retired; automation should use cccc daemon.
Group Bridge and the Local Access Grant Are the Sharp Edge
Group Bridge lets trusted CCCC groups exchange explicit messages across machines or teams. The README also says a bridge peer can, when granted, inspect or work with the other group's local resources, described as read or full local access.
That is a deliberate design choice, and it is the one to think hardest about. Message exchange between two groups is a routing problem with a clear blast radius. Granting a remote group access to local resources is a different category of decision, and the README does not describe a sandbox around it. The grant itself is the boundary. If you enable a bridge, the peer's permission level is the thing you are trusting, not the transport.
The local-first framing is genuine in one respect: runtime data lives in CCCC_HOME rather than in your repository, so the ledger and runtime state do not get committed alongside source. That keeps the repo clean and also means the coordination history is not versioned with the code it produced. If you want a durable record of which agent did what in a given commit range, you will be reading CCCC_HOME separately.
Nothing in the supplied material describes ledger compaction, rotation, or size limits. An append-only file that records every message and event grows without a documented ceiling. Treat that as unverified rather than as a defect, and check it before pointing CCCC at a long-lived repository.
Maintenance Cost and the Install-Channel Ownership Rule
Upgrades are channel-specific, and CCCC enforces the split. A website-installer deployment updates with cccc update, and cccc update --check inspects it first. A pip-owned command refuses standalone self-update and prints the package-manager command instead, which for pip is python -m pip install -U "cccc-pair>=0.4.36".
The README gives a concrete operational detail for pip upgrades: run cccc daemon stop and close any foreground CCCC process so the package manager can replace the executable, especially on Windows. That is a file-lock problem, not a theoretical warning. Switching from pip to the website installer requires python -m pip uninstall cccc-pair first, and the standalone installer refuses to overwrite pip-owned files even with CCCC_ALLOW_REPLACE_EXISTING=1. Budget for this once per machine, and do not script a blind update across mixed channels.
Platform support is shrinking at the edges. CCCC v0.4.37 is the final release for Intel Macs; newer releases do not publish x86_64-apple-darwin artifacts. If you are on an Intel Mac, you are pinned to that line. The release cadence in the supplied material is fast, three releases in roughly two weeks (v0.4.36 on 2026-08-29, v0.4.37 on 2026-09-01, v0.4.38 on 2026-09-07), so pinning matters more than usual.
The project is Apache-2.0. That permits commercial and modified use with the usual notice and patent-grant terms; it is not legal advice, and the Group Bridge resource-sharing behaviour is the part worth reading the licence against if you redistribute a modified build.
Where CCCC Is the Wrong Tool
The daemon is local. The README's remote story is Web Access and IM bridges reaching a machine you run, plus Group Bridge between trusted groups. There is no hosted control plane and no described clustering or failover. If your agents run on three machines and you want one scheduler to place work across them, CCCC is not that. You would be running three daemons and bridging them, which is a different topology with its own trust questions.
The runtime list is also a support surface, not a guarantee. The README names eleven runtimes explicitly and says 5 more, plus custom. A runtime that is listed but not detected by cccc setup gives you a group with fewer peers than you planned. Check cccc status after setup rather than assuming.
Finally, the four-fact delivery model only helps if the runtime reports back. CCCC can record that it handed a payload to a runtime; it cannot record that the model understood it. Read receipts in this system mean the runtime acknowledged, not that the agent acted. If your workflow depends on knowing an agent completed a task, you still need the agent to send an explicit reply, which is what the reply fact is for.
How This Differs From a Plain tmux-and-CLI Setup
The obvious alternative is tmux plus the agent CLIs themselves. tmux gives you persistent sessions and a way to attach from a phone over SSH. The difference is what persists. In tmux, the session survives but the coordination state does not: there is no stored-versus-read distinction, no role-based routing, and no ledger you can replay. Recovering a dead pane means re-reading scrollback and re-prompting.
CCCC moves that state into ledger.jsonl and puts a daemon in front of it, so the same group can be inspected from the CLI, the Web UI, and an IM bridge without any of them holding a private copy. The cost is a daemon you have to start, stop, upgrade, and reason about, plus a port on 127.0.0.1:8848 and a token the moment you leave loopback.
A second alternative is to write your own orchestration over each runtime's SDK. That gives you exactly the delivery semantics you want. It also means you own the ledger, the routing, the role model, and the recovery path, which is the work CCCC has already done and documented. The honest trade is between a daemon you did not write and a coordination layer you have to maintain yourself.
Who Should Adopt CCCC, and What to Check First
Adopt it if you already run two or more agent runtimes on a single machine, you have felt the scrollback problem, and you want a Web UI you can open from a phone without exposing SSH. The one-command install and the absence of a database or broker make the first hour cheap, and the four-fact delivery model is a real answer to a real gap.
Do not adopt it if you are on Intel macOS and want current releases, if you need a distributed scheduler, or if you want someone else to host the control plane. Do not enable Group Bridge with resource access until you have decided which peer you would trust with read access to your working tree, because the grant is the boundary and the README does not describe a sandbox behind it.
Before committing, run cccc doctor and cccc status and confirm that the runtimes you care about actually attached. Check where CCCC_HOME points and confirm it is outside the repository. Confirm which channel owns your binary, because cccc update and the pip upgrade path are mutually exclusive and the wrong one refuses to run. Then pin a version: v0.4.37 is the last release with x86_64-apple-darwin artifacts, and the cadence of three releases in two weeks means an unpinned install will move under you.
Editorial conclusion
Adopt CCCC if you already run two or more coding-agent CLIs on one machine and need message delivery, read, and reply facts to survive a terminal restart. Do not adopt it if you need a distributed control plane, run Intel macOS, or want a hosted service. Verify three things first: that your runtimes appear in cccc status after cccc setup, that CCCC_HOME does not sit inside your repo, and that your install channel owns the binary before you run cccc update.
Community notes