CCCC

Coordinate your coding agents like a group chat

Read receipts, delivery tracking, remote group bridges, and mobile ops — for Claude Code, Codex, ChatGPT Web, and 13 more runtimes in one durable group.

Run multiple coding agents as a persistent, coordinated team across runtimes, machines, and trusted working groups — not a pile of disconnected terminal sessions.

One install command. No Rust toolchain or infrastructure required.

English | 中文 | 日本語

Why CCCC

Using multiple coding agents today usually means lost context in terminal scrollback, no distinction between a stored message, runtime handoff, Inbox consumption, and a reply, start/stop/recover operations scattered across tools, and no way to check on a long-running group from your phone. That's why most multi-agent setups stay fragile demos instead of reliable workflows.

CCCC runs your agents as one durable, coordinated system:

• Durable coordination — working state lives in an append-only ledger, not in terminal scrollback.
• Visible delivery semantics — routing plus separate stored, runtime-delivery, read, and reply facts replace best-effort prompting.
• One control plane — Web UI, CLI, MCP, and IM bridges all operate on the same daemon-owned state.
• Multi-runtime by default — Claude Code, Codex CLI, ChatGPT Web, Grok Build, and the rest of the first-class runtimes can collaborate in one group.
• Group Bridge for remote teams — trusted CCCC groups can exchange explicit messages and, when granted, inspect or work with each other's local resources.
• Local-first operations — one install command, runtime state in CCCC_HOME, and remote supervision only when you choose to expose it.

What CCCC Does

CCCC installs with one command and needs no database, message broker, or Docker. Yet it gives you the pieces fragile multi-agent setups usually lack:

Quick Start

Install

# Stable product distribution (recommended; Python 3.11+)
python -m pip install -U cccc-pair

# RC channel (TestPyPI)
python -m pip install -U --pre \
  --index-url https://test.pypi.org/simple/ \
  --extra-index-url https://pypi.org/simple/ \
  cccc-pair

The PyPI package is the stable, recommended CCCC distribution, with Python as its stable default implementation. On Linux x86-64, Intel/Apple Silicon macOS, and Windows x86-64, its platform wheel also includes a private, version-matched experimental Rust implementation for opt-in performance evaluation with cccc rust. Complete feature and integration parity is not promised; Rust is retained only as a bounded evaluation surface for measured native benefits. Use cccc python for reliability-critical workflows. An optional experimental standalone Rust preview is available for Rust-only deployment testing.

Upgrade

cccc update

Use cccc update --check to inspect the detected installation and update source. The recommended pip install updates the complete cccc-pair product from its detected PyPI channel. Experimental standalone installs update through the GitHub Pages installer. Both paths stop the active Web/daemon pair before replacing files.

Launch

cccc

Open http://127.0.0.1:8848 — by default, CCCC brings up the daemon and the local Web UI together.

In the recommended pip distribution, Python is the stable initial default until an implementation choice is saved. Rust is an experimental, explicit opt-in for performance evaluation. A bare cccc follows the persisted choice. Switch persistently, or switch and run a command in one step:

cccc status            # selected, running, and available implementations
cccc rust              # select experimental Rust, then launch CCCC
cccc python            # select stable Python, then launch CCCC
cccc rust doctor        # select experimental Rust, then run doctor

Switching is an explicit lifecycle operation: CCCC validates the target payload, stops the active Web/daemon pair, and never silently falls back to the other implementation. Agent runtime MCP configurations keep pointing at the stable public cccc launcher, so they follow later switches automatically. Use cccc python to return to the stable implementation at any time.

The experimental standalone distribution contains Rust only, so cccc python and implementation switching are intentionally unavailable there.

Create a multi-agent group

cd /path/to/your/repo
cccc attach .                              # bind this directory as a scope
cccc setup                                 # configure all available runtimes (or select one with --runtime)
cccc actor add foreman --runtime claude    # first actor becomes foreman
cccc actor add implementer --runtime codex # add a peer
cccc group start                           # start all actors
cccc send "Please inspect the repo and propose the first safe task." --to foreman
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"

You now have two agents collaborating in a persistent group with full message history, delivery tracking, and a web dashboard. The daemon owns delivery and coordination, and runtime state stays in CCCC_HOME rather than inside your repo.

What you should see: in the Web UI at http://127.0.0.1:8848, both actors show as running, the foreman's reply arrives in Chat, and the tracked request displays its delivery and read state on the message. If an actor stays stopped, run cccc doctor to check the runtime, and see the FAQ for common first-run fixes.

Programmatic Access (SDK)

Use the official SDK when you need to integrate CCCC into external applications or services:

pip install -U cccc-sdk
npm install cccc-sdk

The SDK does not include a daemon. It connects to a running cccc core instance.

Architecture

graph TB
    subgraph Agents["Agent Runtimes"]
        direction LR
        A1["Claude Code"]
        A2["Codex CLI"]
        A3["ChatGPT Web<br/>GPT-5.x via MCP"]
        A4["Grok Build"]
        A5["+ 12 more + custom"]
    end

    subgraph Daemon["CCCC Daemon · single writer"]
        direction LR
        Ledger[("Ledger<br/>append-only JSONL")]
        ActorMgr["Actor<br/>Manager"]
        Auto["Automation<br/>Rules · Nudge · Cron"]
        Ledger ~~~ ActorMgr ~~~ Auto
    end

    subgraph Ports["Control Plane"]
        direction LR
        Web["Web UI<br/>:8848"]
        CLI["CLI"]
        MCP["MCP<br/>(stdio)"]
    end

    subgraph IM["IM Bridges"]
        direction LR
        TG["Telegram"]
        SL["Slack"]
        DC["Discord"]
        FS["Feishu"]
        DT["DingTalk"]
        WC["WeCom"]
        WX["Weixin"]
    end

    subgraph Remote["Remote CCCC Groups"]
        direction LR
        RG1["Trusted group"]
        RG2["Another machine/team"]
    end

    A1 <-->|MCP tools<br/>PTY/headless| Daemon
    A2 <-->|MCP tools<br/>PTY/headless| Daemon
    A3 <-->|Browser delivery<br/>Remote MCP| Daemon
    A4 <-->|MCP tools| Daemon
    A5 <-->|MCP tools| Daemon
    Daemon <--> Ports
    Web <--> IM
    Daemon <-->|Group Bridge<br/>messages · read · full| RG1
    Daemon <-->|Group Bridge<br/>messages · read · full| RG2

Key design decisions:

• Daemon is the single writer — all state changes go through one process, eliminating race conditions
• Ledger is append-only — events are never mutated, making history reliable and debuggable
• Ports are thin — Web, CLI, MCP, and IM bridges are stateless frontends; the daemon owns all truth
• Remote groups are explicit trust edges — Group Bridge starts with message-only coordination, and read/full access must be granted per remote group
• Runtime home is CCCC_HOME (default ~/.cccc/) — runtime state stays out of your repo

Supported Runtimes

CCCC orchestrates agents across 17 first-class runtimes, with custom available for everything else. Each actor in a group can use a different runtime.

These are stable runtime entrypoints or surfaces. CCCC applies runtime-specific launch defaults automatically; actor/profile commands can be reviewed and customized in settings. The Supported Runtimes guide lists the default autonomy flags, including approval-bypass modes such as agy --dangerously-skip-permissions, grok --always-approve, and opencode --auto.

cccc setup --runtime claude       # auto-configures MCP for this runtime
cccc setup --runtime cline        # configures Cline CLI MCP for its PTY TUI
cccc setup --runtime cursor       # shows the prompt-assisted MCP setup contract
cccc setup --runtime kilo         # shows the prompt-assisted MCP setup contract
cccc setup --runtime antigravity  # shows the prompt-assisted MCP setup contract
cccc runtime list --all           # show all available runtimes
cccc doctor                       # verify environment and runtime availability

Actors can run as PTY (embedded terminal) or headless (structured I/O without a terminal). Claude Code and Codex CLI support both modes; headless gives the daemon tighter delivery and streaming control.

For setup commands, runner-mode guidance, and troubleshooting for every supported runtime, see the Supported Runtimes guide.

ChatGPT Web / GPT-5.x as a local development actor

ChatGPT Web can join a CCCC group as a real actor, not just an external chat window: CCCC delivers group messages into one bound ChatGPT conversation via browser delivery, and GPT-5.x calls back through an actor-bound remote MCP connector — receiving routed messages, replying visibly, editing repository files, and running scoped shell/git commands much like a native local coding agent. This also turns spare ChatGPT Web capacity into additional local-development agent capacity.

Setup requires exposing CCCC through a public HTTPS URL for the MCP connector (Cloudflare Tunnel, ngrok, Tailscale Funnel, or a reverse proxy). CCCC defaults to stable text-only delivery and also offers an experimental GPT Pro mode that attaches a tiny blank PNG when delivering each batch. This compatibility workaround does not switch ChatGPT models or guarantee connector availability, and may stop working when ChatGPT changes. Full setup and troubleshooting: ChatGPT Web Model Runtime.

Group Bridge: connect remote groups

Group Bridge extends CCCC from one local working group into a network of trusted groups. A group on your Windows workstation can coordinate with a group in WSL, a Mac, a server, or a teammate's CCCC instance without merging their runtime state or losing the local-first model.

Access is intentionally layered:

This makes CCCC useful for multi-machine work, lead/worker coordination across several environments, or trusted team collaboration where one group needs to ask another group for status, evidence, or implementation help. It is not a public guest-access feature: grant read/full access only to remote groups you trust with the target workspace.

Start from Settings > Group Bridge in the Web UI: one side generates a one-time pairing invitation, the other side submits it, and the issuer approves the request. After approval, remote groups appear as explicit recipients, and agents can discover available access with cccc_remote_access(action="list"). For setup steps, message flow, remote MCP tools, and troubleshooting, see the Group Bridge guide.

Messaging & Coordination

CCCC implements IM-grade messaging semantics, not just "paste text into a terminal":

• Recipient routing — @all, @peers, @foreman, or specific actor IDs
• Three explicit modes — Send for active delivery, Send + Reply for a concrete response, and Mail for non-interrupting Inbox delivery
• Separate facts — runtime.delivery, Mail read cursors, replies, cancellations, and task completion never impersonate one another
• Consuming Inbox reads — cccc_inbox_read returns the next ordered Mail batch and advances its Mail cursor atomically
• Reply & quote — structured reply_to with quoted context
• Reply requests — Send + Reply is tracked until the recipient responds or the sender cancels it
• Lifecycle boundaries — paused, stopped, or disabled actors are not silently awakened by delivery
• Remote group recipients — Group Bridge targets appear as explicit remote recipients instead of hidden broadcasts

Use Mail for useful agent updates that can wait, Send when delayed awareness would cost more than interrupting the recipient, and Send + Reply only when a concrete answer is also required. Mail cannot target the human user. One message addresses either user alone or one/more agents—send separate messages instead of mixing those audiences. Use tracked-send when delegated work needs a durable owner, outcome, evidence, handoff, or acceptance trail. @all remains available for announcements or urgent shared coordination, but it should not be the default way to start concrete work.

Push attempts travel through the daemon-managed delivery pipeline. Their runtime.delivery facts remain separate from Inbox read state and replies.

Automation & Policies

A small set of delivery timers and automation rules handles operational concerns without turning every message into a prompt:

Beyond built-in policies, you can create custom automation rules:

• Interval triggers — "every N minutes, send a standup reminder"
• Cron schedules — "every weekday at 9am, post a status check"
• One-time triggers — "at 5pm today, pause the group"
• Operational actions — set group state or control actor lifecycles (admin-only, one-time only)

Web UI

The built-in Web UI at http://127.0.0.1:8848 provides:

• Chat view with @mention autocomplete and reply threading
• Per-actor embedded terminals (xterm.js) — see exactly what each agent is doing
• Group & actor management — create, configure, start, stop, restart
• Automation rule editor — configure triggers, schedules, and actions visually
• Context panel — shared vision, sketch, milestones, and tasks
• Group Space — NotebookLM integration for shared knowledge management
• ChatGPT Web Model setup — connect one ChatGPT Web conversation as a CCCC actor
• Group Bridge setup — pair trusted remote groups and choose message/read/full access per connection
• IM bridge configuration — connect to Telegram/Slack/Discord/Feishu/DingTalk/WeCom/Weixin
• Settings — messaging policies, delivery tuning, terminal transcript controls
• Text scale — 90% / 100% / 125% font size with per-browser persistence
• Light / Dark / System themes

Remote access

For accessing the Web UI from outside localhost:

• LAN / private network — bind Web on all local interfaces: CCCC_WEB_HOST=0.0.0.0 cccc
• Cloudflare Tunnel (recommended) — cloudflared tunnel --url http://127.0.0.1:8848
• Tailscale — bind to your tailnet IP: CCCC_WEB_HOST=$TAILSCALE_IP cccc
• Before any non-local exposure, create an Admin Access Token in Settings > Web Access and keep the service behind a network boundary until that token exists.
• In Settings > Web Access, 127.0.0.1 means local-only, while 0.0.0.0 means localhost plus your LAN IP on a normal local host. If CCCC is running inside WSL2's default NAT networking, 0.0.0.0 only exposes Web inside WSL; for LAN devices, use WSL mirrored networking or a Windows portproxy/firewall rule.
• Rust launch uses --host / --port overrides first, then the saved Web Access binding (including legacy Python settings.yaml), then CCCC_WEB_HOST / CCCC_WEB_PORT.
• Save stores the target binding. If Web was started by cccc or cccc web, use Apply now in Settings > Web Access to perform the short supervised restart. If Web is managed by Docker, systemd, or another external supervisor, restart that service instead.
• Start / Stop are only for Tailscale remote access and do not rebind the already-running Web socket.
• Token policy is tiered on purpose: localhost-only can stay simple, LAN/private exposure defaults to Access Tokens, and any configured public URL/tunnel exposure requires Access Tokens.

Optional membership Reach is a managed public-HTTPS path for Linux and macOS preview users. Local CCCC remains fully usable without an account. First create an Admin Access Token in Settings > Web Access, then open the global Account page, link this installation, and approve its device code on the account site. Return to Web Access to turn Reach on. The equivalent CLI flow remains available:

cccc login
cccc reach on
cccc reach status
cccc reach off

Reach installs a pinned cloudflared helper under CCCC_HOME; it does not upload your ledger or repository. Windows helper installation is not bundled in this release, so Reach is currently unavailable on Windows.

IM Bridges

Bridge your working group to your team's IM platform:

cccc im set telegram --token-env TELEGRAM_BOT_TOKEN
cccc im start

Telegram, Slack, Discord, Feishu, DingTalk, and WeCom support progressive replies; overlong results fall back to lossless final-message chunks. Weixin delivers lossless final messages and currently supports direct bot chats only.

From any supported platform, use plain text or /send @foreman <message> for normal coordination, reserve /send @all <message> for true broadcasts, use /status to check group health, and use /pause / /resume to control operations — all from your phone.

CLI Reference

# Lifecycle
cccc                           # start daemon + web UI
cccc daemon start|status|stop  # daemon management

# Groups
cccc attach .                  # bind current directory
cccc groups                    # list all groups
cccc use <group_id>            # switch active group
cccc group start|stop          # start/stop all actors

# Actors
cccc actor add <id> --runtime <runtime>
cccc actor start|stop|restart <id>

# Messaging
cccc send "message" --to foreman
cccc tracked-send "delegated work" --to implementer --title "Task title" --outcome "Done criterion"
cccc send "announcement" --to @all  # explicit broadcast
cccc reply <event_id> "response"
cccc tail -n 50 -f             # follow the ledger

# Inbox
cccc inbox --actor-id <id>     # read and consume the next unread Mail batch

# Operations
cccc doctor                    # environment check
cccc setup --runtime <name>    # configure MCP
cccc runtime list --all        # available runtimes

# IM
cccc im set <platform> --token-env <ENV_VAR>
cccc im start|stop|status

MCP Tools

Ordinary actors always see a 14-tool collaboration core. Other built-in tools remain directly callable through cccc_capability_use, without exposing their full packs in every session. Web Model connectors and specialized assistants keep runtime-specific fixed surfaces where refresh or transport constraints require them.

The reduced core preserves the collaboration protocol while leaving workflow, reasoning style, and optional machinery to the agent and current task. cccc_help remains the on-demand reference for CCCC-specific state, recovery, delegation, and capability routes; it does not prescribe a general reasoning or writing method.

Where CCCC Fits

CCCC is a collaboration kernel — it owns the coordination layer and stays composable with external CI/CD, orchestrators, and deployment tools.

How CCCC Compares

CCCC does not replace your agents — it is the layer that makes them a team. Longer discussion: FAQ — How does CCCC compare?

Security

• Web UI is high-privilege. Before non-local exposure, first create an Admin Access Token in Settings > Web Access.
• Daemon IPC has no authentication. It binds to localhost by default.
• IM bot tokens are read from environment variables, never stored in config files.
• Runtime state lives in CCCC_HOME (~/.cccc/), not in your repository.
• Group Bridge is trust-based. Message-only bridges are the safest default; read/full access should be granted only to remote groups that may inspect or operate on the target workspace.
• Capability allowlist governs which optional MCP surfaces agents can enable. Policy is composed from a packaged default and an optional user overlay in CCCC_HOME/config/.

For detailed security guidance, see SECURITY.md.

Documentation

📚 Full documentation

Installation Options

pip (stable, recommended)

python -m pip install -U cccc-pair

This is the complete supported product distribution, with Python as its stable and recommended implementation. On Linux x86-64, Intel/Apple Silicon macOS, and Windows x86-64, pip selects a platform wheel that also contains a private, version-matched experimental Rust executable for opt-in performance evaluation. Other platforms receive the universal Python wheel; cccc status reports Rust as unavailable instead of pretending to switch.

Experimental standalone Rust preview

# macOS / Linux
curl -fsSL https://chesterra.github.io/cccc/install.sh | sh

# Windows CMD or PowerShell
powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12; Invoke-RestMethod 'https://chesterra.github.io/cccc/install.ps1' | Invoke-Expression"

Use this optional channel only when evaluating the experimental Rust implementation in a Rust-only deployment without Python. It downloads a checksum-verified binary from GitHub Releases and updates through the same installer, but it has no Python fallback or implementation switching and is not the recommended replacement for the stable pip/Python path. The current preview targets glibc 2.28+ Linux x86-64 without a system OpenSSL dependency, macOS 11+ on Intel or Apple Silicon, and Windows x86-64. The installer refuses to overwrite an existing cccc command that it does not own; uninstall that command deliberately or choose another CCCC_INSTALL_DIR first. Commands in other directories are left untouched. For the default install directory, the installer places the new command first in the user PATH and lists any remaining duplicates. Open a new terminal and run cccc doctor; its Installation section reports the invoked executable, the command selected by PATH, and every conflicting command.

The hosted native installer currently selects the experimental v0.4.35-rc1 standalone release. Stable users should use the pip distribution above.

pip (RC from TestPyPI)

python -m pip install -U --pre \
  --index-url https://test.pypi.org/simple/ \
  --extra-index-url https://pypi.org/simple/ \
  cccc-pair

Cargo installation is retained for workspace development, not as a supported end-user distribution.

From source

git clone https://github.com/ChesterRa/cccc
cd cccc
pip install -e .

uv (fast, recommended on Windows)

uv venv -p 3.14 .venv
uv pip install -e .
uv run cccc --help

Native Windows Notes

• For local development on Windows, prefer the repo-root start.ps1.
• If cccc doctor reports Windows PTY: NOT READY, run python -m pip install pywinpty or reinstall with uv pip install -e ..
• Use scripts/build_web.ps1 for the bundled UI and scripts/build_package.ps1 for a full package build.

Docker

cd docker
docker compose up -d  # then create an Admin Access Token in Settings > Web Access before exposing beyond localhost

The Docker image bundles Claude Code, Codex CLI, and Factory CLI. See docker/ for full configuration.

Upgrading from 0.3.x

The 0.4.x line is a ground-up rewrite. Clean uninstall first:

pipx uninstall cccc-pair || true
pip uninstall cccc-pair || true
rm -f ~/.local/bin/cccc ~/.local/bin/ccccd

Then install fresh and run cccc doctor to verify your environment.

The tmux-first 0.3.x line is archived at cccc-tmux.

Community

📱 Join our Telegram group: t.me/ccccpair

Share workflows, troubleshoot issues, and connect with other CCCC users.

Contributing

Contributions are welcome. Please:

1. Check existing Issues before opening a new one
2. For bugs: include cccc version, OS, exact commands, and reproduction steps
3. For features: describe the problem, proposed behavior, and operational impact
4. Keep runtime state in CCCC_HOME — never commit it to the repo

License

Apache-2.0