CCCC v0.4.36 Release Notes

v0.4.36 completes CCCC's transition to one native product. Rust is no longer an experimental implementation selected beside Python: it is CCCC. The public CLI, daemon, MCP server, Web UI, runtime supervision, integrations, and durable state handling now ship as one versioned executable with one behavior model.

This release is deliberately about consolidation rather than expanding the product surface. It removes the cost and ambiguity of maintaining two product engines, unifies the website and pip distributions, preserves the supported 0.4.35 state boundary, and closes the native protocol and migration gaps needed to make that simplification dependable.

One Native CCCC

Running cccc now starts the only supported product implementation. There is no engine preference, version-matched private payload, Python fallback, or second daemon/Web stack behind the command.

The following 0.4.35 transition controls are retired:

• cccc python and cccc rust;
• the public ccccd compatibility command;
• the Python daemon, Web server, launcher, and importable cccc product package;
• implementation-selection settings and mismatch checks.

Use cccc daemon start|status|stop for explicit daemon lifecycle operations. Compatible daemon state filenames remain unchanged so existing homes can be adopted without keeping a Python runtime installed.

This product change does not remove the separate CCCC client SDKs. Python, TypeScript, and Rust applications can continue to connect to the native daemon through the documented SDK and IPC contracts.

One Build, Two Installation Choices

The website installer remains the recommended end-user path. Pip remains available for package-manager compatibility. Both channels now wrap the same release-ready Rust executable rather than building or selecting different products.

Supported release targets are:

• Linux x86-64 with glibc 2.28 or newer;
• Intel macOS 11 or newer;
• Apple Silicon macOS 11 or newer;
• Windows x86-64.

The pip distribution is a native platform wheel with no CCCC Python package or runtime dependencies. v0.4.36 does not publish an sdist or universal wheel, so an unsupported platform fails resolution instead of silently installing the historical Python product.

The default Dockerfile follows the same native-only model and keeps the existing cccc-data volume contract. The parallel .rust Dockerfile and Compose variant are retired because they no longer represent a different product choice.

Install ownership is now explicit. Website installations carry standalone-v1; pip installations carry pip-v1. The standalone updater will not overwrite a pip-owned command, and the website installer will not take over pip-owned files even when generic replacement is enabled. Switching channels requires uninstalling the current owner first, which prevents an update or package-manager uninstall from deleting the other channel's executable.

Existing 0.4.35 Homes Move Forward

v0.4.35 is the final dual-engine release and the supported rollback boundary. v0.4.36 reads supported state from the same CCCC_HOME, including Groups, scopes, actors, append-only ledgers, Mail cursors, settings, access tokens, account and Reach state, actor profiles and secrets, Web Model connectors, Group Bridge trust and receipts, IM configuration, Voice Secretary documents, NotebookLM bindings and jobs, Presentation state, automation, and capability state.

Legacy shadows are consumed or ignored without resurrecting removed settings, and supported reads do not rewrite a home merely to make it parse. This keeps a normal upgrade reversible: stop every 0.4.35 process, back up CCCC_HOME, and install 0.4.36. A 0.4.35 rollback remains possible while no separately documented irreversible migration has been performed.

Native Control Plane and Product Surfaces

The native daemon now owns the complete public event-stream path used by SDK clients, including capability discovery, bounded resume, routing, heartbeat, and slow-reader behavior. CLI, MCP, Web, Group Bridge retry, and runtime recovery use that same daemon authority instead of depending on a Python owner for background work.

Browser-backed product surfaces also have one owner. ChatGPT Web Model, NotebookLM sign-in, and Presentation use the native Web browser projection path; the retired Python attach/VNC operations are no longer exposed as a second lifecycle. Voice Secretary reports the linked native ASR engine truthfully while continuing to manage downloadable model files separately.

Shared prompts, MCP tool metadata, help, and built-in capability resources now live outside the retired Python package and are embedded directly into the native product. Agent-facing guidance therefore follows the same release identity as the daemon that serves it.

NotebookLM: Explicit and Safer Native Workflows

The retained NotebookLM integration is aligned with the upstream v0.8.1 protocol baseline. Native CCCC supports explicit URL, YouTube, Google Drive, text, and project-scoped local-file ingestion, along with the retained research and artifact workflows.

Automatic work-lane and memory-lane mirroring is retired. It obscured which remote notebook was being mutated and added a second synchronization authority. Use explicit source operations instead; legacy 0.4.35 synchronization metadata remains readable for migration status but is not used to initiate new writes.

Source creation and retry handling are also more conservative. If NotebookLM may have accepted a create request but CCCC cannot prove the result, the job stays unresolved rather than becoming a normal retryable failure that could duplicate the source. A retry also verifies that the Group is still bound to the same notebook, preventing an old job from writing into a notebook the Group has since left.

Upgrade

Before upgrading, stop the daemon and any foreground CCCC process, then back up CCCC_HOME.

For a website-installer-owned command:

cccc update --check
cccc update

For a pip-owned command:

cccc daemon stop
python -m pip install -U "cccc-pair>=0.4.36"

To switch from pip to the website installer in the same command directory, first run:

python -m pip uninstall cccc-pair

Then install through the website channel. After either path, open a new terminal and run:

cccc --version
cccc doctor
cccc daemon status

Source checkouts are no longer pip-installable product packages. Build the native executable with ./scripts/build_package.sh on macOS/Linux or scripts\build_package.ps1 on Windows, then run the binary under target/release/.

Compatibility Notes

• A Python interpreter is not required to run CCCC. Python remains in the repository only for release, packaging, migration-fixture, and developer tooling.
• Automation that imports the former cccc Python product package must migrate to the daemon IPC or an official client SDK.
• The legacy IM /context, /launch, and /quit commands are retired; use Web or the native CLI for lifecycle control. The old skip_pending_on_start=false backlog policy is normalized away during upgrade instead of replaying an unbounded provider backlog.
• Browser-projected features still require a supported local Chrome, Chromium, or Microsoft Edge installation.
• Reach remains unavailable on Windows in this release because the managed Windows cloudflared helper is not bundled.
• Do not run a 0.4.35 daemon and a 0.4.36 daemon against the same CCCC_HOME at the same time.

For the complete installation and state-transition details, see the Rust-only product and 0.4.35 migration guide.