CCCC v0.4.56 Release Notes

CCCC v0.4.56 reworks the capability library around the work agents do in a Group. CCCC now ships a short list of 10 skills and MCP servers that we tried on that work ourselves, each with the reason it is listed, when not to use it and how far we checked it. CCCC Web shows for each member of a Group whether it can use an entry, an agent can browse the entries it might use, with when each fits and any setup it needs, and bootstrap gives a short index of them; an agent's search shows whether an entry suits that agent, and an agent that uses a recommended entry receives our notes about when not to use it. See Capability Library.

Remote MCP servers that need a token can now use each managed agent's own token, and a recipe can be updated for all Groups from CCCC Web. Remote and local MCP servers run on the official Rust MCP SDK. A Claude Code agent that CCCC starts no longer loads the CCCC plugin meant for Claude Code sessions you start yourself. This release covers the changes since v0.4.55.

Before You Upgrade

Before upgrading, let sends and recordings finish. Restore or discard waiting sends, then send or copy every unsent draft, restored ones included, and save unsaved edits in Files: all of these live only in the open page. Check whether a message already arrived before sending it again.

Upgrade the CCCC executable, restart the daemon and Web the way you usually launch them, and reload open CCCC pages. The standalone installer behind cccc update stops a running daemon and starts it again from the new version. Before a pip upgrade, run cccc daemon stop and close any foreground CCCC so pip can replace the executable, especially on Windows. A daemon left running keeps the previous version. Runtime history stays in CCCC_HOME.

• cccc_capability_search no longer returns a skill's text. An agent reads it with cccc_capability_use(capability_id=...). A native session keeps the MCP server it started with until that server is started again, for example by restarting the session; until then the description of cccc_capability_import still says to read a skill's text with search.
• Programs that call the daemon directly: capability_search returns summaries, and capability_overview returns skill text only for the self-proposed skill editor. The SDK's 0.4.56 migration guide describes the existing ID-only read that returns the text.
• Existing capability records, bindings and blocks are kept. A record of yours that uses a recommendation's ID keeps winning and is not relabeled.

Capability Library

A short list chosen for the work

The list groups entries by the work agents do: Find and check facts, Read documents and materials, Compute and analyze data and Write for people and review. It holds 6 MCP servers and 4 skills.

• We went through common development and office work of agents in a Group and compared candidates with the way members already do that work. For most of it, members' own tools and local software were enough in our checks, so an entry is listed only where we produced a representative result with it.
• An entry is a primary only where a trial showed a gain over what agents already use, such as their own search, shell, local source code and the project's tools. This release has one primary: Exa, for facts where an agent's own search finds no credible source. Every other entry is an alternative.
• Each reason says what our result showed and its limits; the notes say when not to use the entry and what to check.
• Each entry records how far it was checked: listed, install checked, tool call checked or task checked, with the date and the build. Failed checks are kept. Passing a check does not mean the entry improves a task.
• The list ships with CCCC and changes with new versions. Recommended skills are read-only; to keep a fixed copy, save it under another ID. Nothing is installed or enabled until someone enables an entry; an MCP server is then installed by its installer.

Capability page in CCCC Web

• Open Capability Center, in Settings → Capability Governance and on a Group's Skills tab in Project Context, opens the Capability Center over the page you are on instead of in a new browser tab. Close it, with its close button or Esc, to return to that page, which then reloads its list. The former /ui/capabilities address opens the main page.
• Recommended shows the work groups with their skill and MCP columns, the primary first. A status mark shows whether any member of the Group can use an entry, needs setup first, may depend on its own tools, cannot use it, or is blocked; hover for the words.
• An entry's details show why it is listed, each member's status and the reason, how far it was checked, where it runs, how it signs in and what it needs.
• Enable for Group is offered when some member can use the entry, or might. The MCP and Skills lists show the same status and offer the same action for recommended entries.
• A search on the page no longer drops entries the daemon matched. The page used to filter those results again by text with a narrower rule, so some matches disappeared, such as entries matching several words in different fields.

What agents get

• When a client connects, CCCC's MCP server sends a short note, 511 characters in English: CCCC offers optional skills and MCP servers for research with cited sources, current web facts, papers, reading office files, spreadsheets, data checks, contract redlines, public repository questions and code that must match a library's version; when a task would clearly gain from one, the agent can browse the recommended ones or search for one, and reads an entry's limits before enabling it. Both the MCP handshake CCCC already supported and the newer server/discover used by Web model connectors carry it; Voice secretary sessions, which cannot see those tools, do not. Whether the agent sees the note depends on its client: Claude Code and Codex document that they read it; we did not check other clients.
• cccc_capability_search(recommended=true) lists the recommended entries for the calling agent, at most ten, so it need not guess a word: blocked entries and entries it cannot use are left out, entries it must set up first stay with their requirements, and a query narrows them. Each entry carries the same summary as other search results. Without this argument, search is unchanged.
• cccc_bootstrap lists the recommended entries that an agent might use, one line each with whether it is the primary or an alternative, its exact ID and when it fits. Entries the agent must set up first, or whose requirements CCCC cannot check for that agent, are listed with their requirements; blocked entries and entries the agent cannot use are left out. A note says that entries are optional and that listing does not enable them. The list stays within 24 entries and 3,072 bytes and says how many entries it left out.
• Help points agents to browsing the recommended entries, or to bootstrap's list, when a capability could fill a gap or improve quality or efficiency, asks them to check requirements and limitations first, and to keep their own tools when the added option does not help.
• Help and the description of cccc_capability_search say to search by a name or one short word: every space-separated term must appear in an entry, so each added term narrows the results. The description of cccc_capability_search also names the kinds of work the recommended entries serve, so a client's tool search has matching words.
• cccc_capability_search returns summaries: the first use case, the cases to avoid for recommended entries, requirements, verification and whether the entry suits the calling agent.
• When an agent uses a recommended entry, CCCC returns its notes (when not to use it, known pitfalls and its requirements) alongside the skill's text, the result of preparing an MCP server and each answer from the server's tools, including answers marked as errors. The text and the answers themselves are unchanged. A call that fails before the tool answers carries no notes. The notes are in English.

MCP servers that need a member's token

• A recipe names the environment key that holds the token, never the token. The value comes from the managed agent's own private settings or its linked Profile. The daemon's environment and other members are not used.
• Enabling for the Group records the intent only and does not use anyone's token. An agent prepares its own tools when it uses the entry.
• Native sessions and Web model members cannot use a member token through CCCC.
• A rejected token and a token without permission are reported separately. CCCC does not copy a token into capability records, shared runtime state or logs, and keeps the tool lists fetched with it only in memory.

Updating a recipe

When a newer recipe is available for an installed MCP server, an administrator can update it from the capability page for all Groups after confirming that scope. A failed update keeps the previous installation. Agents never update a recipe.

More dependable MCP servers

• Remote MCP servers use the official Rust MCP SDK 3.9.0 and accept JSON and streaming responses. An expired session is not started again and a call is not sent twice.
• Local MCP servers run on the same SDK. The handshake and the call share one time limit, and an error includes up to the last 8 KiB of the server's error output, with known credentials and declared environment values removed.
• An imported skill keeps its full text, up to 2 MiB.
• A tool result marked as an error no longer counts as a verified call.
• Source links are shown without user names, passwords, query or fragment.

Managed Claude Code Agents

When you set up CCCC for Claude Code sessions you start yourself, CCCC installs a Claude Code plugin in your user settings. Claude Code agents that CCCC starts loaded it too: in the start we observed, its background receiver ended at once and the model spent an extra turn answering that notice. CCCC now turns the plugin off in the settings of each session it starts. Your user and project plugin settings are unchanged, and sessions you start yourself receive messages as before. Checked with Claude Code 2.1.322 and 2.1.317.

Known Limitations

• Two new Claude Code agents, each in a fresh session, were given the same task: a handover written from six documents, plus a one-line edit. The first trial ran before the connection note and the browse option existed; the second ran on the final package, and the requests Claude Code recorded for its model carried the note. Neither agent called bootstrap or browsed or searched the list; each finished the task with its own tools, and both results passed the checks we had written in advance. The task could be done well without an entry, so neither trial shows whether agents look for an entry when it would help, how often they pick one, or whether the list makes such work faster or better. In an earlier trial with a pre-release build whose bootstrap showed only the primary recommendation, a new agent saw it and answered from official sources without it, as the entry's notes allow.
• Capability search matches words literally: every space-separated word of a query has to appear in an entry's text, so each additional word can narrow the results, and Chinese or Japanese text without spaces counts as one word.
• The representative results behind the list come from our own checks on one Linux machine, mostly one task per entry; the reasons and notes say where an entry was not tried.
• While a remote MCP server is enabled for the first time, or a local one is installed, other CCCC requests can wait until it has connected or downloaded, in other Groups too. In a controlled test whose remote server delayed its answer by 30 seconds, a message sent as Mail, inbox reads and a health check from another Group each took about 30 seconds instead of a few milliseconds, while a read of the MCP catalog state, used as a control, still answered in milliseconds. How long real servers and downloads take, and how often this happens, was not measured.
• On Windows, local MCP servers started through npx and similar command shims are now resolved to the file the availability check found. This was not run on Windows.

Validation Scope

Release preparation ran these checks, the Rust checks in isolated homes. Before the last two changes: rustfmt, clippy and the Rust tests in CI's three groups: 4,072 of the 4,073 listed tests that are not ignored passed, each run once, and 10 are ignored. The one failure was a new test whose setup used an import that the release protects; after its setup was fixed, clippy and that test's binary, 287 tests, passed. The next change makes a null recommended count as absent, as null already does for the other optional search arguments; after it, rustfmt, clippy and that test binary (287 tests) passed. The last change opens the Capability Center over the page it came from; it changed the Web front end, including its service worker, and documentation, and no Rust or Python code. On the final code, git diff --check, the repository's Python tests (126 passed), the Web check and the Web tests (5,016 tests in 668 files) passed; ruff ran earlier, and no Python file changed after it. After the last edit to this section, git diff --check and the Python tests were run again.

Each change was also tested when it was made:

• The list was rebuilt from a review of the development and office work agents do in a Group. Each kept entry produced a representative result in that work; its reason and notes say what the result showed and its limits.
• Search was checked without a model on fixed questions. In two sets written separately and sealed before they were run, a fitting entry was among the first three results for 4 and 3 of the 7 questions in each set that had one, and for neither Chinese question in the second set, because every word of a query has to appear in an entry. Bootstrap therefore lists the entries, and help describes the literal matching.
• Tests check that cccc_bootstrap lists each entry an agent might use once, with its role, first use case and marks; leaves out blocked and unsupported entries and skills that available_skills lists; puts pending entries first, then primaries, then the manifest order; and stays within 24 entries and 3,072 bytes, counting the entries it leaves out, also with multi-byte text and an ID longer than the bound. A daemon test checks that recommendations keep the manifest order.
• Tests check that the MCP initialize result carries the connection note, at most 512 characters, and that a Voice secretary task session's result has none, with or without its grant; that a Web model connector returns the same note from the legacy initialize and from server/discover, the latter for both a ChatGPT and a Grok connector; and that recommended: true lists only release recommendations, in bootstrap's order, keeps skills the member has enabled, leaves out blocked, removed and privately overridden entries, returns the same summaries as search, narrows with a query and changes no capability state, while search without the argument, with null or with false is unchanged and any other non-boolean value is rejected. A unit test checks the shared selection and order, and that the release list fits the browse limit of ten.
• Member-token checks used a loopback HTTP MCP fixture and generated test tokens, through real CCCC daemon and MCP processes. Two managed identities received different tool lists; delegated and direct tool calls reached the fixture as the correct identity. Changing a token invalidated only that member's cached list. Switching the shared recipe made no discovery request; the next explicit use reached the new fixture URL with that member's token. Returned data and shared state, events and logs were checked for the test tokens. Separate daemon regressions covered linked Profile credentials and unsupported callers, distinct 401 and 403 failures, global and Group blocks and failed qualification sending no requests, and a foreman's Group enable recording intent without sending a request, with or without its own token. Clearing a fixture's cached tools and calling its generated external name recovered the list with the same member identity; invalid or nonrecoverable names sent no request.
• Local protocol fixtures checked notes in search summaries, skill reads, MCP preparation, direct external tool results and calls through cccc_capability_use. The original skill body, upstream tool result and external arguments were unchanged; the bridge exposed the notes once alongside tool_result. A private record overriding a release ID did not acquire release-owned notes. These checks do not mean that an agent follows the notes or improves its task.
• Against the v0.4.55 binary, local HTTP fixtures reproduced a 406 when SSE acceptance was required and a decoding failure when SSE was returned without that requirement. The same discovery probes succeeded after the change, and the JSON fixture's delegated call still returned its marker. Separate local HTTP tests checked JSON/SSE tool calls, pagination, deadlines and an expired session without repeating the tool call. A warm-cache DuckDB command probe observed missing replies when it closed the service's input immediately after sending requests, and replies when it kept the input open. Stdio fixtures covered handshakes, calls, deadlines and process cleanup. Failure fixtures echoed synthetic credentials and a declared environment value into stderr; the returned diagnostic and stored error redacted them, and an explicit invoker environment value took precedence over the inherited value.
• An isolated development-binary walk imported the same 4,984-character skill through both the target-install and generic import paths and read it back through MCP. Both returned the exact text, including its first and last markers; the v0.4.55 generic import had returned only 2,400 characters. This exercised a text skill, not an attached script or resource bundle.
• Actual Claude Code 2.1.322 and 2.1.317 executables ran with isolated homes and a loopback model fixture, without a real subscription or provider request. With the fixture plugin enabled in user settings, the managed baseline made an opening request containing its empty Monitor completion notice. The session-only override made no opening request in the 15-second observation window, and an explicit prompt still completed. In a later unmanaged session using the same isolated home, the fixture's hooks and Monitor ran again and its marker reached the model fixture. The user settings file stayed byte-identical; the case without an installed plugin also started successfully. This Monitor control and the unchanged native path plus regression tests are not a live end-to-end acceptance test of every native delivery route.

An earlier package, built before the null change and the in-page Capability Center (cccc 0.4.56 for Linux x86_64), was checked in isolated homes without a model. Its Web served the same index and 34 assets as the build. From the extracted archive, a walk without network access connected to CCCC's MCP server as a default member: initialize carried the connection note, equal to the approved 511-character text, and the tool list carried the approved search and use descriptions. Browsing with recommended: true listed the 10 entries in bootstrap's order, still 10 after the member had read the 4 skills, and none once all were blocked; a query narrowed the list to one entry, search with false matched search without the argument, and browsing left the capability state and runtime files unchanged. In the same walk, bootstrap listed the 10 entries in 1,942 bytes, 6 after the skills were read, which then appear in available_skills, and none once all were blocked. A Voice secretary task session received no note and only its own tool. A Web model connector on the package's Web returned the same note from the legacy initialize and from server/discover.

The note and the browse option changed no Web page and no stored state, so the other package checks ran on the package built just before them. The common screens were walked in English, Chinese and Japanese at desktop and phone width: 508 screenshots, with no failed step. The 4 release skills were read through MCP with their exact text and notes, and all 10 search summaries carried no skill text. After an upgrade from an earlier pre-release package with a skill that this release removes enabled for a Group, the daemon, the capability page and bootstrap kept working: the removed skill disappeared from the capability page and bootstrap and using it reported that it was not found, while its old enabled ID remained in the capability state. After an upgrade from the v0.4.55 release, the Group, its member, the ledger and earlier messages kept working; two private skills and a local MCP server imported under v0.4.55 kept working, the server also through the tool name generated before the upgrade, and a private skill holding a release entry's ID stayed private, without that entry's notes.

The final package, built after the last change (cccc 0.4.56 for Linux x86_64), was checked in isolated homes without a model. Its Web served the same index and 33 assets as the build, and the former /ui/capabilities address, with and without a query, opened the main page. From Settings → Capability Governance and from a Group's Skills tab in Project Context, in English, Chinese and Japanese at desktop and phone width, all 12 cases passed: the Capability Center opened in the same tab over the panel it came from, which stayed in place; with a confirmation open inside the center, Esc closed only the confirmation; a second Esc returned to the panel, which reloaded its list and gave focus back to the Open Capability Center button; the close button also returned to the panel; no page error occurred and no new tab opened. Opened from Settings, the Capability Center was captured in the three languages at both widths, 28 screenshots, and looked at; its lists scrolled inside it while the page behind stayed in place, and in the Japanese Skills list a search for データ 検証 kept validate-data among the rows. The common screens were not walked again on this package; the changed paths were checked as described above. The second trial described under Known Limitations also ran on this package.

This is not complete live acceptance; Known Limitations lists what was not checked. These checks show what CCCC sends. In that trial, the requests Claude Code recorded for its model carried the connection note; other clients were not observed. Whether agents look for an entry when it would help, or pick one, was not measured. Member tokens were tested only against local fixture servers. No member token was used against a real provider or SaaS MCP service. Credential-free public services were tried separately; that does not establish acceptance with authenticated services. All local checks were on Linux.