CCCC v0.4.53 Release Notes

CCCC v0.4.53 makes mistakes in message calls show up at once. A message call with a misspelt or misplaced argument used to report success while the argument was stored or ignored; it now fails and names the argument. See Message Calls Name the Arguments They Do Not Recognize.

It also closes a gap in who may state where a message came from: an ordinary Web or MCP message call can no longer supply the fields that IM bridges use to record a platform and sender. See Security: Message Origin. A connected native session now gets start-up examples it can call as written, and the guide gains a starter walkthrough for a two-agent team with a short AGENTS.md template. See Native Sessions and A Starter Pair and an AGENTS.md Template. This release covers the changes since v0.4.52.

Before You Upgrade

Before upgrading, let sends and recordings finish. Restore or discard waiting sends, then send or copy every unsent draft, restored ones included, and save unsaved edits in Files: all of these live only in the open page. Check whether a message already arrived before sending it again.

Upgrade the CCCC executable, restart the daemon and Web the way you usually launch them, and reload open CCCC pages. The standalone installer behind cccc update stops a running daemon and starts it again from the new version. Before a pip upgrade, run cccc daemon stop and close any foreground CCCC so pip can replace the executable, especially on Windows. A daemon left running keeps the previous version. Runtime history stays in CCCC_HOME.

• Agent sessions that were started before the upgrade keep the MCP server they started with. They keep working with the new daemon, and the daemon's argument check applies to their calls at once. The MCP-side changes (the origin check and the new start-up examples) reach a session only when its MCP server is started again, for example by restarting the agent. Updating the daemon alone does not give an already running MCP server the origin check.
• A retry of a message call that carries an argument CCCC does not recognize now fails, even when the same call was accepted before the upgrade. Check whether the message already arrived before sending it again without the argument.
• Messages already stored keep what they stored. Nothing in a ledger is rewritten.

Message Calls Name the Arguments They Do Not Recognize

A message call with an argument CCCC does not recognize, such as mdoe for the mode or a question's options given at the top level instead of inside question, used to succeed. The argument was stored with the message or ignored, and the message went out without what the caller meant: a choice card without its choices, for example.

The call now fails with unknown_arguments. The error lists the argument names in sorted order, without their values, and the attempt changes nothing. This covers sending, replying, sending files, cross-Group sends on the same instance, tracked sends, system notifications, slash-skill dispatch, native session sends and upload preflights, through the Web, MCP, the CLI and direct daemon calls. New messages and files sent through CCCC Connect are not covered yet; a reply to a Connect message is.

A caller-supplied scope_key is now rejected instead of dropped, and so are sender snapshot fields. Accepting an argument's name says nothing about who may use it: authorization checks are separate and unchanged.

Security: Message Origin

IM bridges record where a message came from: the platform, the chat and the sender. Ordinary Web messages and MCP message tools accepted the same fields from the caller, so a caller could put a false platform and sender in the envelope the recipient sees. This was reproduced with a non-administrator Web token limited to one Group. The probe did not demonstrate access beyond the token's permitted Group.

Web and MCP message calls now reject these fields, such as source_platform or transport, before anything is sent or stored. When a Web message names another Group as the source of a forwarded message, the signed-in user must be able to access that Group. Forwarding by a user who has that access, replies to genuine cross-Group messages and file uploads work as before. IM bridges themselves are unaffected.

Two limits remain. The source references an MCP tool call gives for a forwarded message are not verified, and programs that call the daemon directly on the same machine are trusted as before.

A message a native session sends directly, and the record a cross-Group send keeps in its own Group, also no longer store the session's internal binding with the message. The ordinary Web and MCP entrypoints we inspected reject or replace caller-supplied bindings.

Native Sessions

A connected native session has no Group of its own to fall back on, so each Group tool needs an explicit group_id. The calls cccc_bootstrap suggested to such a session left it out, and its agent-state examples carried an actor_id placeholder that a session does not need. In a zero-model fixture of a native Claude session, none of the eight suggested examples succeeded when called as returned.

The suggested calls now name the Group, the agent-state examples use the caller's own identity, and the parameter descriptions a native session sees say that group_id must be given. With this build, all eight examples succeeded when called as returned, in the same native fixture and in a fixture of an agent CCCC starts. The examples' placeholder text was sent as it is, so this checks their arguments, not what an agent would write in them.

The collaboration guidance also no longer suggests Mail for context that has no higher-order perspective. Under the MCP profile, an agent's Mail to another agent needs an insight, so following that line led to a rejected call.

A Starter Pair and an AGENTS.md Template

The guide's Builder + Reviewer Pair use case is now a path you can follow from an empty project: register two agents, merge a short template into the project's instructions, start them, agree who edits which files, hand off, review and integrate. The short AGENTS.md template is a block to copy and adapt: scope, ownership, independent review, evidence, handoff and authority boundaries.

Supported Runtimes now explains where a Claude Code agent that CCCC starts edits files. Claude Code has such a background session enter a worktree before it edits files in the main checkout by default, so its result can sit outside the checkout the rest of the Group uses. The section shows the Claude Code setting that changes this and how to pass it in the agent's command. CCCC's own default is unchanged.

Best Practices was corrected in several places: it no longer suggests checking delivery with cccc inbox, which consumes the agent's Mail, or restarting an agent to clear its context.

Validation Scope

Release preparation ran these checks on one frozen tree, all but ruff in isolated homes: the Rust workspace tests (113 targets, 3,937 passed, 0 failed, 10 ignored), rustfmt and clippy, the CI test profile with nextest 0.9.148 and real Chrome forbidden (3,887 passed, 60 skipped), the daemon self-launch tests (3 passed), the Web check and the full Web tests (4,939 tests in 657 files), and the repository's Python tests (126 passed) and ruff. Corrections made afterwards changed only these release notes, and git diff --check and the Python tests were run again on them.

The argument check has a test for each entry it covers. In a separate copy of the source, removing the check from the send entry made the new message test fail at its send rejection. The arguments that CCCC's own ports, the SDK and MCP servers from v0.4.45 to v0.4.52 send were listed by reading their source, and the lists accept them; those older MCP servers were not each run against this daemon.

The origin check's HTTP tests cover a restricted and an administrator caller, unchanged ledgers and no new stored blobs after a rejection, an authorized forward, a reply to a genuine cross-Group message and both upload paths. Removing the Web source-access check in a separate copy made the restricted-source test fail, with the request accepted instead of refused. The MCP test checks that the tools reject these fields before a daemon exists, then sends an ordinary message.

The binding test sends both ways with valid native session fixtures and checks that the direct message and both cross-Group records do not keep the captured native binding. Removing either part of the fix made it fail at that path. These regression cases exercise native bindings, not a captured Web binding.

The three lock tests were changed after a probe in a separate copy, using cccc-core's lock while another thread started child processes, found an immediate reclaim busy in 187 of 51,565 cycles over five seconds. Whether an earlier failure of the CLI's lock test in a full run had this cause is not established.

The start-up examples were called as returned, without a model, against the debug builds before and after the change. Before, none of the eight succeeded in the native Claude fixture and five did in the fixture of an agent CCCC starts; after, all eight succeeded in both.

The guide's changed registration, launch and messaging examples were run against an isolated daemon with stand-in runtime executables: pair registration and roles, cccc group start reaching the stand-in Codex launcher before its intentional failure, the Mail summary line as written, and the documented cccc actor update command, whose setting reached the agent's private settings file.

The Linux x86_64 package built for this release, cccc 0.4.53, was checked in isolated homes by two separate runs. The first checked its version and the files in its archive; the 33 scripts and stylesheets its Web page references, byte for byte against the Web build; through its MCP server, a misspelt mode, a question's options given at the top level and two IM origin fields, each rejected without repeating the value and with the ledger and the stored blobs unchanged, followed by an ordinary message that was accepted; and the documented cccc actor update command with a stand-in Claude executable, whose setting reached the agent's private settings file.

The second started from the official v0.4.52 Linux package, sent messages with it, then replaced its daemon with this package's while the v0.4.52 MCP server kept running. Through that older MCP server an ordinary send and a reply still succeeded, and it still passed IM origin fields on, which a newly started MCP server rejected. Retries of an ordinary message and of a question that carried an unrecognized argument failed with unknown_arguments; without the argument, the ordinary message was recognized as already sent and the question was refused as a conflicting retry. What the old daemon had written to the ledger was not rewritten. On the package's Web, a restricted token sent an ordinary message and replied to a genuine cross-Group message, while an IM origin field and a source Group it cannot access were refused with the ledger unchanged, and all 229 scripts and stylesheets in the Web build were served byte for byte. The start-up examples were called as returned on the package, and all eight succeeded in both fixtures.

This is not complete live acceptance. No real runtime or model was used for the start-up examples, the walkthrough or the Claude Code setting, so how a real Claude Code session treats that setting, and whether the walkthrough helps a new team, are not verified. None of these changes was tried on native Windows or macOS.