Skip to content

v0.4.35

Latest

Choose a tag to compare

@ChesterRa ChesterRa released this 28 Aug 08:47
· 4 commits to main since this release

CCCC v0.4.35 Release Notes

v0.4.35 makes CCCC coordination more intentional and more dependable. It
introduces a three-mode message model that separates immediate interruption from
durable Mail, adds managed DeepSeek Harness support, brings optional CCCC
Account and Reach into the Web UI, and strengthens long-running runtime,
recovery, security, and cross-platform behavior.

Python remains the stable default implementation. Rust remains an explicit,
experimental option for evaluating faster startup and lower runtime overhead;
this release narrows important behavior gaps without claiming complete feature
or integration parity.

Messages That Interrupt Only When They Should

CCCC now exposes three explicit message modes across Web, CLI, MCP, Python, and
Rust:

  • Send asks CCCC to hand the message to the recipient runtime now.
  • Send + Reply performs the same handoff and keeps a concrete reply
    obligation open until the recipient replies or the sender cancels it.
  • Mail writes to the recipient's durable Inbox without invoking, waking, or
    steering the runtime.

Runtime delivery, Mail reads, replies, cancellations, and task completion are
separate facts. A successful handoff no longer pretends that the model read or
understood a message, and reading Mail no longer replays already handled Send
traffic. Agents consume the next ordered Mail batch with cccc_inbox_read;
historical direct messages remain available through message history.

Mail is designed for useful updates that can wait. After a configurable window,
CCCC may issue at most one content-free Inbox notice instead of repeatedly
injecting message bodies into the runtime. Send + Reply uses the same bounded
approach for an accepted message whose reply remains open. Paused or stopped
actors are not awakened by these notices.

The new contract also makes routing less ambiguous:

  • Mail is agent-only; messages to the human user use Send or Send + Reply.
  • One message addresses either the user or one or more agents, never a mixed
    human/agent audience.
  • Send + Reply requires concrete actor recipients rather than a broadcast
    selector.
  • When the original sender is an agent, a Mail reply can satisfy the existing
    reply obligation without interrupting that sender.
  • Group Bridge preserves the chosen delivery mode, source identity, reply
    state, and cancellation across trusted remote groups.

Managed DeepSeek Harness Runtime

DeepSeek Harness is now a first-class deepseek headless runtime. CCCC installs
the exact tested ACP composition under CCCC_HOME, leaves provider credentials
as deployment inputs, and isolates provider homes and sessions per actor instead
of modifying a project package or the user's global DeepSeek configuration.

Structured ACP turns are projected into the same durable headless events used by
other providers. Delivery, timeout, cancellation, and recovery follow one
outcome boundary: committed turns are deduplicated, failed writes remain
retryable, and a timeout is not retried until CCCC has established what happened
to the provider turn. Large histories use bounded indexes instead of full-log
rescans.

Permanent setup conditions are handled deliberately. Missing credentials and
context-window overflow stop the affected runtime and require an explicit start
or restart; that gate survives daemon restarts and Python/Rust switches instead
of creating an automatic failure loop.

DeepSeek Harness currently depends on an upstream developer-preview package
set. Live provider behavior still requires a valid DEEPSEEK_API_KEY and cannot
be proven by offline release tests.

Optional CCCC Account and Reach

CCCC Account is now a first-class global Web surface rather than a hidden part
of tunnel configuration. You can link one installation through device
authorization, inspect its account-backed service state, manage the account, or
disconnect it without affecting local Groups and agents.

Reach is the first optional account-backed service. On Linux and macOS it can
publish the local CCCC Web surface through a managed public HTTPS hostname:

cccc login
cccc reach on
cccc reach status
cccc reach off
cccc logout

The same flow is available in Web through Account and Settings > Web
Access
. CCCC supervises a checksum-pinned cloudflared helper under
CCCC_HOME; it does not upload your ledger or repository. Account linkage and
Reach are optional, and local-only CCCC remains fully usable without either.

The remote-access boundary was hardened alongside the new flow. Reach checks
the identity of the live local CCCC Web instance before opening a tunnel, uses
short-lived one-time exchanges for administrator links, binds device credentials
to their issuing account origin, validates browser origins for authenticated
writes, and stops inherited helpers when Reach is disabled or an installation is
revoked.

Reach remains a preview and is unavailable on Windows in this release because a
pinned Windows helper is not bundled.

Better Context, Tasks, and Capability Control

Large Group context and Task Board views now use paged, version-consistent
queries. The Web UI retains exact selected tasks, ignores stale results after a
Group switch, and loads detail only when needed rather than requiring one large
snapshot. SSE reconnects reconcile missed ledger events without silently
dropping the middle of an active conversation.

CCCC Self-Evolution is now a packaged, built-in Skill enabled once for new and
existing Groups. Explicit disablement remains durable, and earlier local
self-proposed bindings migrate without creating duplicate active capabilities.
Capability metadata, qualification state, and slash-command visibility remain
aligned between Python and Rust.

A More Resilient Web Workspace

This release includes a broad set of interaction improvements:

  • Project selection can create directories directly, and Windows can browse
    available drive roots.
  • Presentation has a focused full-screen mobile surface with modal keyboard
    behavior instead of competing with the chat layout.
  • Chat bottom-follow, filtered histories, empty-state pagination, and delayed
    anchor restoration no longer depend on timing races.
  • Runtime activity remains visible through a bounded ticker without turning
    transient activity into chat history.
  • Voice Secretary keeps recording and prompt work bound to the correct Group;
    microphone resampling also preserves buffered audio when the input rate
    changes.
  • Installed PWA icons and Apple touch icons follow valid custom branding, with
    safe built-in fallbacks and consistent Python/Rust routes.
  • Stale development chunks degrade or reload in a bounded way rather than
    collapsing the entire composer.

Runtime, Recovery, and Installation Reliability

Daemon startup and restoration now establish clearer ownership boundaries.
Runtime recovery is serialized with Group and actor lifecycle mutations, old
claims are settled before new work is advertised, and provider exits record
durable evidence without silently changing the user's desired actor state.
Codex and Devin MCP bootstrap detection also fail more safely when hooks are
unavailable or commands require platform-specific quoting.

Windows received a concentrated reliability pass. The combined launcher owns
the exact daemon process it created, waits through graceful shutdown before
bounded fallback cleanup, and cannot stop a replacement daemon after a
descriptor handoff. Standalone updates wait for executable locks, preserve a
verified replacement when only restart fails, and use native exit codes rather
than treating expected diagnostics as fatal PowerShell errors.

Across Unix and Windows, standalone self-update identifies the exact managed
executable. A markerless foreign or legacy cccc command is not replaced merely
because it prints a plausible version. Python publication retries likewise
compare immutable artifact hashes, preventing files from different builds from
being mixed under one release identity.

Upgrade and Compatibility Notes

Upgrade the recommended distribution from PyPI:

python -m pip install -U 'cccc-pair==0.4.35'

Python 3.11 through 3.14 remain supported. Supported Linux x86-64, Intel and
Apple Silicon macOS, and Windows x86-64 wheels also contain the version-matched
experimental Rust implementation. Python remains selected by default; use
cccc rust to opt in and cccc python to return.

The optional standalone Rust build can be selected explicitly:

curl -fsSL https://chesterra.github.io/cccc/install.sh | \
  CCCC_VERSION=0.4.35 sh
$env:CCCC_VERSION = "0.4.35"
powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12; Invoke-RestMethod 'https://chesterra.github.io/cccc/install.ps1' | Invoke-Expression"
Remove-Item Env:CCCC_VERSION

The standalone distribution is still an experimental Rust-only channel. It has
no Python fallback or implementation switching; the pip distribution remains
the recommended complete product.

Existing Groups, ledgers, and CCCC_HOME remain the shared authority and are
migrated in place where required. As with any operational upgrade, back up
important state before installing.

Integrators must update new message writes to provide message_mode with one of
send, request_reply, or mail. The former generic acknowledgement/read model
is retired for new traffic: Mail uses mail.read, immediate delivery uses
runtime.delivery, and reply obligations belong only to request_reply.
Historical events remain readable but do not create new obligations.

v0.4.35 includes all changes from v0.4.35-rc1 plus the post-candidate
messaging, account, context, security, mobile, and recovery improvements above.