Dev & Engineering multi-runtime-orchestrationmcpappend-only-ledgercoding-workflowsremote-operationsim-bridgeschatgpt-web

CCCC Coordination Console

Run coding agents as a durable, trackable team across runtimes, machines, and remote operations.

FollowAgents review · FARS-2.1
Use with care
61/ 100 5-point scale 3.1 / 5
1 2 3 4 5 6
Per-dimension scores and reasoning
1Trust17 / 29 · 2.9/5

Evidence shows: README explicitly states Web UI is high-privilege and requires Admin Access Token; daemon IPC binds to localhost by default; IM tokens are read from environment variables; Group Bridge uses a trust model with explicit read/full authorization; capability allowlist governs MCP capabilities. This reflects least privilege. However, user confirmation is only mentioned for Group Bridge pairing and Web Access settings, not covering all high-risk operations, so user_confirmation scores 1. Data flow transparency: README describes ledger recording all messages and events, but does not detail data flow and storage locations, so scores 2. Sensitive data handling: IM tokens from env vars, runtime state in CCCC_HOME, but no mention of encryption, so scores 2. Dependency security: pyproject.toml lists dependency version ranges, CI has caching, but no vulnerability scanning evidence, so scores 2. External effects: Group Bridge allows remote operations but requires explicit authorization, and README warns against public exposure, so scores 2. Rollback: installer tests cover rollback, but no user-level rollback documentation, so scores 2. Source attribution: no contributor guide or author info, so scores 1.

2Reliability9 / 14 · 3.2/5

Evidence shows: README and CI config are consistent, Python and Rust implementations coexist, but README clearly states Rust is experimental and Python is stable, reflecting self-consistency. Dependency availability: pyproject.toml lists dependencies, CI has caching, but no availability guarantee, so scores 2. Failure messages: README provides doctor command and FAQ, but no detailed error message examples, so scores 2.

3Adaptability12 / 18 · 3.3/5

Evidence shows: README defines target audience (multi-agent coordination) and multiple use cases, with a suitability table. Capability boundaries: README describes support for 17 runtimes and custom, and Group Bridge permission levels. Trigger precision: README describes message routing and automation rules, but no detailed trigger conditions, so scores 2. Environment fit: README provides multiple installation methods (pip, Docker, source) and supports multiple platforms, so scores 2.

4Convention10 / 18 · 2.8/5

Evidence shows: README is well-structured with quick start, architecture, CLI reference, etc., good information architecture. Install notes are detailed, including pip, Docker, source. Naming stability: version numbers consistent in Cargo.toml and pyproject.toml, but no naming convention doc, so scores 1. Examples and FAQ: README provides multiple examples and FAQ links, so scores 2. Known limitations: README mentions Rust implementation is experimental and some features unsupported, so scores 2. License: Apache-2.0 license file present, so scores 2. Versioning changelog: no CHANGELOG file, so scores 1. Maintenance responsibility: no maintainer info or contribution guide, so scores 1.

5Effectiveness9 / 13 · 3.5/5

Evidence shows: README describes outputs (Web UI, CLI, MCP tools) and available features, output usability is good. Marginal value: compared to existing tools, CCCC provides cross-runtime coordination and persistent state, unique value. Cost-benefit: simple installation, no extra infrastructure, but learning curve, so scores 2.

6Verifiability4 / 8 · 2.5/5

Evidence shows: README claims (e.g., support for 17 runtimes) have corresponding documentation, but no independent verification. Cross-source corroboration: CI config and test scripts provide partial verification, but no external verification, so scores 1. Fact-inference separation: README clearly distinguishes stable and experimental features, so scores 2.

Evidence confidence: Low Reviewed Aug 09, 2026 Reviewed revision 9d370ef6e0b5
The upstream repository has new commits since this review. The score still applies to the reviewed revision shown and may not cover the latest changes.
Before you use it
  • Web UI is high-privilege; must set Admin Access Token before exposing publicly to prevent unauthorized access.
  • Group Bridge read/full permissions should be granted cautiously, only to trusted remote groups.
  • Rust implementation is experimental; use Python stable version for production.
  • Dependency security lacks vulnerability scanning evidence; recommend checking dependencies for vulnerabilities.
See the full review method →

What does this agent do, and when should you use it?

CCCC is a local-first coordination system for multi-agent software development, centered on a daemon that manages groups, actors, and message state. Its append-only JSONL ledger records messages and events, while a Web UI, CLI, MCP surface, and IM bridges use the same control plane. A group can combine 16 first-class runtimes, including Claude Code, Codex CLI, and ChatGPT Web, with a custom runtime path for other commands. It fits teams that need long-running coding work, auditable handoffs, and delivery/read/reply tracking, with runtime state stored in CCCC_HOME rather than the repository.

Run cccc attach . to bind a directory as the work scope, cccc setup to configure runtimes, and cccc actor add <id> --runtime <runtime> to create a foreman and peers. cccc group start launches actors; the daemon delivers cccc send and cccc tracked-send messages and appends messages and events to ledger.jsonl. Actors use the MCP collaboration core for inboxes, messaging, files, context, tasks, and state, while on-demand capabilities include cccc_repo, cccc_terminal, cccc_actor, cccc_automation, and remote-group access tools. The Web UI exposes chat, delivery/read state, embedded terminals, automation rules, and settings; bridges for Telegram, Slack, Discord, Feishu/Lark, DingTalk, WeCom, and Weixin expose coordination and status operations through IM.

  1. An engineering lead coordinating Claude Code and Codex CLI on one repository, with explicit read receipts and validation handoffs.
  2. A developer or team supervising long-running coding work from a phone through Telegram, Slack, or another supported IM bridge.
  3. A distributed team running CCCC groups on Windows, WSL, Macs, servers, or trusted teammate machines and using Group Bridge for explicit cross-group collaboration.
  4. An engineering organization that needs replayable message and event records to audit whether delegated work was delivered, read, acknowledged, and answered.
  5. A user who wants to bind a ChatGPT Web conversation as a development actor with browser delivery and a remote MCP connector.

What are this agent's strengths and limitations?

Pros
  • A single-writer daemon and append-only ledger.jsonl provide replayable, auditable message and event state.
  • Its coordination model includes routing, read cursors, attention acknowledgments, and reply-required obligations rather than only terminal prompting.
  • Web UI, CLI, MCP, and IM bridges share daemon-owned state, supporting both local terminal control and phone-based operations.
  • It supports 16 first-class runtimes plus custom, allowing combinations such as Claude Code, Codex CLI, and ChatGPT Web in one group.
Limitations
  • The default Python distribution requires Python 3.11+; the native distribution requires Rust 1.88+, and both cccc executables must not coexist on PATH.
  • The ChatGPT Web runtime depends on browser delivery, remote MCP, and a public HTTPS exposure; GPT-5.x Pro sessions cannot use this integration.
  • Daemon IPC has no authentication and binds to localhost by default; non-local Web exposure requires an Admin Access Token and a network boundary.
  • Group Bridge read and full access can let trusted remote groups inspect context or operate on a workspace, so permissions require careful administration.

How do you install or deploy this agent?

The default distribution requires Python 3.11+: pip install -U cccc-pair. The native Rust distribution requires Rust 1.88+: cargo install cccc --locked. Do not keep both cccc executables on PATH. Then run cccc; it starts the daemon and local Web UI by default. Open http://127.0.0.1:8848.

How do you use this agent?

From the target repository, run: cccc attach .; cccc setup; cccc actor add foreman --runtime claude; cccc actor add implementer --runtime codex; cccc group start. Send ordinary coordination with cccc send "Please inspect the repo and propose the first safe task." --to foreman. For a durable delegation, run cccc tracked-send "Please take the first concrete task and reply with validation evidence." --to implementer --title "First concrete task" --outcome "The change and validation evidence are reported". Run cccc doctor if an actor stays stopped. The ChatGPT Web runtime additionally requires exposing CCCC through a public HTTPS URL and configuring a remote MCP connector in one bound ChatGPT conversation.

How does this agent compare with similar options?

Compared with native agent teams such as Claude Code subagents/teams, CCCC adds cross-runtime groups, state that survives restarts, phone/IM operations, and an audit ledger. Compared with isolated parallel task runners, it emphasizes messaging, handoffs, acknowledgments, and daemon-owned coordination; the README positions pure DAG orchestration as a case for a dedicated orchestrator.

FAQ

Does it require a database, message broker, or Docker?
The README describes a one-install, zero-external-dependency setup with no database, message broker, or Docker required. Docker is offered as a separate deployment option.
How can I tell whether a delegated task was actually handled?
Ordinary messages have delivery state and read cursors. For work requiring a result and evidence, use cccc tracked-send, which tracks reply-required obligations.
What should I do before accessing it remotely?
The Web UI is high privilege. Create an Admin Access Token in Settings > Web Access before non-local exposure. Group Bridge starts message-only; grant read or full access only to trusted groups.
What if an actor does not start?
Run cccc doctor to check the environment and runtime availability. The README also directs first-run troubleshooting to its FAQ.
Can it replace a DAG workflow orchestrator?
No. The project describes itself as a collaboration kernel that can compose with CI/CD, orchestrators, and deployment tools; it recommends a dedicated orchestrator for pure DAG workflows.

Compare agents like this one

The same FARS review applied across the shortlist this agent qualifies for.

Related agents