CCC

Your coding agents outgrew your terminal.

CCC puts every session on one local board and tells you which one needs you.

_Start the next while Claude builds the first._

“Hey Amir, great product. I tried about 20 before finding yours. I have been really enjoying it.”

— CCC user

One local dashboard that attaches to every Claude Code, Codex, Cursor, Antigravity, Kilo Code, Kimi Code, OpenCode, and Devin session on your machine, however you launched it — plus read-only ingestion of GitHub Copilot CLI, VS Code Copilot Chat, and Grok CLI sessions. Spawn, monitor, and ingest all eight; steer seven of them with follow-up. Local, source-available, free for non-commercial use.

📢 Shipping fast. Watch → Releases (top-right) to get pinged on new versions without the noise.

!CCC v5.29 showing the session fleet, an active agent conversation, one-tap orchestration controls, and a live lane map

Install with curl:

curl -fsSL https://raw.githubusercontent.com/amirfish1/claude-command-center/main/scripts/install.sh | CCC_FROM=readme bash

With Homebrew:

brew tap amirfish1/ccc
brew install ccc
ccc

Or download the macOS DMG and drag CCC.app to Applications: github.com/amirfish1/claude-command-center/releases/latest

Try the read-only demo first: ccc.amirfish.ai/demo (or amirfish1.github.io/claude-command-center/demo) - the full dashboard with seeded fake data, no install required.

See CCC at work

One board, eight engines Every Claude Code, Codex, Cursor, Antigravity, Kilo Code, Kimi Code, OpenCode, and Devin session lands on one board — however you launched it. CCC reads each engine's on-disk state, so even sessions you started by hand in a terminal show up.
	Flow canvas & Project tree Group sessions under named, nestable Flow objects — a hierarchical map of your day's work, with a live "Current sessions" triage band riding on top.
	Split conversations Drag any session onto the edge of an open transcript to read two agents side by side — each pane keeps its own input bar.
Find anything, from any session Full-text search across your entire session history, built in and zero-setup — with an optional semantic mode for when you can't remember the words you used.
	Sessions that coordinate without you Group chats keep two sessions on one goal in sync — post once and every participant is pinged, instead of you relaying output between terminals.
Durable queues, one inbox File work into named WatchTower queues instead of remembering what to ask which session. Tickets survive closed sessions, workers drain them in parallel, and the queue inbox shows what needs you.
	Workers that specialize over time Each worker reads its queue's shared learnings file before it starts and writes back when it ends, so a queue handling the same kind of ticket for months keeps getting faster, not just busier.
Work from anywhere The whole fleet on your phone — monitor sessions, answer agents, and steer from anywhere on your trusted network. Loopback by default, never the open internet.

Also in the box:

• More queue tooling — per-queue AI status briefs, GitHub-backed queues synced from issues, and one-click "create a queue for this session".
• Answer permission prompts from the dashboard — Claude Code's approve/deny prompts surface inline; CCC never interrupts a possibly-mid-turn session without your Approve.
• Board view (kanban, optional) — drag-drop columns derived from session state, with rubber-band multi-select. The list is the primary surface; the board is an opt-in lens.
• System status — a health modal over the whole fleet: restart-all, spawned-process cleanup, delivery receipts.
• Cost-aware cold-session composer — ranked cheaper routes (continue fresh on a lower tier, search history) instead of a blind expensive resume.
• FIRST FLIGHT tour — a spotlight walkthrough on first run, replayable any time from Settings.
• Settings modal — instant search (Cmd/Ctrl+,), keyboard navigation, per-section reset.
• Plan-to-fleet — import a plan or mission brief into a WatchTower queue and drain it with workers.
• Fresh worktree spawns — launch a session in -wt// on feat/, with optional init scripts.
• Headless spawn with follow-up — claude -p sessions you keep talking to from the browser, no terminal needed.
• Resume-on-demand — messaging a dormant session auto-spawns a headless resume to deliver it.
• Auto-fix deploys — polls Vercel, spawns a /fix-deploy session on new production errors.
• AI-assisted titles — regenerate a card's title via claude -p (Haiku by default).
• Orchestration skill + 12-skill pack — one Claude session can spawn, inject into, and synchronously ask sibling sessions over plain HTTP.
• Usage tracking — your pace against plan limits, per engine, with cache-adjusted token rankings, before you hit the wall. Per-session cost cards estimate weekly-quota contribution and show allocated subscription dollars next to the API list-price equivalent.
• Model deny-list — ~/.claude/command-center/model-policy.json blocks models across every picker, spawn path, and queue; WatchTower workers honor it too.
• /compact as a card — one self-narrating card with stage names, a live clock, and the tokens-freed payoff, instead of a spinner that could report a slow compaction as failed.
• Workers tab — Compact/Cozy/Detailed densities, a fixed-column grid, a WORKING NOW strip, and worker rows that appear before the engine session exists.
• Self-attaching agents — headless sessions launched outside CCC discover their parent session via process ancestry; ccc spawn and queue lanes appear in the list the moment they start.

CCC latches onto every Claude Code, Codex, Cursor, Antigravity, Kilo Code, Kimi Code, OpenCode, and Devin session on your machine: terminal sessions, headless processes, and sessions you spawned from the dashboard. It treats each agent's on-disk state as the source of truth, so nothing slips through. Spawn the next task while the first is still building. Switch between projects without losing context. Ship multiple things at once.

See the engine support matrix below for what each engine does. Spawn, monitor, and transcript ingestion work across all eight; follow-up (steering a dormant session) works on seven (Kilo Code is fire-and-forget), and Cursor IDE sync is metadata-only by design.

What you get

See your whole fleet, past one session. The way you build faster is a session per workstream: one on the feature, one on its go-to-market, one on the next feature, one on research. CCC puts every model and engine on one board, every row enriched so you read status without clicking in: a needs-you signal, live context left, a cost tier, and, with the Token Optimizer plugin, a quality score. Pin strategy sessions, nest workers under them, group by project, or lay the whole fleet out on a canvas.

Stop wasting tokens, keep quality where it matters. Your best model leads; execution fans out to cheaper models, or another platform entirely, through spawns, queues, and workers you point at any engine. CCC shows your pace against your plan's limits before you hit the wall, attributes a spend spike to the exact session or automation that caused it, and flags sessions running on a tier they don't need.

Sessions that exchange context on their own. Two sessions on one goal stay in sync through group chats and a sibling-ask API, instead of you reading one agent's output off one screen and retyping it into the other. Post once and every participant is pinged; ask a sibling synchronously when you need an answer right now; hand a problem to a fresh spawned session that reports back when it finishes.

Workers that specialize over time. Each worker reads its queue's shared learnings file before it starts and writes back to it when it ends, so a queue handling the same kind of ticket for months keeps getting faster and more accurate, not just busier. Ships via WatchTower, which CCC installs on first launch as its queue engine — Python 3.9+. WatchTower is a hard dependency: if it can't be installed, CCC fails loudly at startup with a clear error rather than silently running a stale queue.

Find anything, from any session. The problem you solved two weeks ago in some other session, found in seconds instead of solved again: full-text search across your session history, built in, zero setup, with an optional deeper semantic mode for when you can't remember the words you used. Covers Claude Code and Codex today.

Work from anywhere. Two sides of one opt-in: your phone as a client to the fleet, and CCC installed on any machine you can reach, a VM or a home server, open in any browser on your trusted network. Loopback by default, never the open internet.

Why this exists

Most Claude Code orchestration tools are opinionated wrappers. They want to own execution. You launch agents through them, and in return you get a dashboard. That's fine until it isn't. The moment you open a terminal, claude --resume something, and iterate on it by hand, you're outside the tool's universe. The dashboard can't see it. The work you just did doesn't show up on the kanban, against the issue, in the review queue.

This goes the other way. It treats Claude Code's on-disk state as the source of truth: ~/.claude/projects/*.jsonl transcripts, the ~/.claude/sessions/.json live registry, and per-tool-call sidecar files written by two hooks we install into ~/.claude/settings.json. If Claude Code is running anywhere on your machine, it shows up here. If you close the dashboard, your sessions keep running. If you open a terminal and iterate by hand, the card updates.

The dashboard also knows how to spawn headless sessions (via claude -p --input-format stream-json) and resume dormant ones on demand, but those are additive. The thing it's built around is attaching to work that already exists.

How it compares

| | CCC | Orca | Vibe Kanban | Conductor | Claude Squad | opcode | herdr | |---|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | Sees sessions you launched by hand, outside the tool | ✅ | ❌ | ⚠️ partial | ❌ | ❌ | ✅ | ❌ | | One dashboard across many agent engines | ✅ 8 spawnable + 3 read-only | ✅ | ✅ | ❌ | ✅ | ❌ | ✅ | | Tells you which session needs you | ✅ read from the transcript | ⚠️ finish notifications | ❌ | ❌ | ❌ | ❌ | ⚠️ status detection | | Sessions coordinate without you as the relay | ✅ group chats + sibling-ask | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | | Durable queues with workers that learn | ✅ WatchTower | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | | GitHub issue → session → verify → close loop | ✅ closes with commit-SHA comment | ⚠️ PR/issue browsing | ⚠️ PR-focused | ❌ | ⚠️ | ❌ | ❌ | | Survives closing the dashboard | ✅ the dashboard is a lens, not a runtime | ❌ | ⚠️ | ❌ | ✅ | ✅ | ✅ | | Mobile companion | ✅ full dashboard in your phone browser | ✅ native app | ✅ | ❌ | ❌ | ❌ | ❌ | | Worktree-per-task isolation | ❌ attach-first by design | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | | No account, no cloud, runs locally | ✅ stdlib Python, no build | ⚠️ | ⚠️ Postgres | ⚠️ | ✅ | ✅ | ✅ | | Setup | one curl line, or brew / DMG | desktop download | desktop / self-host | desktop download | terminal install | desktop download | terminal install |

Competitor cells reflect a survey of 20+ tools in this space (April–August 2026) — everyone ships weekly, so check their current docs before quoting. The one deliberate ❌: CCC doesn't own worktrees per task. It attaches to the work you already have instead of wrapping every run.

The whole point is the first row: the moment you touch a terminal, a tool that owns execution goes blind. CCC reads the state the engines already write, so it never does. Deeper dives: vs claude-squad / Conductor / Sculptor, vs heavyweight IDEs.

Recent

• 2026-09-13: v5.33.0. Codex conversations now render through the same live transcript view as every other engine — tool calls, diffs, images, and approval requests stream inline, and the separate native view is gone entirely. The Workers tab becomes a real table: Compact/Cozy/Detailed densities, a fixed-column grid, a WORKING NOW strip, and worker rows that appear the moment a worker spawns — before its engine session exists. Sessions now show what they actually cost: a weekly-quota estimate plus allocated subscription dollars next to the API list-price equivalent. /compact runs as one self-narrating card (stages, live clock, 112k → 16k tokens · −86%) instead of a spinner that could report a slow compaction as a failure. A machine-wide model deny-list (~/.claude/command-center/model-policy.json) blocks models across every picker, spawn path, and queue — WatchTower workers honor it too — and Devin's free SWE-2 family joins the model picker. Plus: externally-launched headless sessions auto-attach to their parent session, ccc spawn sessions appear in the list the moment they start, a 21-step first-run guide, kimi web as a supervised service, and ~70 fixes.

• 2026-08-28: v5.29.0. A follow-up for people running a real fleet: Simple Mode gives your phone a plain-language Home screen, the new orchestration rail lets you Delegate, Verify, or Critique and then watch the lanes work, and the model catalog now shows live Codex pricing and limits alongside the other engines. Recent-work search now scans local Claude, Codex, Kimi, Gemini, and Cursor transcripts directly. The sidebar also gets its overdue polish pass: readable row styles, wrapping, a clear selected state, and correct icon alignment.

• 2026-08-10: v5.21.0. A mobile and reliability release. The phone dashboard got a full responsiveness pass — conversations open ~6× faster (2476ms → 395ms), the sidebar scrolls as one surface instead of trapping your finger in three panels, the new-session composer stops pushing its send button off-screen, and the list chrome condenses so far more sessions fit on a phone screen. On reliability: CCC no longer interrupts a possibly-mid-turn session on its own (automatic interrupt paths now file an approval ask), a global delivery-health banner surfaces lost WatchTower receipts, Kimi/Devin queues stopped wedging after mid-turn crashes, and trashed sessions stopped resurrecting for a few minutes after the click. Plus a cache-adjusted token headline in the status rail, a connection-type chip in the metadata rail, 1D/2D/7D cache-adjusted session ranking in the throughput sidebar, and a Kimi quota line in the combined throughput chart.
• 2026-08-07: v5.20.0. Devin joins as the eighth engine, now fully spawnable via its local CLI (devin -p) with headless spawn, resume, and transcript ingestion from its SQLite store — cloud API sessions stay read-only. Plus a per-repository new-session button in the sidebar, a private queue/worker diagnostic Q2 can send in one click, and a broad reasoning-effort picker rollout across every composer surface.
• 2026-07-20: v5.9.0. Kimi Code joins as the sixth engine (spawn, steer, live token streaming, guided setup in Settings). Plus a FIRST FLIGHT onboarding tour, a searchable full settings modal (Cmd/Ctrl+,), a cost-aware cold-session composer that offers ranked cheaper routes instead of a blind expensive resume, a 12-skill orchestration pack, plan-to-fleet queue import, and a perf pass that gets new sessions into the list in seconds.
• 2026-06-25: v5.4.0. Project tree: the "By objects" sidebar now splits a live "Current sessions" triage band over a hierarchical map of your day, sessions grouped under nestable, draggable Flow objects. Plus a new /api/sessions/events SSE stream (subscribe to session-state changes instead of polling) and a broad Codex, sidebar, and Total Recall search polish wave.
• 2026-06-03: v4.6.0. Major performance pass: the dashboard idles instead of pinning a CPU core, group-chat opens ~40x faster, long conversations open near-instantly (windowed load + scroll-up to load earlier), and Codex sessions with screenshots no longer stall on multi-MB images. New CCC self-health readout in the footer.
• 2026-05-21: v4.0.0. Antigravity (Google DeepMind) joins the dashboard as a first-class engine alongside Claude Code and Codex.
• 2026-05-21: Drag any conversation row outside the window to pop it into a focused side pane, with 24 per-conversation accent colors.
• 2026-05-19: Template gallery mechanism for reusable new-session prompts, driven by static/templates.json. (#46)
• 2026-05-19: VS Code extension v0.1.0 published, spawn a session from the active workspace folder. (#52)
• 2026-05-19: One-command curl | bash installer; git clone demoted to a "From source" section. (#58)
• 2026-05-19: Static GitHub Pages demo with seeded mock data (no install required). (#49)
• 2026-05-18: Local macOS say text-to-speech button on conversations.

If you install it, I'd love to hear how. Drop a ⭐, open an issue with

what worked or what broke, or just say hi. This is a one-person project

built around a specific workflow. Outside feedback is the only way I know

how widely it lands. @amirfish1

Quickstart

Try the demo: ccc.amirfish.ai/demo: the read-only dashboard with seeded fake data, no install required.

Requirements: Git and Python 3.9+. Install at least one supported agent CLI to launch sessions: Claude Code, Codex, Gemini, or Antigravity. The dashboard itself starts without an agent CLI. Optional: gh for GitHub integration, vercel for deploy status. Linux is supported for headless / remote-box use (see Running on Linux); the macOS-only desktop conveniences degrade cleanly there. Windows is supported for native foreground use with PowerShell, and WSL2 remains the best route if you want the Linux service path.

curl: clones into ~/.ccc/claude-command-center and runs in foreground. Re-running does a git pull.

curl -fsSL https://raw.githubusercontent.com/amirfish1/claude-command-center/main/scripts/install.sh | CCC_FROM=readme bash

Windows PowerShell: clones into %USERPROFILE%\.ccc\claude-command-center and runs in foreground. Re-running does a git pull.

irm https://raw.githubusercontent.com/amirfish1/claude-command-center/main/scripts/install.ps1 | iex

Homebrew — installs into the Cellar, puts ccc on PATH, pins a brew-managed Python. Upgrade via brew upgrade ccc.

brew tap amirfish1/ccc
brew install ccc
ccc                              # foreground
brew services start ccc          # or run as a brew-managed background service

DMG — drag the app to Applications and double-click to launch. On first launch, the signed and notarized app installs its local source into ~/.ccc/claude-command-center, shows progress, and opens the dashboard when its loopback server is ready. Installation errors include the real log plus Retry, Open Log, and Quit actions. CCC does not automate Terminal or request macOS Automation access. Download the latest release.

If you'd rather clone first and run the script directly, pass the channel as a flag instead: ./scripts/install.sh --from=readme.

The ccc CLI

Once CCC is running, the repo-root ccc script answers "what sessions exist and what are they doing" in one command — no dashboard needed:

ccc sessions              # live census: state, age, engine, repo, name
ccc list-sessions --since 5h   # only sessions active in the window
ccc sessions --json       # machine-readable census
ccc models                # every engine's models, effort ladders, cost,
                          # release dates where the id carries one
ccc quota                 # weekly quota left per engine + when it resets
ccc doctor                # per-engine CLI/auth/BYOK health, dry-run only
ccc spawn "fix the flaky login test" --engine claude --model opus-5
ccc spawn "drain the queue" --report-to <your-session-id>   # reports back
ccc send queue-drain "also update the changelog"   # fire-and-forget
ccc send <session-id> "stop, wrong branch" --steer # interrupt the turn
ccc ask queue-drain "what's your status?"          # block for the reply

It finds the server via ~/.claude/command-center/port.txt (override with --server or $CCC_SERVER) and shows every live session — including spawned children (indented under their parent) and sessions the dashboard has no conversation row for. ccc spawn is the orchestration entry point: it posts to /api/sessions/spawn scoped to your current directory (override with --cwd), and ccc models lists the live per-engine model catalog so agents never have to guess a --model id. ccc send and ccc ask message any running session — fire-and-forget or blocking for the reply — addressed by session id, a unique id prefix, or a unique fragment of the name shown in ccc sessions. The installer links it to ~/.local/bin/ccc; from a checkout you can also run ./ccc. With no subcommand, ccc passes through to run.sh (the same launching behaviour as the Homebrew ccc).

WatchTower comes with it

WatchTower (wt) is CCC's queue engine, not an optional add-on — it owns ticket lifecycle, worker dispatch, plan-to-fleet import, and delivery receipts. Every install path installs it: the curl and PowerShell installers do it up front, and run.sh bootstraps it on first launch, so Homebrew, the DMG, Docker, and a plain git clone all end up with it too.

One script, scripts/install-watchtower.sh, owns the whole chain: an existing local checkout ($WATCHTOWER_DIR, ~/Apps/watchtower, ~/dev/watchtower) first, then a shallow clone at ~/.ccc/watchtower, then a source tarball, and only as a last resort the watchtower-cli package on PyPI — that release lags the repo, so it is a floor rather than the target. It installs into the same interpreter that runs server.py (CCC imports watchtower.queue in-process, which is why this can't be a pipx install), then runs wt start so the daemon survives reboot and login. It needs Python 3.11+; on an older interpreter CCC skips it and runs on a built-in fallback queue engine that can file tickets but will not dispatch workers, import plans, or issue receipts.

Updates: the clone CCC owns is fast-forwarded at most once a day. A checkout of your own is never pulled — it is a working tree that may hold uncommitted work, so if it is behind its upstream CCC says so and leaves it alone.

Set CCC_SKIP_WATCHTOWER=1 to opt out. If wt ends up installed but not on your PATH, the dashboard still works — only the CLI surfaces stay hidden — and the installer prints the directory to add.

From source

git clone https://github.com/amirfish1/claude-command-center
cd claude-command-center
Try it. Runs in the foreground until Ctrl-C / terminal close
./run.sh
Keep it. Install as a per-user launchd agent that starts now and at login
./run.sh --install-service

Open http://localhost:8090, then pick a repo from the repo dropdown before starting repo-scoped actions.

--install-service writes separate dashboard and persistent-worker launch agents under ~/Library/LaunchAgents/. The worker has an independent lifecycle so dashboard upgrades do not make it part of the dashboard's process tree. Both start immediately and again at macOS login. The installer bakes in whatever PORT / CCC_* env vars were set when you ran it. Re-run it to update config; check with ./run.sh --service-status; remove with ./run.sh --uninstall-service. Dashboard logs use ~/.claude/command-center/logs/service.{out,err}.log; worker logs use worker.{out,err}.log. Normal CCC app updates keep using the same checkout path; re-run ./run.sh --install-service only when you want to change baked-in env vars or pick up a release that changes the launchd plist itself.

Running on Windows

CCC runs natively on Windows as a foreground PowerShell process. The dashboard, session ingestion, repo picker, and agent spawn paths use the same Python server as macOS/Linux. macOS-only desktop conveniences (screenshots, jump-to-terminal, native folder picker, Finder reveal, desktop deep links) are hidden on Windows the same way they are on Linux.

git clone https://github.com/amirfish1/claude-command-center
cd claude-command-center
Try it. Runs in the foreground until Ctrl-C / terminal close
.\run.ps1
Optional: open the dashboard as a chromeless Chromium app window
.\run.ps1 --app

Open http://localhost:8090, then pick a repo from the repo dropdown before starting repo-scoped actions. Native Windows service install is not implemented yet; keep the PowerShell window open or run .\run.ps1 under your preferred process manager.

If you prefer Linux-style service management on Windows, run CCC inside WSL2 and use the Linux instructions below.

Running on Linux

CCC runs on Linux as a headless service you reach from the browser on another machine. The core (the session board, ~/.claude transcript ingestion, session spawn and drive) works the same as on macOS. The native folder picker works on Linux desktops too when zenity, kdialog, or yad is installed; on headless boxes the Browse buttons fall back to an in-browser picker that walks the server filesystem. The remaining macOS-only desktop conveniences (screenshots, jump-to-terminal, open-in-desktop) are not available on Linux yet; the UI hides those controls automatically, so you never see a button that does nothing.

Windows users who want a systemd-managed service can use this Linux path under WSL2. Install Python 3, git, and your agent CLIs inside the WSL distro, then open http://localhost:8090 from the Windows browser after ./run.sh starts.

git clone https://github.com/amirfish1/claude-command-center
cd claude-command-center
Try it in the foreground
./run.sh
Keep it. Installs a systemd user service that starts now and at login
./run.sh --install-service

--install-service writes independent ccc.service and ccc-worker.service systemd user units under ~/.config/systemd/user/. The dashboard wants the worker but does not own its control group, so restarting the dashboard leaves the worker running. Check both with ./run.sh --service-status (or systemctl --user status ccc ccc-worker), follow logs with journalctl --user -u ccc -f, and remove it with ./run.sh --uninstall-service. On a headless box with no active login session, run sudo loginctl enable-linger $USER once so the service survives logout and starts at boot. If systemctl is not available, run CCC in the foreground or under your own process manager instead. A foreground ./run.sh also ensures a detached worker is running before it starts the dashboard; its logs use ~/.claude/command-center/logs/worker.{out,err}.log.

In WSL2, ./run.sh --install-service requires a distro with systemd enabled. If your WSL distro does not expose systemctl --user, keep CCC in the foreground with ./run.sh or run it under your own process manager.

To reach the dashboard from another machine, see SECURITY.md for the CCC_BIND_HOST and same-origin options before exposing the port.

First launch (foreground or service) copies two hook scripts into ~/.claude/command-center/hooks/ and registers them in ~/.claude/settings.json. After that, every Claude Code session on your machine (terminal, headless, or dashboard-spawned) writes sidecar state the UI uses for the kanban.

Core concepts

┌─────────────┐   writes   ┌────────────────────────────────┐
│ any claude  │ ─────────> │ ~/.claude/projects/*.jsonl     │
│ process     │            │ ~/.claude/sessions/<pid>.json  │
│ anywhere on │            │ ~/.claude/command-center/          │
│ your machine│            │   live-state/<sid>.json        │
└─────────────┘            └──────────────┬─────────────────┘
                                          │  reads
                                          v
                              ┌───────────────────────┐
                              │ server.py (stdlib)    │
                              │ :8090                 │
                              └───────────┬───────────┘
                                          │
                                          v
                              ┌───────────────────────┐
                              │ static/index.html     │
                              │ session list + detail │
                              └───────────────────────┘

• Session: any Claude Code transcript on disk, alive or dormant.
• Attach: the server reads Claude's own files + sidecar state the

• Board columns (optional board view): Backlog → Planning → Working →

• Backlog: open GitHub issues + TODO.md entries, surfaced as cards

• Objects & the Project tree: group sessions under named, nestable

Codex conversations

Codex conversations render through the same shared transcript view as every other engine — one pane, one composer, one renderer. A live overlay merges in-progress turns into the transcript as they happen: tool calls, diffs, images, and approval requests stream inline. Capability availability follows the installed Codex version and connected host. Existing desktop-owned tasks connect through their desktop owner when available. See the Codex conversation guide for connection limits, preview features, queue ownership, and verification coverage.

Engine support

CCC was built around Claude Code first; Codex, Cursor, Antigravity, Kilo Code, Kimi Code, OpenCode, and Devin support followed. Spawn-from-dashboard works for all eight. The rest varies:

| Engine | Spawn (headless from UI) | Resume (terminal inject / headless resume) | Transcript ingestion | Per-session model + reasoning-effort picker | |---------------|--------------------------|--------------------------------------------|----------------------|--------------------------| | Claude Code | yes | yes (both) | yes — first-class JSONL (~/.claude/projects/*.jsonl) | yes — UI picker, incl. 1M-context toggle; effort low medium high xhigh max | | Codex | yes | yes (both) | yes — JSONL ingestion; when the app-server bridge is connected, live turns stream into the shared transcript view (tools, diffs, approvals) | yes — UI picker via per-session override; default from CCC_CODEX_MODEL; effort low medium high xhigh (no max) | | Cursor | yes — headless via cursor-agent | yes — follow-ups route through cursor-agent --resume | partial — Cursor agent transcripts parsed from ~/.cursor/projects/ | model only — UI/default picker, default from CCC_CURSOR_MODEL; no effort ladder | | Antigravity | yes — headless via agy print mode | yes — follow-ups route through AGY CLI or the running app's language-server RPC | yes — JSONL transcripts from ~/.gemini/antigravity/brain/ | model auto-detected from transcript metadata; no effort ladder | | Kilo Code | yes — headless via kilo run --auto | no — fire-and-forget headless run, no resume wiring yet | yes — reads Kilo's SQLite store (~/.local/share/kilo/kilo.db); externally-launched sessions appear on the board | model only — UI/default picker, default from CCC_KILO_MODEL; no effort ladder | | Kimi Code | yes — ACP client over kimi acp, token-level live streaming | yes — steer live ACP sessions with inline permission-prompt answers; attach for TUI sessions | yes — reads ~/.kimi-code/sessions/; live list and archive | yes — UI/default model picker; default from CCC_KIMI_MODEL; effort ladder read from Kimi's own config.toml (support_efforts) | | OpenCode | yes — headless via opencode run --auto | yes — follow-ups route through opencode run --session --auto | yes — externally-launched OpenCode (opencode.ai) sessions appear on the board | model only — UI/default picker, default from CCC_OPENCODE_MODEL; no effort ladder | | Devin | yes — local CLI, headless via devin -p | yes — local CLI resumes via devin --resume -p; cloud API sessions (devin- prefix) stay read-only | yes — local CLI sessions (devincli- prefix) parsed from its SQLite DB (message_nodes); cloud API sessions listed read-only when DEVIN_API_KEY is set | no |

Where an engine has no effort ladder, CCC hides the effort control rather than guessing one, and drops a reasoning_effort sent to it over the API. The live per-engine ladders are published at GET /api/engines/models under efforts_by_engine.

Three further engines are ingested read-only today: GitHub Copilot CLI, VS Code Copilot Chat, and Grok CLI sessions appear on the board with their transcripts, but can't be spawned or steered from the dashboard yet.

Note on Cursor IDE integration: While CCC spawns Cursor agents headlessly via the CLI, the Desktop IDE manages UI state internally using a highly-nested, proprietary Protobuf Merkle tree in store.db. Full "two-way chat sync" into the IDE is unsupported due to the extreme risk of workspace corruption. Instead, CCC performs a metadata integration: CLI sessions are injected into the IDE sidebar as bookmarks (with correct titles and timestamps) so you don't lose track of them, but they cannot be interacted with natively inside the IDE window. Use the CCC dashboard for full history.

If you'd like to see an engine bumped from "partial" to first-class, open an issue — it's mostly adapter work, the ingestion layer is engine-agnostic.

Bring your own key (BYOK)

Paste provider API keys once in Settings → Engines and route spawns through them instead of whatever local CLI auth an engine already has. Keys are stored per profile (name them however you like — work, personal, client-x) so different projects can use different keys.

• Storage: the macOS Keychain (security, service ccc-byok) when

• Supported providers: Anthropic, OpenAI, OpenRouter, TokenRouter, xAI,

• Routing OpenRouter/TokenRouter models: OpenCode accepts model ids in

• Per-spawn profile: the /api/sessions/spawn payload accepts

• Cost visibility: GET /api/engines/models marks BYOK-backed models

• Current scope: env injection is wired for **OpenCode, Droid, and

• Health check: ccc doctor (or GET /api/engines/doctor) reports,

!Settings → Engines: BYOK panel with an add-key form, profile list, and a 30-day spend summary

Features

• One board, eight engines: spawn, resume, and review Claude Code, Codex, Cursor, Antigravity, Kilo Code, Kimi Code, OpenCode, and Devin sessions from one dashboard. See the engine support matrix for per-engine parity. Kimi Code has a guided setup flow in Settings → Engines that detects the CLI, walks through install and kimi login, and verifies with a smoke-test spawn.
• Cost-aware cold-session composer: when a session is large and stale, the send button is replaced by ranked routes — continue in a new session on a cheaper tier, search history, copy session id — with the full (expensive) resume demoted to a priced link. Routes are ranked by intent: question-shaped text promotes search, task-shaped text promotes continuing fresh.
• FIRST FLIGHT tour: a spotlight walkthrough of the dashboard on first run, with newcomer and multi-engine paths and sample cards on empty installs. Replay any time from Settings.
• Settings modal: the gear menu is a full settings modal with instant search (Cmd/Ctrl+, to open), keyboard navigation, and per-section reset — appearance, layout, sessions, fleet & network, tools, maintenance, help.
• Plan-to-fleet: import a plan or mission-brief document into a WatchTower queue from the dashboard — preview the tickets wt import extracts, file them on confirm, optionally drain with a worker.
• ACP adapter (optional): expose CCC over the Agent Client Protocol so editors and ACP clients (VS Code, JetBrains, Zed, and agents like Hermes) can drive Claude Code sessions over JSON-RPC stdio. Runs as a separate process (python3 ccc_acp.py); install with the acp extra. The core server stays stdlib-only.
• Board view (kanban, optional): every session on drag-drop columns

• Project tree: the sidebar's By objects view stacks a live

• Split conversations: drag any sidebar session onto the right or

• GitHub integration: start a session from an issue with one click

• Attach to existing sessions: terminal claude processes show up

• Open in Claude Desktop (macOS): third destination button beside

• Fresh worktree spawns: toggle worktree mode to launch a session in

• Headless spawn with follow-up: launch claude -p sessions from the

• Resume-on-demand: injecting into a dormant session auto-spawns a

• Auto-fix deploys: optionally polls Vercel, spawns a /fix-deploy

• AI-assisted titles: click ✨ on any card to regenerate its title

Decision Inbox

Stalled work should not become your problem again. Once an hour CCC scans for what is stuck, does the thinking with a cheap analyst, and leaves you a three-option card. You click one; CCC spawns or steers the follow-through.

Sources scanned each run:

• Strategy board (optional): a markdown table with Task | Status | ETA

• WatchTower queues: queues that are stuck with open tickets older than

• Idle sessions: live sessions idle for more than idle_hours whose last

The token governor runs in the same pass over live sessions only and flags the ones burning tokens for nothing: the same tool error repeated three times, no file edits for 45 minutes while still working, or context at 85% with no compaction. Each finding gets one-click Nudge (steer a reset instruction in), Pause (interrupt the turn), or Kill.

Anti-spam: at most five new cards per run, and a source that already has an open card, or was decided or dismissed in the last week, is skipped.

!Decision Inbox: a token-governor strip flags a session at 98% context with Nudge/Pause/Kill, above three-option decision cards for stalled WatchTower queues and board items, one option recommended

Open it from the Decisions icon in the app rail or at /decision-inbox.html. Configure in ~/.claude/command-center/decision-inbox.json:

{
  "strategy_board": "~/notes/Strategy Board.md",
  "interval_s": 3600,
  "max_cards_per_run": 5,
  "idle_hours": 2,
  "wt_age_days": 3,
  "model": "claude-sonnet-5",
  "spawn_cwd": "~/projects"
}

External producers (a digest job, a monitor, a cron) can file their own cards: POST /api/decision-inbox (alias /api/decision-inbox/cards) with {"source": "digest", "source_id": "studio-a:no-sessions", "title": "...", "detail": "...", "severity": "warn", "options": [...]}. The reply is {ok, card_id, deduped}. Cards dedupe by source:source_id, so a producer that fires every run holds one open card that counts repeats. Omit options to get the default trio: acknowledge, spawn an investigator, or snooze for 24 hours.

Set CCC_DECISION_INBOX_DISABLED=1 to keep the loop off entirely. Cards and run history live in ~/.claude/command-center/decision-inbox/. API: GET /api/decision-inbox, POST /api/decision-inbox/{run,decide,dismiss,governor}.

Kimi Knowledge Bridge

Kimi Code sessions can become searchable in Total Recall without copying them into another agent's session format or writing Total Recall's database. CCC exports one privacy-filtered Markdown brief for each Kimi session, then connects that folder through Total Recall's dashboard API.

From a CCC checkout, export the current Kimi sessions:

python3 scripts/kimi-recall-bridge.py sync

Connect the generated folder to Total Recall once (this runs the supported total-recall ingest command):

python3 scripts/kimi-recall-bridge.py connect

To keep it current on macOS, explicitly install the opt-in five-minute LaunchAgent:

python3 scripts/kimi-recall-bridge.py install-launchd

The bridge writes to ~/.ccc/total-recall/kimi-code by default. It retains Kimi's session ID, project, model, and timestamps, but intentionally excludes system prompts, thinking blocks, and tool input/output. These are knowledge documents rather than native Total Recall session rows; native Kimi ingestion is tracked upstream in Total Recall issue #18.

Orchestration skill

CCC ships a Claude Code skill (ccc-orchestration) that lets one Claude session spawn, inject into, and synchronously ask sibling sessions over plain HTTP. On top of it sits a 12-skill orchestration pack (skills/README.md) that turns spawn/inject/ask into concrete workflows — pair-verify, standup, second-opinion, bug-race, docs-drift, release-audit, and more — each with stated spawn cost, a dry-run mode, and an honest fallback when CCC is down. On startup the server copies the skill to ~/.claude/skills/ccc-orchestration/SKILL.md (set CCC_SKIP_SKILL_INSTALL=1 to opt out) and writes its base URL to ~/.claude/command-center/port.txt so the skill can discover the running instance without hardcoding a port.

Spawn calls pass repo_path (or cwd) plus optional engine: "claude" | "codex" | "cursor" | "antigravity" | "kilo" | "kimi" | "opencode", model, and reasoning_effort to /api/sessions/spawn; omitted engine/model/effort values use the server-side defaults from the dashboard. The effort ladder is per engine (Claude low…max, Codex low…xhigh, Kimi whatever its own config declares

... (README truncated for length)