ccx

Development biography · earlier archive

Development profile compiled from project source and retained records in October 2026. Dates and test results describe those records; they do not imply a new build, live acceptance test or public release.

Biography

The problem. By September 2026 Douglas was running Claude Code and OpenAI's Codex daily, often on the same repositories. A dozen community projects promised to connect them: plugins that let one agent call the other, shared memory, edit-claim boards, session hand-offs. Each touched his global configuration differently, and their READMEs didn't always match their code. Two agents editing the same checkout without coordination also produced real overlap problems, most visibly in his large AssistantApp project.

Origin. ccx 0.1.0 (2026-09-24) was a "routing console". It audited eleven repositories from source at pinned commits and showed every option they expose. It built a plan for wiring Claude and Codex together on a "patch bay": channels such as Claude asks Codex, Shared memory and Edit claims, each patched with one component at a stage (study, evaluate, pilot, adopt). Each component got a checked install, a verify checklist and a restorable snapshot. The two screenshots below are from this era.

What it became. Over the following weeks ccx moved from configuring the agents to working alongside them:

• Chat. Real Claude Code sessions (claude -p stream-json) and Codex threads (codex app-server) run in one transcript view. Approvals, questions and plans arrive as cards. There are worktree chats, forks, attachments, voice replies, and a dock with terminals, plan and code.
• Missions. One agent implements in an isolated copy, the other reviews the exact patch, and nothing reaches the mission branch until the person integrates it. A review contract is written first, checks run sandboxed with no network, review is bound to the patch hash, and runtime-sealed receipts and commit trailers record who did what.
• Workflows. Presets (Second Opinion, Test Engineering, Code Review and others) take a task through contract → explore/plan → implement → evidence → review → decision. Each phase is given to Claude, Codex or both "blind". Since 2026-10-07 each run keeps its own ROADMAP section ticked off phase by phase.
• Peers. Claude Code and Codex sessions on the Mac can message and delegate to each other, with loop guards. A message is always a teammate's request, never the person's approval.
• Canvas. Projects, their modules and their chats, colour-coded with project icons, filters, an overlap view built from per-turn file "custody", and a housekeeping card fed by MacResilience.
• Workers. Scheduled roles: SDK watch, a doc-status (TAGS) worker that drafts status updates with free local models for the person to accept, an icon worker, and housekeeping.
• Research. Read-only research chats apart from projects. Local embeddings suggest related projects.

Audience. One person: Douglas, on his own Mac. It isn't packaged for others. Its rules assume a single owner who approves everything. Subscription CLI use inside it is personal use.

Distinctive ideas.

• Approval is never delegated. Agents (including other agents' messages) can ask, preview and propose. Approving, integrating, accepting findings and widening scope stay on the person's page.
• Evidence over assertion. Checks are fingerprinted against what they depend on and go stale honestly. A step that can't be observed finishes as "Ran, not verified". Records are append-only and atomically written.
• Two models, cross-checked. The design leans on disagreement: blind parallel analyses, a reviewer who sets acceptance checks before code exists, and hand-over mid-change from one model to another with a briefing written from the journal.
• Local and cheap first. Background drafting, classification and embeddings go to free local models (aa-gpu: Apple on-device, Ollama qwen3). Claude and Codex are used only when asked.

A concrete user journey.

• On the Canvas, Douglas clicks "+" to start a project.
• ccx creates the project archive with a ROADMAP.md, suggests a workflow preset, and starts a run in its own worktree.
• Codex writes the task contract; Claude critiques; Codex implements; ccx runs the contract's evidence commands sandboxed.
• A blocking critique sends it back for a second attempt. The roadmap section shows "attempt 2" and why.
• When the evidence passes and no reviewer blocks, the run is "ready" and Douglas accepts it. ccx commits on the run's branch; merging stays his.
• Meanwhile the canvas shows which chats touched which files. The housekeeping card says whether removing that worktree later would lose anything.

Main features: what a visitor could see

Authored by the ccx project:

• Home patch bay and Installed pages: see screenshots. Wiring per channel, next step, checks, clients.
• Chat page: transcript, approval/question/plan cards; Codex MCP forms, permission-grant cards, goal bar, usage card (2026-10-07); "Run in the cloud" for GitHub projects (2026-10-10). No screenshot exists.
• Missions, Workflows, Canvas, Research, Peers, Workers, Projects, Memory, Snapshots, Activity, Verify (receipts): no screenshots exist.
• Spoken replies (ccx-vocal, tools/vocal-expression) and "Ideas, heard" (renders a short musical score to .m4a via tools/midi-express, behind a MIDI firewall): no website-safe samples exist; see §7.

Dependencies, not authored by ccx:

• Claude Code CLI, Codex CLI/app-server, git.
• Optional third-party components ccx installs and verifies: openai/codex-plugin-cc, hex1n/cc-plugin-codex, ozankasikci/global-agent-memory, dan-calin/shared-agent-memory, sharememory, a codex-team-bridge and others, pinned under catalog/ and eval/src/.

Technical foundations

• Server: Node, ESM, no npm dependencies. bin/ccx.mjs (CLI), app/server.mjs (HTTP + SSE on 127.0.0.1 with a per-launch token), app/js/ (no-framework UI under a strict CSP), mcp/server.mjs (stdio MCP server exposing ccx_ tools to agents).
• Core libs in lib/: missions, workflows, chat / chat-codex, peers, custody, canvas, housekeeping, mr-provider, doc-worker, icon-worker, research, relate, run-roadmap, cloud, terminals (pty via lib/pty-host.py).
• Native: app-mac/main.swift is a WKWebView wrapper built by scripts/build-app.sh and signed with the studio’s Developer ID. app-ios/ is the iPhone companion, paired over the TLS "remote" API (lib/remote.mjs) with a pinned certificate and per-device revocable tokens.
• Integrations:
• aa-bridge (Swift AssistantAgent mission runtime);
• aa-gpu at 127.0.0.1:11500 (free local models and embeddings);
• MacResilience MCP helper, through a read-only allowlist with readOnlyHint checked and its build pinned;
• tagkit/md-tags (DocStatus);
• CBOR-LD evidence packets for workflow runs.
• Safety model: one lock across UI/MCP/CLI, snapshot before change, confirm-first, owner-only evidence folders, compare-and-swap settings.

Maturity by feature (evidence; unknown marked)

The full suite at 2026-10-10 was 341 tests, 340 passing. The one failure was another session's allowlist change.

Roadmap, limits, FAQs

Roadmap (from docs/plans and open work, not commitments):

• current screenshots and a public write-up;
• custody fix for failed turns (a background task was started);
• stale-token banner;
• cloud runs for workflow phases;
• one model router shared with AssistantApp;
• the Responses provider and voice , on hold pending an API budget.

Limits:

• macOS only, single user.
• ccx.app runs from the working folder, so uncommitted edits load on relaunch: it's development software.
• It depends on subscription CLIs: personal use, not a shippable product.
• Missions need aa-bridge built.
• Cloud sessions only for GitHub repositories.

FAQs:

• Is ccx a product I can download? No. It's a private tool, unlicensed and unreleased.
• Do the agents act on their own? They propose. Edits, commands, integrations and scope changes wait for the studio’s approval in ccx.
• Why two AI models? One builds and the other reviews, so an error must get past both. Blind parallel analysis surfaces disagreement.
• Does it send code to the cloud? Only through the agents' own CLIs, and through cloud sessions for projects already on GitHub, when the owner starts them. The server listens only locally.