CCCC 0.4.54

CCCC v0.4.54 Release Notes

CCCC v0.4.54 makes one silent event visible. When an agent that CCCC starts comes
back on a new conversation although an earlier one was saved, CCCC now records
when that happened and which of the compared settings had changed, and the
agent's page shows it. See When a Saved Conversation Is Not
Resumed. This release does not change
which conversation a start selects.

It also corrects the order in which history and the Inbox read a Group's rotated
ledger segments after the system clock went backwards, stops read-only opens of
a ledger from causing extra checks in CCCC Web on Linux, no longer lists a
removed agent in Agent State, and fixes several layout defects in CCCC Web. See
Rotated Ledger Segments, Agent State After a
Removal and Web. This release covers the
changes since v0.4.53.

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.

• Saved conversations are matched as before. If an upgrade changes the location
  of the cccc executable, or the daemon is then started with a different
  PATH, managed Claude and Pi agents and ACP agents other than Antigravity can
  start new conversations, as they did in earlier versions. From this version
  each such start records the replacement and attempts to write one notice to
  the user, so several agents can produce several notices after one upgrade. An upgrade that leaves the
  executable where it was does not cause this through CCCC's location.
• A changed launch PATH or CCCC program location is named only when both the
  saved record and the new one contain that detail. A record saved by an earlier
  version does not, and the reason is then the broader "launch settings or
  environment". A successful start records the detail for later comparisons.
• In a Group whose rotated ledger segments were already read in the wrong order,
  new Mail arrives normally after the upgrade. Mail that an Inbox read had
  already passed over may not return to the Inbox; it remains in the Group's
  history. Nothing in a ledger is rewritten.

When a Saved Conversation Is Not Resumed

An agent that CCCC starts keeps a record of its conversation, and a later start
resumes that conversation when the record still matches the launch. When the
agent's runtime, command, model, workspace, launch settings or launch environment
no longer match, the agent starts a new conversation. That start succeeds, so
nothing was shown as failed, and the new record replaced the old one: afterwards
nothing told why the agent had come back without its context.

CCCC now keeps that fact with the new record.

• The agent's page and its terminal view show a small information mark after
  the status. Hovering over it, or selecting it with a click, a tap or the
  keyboard, gives the time of the record and the compared settings that had
  changed.
• For managed Claude and Pi agents and for ACP agents other than Antigravity,
  the launch environment includes a PATH built from the agent's own PATH
  setting or, without one, from the PATH the daemon was started with, with
  CCCC's directory placed first. Starting the daemon from a different shell can
  therefore be enough to start a new conversation. For these agents a changed
  launch PATH and a changed CCCC program location are named separately from
  the other launch settings, when both the saved record and the new one contain
  that detail.
• CCCC attempts to write one system notice addressed to the user. A written
  notice is stored in the Group's ledger, and an enabled IM bridge can forward
  it. The Web conversation view does not show it; in the Web, the mark on the
  agent's page is where to look.
• cccc actor list and the Actor listing report runtime_session_replaced_at
  and runtime_session_replaced_reasons. The list of reasons is open: a client
  should not fail on a value it does not know.

No new replacement is recorded for a first start, for New session, when
resume is disabled, or when the saved record of a Pi or ACP session shows that
it never received a prompt. An existing record stays until New session or
the next replacement.

The record says that a conversation was not resumed and what differed. It does
not make an agent resume in more cases than before.

Rotated Ledger Segments

History and the Inbox now read a Group's rotated ledger segments in the order
they were rotated. Segments were read in file-name order, and a name starts with
the time of its rotation, so when the system clock went backwards between two
rotations a later segment was read first: history showed its messages out of
order, and an Inbox read could skip Mail. Nothing was removed from the ledger.

A ledger is rotated only by an explicit compaction such as cccc ledger compact.
A Group with no rotated ledger segments is unaffected by this ordering defect.

Agent State After a Removal

Removing an agent from a Group cleared its state but left an empty entry in the
Group's stored context. Agent State in Project Context kept a card for the
removed agent, and context reads returned the entry.

Context reads now return states only for agents still in the Group. This also
applies to entries left by removals in earlier versions, so nothing needs to be
cleaned up after the upgrade. States of agents still in the Group are kept even
if they are disabled or stopped. This filtering does not rewrite the stored
context.

Web

• CCCC Web ignores file-open notifications when it watches Group ledgers. On
  Linux, a read-only open of a ledger by any program could queue redundant ledger
  checks. Writes, rotations, Group removal and the periodic recovery scan are
  handled as before.
• On a phone-sized screen, the Edit button under a stopped agent's page no longer
  breaks its label over two lines and grows taller than the buttons beside it.
  It shows its icon alone there, as it already does while the agent is running.
• The Group menu, opened from the run button in the header or from a Group in
  the sidebar, no longer reserves extra width as if neighbouring items stood
  side by side. The labels filled only part of it.
• In the add-agent dialog, Cancel no longer grows taller than the create button
  beside it when that button has a hint line under it.
• A settings choice whose options wrap onto a second row, such as the default
  recipient in Japanese and English, now forms one block of aligned rows.
• The card that opens from a recipient in the composer gives the recipient's
  kind more room on wider screens. It was cut off in Japanese and English.

Validation Scope

Release preparation ran these checks, the Rust checks in isolated homes. First
the Web check and the full Web tests (4,942 tests in 657 files), the
repository's Python tests (126 passed) and ruff, and the release version checks
for v0.4.54. Then, after one correction to the fixture of an existing Rust
test, rustfmt, clippy and the Rust workspace tests (113 targets, 3,958 passed,
0 failed, 10 ignored), the CI test profile with nextest 0.9.148 and real Chrome
forbidden (3,908 passed, 60 skipped) and the daemon self-launch tests (3
passed). After these checks, edits were limited to these release notes, and git
diff --check and the Python tests were run again on them.

The conversation record was exercised with fixture runtimes: replacement tracking
through the Claude, Codex, Pi, native ACP and Antigravity records, the notice and
its routing, and one start and stop sequence through the daemon's supervisor with
a stand-in for the Antigravity protocol. Grok, OpenCode and Kilo write the shared
record through the same function as Claude and Codex and have no dedicated
replacement test. Tests pin the launch fingerprints of Claude, Pi and native ACP
to values encoded independently from the v0.4.53 format and resume records
written in that format. The mark was checked in an isolated headless browser
against injected listing fields, in light and dark, in the terminal view, with
the keyboard and with touch emulation at phone width.

The removed agent's state was tested through a real removal in the daemon:
every detail level of a context read with and without paging, the stored
context and its version, and adding the same agent again.

The Edit button was checked in an isolated headless browser at 390 pixels in
Chinese, English and Japanese and at 360 pixels in Chinese. The Group menu was
checked from the header of a running Group in the three languages at 1440 and
390 pixels and in Japanese at 70 and 125 percent text size, and from the
sidebar at 1440 pixels. The add-agent footer, the default-recipient choice and
the recipient card were checked at 1440 pixels in the three languages, and the
other choices of that kind in the Guidance, Web Models and Developer settings
in Japanese at 1440 and 1040 pixels and in English at 1040 pixels. At about 820
pixels of window width the recipient's kind is still cut off in Japanese.
These browser checks are disposable probes and are not part of the automated
test suite.

This is not complete live acceptance. No real runtime or model, no real phone
and no real IM bridge was used for the conversation record, so how often a real
upgrade or restart leads to a new conversation is not measured. The watcher
change was measured on Linux only. None of these changes was tried on native
Windows or macOS.