cc-mini ships no licence file, and its README understates the Python floor

No LICENSE in the tree and no licence field in the manifest

The repository root holds .gitignore, README.md, assets/, docs/, install.sh, pyproject.toml, src/ and tests/. There is no LICENSE file, and pyproject.toml carries no licence field and no licence-files entry either, which is why the platform records the licence as unknown rather than guessing.

That combination has a concrete meaning. With no grant anywhere, default copyright applies to all of it, so you can read it and you can learn from it, and you do not have permission to redistribute it, bundle it into a product, or ship a fork without the author's say-so.

There is no GitHub release history either, so there is no earlier published version with different terms to compare against. The only version number in the project is 0.1.0 in the manifest, which is consistent with a pre-release state and with a README that advertises several of its features as reimplementations of unreleased upstream work.

None of that makes the project unusable. It makes it a repository to fork rather than a dependency to add.

The README says Python 3.10, the manifest requires 3.11

The requirements section asks for Python 3.10 or newer with 3.11 or newer recommended. The packaging metadata says requires-python is 3.11 or newer, with no recommendation involved.

Those two statements do not agree, and the failure mode matters. Following the README on Python 3.10 gets you to pip install, which then refuses the distribution on the version constraint, so the reader loses time before the project has run a line of code. The 3.11 recommendation in the README is in practice a hard requirement.

The dependency list is short and readable: anthropic and openai SDKs, httpx, prompt_toolkit, rich and python-dotenv, all with lower bounds only and no upper pins. The development extra adds build, hatchling, pytest and pytest-asyncio.

Note what those dependencies mean in practice. Both vendor SDKs are unconditional, so you install the Anthropic client and the OpenAI client even when you have configured exactly one provider. The agentic framing in the description carries over from Claude Code, and this manifest still installs both sides of that conversation.

The recommended install pipes main into bash, and the sandbox wraps the agent's shell

Two install paths, and they make very different promises:

# One-line install (recommended)
curl -fsSL https://raw.githubusercontent.com/e10nMa2k/cc-mini/main/install.sh | bash

# Or manual
git clone https://github.com/e10nMa2k/cc-mini.git
cd cc-mini
pip install -e ".[dev]"

The recommended path downloads a script from the moving main branch and hands it straight to a shell. There is no tag, no checksum and no review step. The manual path is three commands you can read first, and it installs the development extra rather than the runtime alone.

That asymmetry is worth noticing against the project's own security posture. One of its five advanced features is a sandbox described as bubblewrap isolation for bash commands, so the agent's own shell gets wrapped, while the way you install the wrapper is an unpinned remote script. The test suite reflects the same split: ordinary tests run directly, and the bubblewrap cases are a separate integration class you exclude with a filter.

pytest tests/ -v
pytest tests/ -v -k "not integration"  # skip bwrap tests

The documentation does not say which operating systems the sandbox supports.

Six directories ship as top-level packages, four with generic names

The build configuration is where the packaging gets interesting:

[tool.hatch.build.targets.wheel]
packages = ["src/core", "src/features", "src/tui", "src/commands", "src/buddy", "src/tools"]

Because those directories are listed as the packages themselves, installing the distribution puts modules named core, features, tui, commands, buddy and tools into site-packages. Four of those six names are generic enough to collide with anything else installed in the same environment, and there is no shared namespace prefix such as cc_mini in front of them.

The console script is a separate matter and looks fine: the entry point is tui.app:main, which lines up with src/tui/ and with the interactive REPL the README advertises.

The source layout itself is worth reading for the design claim. The core directory holds the engine, the LLM client, configuration, the system prompt builder, the tool protocol, the permission checker and session persistence, described as the pure harness, with tool implementations one file each under tools/. The README's structure listing covers core in full and then stops partway through the tools directory, at a line beginning with the word file, so the rest of the layout is not shown.

Project skills and project config both load from the working directory

The data path table splits state across two roots. Source code, the installation itself, and your own skills live under ~/.cc-mini/. Sessions, memory, plans, REPL history and the companion data live under ~/.config/cc-mini/. User skills are ~/.cc-mini/skills/, and project skills are read from a .cc-mini directory inside the current working directory. Project configuration is a .cc-mini.toml file, again relative to where you launched from.

That last pair is the one to think about before running the harness anywhere unfamiliar. Skills are one-command workflows, with /review, /commit, /test and /simplify shipped as examples, and the documentation includes a worked example of a project-specific custom skill. A project that ships its own .cc-mini directory therefore supplies its own workflows to any harness started inside it, and a .cc-mini.toml supplies its own configuration.

This is a normal pattern for project-scoped tooling and a normal supply-chain exposure at the same time. Nothing about it is hidden, but nothing prompts for it either, so the check belongs to whoever is about to type the command in a cloned repository.

Six of nine tools are auto-approved and one flag removes the other three

The permission model is mode-aware and split by tool class. Read, Glob, Grep, AskUser, EnterPlanMode and ExitPlanMode are auto-approved. Edit, Write and Bash each require confirmation. The two modes are default and plan, and in plan mode the subagents explore the codebase in parallel before you implement, under what the documentation calls permission isolation.

Coordinator mode adds three more tools: Agent to spawn a worker, SendMessage to continue one, and TaskStop to stop one. Plan mode uses the same Agent tool for read-only exploration.

So of the nine built-in tools, three can change something on the machine and every one of those three asks first. That is the right default for a tool that runs shell commands, and it is one flag away from being off:

cc-mini                              # Interactive REPL
cc-mini "what tests exist?"          # One-shot prompt
cc-mini -p "summarize this codebase" # Print and exit
cc-mini --auto-approve               # Skip permission prompts
cc-mini --resume 1                   # Resume previous session
cc-mini --coordinator                # Coordinator mode

That listing also carries an undocumented wrinkle: a bare quoted prompt and the same prompt behind -p are presented as two different modes, one interactive and one printing and exiting, and the flag's own semantics are never spelled out beyond that comment.

Both vendor SDKs installed, and a provider variable that names a protocol

The provider configuration is where the OpenAI-compatibility story gets precise. For Anthropic you export ANTHROPIC_API_KEY. For anything else you export CC_MINI_PROVIDER=openai, and the comments are emphatic that this is a protocol type rather than a vendor name: Azure AI Foundry and other OpenAI-compatible gateways still use openai, and you must not set the provider to foundry or bedrock. Alongside it come OPENAI_API_KEY, an OPENAI_BASE_URL pointing at your gateway, and an optional CC_MINI_MODEL whose documented default is gpt-5.1-codex.

Two things follow. A gateway deployment needs no vendor-specific branch, which is a genuinely useful design. And the model variable is documented only inside the OpenAI-compatible branch, so there is no stated way to pin a model on the Anthropic side, even though both SDKs are installed.

The slash command surface is small and conventional: /help, /compact, /resume, /history, /clear, /skills, /buddy with its own help, and the four skills. The five advanced features are described as reimplementations of features from unreleased Claude Code versions, which is both an honest statement of provenance and a signal about how much of this is waiting on upstream.

A thousand lines of Python, advertised above a Tamagotchi

The sizing claim sits in the header as roughly 1000 lines of Python for the entire core, with a tilde in front of it and no way to reproduce the number from the repository. What can be counted from the packaging config is six shipped packages, and the structure listing names seven files inside core alone: engine, llm, config, context, tool, permissions and session.

The feature advertised first under a new heading is not any of that. It is Buddy, a companion in the terminal that you hatch with /buddy, with a personality, stats, mood and speech bubbles, and custom ASCII species because, in the project's words, you can bring your own Pikachu. The sample session shows a hatch result with a rarity name and a five-star rank, then a mood readout as two bar meters with numeric values and labels.

It is a strange thing to lead with, and it is also the one feature with a full page of its own documentation alongside coordinator, memory, skills, sandbox and configuration. Read the repository as a teaching harness for an agent tool loop and the pet is a curiosity; read it as a product and the emphasis is inverted.

Editorial conclusion

cc-mini is worth reading and worth forking, and neither of those needs permission from anyone. Copying it into something else does, because there is no licence file, no licence field in the packaging manifest and no release history to point at. That is the first thing to settle. The second is where you run it: project skills are loaded from a .cc-mini directory in the current working directory and project configuration comes from a .cc-mini.toml beside it, so launching the harness inside a repository you did not write means trusting code that project brought with it. The third is the Python version, because the README's 3.10 will install and then fail packaging, while the manifest's 3.11 will refuse it cleanly. Everything else is small and legible: both vendor SDKs installed regardless of provider, permission prompts on write and shell with a flag to skip them, and a sandbox that only applies to the agent's own shell commands.

Frequently asked questions

Official sources

1. e10nMa2k/cc-mini on GitHub
2. Issues
3. README