CCCC v0.4.37 Release Notes

v0.4.37 adds an Experimental spoken control surface to CCCC and strengthens the boundaries that make local and remote collaboration dependable. The main addition is Codex Voice: a low-latency Realtime Voice conversation backed by one persistent Codex analyst that can investigate the workspace, inspect CCCC state, and coordinate real Actor work without turning the voice layer into a second orchestration system.

The release also makes direct localhost Web use simple again, hardens remote Web and Group Bridge authentication, restores compact but actionable agent delivery guidance, and prevents large Web messages from failing at the HTTP boundary.

Codex Voice: Conversation Backed by Real Investigation

Codex Voice appears as one global control below the Group list. It is not an Actor and is not owned by whichever Group happens to be selected in the sidebar. The main control opens a single operational console; the adjacent call control starts or stops live audio.

The console combines two roles:

• Realtime Voice handles natural speech, interruption, clarification, and short conversational responses.
• Voice Analyst is the backing Codex thread. It can inspect the repository, use Codex and CCCC tools, query an explicitly named Group, perform substantial analysis, and return progress and results to the spoken conversation.

This separation keeps the audio loop responsive without reducing the feature to a dictation relay. When a request needs deeper work, Realtime Voice delegates one bounded investigation to the Analyst. The Analyst can also send tracked work to a concrete CCCC Actor; only that assigned Actor's reply is accepted as the authoritative result and returned to the Analyst.

The console includes:

• speaking-voice selection;
• microphone and supported speaker selection;
• mute, playback recovery, and Stop controls in the audio header;
• accumulated interim and final transcripts instead of unreadable fragment replacement;
• the genuine Codex TUI for the same Analyst thread, embedded beside the conversation on desktop and available as a tab on narrow screens.

One Analyst Across Voice Calls

Stopping a voice call releases browser audio and the shared recording lease, but it does not discard the Voice Analyst. Ongoing investigation or linked Actor work can finish in the warm Analyst thread, and a later call reuses that context. The exact materialized thread and repository binding are retained so the next Web process can resume them instead of silently creating a new analyst.

The first selected Group supplies a concrete repository working directory only when the Analyst is initially created. It does not become a permanent product scope. Later sidebar changes neither retarget the Analyst nor interrupt the call, and the Analyst can inspect another Group only when that Group is named explicitly.

Lifecycle handling is deliberately conservative:

• a Voice delegation is correlated with its exact Codex turn before output is treated as speakable;
• terminal input cannot steal a Voice request while its turn is being created;
• completed turns cannot be reactivated by a late RPC response;
• an unreplayable event-stream gap invalidates the session instead of leaving stale busy state behind;
• a deleted, detached, or moved repository binding is replaced before reuse;
• only the exact active call generation may turn a late Analyst or Actor result back into speech.

Local Web Without Account Setup

Opening CCCC directly through localhost, 127.0.0.1, or ::1 is passwordless again. CCCC grants an in-memory local administrator principal only when the reconstructed browser-facing origin is genuinely loopback. It does not create a hidden Access Token or persist a local credential.

The remote boundary remains explicit. LAN, Reach, public URL, and reverse-proxy exposure cannot be enabled until an Admin Access Token exists. Non-local clients must then authenticate with an applicable token, and Group-scoped tokens remain confined to their allowed Groups. Exact Origin checks remain in force for unsafe writes and sockets, and non-local clients cannot obtain the loopback principal by spoofing Host or forwarding headers.

Token-based Web login now establishes a rolling 30-day HttpOnly, SameSite=Lax cookie and removes the temporary bearer from browser session storage after verification. This lets ordinary mobile tab reclamation survive without moving credentials into URLs or long-lived JavaScript storage.

HTTPS responses add HSTS alongside restrictive framing, content-type, referrer, and permissions headers. Supervised loopback deployments configure their reverse-proxy trust boundary automatically; externally managed proxies must explicitly enable trusted forwarding and overwrite client-supplied forwarding headers.

Reach startup also verifies the identity of the recorded local CCCC Web process before opening a tunnel. A stale runtime record and an unrelated process that later occupies the same port are not enough to expose that service.

Group Bridge v2: Proof Before Trust

Native peers now prefer a signed v2 WebSocket handshake. A fresh server challenge, a client nonce in the signed hello, and a server-signed confirmation of the complete transcript bind both sides to the same live exchange. Captured challenge or ready frames cannot be replayed as a new session.

After a trust completes v2 successfully, both peers persist min_session_protocol=2 before reporting the route ready. Later v1 downgrade attempts are rejected. Existing v1 trusts may continue using the compatibility path until their first successful v2 handshake, preserving a controlled upgrade without keeping downgrade available forever.

Pairing recovery is bounded as well. An approved, unclaimed request created before claim expiry was persisted receives one ten-minute compatibility window when that exact record is first accessed. Polling another request does not start its window, and later retries cannot extend the migrated deadline.

Public Bridge endpoints require HTTPS/WSS, query-string bearer credentials are rejected, and the live route retains bounded reconnect and HTTP fallback behavior. Large messages sent from Web across the Bridge now follow the same text-attachment path as large same-Group Web messages instead of failing with HTTP 413.

Clearer Agent Messaging

Runtime delivery envelopes now keep the one identifier an agent needs to act: the full current event_id. Default storage mode and full parent metadata are omitted, while replies retain a short parent correlation marker. A typical delivery is therefore compact and actionable:

[cccc] user → peer-a [event_id=<full event id>]: Please inspect this failure

Each delivered batch receives one canonical reminder to reply through cccc_message_reply(event_id=...). Successful MCP message operations again include the short whole-situation reconstruction cue, while rejected or partially completed operations preserve structured error details and recovery actions. Nested Code Mode calls retain those details instead of flattening them to an opaque string.

Additional reliability changes include:

• request_reply with no recipient or @foreman resolves to the one concrete available Foreman; broadcasts remain invalid for reply obligations;
• structured runtime turns are no longer silently truncated at the historical 24 KiB text boundary;
• same-Group and remote Bridge Web messages above 64 KiB are stored as UTF-8 text attachments after preflight, while local cross-Group text remains inline under the bounded daemon IPC contract;
• the Web composer keeps a stable desktop height and bounded mobile growth across typed, pasted, dictated, suggested, and restored drafts.

Upgrade

Stop the daemon and any foreground CCCC process before upgrading. Backing up CCCC_HOME remains recommended.

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.37"

Then open a new terminal and verify the active installation:

cccc --version
cccc doctor
cccc daemon status

v0.4.37 keeps the native-only installation and ownership model introduced in v0.4.36; the website installer and pip platform wheel still deliver the same Rust executable.

Compatibility and Experimental Boundaries

• Codex Voice requires an installed Codex CLI, an existing codex login, a browser with microphone and WebRTC support, and at least one attached repository for first launch.
• Live audio is processed by Codex Voice. The native CCCC process reads the existing Codex credential to negotiate the provider call; the browser receives a WebRTC answer and bounded session events, not the credential.
• The Voice Analyst uses the current Codex account and Codex defaults and runs with the same trusted-local YOLO authority as a CCCC Codex Actor. Global Voice routes require a local or Admin Web principal.
• Only one live Codex Voice call and one warm Voice Analyst are managed per interactive Web host. The audio call does not reconnect automatically after a page reload or browser transport loss.
• Current live evidence covers Linux x86-64/WSL2 with desktop Chrome plus a 390 px responsive browser journey. Native macOS, native Windows, mobile browsers, and physical-device audio quality are not claimed yet.
• Once a Group Bridge trust has completed v2 and persisted its protocol pin, keep both peers on v0.4.37 or newer. Rolling only one peer back to a v1-only release can interrupt that Bridge until both sides support v2 again.

For setup and operating details, see the Web UI guide and the Group Bridge guide.