CCCC v0.4.32 Release Notes
v0.4.32 is a major collaboration-quality and runtime-continuity release. Its theme is simple: less ambient orchestration, better-placed judgment.
The centerpiece is the Insight Loop. Instead of trying to make agents wiser by surrounding every turn with a larger permanent playbook, CCCC now creates a separate channel for higher-order peer judgment and places stronger cognitive resets at a few high-leverage collaboration boundaries. At the same time, the default system prompt, help reference, visible tool surface, and background automation are leaner.
The result is not a promise that a prompt can manufacture perfect judgment. It is a more deliberate collaboration contract: routine work stays operational, while peer communication has an explicit place to question the level, framing, direction, and consequences of that work.
A Lighter Default Collaboration Surface
Ordinary actors now start with a compact 13-tool collaboration core. Project context, memory, runtime administration, repository utilities, presentation tools, and other specialized capabilities remain available through cccc_capability_use, but their full tool packs no longer need to occupy every session.
CCCC's base system prompt and help reference have also been narrowed to what the platform actually owns: message routing, inbox handling, shared state, recovery, durable coordination, and capability access. General reasoning style, writing doctrine, and broad workflow ideology have been removed from the always-on surface.
New groups also start with generic nudge, unread, keepalive, and periodic help reminders disabled. Explicit reply-required and attention acknowledgement reminders remain available where they protect a real delivery obligation. Existing groups keep their configured or compatibility behavior; this release does not rewrite their automation settings.
This is an intentional trade: CCCC carries less permanent instruction weight, then spends attention more selectively where collaboration is most likely to lose perspective.
Peer Insight: A Second Channel for Judgment
Peer-facing messages sent through CCCC's built-in MCP tools now distinguish two projections:
textcarries the operational exchange at the current working level.insightcarries the sender's most consequential provisional higher-order perspective.
Insight is not intended to be a title, summary, afterthought, or private chain-of-thought transcript. It is the place to step above the immediate work unit and expose what becomes visible from there: what the work is really serving, which premise or framing deserves challenge, where the current path leads, what could invalidate it, when to step back or move to Plan B, and what a successful result should make possible next.
The perspective remains explicitly provisional. Receiving agents are asked to rebuild the judgment independently rather than inheriting the sender's framing, confidence, or role. A useful Insight may challenge the current course or confirm it; its value comes from changing the level or frame of judgment, not from manufacturing disagreement.
This data is preserved across the full messaging path. Local delivery, remote Group Bridge messages, IM projection, replies, tracked delegation, files, search results, and the Web UI carry the structured perspective without merging it into the ordinary message body. In Web chat it appears as Sender perspective, separate from the working message.
For peer recipients, the built-in MCP messaging path rejects a missing Insight before writing a ledger event, waking an actor, creating a tracked task, or storing a file blob. User-only messages are exempt. The underlying CCCS and daemon field remains additive for custom integrations, while CCCC's own agent messaging path enforces the stronger collaboration contract.
The Rest of the Insight Loop
The separate field is only one part of the mechanism.
After a successful MCP message operation, the sender receives a focused checkpoint to step outside the message's momentum, reconstruct the current situation, and resume the highest-value work that still deserves to continue. If an agent attempts a peer message without Insight, the failed preflight becomes a stronger pre-send review boundary: nothing has been delivered, and the agent is prompted to reconsider the whole course rather than mechanically adding a field to the same draft.
Bootstrap has a complementary takeover cue. It appears only when recovery contains real unfinished work such as an active task, current focus, next action, blocker, open loop, commitment, attention item, or shared coordination focus. Historical background alone does not trigger it. The recovering agent is encouraged to treat prior state as testimony rather than authority, preserving what still earns preservation instead of blindly continuing an inherited track.
Together, these pieces form the Insight Loop: an independent perspective before peer delivery, a checkpoint after communication, and a conditional re-evaluation when an agent takes work back over.
ChatGPT Web Delivery Is Safer While ChatGPT Is Busy
CCCC can now append a prompt while ChatGPT is already generating, but only through a verified Send prompt control inside the active composer. It will not mistake ChatGPT's Stop button—or a similarly named control elsewhere on the page—for a send target.
If no safe composer control is available, delivery is deferred instead of being reported as failed. The unread batch remains eligible for a bounded, single-flight retry with backoff. Staged composer text is reused only when it exactly matches the current batch, and new unread messages can be incorporated into a later deterministic delivery attempt.
Once a submit click has actually been invoked, CCCC uses an explicit at-most-once policy. A new message echo confirms delivery; a click whose dispatch cannot be proven is recorded as ambiguous and is not automatically sent again. This favors avoiding duplicate prompts over silently retrying an action that may already have reached ChatGPT.
Projected Browsers Stay Off the Linux Desktop
On native Linux, ChatGPT projected browsers now require a CCCC-owned Xvfb display. CCCC removes inherited Wayland display markers, forces Chrome or Edge onto the isolated X11 display, and refuses to fall back to the host desktop when Xvfb is missing.
This closes the gap where an embedded browser could also appear as a physical Chrome window. cccc doctor now reports the system Chrome/Edge browser, required Xvfb isolation, and optional x11vnc viewer separately. x11vnc is not required for isolation: when it is absent, the embedded panel continues through the built-in CDP screencast viewer.
Persisted Linux browser processes are reused only when their metadata proves that they belong to a CCCC-owned Xvfb display. Unverified legacy sessions are rebuilt instead of being trusted.
Grok Build Sessions Now Survive Restarts
Grok Build PTY actors now receive a CCCC-owned session UUID and resume that exact provider session with Grok's native --session-id and --resume flags. This gives Grok actors the same practical restart continuity users expect from Codex and Claude Code, without relying on directory-wide “continue the most recent session” behavior.
Commands that already contain Grok session-control flags remain user-owned and are not rewritten. The Web new-session action can deliberately rotate to a fresh Grok session, and CCCC_RUNTIME_RESUME=0 still disables provider-session reuse globally.
Faster Everyday Web Messaging
When the Web composer is empty, press Up to recall the latest loaded user message in the current Group, then use Up and Down to browse the local history snapshot. Editing the text, moving the cursor, changing groups, or pressing Escape exits history mode.
Recall restores message text only. Current recipients, reply context, attachments, priority, and delivery mode remain unchanged, so users can reuse wording without silently reviving stale routing state. Recipient detail popovers are also easier to operate because moving the pointer into the popover no longer makes it disappear immediately.
Additional Reliability Improvements
Changing terminal theme, scrollback, or control ownership no longer recreates the live xterm instance. The terminal keeps its existing WebSocket-bound input and resize subscriptions while applying the updated options in place.
Group Space memory synchronization also skips stale bindings that refer to deleted groups, preventing removed group state from interfering with later synchronization work.
Stronger Release Confidence
The release pipeline has been rebuilt around durable checks rather than one-time migration machinery. Web formatting and linting now use Vite+ with Oxfmt and Oxlint, Python tests are distributed across four deterministic pull-request shards, a serial nightly run preserves an order-sensitive reference path, Windows keeps focused PTY smoke coverage, and packaging consumes the exact Web artifact produced by the Web job.
Artifact-dependent tests now run at the package boundary where the built bundle actually exists. This keeps clean Python shards honest without weakening the final wheel contract.
Upgrade Notes
- No group-ledger or shared-state migration is required.
- On native Linux, install
xvfbbefore starting or restarting a projected ChatGPT browser. Installx11vnconly if you want the VNC viewer; CDP screencasting remains available without it. - After installing Xvfb, use Restart ChatGPT browser rather than only refreshing the CCCC Web page.
- Existing group automation settings are preserved. Lean automation defaults apply when a new group is created.
- Built-in MCP messages addressed to peer agents now require
insight; user-only messages do not. - Existing custom Grok session flags remain authoritative. Set
CCCC_RUNTIME_RESUME=0if provider-session reuse is not desired.
Why Upgrade
Upgrade to v0.4.32 if you want agents to exchange more than status and handoff text, prefer a smaller default orchestration footprint, run Grok Build actors across restarts, deliver work into an active ChatGPT Web session, use embedded projected browsers on Linux, or want quicker message reuse in the Web composer.
More broadly, this release establishes a new direction for CCCC: keep the collaboration kernel lean, then place explicit judgment and recovery cues where they can change an actual decision.