CodeDelta +
CodeDelta + →
everything besides churn

The Code Browser.

Every scan writes one self-contained page that reads the code: five tabs that never leave the screen — Changes (the side-by-side diff, for comparisons), Overview, Files, Classes and Visualiser — with the browser’s Back button and a breadcrumb on every screen. A single-project scan gets the same page without the Changes tab.

Overview. A comparison opens with the changed files ranked by what happened in them, each with a one-line story; below that, the whole project — languages, directories with their include links, every class, every file — and changed files open in the diff.

Changes. The side-by-side diff: every counter in the toolbar is a claim you can click and step through, the Ledger decomposes it into rows, moves paint violet at both ends, and the changed-file list carries per-function churn chips.

Files. A directory tree of every file; the reader shows a file’s classes, its functions in line order, what it includes, who includes it, and the source with line numbers. Changed files wear C/D/A chips and open in the diff.

Classes. Every class or namespace container found (C++, C# and Java): its files, its methods with file and line, the classes its code mentions — a textual match, each mention cited to file and line — and the classes that mention it.

Visualiser — directories. The include map as a 3D scene: one dot per top-level directory, an arrow from A to B for every include that crosses between them, with the count on the arrow. Drag to orbit, scroll to zoom.

Visualiser — classes. The class ego view: one class at the centre, its methods round it coloured by this scan’s churn, the classes its code mentions as satellites; click one to travel to it, and every link cites where the mention is.

Read it in the guide: The Code Browser · the papers behind the counters: Papers.

The AI Agent Scan.

Named SDK calls, model endpoints, exec-on-model-output, raw API keys, non-Western providers — found by reading the code, never by running it. Every flag names the file and line; the Agent Map draws the AI bill of materials as a picture.

The agent-scan report. Flagged files ranked by risk, each with the reason — which SDK, which endpoint, which danger pattern — and a link to the source.

The evidence. Click a flag and the flagged lines are shown in context, so the finding can be checked in seconds rather than trusted.

In the desktop app. The same scan from the app’s AI Agent Scan mode: one click, one local window, nothing leaves the machine.

The Agent Map. Every file where an AI SDK was detected, connected to the providers it calls. Red providers sit in sovereignty-sensitive jurisdictions (CN/RU/KP/IR) — data sent there leaves friendly soil. Hover anything for its story.

Also in the box, without a picture: the AI bill of materials (native and CycloneDX) and the policy gate (--gate) that blocks unapproved providers in CI; the baseline that fails a merge only on new findings. CLI / CI reference.

The AI Code Scan.

Files scored for generated-code characteristics — HIGH, Elevated, Normal — as a review aid. It tells you where to look first; it never claims to know who wrote a line. The paper says exactly what it can and cannot do.

The AI Code Scan. 1,000 files scored — 1 HIGH, 395 ELEVATED, ~39% of flagged code showing generated-code characteristics. A review aid, never an authorship verdict.

In your pipeline.

Two lines in a workflow file. On every pull request, inside your own runner: the churn summary and agent findings as a PR comment, SARIF into the Security tab, and an optional merge gate. The engine downloads itself; a licence is built in for the beta.

The PR comment. Churn summary, TRUE_CHURN with the generated files named, agent findings — posted by the Action on the pull request.

The run. The Action in the Actions tab: fetch the engine, install the licence, scan the diff, comment, upload SARIF, gate.

Set it up in five minutes · See it on a real PR · an MCP server lets your own agents call the engine (CLI / CI).

The desktop app.

macOS, Windows and Linux. Pick a mode, point it at two snapshots or one project, and read churn, the AI code scan, the agent scan and the Code Browser in one local window — nothing phones home.

The desktop app. Analysis modes on the left, the results panel on the right; Open Churn Report and Open Code Browser under every run.

The tiles. Every counter with its definition one hover away — CHG/DEL/ADD, TRUE_CHURN, REWORK, generated churn, data share — and a button to the report or the Code Browser behind each number.

The Build-File Alert.

The files that control how a project builds and ships — Makefiles, CI pipelines, packaging, dependency manifests — are where supply-chain backdoors such as xz-utils actually entered. When a scan compares two versions, CodeDelta lists every build file that changed. It’s computed with no ML and no scoring — pure determinism: both directory trees are walked and every filename is checked against a rule table (exact names like Makefile, Dockerfile, package.json; tell-tale suffixes like .m4, .spec; locations like .github/workflows/ where a yml file is executable CI). Each recognised file gets a category — build definition, CI/CD, packaging, dependency manifest. Then the two lists are compared: in new only = ADDED, in old only = DELETED, in both = the bytes are compared and if they differ = MODIFIED.

Why it matters: code review reads source diffs — and the xz-utils payload never appeared in one. It entered through an edit to an autoconf .m4 build file that no source reviewer would open. Churn in build machinery is rare and disproportionately consequential, which is exactly the profile that deserves an alert rather than a line in a table. One honest limit: this catches the conventional build surface — a determined attacker can invoke an arbitrarily named script from a build, so it is coverage of the known surface, not a guarantee.

Build Files Changed In This Diff. The count is the red-alarm entries; install hooks — a package.json that gains a postinstall, a setup.py with a cmdclass override, code that runs the moment someone installs — head the table whatever their category. Dependency manifests sit in the quieter line below because they change constantly and red-flagging them would desensitise the alert.

On a real release pair. FFmpeg 6.0 → 7.0: 28 build files changed — configure, the root Makefile and the per-architecture Makefiles across the codec libraries. Exactly the class of files the xz attacker edited.

The standing inventory. Every agent report opens its build section with what build machinery exists — FFmpeg carries 50 build files. Against that baseline, a changed one is an event and a new one is a question.

Run against two real curl releases (8.5.0 → 8.8.0) it flags 69 build-file changes — configure.ac, the .m4 macros, thirty CI workflows — exactly the surface the xz attacker used. Every agent report also carries the standing Build & Deployment Surface inventory of what build machinery exists in the tree. A pointer for review, not a verdict. Details in the user guide.

Every scan that compares two versions carries the change alert; snapshot scans have nothing to diff. The presence inventory rides every agent scan.

Free to evaluate until 31 October 2026, on every platform.