# CCCC: a durable group ledger for coding agents across runtimes

> CCCC (cccc-pair) coordinates Claude Code, Codex CLI and other runtimes through one append-only ledger, a daemon-owned control plane and optional remote bridges. Here is what it installs, how the delivery semantics work, and where it stops being the right tool.

**ChesterRa/cccc** — 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

- Repository: https://github.com/ChesterRa/cccc
- Website: https://cccc.sh/
- Stars: 1,254 · Forks: 113
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/chesterra-cccc

## The problem CCCC targets: handoffs that vanish into scrollback

Running two or three coding agents in one repository usually works until you need to know what actually happened. The README describes the failure directly: lost context in terminal scrollback, no distinction between a stored message, a runtime handoff, Inbox consumption and a reply, and start/stop/recover operations scattered across tools. That is a coordination problem, not a model problem, and it gets worse the longer a session runs.

CCCC's answer is to treat the group itself as the durable object. Working state lives in an append-only ledger rather than in scrollback, and every message and event is recorded there. The project ships as cccc-pair on PyPI, is written in Rust (workspace version 0.4.40, rust-version 1.88), and is licensed Apache-2.0. The audience is narrow and specific: developers who already run Claude Code, Codex CLI, ChatGPT Web or the other listed runtimes and want them to behave as one team across machines, rather than as separate terminals that happen to share a folder.

## How the ledger, delivery facts and daemon fit together

The README names ledger.jsonl as the single source of truth: an append-only file that records every message and event, described as replayable and auditable. The design consequence is that a message is not one event but several. Routing is separate from stored, runtime-delivery, read and reply facts. The README is explicit that runtime handoff never pretends a message was read, which is the part most multi-agent setups get wrong when they pipe text between processes and hope.

Above the ledger sits a daemon. Web UI, CLI, MCP tools and IM bridges all talk to that one daemon, so there is no state fragmentation between interfaces. Coordination is role-based: a foreman plus peer model with permission boundaries and recipient routing through @all, @peers and @foreman. Messaging is split into Send, Send + Reply and Mail, with a Mail-only Inbox consumed in ledger order.

The repository layout matches that story: the Cargo workspace separates cccc-core, cccc-runtime, cccc-daemon, cccc-client, cccc-mcp, cccc-web and cccc-cli, with cccc-cli as the default member. Runtime data stays in CCCC_HOME rather than in your repository, which keeps the ledger out of your commits but also means the group's memory is not versioned with the code it discusses.

## Installing CCCC and creating your first group

The README recommends the website installer on macOS and Linux. The one-liner downloads and runs install.sh from the project's documentation site.

```bash
curl -fsSL https://chesterra.github.io/cccc/install.sh | sh
```

Windows has a separate PowerShell path, and there is a pip-compatible wheel if your tooling requires a package manager. The README is careful about what that wheel is: CCCC 0.4.36 has one product implementation, Rust, and the pip command installs the same native executable in a platform wheel. It does not install a Python daemon, launcher or fallback.

```bash
python -m pip install -U "cccc-pair>=0.4.36"
```

Supported targets are Linux x86-64 with glibc 2.28 or newer, Apple Silicon macOS 11 or newer, and Windows x86-64. Launching is a bare command, and by default CCCC brings up the daemon and the local Web UI together on port 8848.

```bash
cccc
```

Open http://127.0.0.1:8848. Direct localhost or 127.0.0.1 use stays passwordless and does not create an Access Token; explicit Admin Access Tokens are required only when you enable LAN, Reach, a public URL or reverse-proxied access. Before wiring agents together, the diagnostics commands are worth running once.

```bash
cccc status
cccc doctor
cccc daemon status
```

cccc status reports the product, daemon, groups, actors and agent runtimes. cccc doctor covers installation and environment diagnostics. cccc daemon status is the explicit daemon lifecycle check. Note that cccc python, cccc rust and the former ccccd alias are retired; existing automation should call cccc daemon instead, though compatible daemon state filenames are retained so 0.4.35 homes can be adopted without a Python runtime.

The first real use is binding a repository as a scope and configuring the runtimes you have installed. The README's group example starts with these two commands.

```bash
cd /path/to/your/repo
cccc attach .
cccc setup
```

cccc attach binds the directory as a scope; cccc setup configures the available runtimes. After that the group exists on the ledger, and the Web UI at 127.0.0.1:8848 is where you watch delivery and read facts accumulate.

## Group Bridge and remote supervision: useful, and the sharpest edge

Group Bridge connects trusted CCCC groups across machines or teams. It starts with explicit message exchange and can optionally grant read or full local access to the other group's resources. The README frames this as a deliberate escalation, and it is the feature most likely to decide whether you adopt CCCC at all.

Two things are worth separating. Remote supervision through Web Access and IM bridges lets you check on a long-running group from a phone, which is a read-mostly convenience. Group Bridge with granted local access is a different risk class: another trusted group can inspect or work with your local resources. The README does not document a rollback path for a granted permission, and it does not describe an audit trail for bridge grants beyond what the ledger records. If your threat model includes a compromised peer group, that gap matters more than any throughput question.

The local-first default is the counterweight. Runtime state stays in CCCC_HOME, remote exposure happens only when you choose it, and localhost access needs no token. The trade-off is that the moment you enable LAN, Reach, a public URL or a reverse proxy, you take on Admin Access Token management yourself, and the README does not lay out token rotation.

## Where CCCC is the wrong tool

The clearest case against CCCC is a single agent in a single terminal. The ledger, the delivery facts and the daemon exist to solve coordination between actors; with one actor there is nothing to coordinate, and you have added a background process and a state directory for no gain.

Platform is the second boundary, and it is a hard one. 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 release unless you change hardware, and the README does not describe an alternative build path. Linux support is x86-64 with glibc 2.28 or newer, so older distributions are out.

The third is ownership of state. The ledger lives in CCCC_HOME, not in your repository. That is the right call for keeping commits clean, but it means the group's history is not part of the codebase, is not reviewed with it, and does not travel with a clone. Teams that expect coordination artifacts to be versioned alongside the code will find the model inverted.

Finally, the upgrade rules are stricter than a typical CLI. A pip-owned command deliberately refuses standalone self-update and prints the package-manager command instead. Before a pip upgrade you are told to run cccc daemon stop and close any foreground CCCC process so the package manager can replace the executable, especially on Windows. The standalone installer refuses to overwrite pip-owned files even with CCCC_ALLOW_REPLACE_EXISTING=1, so switching channels requires python -m pip uninstall cccc-pair first. If you cannot stop the daemon on a schedule, upgrades become an operation rather than a command.

## How CCCC differs from a plain multiplexer or a hosted orchestrator

The obvious comparison is a terminal multiplexer such as tmux or a session manager like smux: you get several panes, each running an agent, and you switch between them. The difference is what survives. A multiplexer keeps processes alive; it does not model whether a message was stored, delivered to a runtime, read, or answered. CCCC's separate delivery, read and reply facts are the whole point, and they are what a pane cannot give you because a pane has no concept of a recipient.

The other comparison is a hosted orchestration platform. Those centralize state on someone else's infrastructure and typically assume a specific runtime or API. CCCC is local-first: one install command, no database, no message broker, no Docker, state in CCCC_HOME, and a first-class runtime list that spans Claude Code, Codex CLI, GitHub Copilot CLI, Cursor CLI, Devin CLI, Kiro CLI, Kilo Code CLI, Antigravity CLI, Grok Build, OpenCode and ChatGPT Web, plus custom for anything else. The cost of that breadth is that CCCC owns the abstraction layer between your agents; the benefit is that you keep the ledger.

If your agents already share a well-defined API and you only need them called in sequence, a small script is less machinery than a daemon plus a ledger plus a Web UI.

## Maintenance, releases and licence

The repository is not archived, and the last push was on 2026-09-10, so it is current. Release cadence has been tight: v0.4.36 on 2026-08-29, v0.4.37 on 2026-09-01, v0.4.38 on 2026-09-07, with the workspace and pyproject version at 0.4.40. Fast releases are convenient when you track a bug fix and inconvenient when you need a frozen target, and the pip channel's refusal to self-update means each bump is a package-manager operation with a daemon stop in front of it.

The Rust toolchain requirement is 1.88 or newer, which matters only if you build from source; the README states that the one install command needs no Rust toolchain. Licence is Apache-2.0 for the workspace, and the pyproject metadata carries the same identifier. Apache-2.0 includes an explicit patent grant and requires attribution and notice retention when you redistribute. That is the shape of the obligation, not legal advice; if you embed CCCC in a product, have counsel read the LICENSE file and the SECURITY.md and SUPPORT.md at the repository root, which the README does not summarize.

## Conclusion

Adopt CCCC if you already run several coding agents in one repository and keep losing handoffs to terminal scrollback, or if you need to check on a long-running group from a phone. Skip it if you have a single agent in a single terminal, if you need a stable Intel macOS build (v0.4.37 is the last release that publishes x86_64-apple-darwin artifacts), or if you cannot accept a daemon owning state outside your repo. Verify first that your runtime appears in the first-class list, that your platform is among Linux x86-64 with glibc 2.28+, Apple Silicon macOS 11+ or Windows x86-64, and that you are comfortable with the upgrade rules in the README: run cccc daemon stop before a pip upgrade, and run python -m pip uninstall cccc-pair before switching to the website installer.

## FAQ

### What does CCCC stand for?

The repository does not expand the acronym. The README and pyproject.toml describe the project only as CCCC, with the PyPI package named cccc-pair and the description "Global multi-agent delivery kernel with working groups, scopes, and an append-only collaboration ledger."

### Does CCCC need Docker, a database or a message broker?

No. The README states that CCCC installs with one command and needs no database, message broker or Docker, and that runtime state lives in CCCC_HOME rather than in your repository.

### Which coding agent runtimes does CCCC support?

The README lists Claude Code, Codex CLI, ChatGPT Web, GitHub Copilot CLI, Cursor CLI, Devin CLI, Kiro CLI, Kilo Code CLI, Antigravity CLI, Grok Build and OpenCode among the first-class runtimes, plus custom for anything else. It also refers to 13 more runtimes in one durable group in the header.

### Do I need an Access Token to use the CCCC Web UI?

Not for local use. The README states that direct localhost or 127.0.0.1 access stays passwordless and does not create an Access Token; explicit Admin Access Tokens are required only when enabling LAN, Reach, a public URL or reverse-proxied access.

### How do I upgrade CCCC if I installed it with pip?

The README gives python -m pip install -U "cccc-pair>=0.4.36" and notes that a pip-owned command refuses standalone self-update. Before upgrading, run cccc daemon stop and close any foreground CCCC process so the package manager can replace the executable.

## Sources

- [ChesterRa/cccc on GitHub](https://github.com/ChesterRa/cccc)
- [License: Apache-2.0](https://github.com/ChesterRa/cccc/blob/main/LICENSE)
- [Project website](https://cccc.sh/)
- [README](https://github.com/ChesterRa/cccc/blob/main/README.md)
- [Releases](https://github.com/ChesterRa/cccc/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chesterra-cccc