CCCC v0.4.14 Release Notes

v0.4.14 is a ChatGPT Web Model stabilization and setup-clarity release.

The previous release made ChatGPT Web Model and local voice support serious runtime surfaces. This release tightens the part of that work users are most likely to touch first: getting ChatGPT connected, understanding what kind of ChatGPT session can actually do local work, and keeping the Web Model runtime easier to diagnose once it is running.

The main theme is focus. CCCC now treats the MCP-capable GPT-5.x ChatGPT path as the supported local-development path, while keeping experimental No-MCP advisory infrastructure isolated from the ChatGPT main flow.

ChatGPT Web Model Setup Is Clearer

v0.4.14 turns the ChatGPT Web Model setup path into a more explicit zero-to-ready flow.

The README and Web Model guide now describe the concrete setup order:

1. expose cccc web through a public HTTPS URL,
2. configure Web Access and an Admin Access Token,
3. create/start the ChatGPT Web Model actor,
4. copy the actor-bound MCP URL,
5. create a ChatGPT app from the current ChatGPT Apps/Connectors settings, such as Settings > Apps > Advanced settings > Create app,
6. set Authentication to No Auth, and
7. bind a target ChatGPT conversation before sending real work.

The docs also call out practical tunnel choices such as Cloudflare Tunnel, ngrok, Tailscale Funnel, and standard HTTPS reverse proxies. The goal is that a new user can follow one path instead of piecing together CCCC settings, ChatGPT app configuration, and browser sign-in behavior from separate hints.

GPT-5.x Is the Local Runtime Path

v0.4.14 makes the GPT-5.x / GPT-5.x Pro boundary more direct.

For local development, use a GPT-5.x ChatGPT session that can see and call the CCCC MCP connector. That path can receive CCCC messages, call local-development tools, edit the active workspace, run scoped shell/git work, and reply through CCCC.

GPT-5.x Pro is documented as advisory-only for CCCC today. Current ChatGPT Pro sessions do not reliably expose third-party MCP tools and do not provide a reliable No-MCP local-resource fallback. That means Pro should not be marketed as a CCCC local runtime: it has no dependable repository access, shell/git access, or CCCC tool access unless the user manually provides context outside the runtime path.

The Web Model bootstrap/help guidance now reinforces the same rule. If the selected ChatGPT model cannot see CCCC MCP tools, the model should not claim local execution and should ask the user to switch to a GPT-5.x ChatGPT session with the CCCC connector enabled.

Web Model Runtime Reliability

This release includes another hardening pass around ChatGPT browser state and delivery.

Status polling now avoids unnecessary deep CDP inspection by default, reducing contention with the shared projected ChatGPT browser session. User-initiated actions that need fresh browser truth, such as opening the surface or binding the current chat, still inspect the live browser state when needed.

The setup and runtime surfaces also handle global setup more coherently: users can open the ChatGPT browser before the actor is fully configured, and binding a current conversation uses the browser surface state instead of depending only on stale cached status.

This is not a claim that ChatGPT's website behaves like a local CLI. It is a practical reliability improvement: fewer unnecessary browser probes, clearer sign-in/target status, and less chance that setup UI reports a misleading inactive or missing browser state.

Web Models UI Is Future-Proofed

The settings navigation now uses the generic Web Models concept instead of labeling the whole tab as ChatGPT Web Model.

The current provider-specific panel is still ChatGPT-specific, because the implementation is ChatGPT-specific: ChatGPT sign-in, ChatGPT target conversation binding, ChatGPT MCP app setup, and ChatGPT browser delivery all remain explicit. Under the hood, the i18n keys are now structured as webModels.chatgpt.*, leaving room for future provider-specific surfaces such as Grok, Gemini, Claude, or AI Studio without renaming the entire settings area later.

The ChatGPT Web Model settings panel is also localized through the Settings i18n namespace in English, Simplified Chinese, and Japanese.

Composer Recipient Persistence

The Web composer now keeps normal message recipients per group instead of clearing them every time a message is sent.

Reply mode still has its own recipient behavior, but after cancelling or completing a reply the composer restores the normal recipient state for the active group. This reduces repeated recipient selection in everyday group work while avoiding accidental cross-group sends during group switches.

Pet reminder drafts were adjusted to respect the same reply-aware recipient path, so staged assistant drafts do not overwrite the user's normal recipient memory unnecessarily.

No-MCP Advisory Groundwork

v0.4.14 includes session-scoped No-MCP advisory infrastructure as backend groundwork, not as the ChatGPT local-development path.

The No-MCP layer is designed around read-only, session-bound project context and advisory text return. It uses scoped session IDs and secrets, expiry, allowlisted project reads, denied sensitive paths, range-limited file reads, literal search, bounded diff output, and idempotent advisory message submission.

This is intentionally not a full MCP-over-URL gateway and not a replacement for ChatGPT MCP local execution. It remains groundwork for future web agents that cannot configure MCP but can reliably access a public CCCC URL, such as a future Grok or Claude-style advisory integration. ChatGPT local development remains the MCP path.

Why Upgrade

Upgrade to v0.4.14 if you want to:

• configure ChatGPT Web Model from a clearer zero-to-ready path,
• use the Web Model settings panel in English, Simplified Chinese, or Japanese,
• avoid confusing GPT-5.x Pro expectations around local access,
• reduce ChatGPT browser status/probing contention during setup and runtime inspection,
• keep normal composer recipients across repeated messages, and
• pick up the No-MCP advisory substrate for future no-MCP web agent work without changing the supported ChatGPT runtime path.

In short, v0.4.14 is the release that makes the v0.4.13 ChatGPT Web Model work easier to configure, easier to explain, and less likely to mislead users about which ChatGPT sessions can really act as local CCCC runtimes.