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.