CodeClone

Deterministic Structural Change Controller for AI-assisted Python development

Let agents move fast.
Keep structural change explicit, bounded, and verifiable.

[!NOTE] This README documents the unreleased CodeClone 2.1 alpha line. The basic analysis commands below work with the current stable release, CodeClone 2.0.2. Agent change control and Engineering Memory require the 2.1 prerelease.

What is CodeClone?

CodeClone helps developers use AI coding agents without losing control of structural change.

Before an agent edits code, CodeClone records the intended change, maps the structural blast radius, and establishes explicit edit boundaries. After the edit, it compares the real patch with the declared scope, verifies structural regressions, and leaves an auditable review receipt.

CodeClone makes silent scope expansion visible before it disappears inside an otherwise reasonable-looking diff.

CodeClone does not ask an LLM to decide whether a structural change is safe. It uses deterministic repository facts shared across agents, human reviewers, IDEs, reports, and CI.

How the controlled-change workflow works

For an agent, the normal workflow is:

analyze → start → edit → finish

Analyze

CodeClone builds one canonical structural report for the repository and compares it with the accepted baseline.

Start

start_controlled_change:

• records the agent's intent;
• maps structural blast radius;
• separates editable paths from review context and do-not-touch boundaries;
• exposes the regression budget relative to the accepted baseline;
• returns the authoritative edit_allowed result.

Edit

The agent writes the code. CodeClone does not generate or rewrite source files.

Where the host supports hooks, integrations can stop edits unless edit_allowed=true.

Finish

finish_controlled_change:

• resolves the actual changed files;
• checks declared scope against the real patch;
• verifies structural changes;
• validates optional review claims;
• records Patch Trail evidence;
• produces an auditable review receipt.

The result is not an AI opinion about the patch. It is a deterministic comparison between declared intent, repository structure, the accepted baseline, and the actual change.

Read the Structural Change Controller guide

What you get

CodeClone requires no hosted service or cloud account. Analysis state, controller state, Engineering Memory, and trajectories are stored locally.

Why intent comes before the diff

Most review tools begin after the patch already exists. CodeClone begins earlier:

task request
  → declared intent
  → structural blast radius
  → explicit boundary
  → actual patch
  → deterministic verification

Agent scope expansion can look reasonable in the final diff. A narrow task may quietly spread into shared helpers, tests, configuration, public APIs, or unrelated modules.

By the time that expansion reaches the final diff, it already looks intentional. CodeClone catches it at the declared boundary instead — by comparing what the agent said it would change with what it actually changed.

One canonical structural report

CodeClone runs one deterministic analysis and renders the same canonical report through every supported surface.

The report covers:

• function, block, and segment clones;
• clone drift and duplicated branch families;
• complexity, coupling, cohesion, dependency cycles, and dead code;
• public API inventory and baseline-aware API break detection;
• external coverage joined with structural hotspots;
• deterministic structural health and review priorities.

codeclone . --json --html --md --sarif --text

How CodeClone works · Canonical report contract

Baseline-aware governance and CI

The baseline is a versioned, integrity-checked contract that records the accepted structural state of the repository.

It lets CodeClone and connected agents distinguish:

• findings that already existed;
• regressions introduced by the current change;
• deliberate baseline updates approved by the user.

Check future changes against the committed baseline:

codeclone . --ci

Use CodeClone in GitHub Actions:

- uses: orenlab/codeclone/.github/actions/codeclone@v2
  with:
    fail-on-new: "true"
    sarif: "true"
    pr-comment: "true"

CI can reject newly introduced clones, metric regressions, API breaks, and coverage regressions without requiring the existing repository to be clean first.

Baseline contract · Metrics and quality gates · GitHub Action documentation

Engineering Memory

Engineering Memory gives agents durable, repository-specific context without treating model output as project truth.

The local SQLite store can contain:

• architecture and contract notes;
• risks, test anchors, and public surfaces;
• git and change-control provenance;
• prior trajectories and Patch Trail evidence;
• recurring advisory patterns called Experiences.

Agent-created records remain drafts until a human approves them.

codeclone memory init --root .
codeclone memory search "baseline schema" --match all

Memory can guide an agent. It cannot authorize edits, override blast radius, change a gate, or replace canonical report facts.

Engineering Memory documentation · Trajectories and Experiences

Trust boundaries

• Structural findings and gates come from deterministic analysis, not LLM judgment.
• edit_allowed is an explicit controller result; status or advisory ownership does not grant permission.
• Read-only analysis commands do not modify source code or project governance state.
• Baseline updates are explicit user-approved governance actions.
• Controller and memory operations write only to their explicit local state stores.
• Memory and trajectory evidence remain advisory.
• stdio is the recommended transport for local clients.
• Remote HTTP exposure requires explicit --allow-remote.

Documentation

orenlab.github.io/codeclone

• Getting started
• Structural Change Controller
• Engineering Memory
• MCP usage
• Configuration reference

Links

• PyPI: https://pypi.org/project/codeclone/
• Discord: https://discord.com/invite/U72KmRvpUx
• Issues: https://github.com/orenlab/codeclone/issues
• Discussions: https://github.com/orenlab/codeclone/discussions

Quick start

1. Analyze a repository

Run the stable release without installing anything:

uvx codeclone@latest .

Prefer a browsable report? Generate the HTML view and open it:

uvx codeclone@latest . --html --open-html-report

Once you use it regularly, install it as a local tool:

uv tool install codeclone
codeclone .

2. Record the current structural baseline

Before asking an agent to change the repository, capture the accepted state once:

codeclone . --update-baseline
git add codeclone.baseline.json
git commit -m "chore: add CodeClone structural baseline"

The baseline records the structural debt that already exists. Future analysis can then separate new regressions from findings that were already present, so agents and reviewers can focus on what the current change introduced.

Updating the baseline is an explicit governance action. Do not regenerate it merely to make a failing check pass.

3. Set up CodeClone for your AI agent (2.1 alpha)

Install the prerelease MCP server:

uv tool install --prerelease allow "codeclone[mcp]"
codeclone-mcp --transport stdio

Then wire it into your client:

Every client uses the same MCP interface and the same canonical structural facts.

Development setup

Run the repository version from source:

git clone https://github.com/orenlab/codeclone.git
cd codeclone
uv sync --all-extras
uv run codeclone .

CodeClone 2.1 requires Python 3.10 or newer.

License

• Code: MPL-2.0
• Documentation: MIT

See LICENSES.md for the license scope map.