CCCC 0.4.53

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.