CCCC 0.4.52

CCCC v0.4.52 Release Notes

CCCC v0.4.52 keeps the resource panel across a refresh: reloading a browser tab
brings back the tabs you had open, the one you were reading, a side-by-side
comparison, and whether the panel was collapsed or maximized. Switching Groups no
longer flashes the connection symbol or an unread mail mark. See Tabs Come Back
After a Refresh and Steadier Group
Switching.

It also does less work in the background. The Web no longer reads the whole
history of every Group every 30 seconds to find messages for Chet, connected
sessions ask the daemon less often while they are idle, and on Linux with glibc
the daemon asks the allocator every five minutes to return unused pages to the
system. See Less Work in the
Background and Less Memory Held After Busy
Periods. A Ctrl-C that arrived while the Web
was starting no longer ends cccc web, cccc --headless or cccc without the
terminal interface at once; see Ctrl-C While the Web
Starts. This release covers the changes since
v0.4.51.

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.

• A page from v0.4.51 or earlier does not save its resource tabs, so the reload
  right after upgrading still starts with an empty panel. Tabs you open after that
  come back on later refreshes.
• Claude, Pi and OpenCode sessions that are already connected keep their current
  receiver, which still asks the daemon at the earlier interval, until the session
  is started again. They keep working with the new daemon in the meantime, so there
  is no need to restart them for this.

Tabs Come Back After a Refresh

Each Group keeps its own resource tabs, and refreshing the same browser tab now
restores them: their order, the selected tab, the side-by-side layout, and
whether the panel was collapsed or maximized. A Group's side-by-side layout also
stays when you switch to another Group and back.

Only which workspace files, attachments and Presentation slots were open is kept,
in that browser tab's session storage, never their contents. Each resource is read
again with your current permissions when it is shown:

• A workspace file that was deleted or renamed in the meantime shows the usual
  error with Retry. Until the Group's folder list has loaded, a restored file
  shows Loading instead of saying it belongs to another folder.
• A message's reference to a Presentation slot fetches that message again. If
  the message no longer holds the reference, the tab says so instead of showing
  the slot's current card; if the request fails, the tab offers Retry.
• Attachments the ledger had not confirmed yet are left out.

Unsaved edits, reading positions and recently closed tabs are not restored. Browser
tabs do not share this state, and whether a tab the browser duplicates or reopens
keeps it depends on the browser.

Steadier Group Switching

Switching Groups replaces the Group's event stream. For that moment the header
showed the connection symbol as reconnecting, and a member's unread mail mark
disappeared and came back. The connection now stays shown as connected while the
new stream opens. It shows reconnecting only if the stream has not opened within a
second, and a stream that fails still shows at once. Unread counts already shown
stay until fresh ones arrive. On the first visit to a Group there are no counts to
keep, so its marks appear once they load, as before.

Less Work in the Background

• Messages for Chet. Every 30 seconds the Web read the whole history of every
  Group to find messages addressed to Chet. When the Groups' ledger indexes did not
  all fit the in-memory cache, these sweeps could rebuild them again and again,
  which cost a burst of CPU each time and raised resident memory. The Web now keeps
  its place in each Group's ledger and reads only what was written since. It still
  reads a Group in full when the Web starts or first sees the Group, when the
  Group's ledger files change in a way it cannot continue from (for example after
  the ledger rotates), and after a failed read. Pending registrations and
  dispatches are still retried, and the sweep still runs every 30 seconds to
  recover messages the live event feed missed.
• Idle sessions. A Claude, Pi or OpenCode session connected to CCCC asks the
  daemon for its next message less often while nothing is waiting for it: after an
  empty answer it waits 500 ms instead of 200 ms before asking again. Other timing,
  including Claude's existing notification limit, is unchanged. A message sent to
  an idle session can take a little longer to be picked up. Sessions that are
  already connected change over as described in Before You
  Upgrade.
• Message rendering. The actions on each message (reply, copy link, relay and
  the others) were rebuilt on every render of the chat, so each new message
  re-rendered every visible message and its action bar. They now keep one identity,
  which removes those re-renders. What the actions do is unchanged; each uses the
  Group and settings current when it is clicked.
• Agent reads and daemon replies. Agents reading message history through MCP
  get the newest page without the daemon first collecting every message they can
  see, and the daemon no longer copies most results once more before replying.
  Results are unchanged.

Less Memory Held After Busy Periods

On Linux with glibc, memory the daemon freed after a busy period could stay with
the process, so its resident memory could stay near the size of its busiest
moment. The daemon now asks the allocator every five minutes, the first time five
minutes after it starts, to return unused pages to the system. When the daemon
runs inside cccc, cccc web or cccc --headless, the whole process is trimmed,
Web included; a daemon started with cccc daemon start trims only itself. macOS
and Windows are unchanged.

This is not a memory limit: memory still grows while the daemon is busy, and pages
it returned take a little time to reuse. The daemon diagnostics log records the
first trim after the daemon starts and any trim that takes longer than 200 ms, with
how long it took and the resident memory before and after.

Ctrl-C While the Web Starts

A Ctrl-C after the daemon was ready and while the Web was starting, including just
as its Local: address appeared, ended cccc web, cccc --headless and cccc
without the terminal interface at once. Such a Ctrl-C now starts the usual stop,
and a second one still forces the exit. How these commands handle a Ctrl-C before
their daemon is ready is unchanged.

The terminal interface on Linux and macOS had a similar gap right after it began
watching for signals, and now listens for Ctrl-C from that moment.

Building From Source

./scripts/build_package.sh and build_package.ps1 now name the archive they
write in dist/ after the commit, for example
cccc-v0.4.52+<commit>-x86_64-unknown-linux-gnu.tar.gz, adding -dirty when the
tree has uncommitted changes and using local outside a Git checkout. A local
build therefore no longer replaces a release archive of the same version, and
rebuilding replaces only the archive of the same name. The executable is still
target/release/cccc, or target\release\cccc.exe on Windows.

Validation Scope

Release preparation ran these checks on one frozen tree, all but ruff in isolated
homes: the Rust workspace tests (113 targets, 3,927 passed, 0 failed, 10 ignored),
rustfmt and clippy, the CI test profile with nextest 0.9.148 and real Chrome
forbidden (3,877 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 Ctrl-C change was checked in a separate copy of the source: two new process
tests each run one signal watcher alone in a fresh process and raise an interrupt
before the watcher first runs. Making either watcher register only once it first
runs again made its own test fail with the process ended by the interrupt, while
the other test passed. The headless startup test that failed once on CI passed in
the same copy.

The restored panel was walked in an isolated headless Chrome, with the Web source
served against an isolated v0.4.51 backend: the side-by-side layout with one file
on both sides, attachments, live and quoted Presentation slots, a quote that could
not be recovered and a failed request with Retry, a maximized panel, Group
switches, a deleted file, a new independent browser tab, and the two sides
stacked top and bottom at 390 pixels wide, with no page errors. With the Group
request slowed to 0.8 seconds, the notice about another folder appeared once on
refresh before the change and not after it.

Group switching was checked frame by frame in headless Chrome, with a member who
had unread mail: over six switches, the reconnect symbol had stayed on screen for
50–100 ms on each switch, and the mail mark had been gone for 50–100 ms on each of
five returns to a Group. With the change neither occurred, on the Web source and
again on the Web of a trial build containing it. On a test Group of 150 messages,
one incoming message re-rendered about 330 components instead of about 4,200.

The Chet sweep was measured in isolated homes with nine synthetic Groups holding
56.8 MB of ledgers, one 180-second run per case. With the previous Web and the
sweep running, the process used 0.19–0.38 s of CPU in the two seconds around each
30-second mark, against 0.03–0.05 s with the sweep held inactive, and its resident
memory ranged from 346 to 597 MiB after the first 10 seconds, against 217 MiB.
With a trial build containing this change and the sweep running, the same windows
used 0.04–0.06 s, and resident memory stayed between 241 and 244 MiB. On a
long-running installation, a one-second sample over six minutes after switching to
that trial build showed none of the 30-second bursts seen before. Tests run the
sweep against a stand-in daemon, and five mutations of the change (dropping either
reread, not keeping the place, keeping events from before an import marker, and
letting one failed read stop the whole sweep) each made a test fail.

With five idle Claude sessions, one 60-second run per version, the daemon used
0.62% of one CPU core instead of 1.27%, and each session's receiver 0.10–0.12%
instead of 0.27–0.30%. Ten first notifications after idle periods appeared in the
receiver's output 12–404 ms after they were sent, instead of 31–139 ms.

Allocator settings were compared on the v0.4.51 package in isolated homes under a
synthetic load of 16 paced clients, two runs each. With default settings, resident
memory after a 30-second rest was about 985 MiB. In a matched pair with a small
probe loaded, two trims during the load took 42 and 59 ms and each brought
resident memory down to about 280 MiB, after which the load grew it again.
Limiting glibc to two arenas held memory at about 305 MiB but cost about 58% more
CPU per request, so it was not adopted. On a long-running installation, a trial
build with the trim but without the Chet sweep change ran for about six and a half
hours. Its diagnostics log recorded the first trim, which took 113 ms, and 22
later trims that took over 200 ms, up to 415 ms; each brought resident memory from
1,382–2,223 MiB down to 286–433 MiB. On the same installation with the Chet sweep
change, the first trim took 24 ms and brought resident memory from 517 to 296 MiB,
and the diagnostics log recorded no later trim over 200 ms in the following hour
and a half.

The new message history path was timed against the old one in one release test
binary on a synthetic Group of 37,500 events: the default page's median went from
2.0 ms to 0.3 ms. Reading the latest 120 messages, their delivery statuses or 50
messages of history requested 12–21% fewer bytes from the Rust allocator. The
archive helper's tests cover tar and zip archives, and four mutations of it each
made a test fail.

The Linux x86_64 package built for this release, cccc 0.4.52, was checked in
isolated homes: its version and the files in its archive; the 33 scripts and
stylesheets its own Web serves, byte for byte against the Web build; and six Group
switches on its own Web, frame by frame, with the connection shown as connected in
every frame and the mail mark kept on all five returns to a Group. Its host, which
runs the daemon and the Web in one process, did not trim at startup, recorded its
first trim in the diagnostics log 300 seconds after starting, returned the same
entry through the daemon's diagnostics, and ended normally on Ctrl-C.

This is not complete live acceptance. None of these changes was tried here on
native Windows or macOS, and the PowerShell package script was reviewed but not
run. The panel and Group switching were not tried in Safari, Firefox or on real
phones, and idle sessions were measured with Claude receivers only.