CCCC v0.4.45 Release Notes

CCCC v0.4.45 moves Grok Bot delivery to native Webhook Routines, makes Web Model connections easier to configure, and improves reliability in busy, long-running Groups. Inbox reads use less repeated work, task operations gain retry identities and optional revision checks, and runtime recovery preserves unfinished work more carefully.

Native cloud tasks also gain clearer completion state, safer credential handoff and an explicit way to end a turn that cannot finish.

This release covers the changes since v0.4.44. Existing Grok Bot Actors need Webhook Routine setup after upgrading; browser delivery is removed.

Grok Bot Uses Native Webhook Delivery

Grok Bot Actors now receive work through a saved Webhook Routine and the CCCC remote MCP connector. CCCC sends a wake, the Bot claims its queued inputs, replies through MCP, and confirms completion. This uses the existing Grok subscription without browser message injection, a CCCC-managed Grok login, a separate model API key, or an additional bridge service.

• CCCC preserves input order and admits one active task per Actor. An accepted wake is shown separately from a claimed or completed task.
• Temporary claim and execution credentials have separate authority. A completed task's credential can only retry that task's completion; it cannot acknowledge newer work. Nested MCP calls retain the validated task scope.
• Uncertain or interrupted tasks remain visible for review. Pausing CCCC access revokes its credentials but does not cancel cloud work already running in Grok. Explicit recovery retires the selected unfinished task without replaying its inputs.
• Routine credentials remain private to the CCCC host. Group copies and imports do not carry connection credentials or authority.

To upgrade an existing Actor, configure the shared Grok MCP connector, save its Bot URL, generate the Routine setup instructions, and save the Routine's POST to URL and Key from the Grok desktop app. Existing Actors without these credentials show Setup required. Review old unfinished work and disable obsolete provider Routines yourself when appropriate; CCCC does not delete cloud configuration or provide a browser fallback.

See the Grok Bot guide for setup, exact recovery steps, subscription limits and the current validation boundary. Grok Bot, Grok Build CLI and Grok Voice remain separate integrations.

Clearer Web Model Connections

ChatGPT Web Model, ChatGPT Dots and Grok Bot share consistent access controls, connection entry points and task-status language where their semantics agree. Their provider-specific setup stays distinct: ChatGPT uses a shared browser login, Dots uses native event pairing, and Grok uses a Bot Routine.

• Actor details focus on current operation; the editor holds connection setup. Dots retains its vertical task-progress view, and duplicate edit, access and delivery controls are reduced.
• ChatGPT offers a direct entry to its shared login window. Readiness is inspected independently from the existence of a browser window or old delivery history, with an explicit recheck for the current page.
• ChatGPT page recognition handles the current composer and message layout. Auth/search inputs are not treated as conversation composers, a delivery echo must be in a user message, and a pairing receipt must be in the following assistant reply. Drafts, active generation and attachment-only input remain protected.
• Connection drafts can be edited while access is enabled. Applying changes rechecks the runtime's lifecycle requirements and preserves drafts on failure. Grok route or Routine changes require the current task to finish or be explicitly resolved; they do not interrupt it. Changing Bots clears old Routine drafts and credentials, and accepted Bot URLs are compared in their canonical form.
• Global settings distinguish administrator-managed configuration from Actor setup. Diagnostics share presentation without mixing ChatGPT and Grok credentials or implying that a cloud task has been cancelled.
• Dots distinguishes paused access from missing or changed host identity. Setup on an already paired, paused Actor waits for the user to resume access. Bounded diagnostics compare salted host-identity fingerprints without logging raw identity or credentials.
• Native task instructions clarify how to retain the current claim result and pass execution credentials as tool arguments, including through host JavaScript orchestration. Saved handlers and CCCC business code remain credential-free; a new execution cannot recover an abandoned turn's credentials.
• Claimed Dots and Grok turns show Awaiting completion rather than implying the provider is still processing them. End this turn is available in Task delivery without first pausing the Actor. After confirmation, CCCC revokes that turn's authority and preserves an existing completion or records cancellation. Pairing, subscription and enabled state remain intact. This does not stop cloud work or resend the original inputs; other queued work may continue while access is enabled. Exact turn checks protect newer work from stale controls.

Less Repeated Work in Large Groups

Inbox queries, unread automation and startup delivery recovery stream ledger facts and retain compact projections instead of keeping full historical event payloads in memory. Warm reads incorporate new facts without rebuilding the entire history, while cursor and Actor-generation changes preserve the correct read and delivery boundaries.

Archive-backed reads keep file-descriptor use bounded and decode selected records by segment, avoiding repeated decompression of the same gzip prefix for each message. Snapshot validation handles ledger rotation and concurrent appends without publishing a page from changed archive data. Read failures remain errors rather than being concealed as empty results.

The Web client bounds recoverable Group caches and retires unused terminal streams. Active output and loading work remain protected; cache eviction does not delete ledger history or composer drafts. These changes address specific retention paths, not every source of browser-process memory.

Safer Task Creation, Editing and Context Reads

• Retry-safe creation: callers can supply client_request_id and refer to earlier creates through parent_ref and blocked_by_refs. Retrying the same caller-owned identity returns the existing task instead of creating a duplicate. Reference targets are persisted before dependent creates, including across task-number digit widths and partial-write retries.
• Optional conflict checks: task reads expose rev; existing-task operations accept if_task_rev. A mismatch rejects the batch with task_conflict, without treating unrelated task or Agent State changes as conflicts. Revisions advance per semantic operation, and identical patches preserve their revision. Existing callers can continue without guards.
• Bounded reads: Context callers can request task pages and a max_bytes bound. Oversized text is explicitly clipped in the returned page; stored tasks remain intact. Overview responses also respect the byte bound, including the rendered MCP response.
• Actor retirement: removing an Actor clears its assignment and handoff references on planned/active tasks and clears its old hot/warm Agent State. Task progress, content, completed-task history and other Actors remain intact. A foreman cannot remove itself; user removal promotes the next visible Actor and records the succession.

Integrations should use returned task IDs and revisions rather than infer them. A reused creation identity returns the original task; it does not apply a new payload. After a storage error, reload before retrying: ordered writes and atomic task files do not make the whole Context a multi-file transaction. See the Context operations contract for these opt-in fields and their exact semantics.

Ledger history search also accepts an exact stored recipient and inclusive RFC 3339 time bounds through IPC, HTTP and MCP. Filters apply before pagination and preserve ledger order. Recipient filtering does not expand @all, @peers or @foreman into individual Actors.

Optional Mail Reminders Without Replaying Work

delivery.mail_notice_repeat_seconds enables repeat reminders for still-pending Mail. It defaults to 0, preserving the existing single-notice behavior. Repeats remind an Actor to read its Inbox; they do not resend the business message, rerun a task, advance the read cursor, or promote Mail to Push.

Queued, claimed and failed notice deliveries remain with their original owner. Accepted or ambiguous handoffs can become eligible for another reminder after the configured interval, and withdrawn unsent notices release their claim. Reads, replies and delivery of the underlying Mail close its eligibility. Interval and Actor-generation changes rebuild the relevant cached state.

Claim pruning now runs for relevant notice/delivery facts and scheduling, avoiding a full claim scan for every unrelated event during history replay.

More Predictable Runtime Recovery and Diagnostics

• Claude: wait for late Agent View replies, preserve the saved session when queued input interrupts a turn, and pause automatic restoration after ten consecutive failures. Diagnostics identify safe error kinds. Stop failures distinguish a missing control endpoint from a job that is still present; resources remain owned until authoritative removal is confirmed.
• Codex: honor the model explicitly declared in the runtime command when opening the native thread.
• DeepSeek: distinguish failed turns from incomplete delivery so provider failures do not keep resubmitting the same work as though it never ran.
• Pi: show tool activity in the headless trace with limited command/file summaries, protecting arguments and private values. A length-stopped turn with no final reply settles as failed rather than remaining unfinished.
• Terminal diagnostics: Actor queries expose the last output timestamp and quiet duration without starting work or waiting on busy transcript I/O. Output and silence are observations, not proof of working, idle or completed state; these fields do not introduce a new Web activity indicator.

Clearer Connections and Upgrade Notes

Direct connection previews distinguish the local Group from the inviting Group and keep the request action visible. Connectivity and identity-check failures show a retrying state with technical details, without being mistaken for a closed connection. Account-based invitations use clearer entry points. The cloudflared test fixtures also preserve multicall executable names, fixing the reported CI startup failures without changing production launch behavior.

Upgrade the CCCC executable, then restart the daemon/Web through your usual launch method to load the new code and bundled assets. Runtime history remains in CCCC_HOME. Keep third-party clients aligned with the documented optional task and search fields.

Refresh the CCCC plugin's tools and update existing Dots native tasks and Grok Webhook Routines with the current setup instructions. Reuse healthy bindings and existing tasks rather than deleting Actors or creating duplicate routines. Finish or explicitly end accepted unfinished turns before replacing native task configuration. To run an ended task again, review any earlier side effects and send a new, explicit message.

If upgrading from v0.4.43 or earlier, also review the v0.4.44 upgrade notes, including the move from CCCC-specific PROJECT.md handling to runtime-loaded AGENTS.md.

Live Voice remains experimental. This release does not claim to resolve Grok Voice pitch/timbre drift. External-session hot attachment is not included in v0.4.45.

Full source comparison