CodeDelta is a command-line source code metrics tool with a browser-based GUI. It compares two snapshots of a source project — an old version and a new version — and measures exactly what changed, how much, and how complex. It is a professional-grade source code analysis tool for macOS, Linux, and Windows.

Core Principle

If your source files are constantly being changed, the source base is not stable and is not ready for release. CodeDelta makes this visible. Every build, every sprint, every release — run CodeDelta and watch the churn numbers. A healthy codebase shows decreasing churn as a release approaches. A codebase that remains "hot and active" near release is a risk.

Key Features

• Churn Analysis — CHG/DEL/ADD/CRN_SLOC and CHG/DEL/ADD/CRN_LLOC per file and project
• AI Audit (GSS) — detects AI-generated code by measuring structural patterns
• Agent Scan (AIS) — detects code that initiates AI agents at runtime
• Full metric set — LOC, SLOC, LLOC, PLOC, COM_LOC, BYTES, NFILE, all churn metrics
• Metric Sets — user-defined named subsets of metric columns for filtered reports
• Excluded Directories — skip vendor, test, or generated code directories
• Snapshot Date — tag each run with the date the source was extracted
• O/X CSV rows — old metrics and diff rows per changed file
• Myers algorithm with Jaccard similarity — more accurate than GNU diff
• Two-pass LLOC — function-boundary-aware logical line counting
• 55 languages supported
• SQLite database — no server required, accumulates every run for trend analysis
• Browser GUI — runs locally on port 7654

The Difference Between SLOC and LLOC

SLOC (Source Lines of Code) is a physical count — the number of non-empty, non-comment lines in the file. Two statements on one line = 1 SLOC.

LLOC (Logical Lines of Code) is a count of logical statements, excluding anything inside comments or string literals. Statements are delimited by semicolons in C-family languages, and by statement-ending newlines — with bracket, string and line-continuation awareness — in newline-terminated languages such as Python, JavaScript/TypeScript, Go, Ruby and Shell. One statement spread over three lines = 1 LLOC. This is invariant to formatting and is the preferred metric for measuring real code change.

int i=0; float j=0;  // This is 2 LLOC, 1 SLOC

cout << "Testing"
     << " Hello"
     << " there.";   // This is 1 LLOC, 3 SLOC

What Gets Measured

CodeDelta counts all source files recursively under the base directory, maps each file to a language by extension, and counts metrics per file. A file with no extension is classified by its first line when that is a #! interpreter line: #!/bin/sh or #!/usr/bin/env python3 make it Shell or Python, and Perl, Ruby and node scripts are recognised the same way. Symbolic links are never followed: each one is skipped and listed with the files not measured (the Coverage block in the report, Status X rows in the CSV). For comparisons, files are matched by relative path. A file present in the new project but not the old is Added (N). A file in the old but not the new is Deleted (D). A file present in both is either Changed (C) or Unchanged (U).

Supported Languages

CodeDelta detects 55 languages by file extension. For 27 of them it computes real, formatting-invariant logical lines (LLOC); the remaining 19 are measured by physical lines, where LLOC equals SLOC. The table below is the complete, current list.

Need a language we don't cover yet — or full two-pass LLOC for one currently counted SLOC-only? Additional language support can be added on request as part of a support arrangement — contact us at codedelta.app to discuss your stack.

See the complete extension-to-language reference in section 03 (GUI Guide → Extension Overrides) for which file extensions auto-detect to which language. Custom mappings can be added without recompiling via the Extension Overrides field.

CodeDelta computes the source code metrics most commonly used in software-engineering analysis: SLOC, LLOC, comment counts, file counts, and per-language breakdowns. See the Metrics Reference table above for the full set.

Size Metrics

Change Metrics (per file and project)

How the shape metrics are classified — full disclosure

REWORK vs REWRITE, in one breath: REWORK measures editing — statements modified in place that recognisably survive; REWRITE counts replacement-in-place — statements torn out with something different written where they stood. Editing a novel: REWORK is touching up sentences, REWRITE is redoing the paragraph. REWORK is a ratio of total churn; REWRITE is a count of pairs.

REP_CHURN, REWORK, PURE_DEL and PURE_ADD are pure arithmetic over the churn counters. REWRITE is the one metric that rests on a judgement, so here is exactly how it is made. The differ aligns the two versions’ logical statements (Myers shortest edit script) and finds replace regions — gaps where old statements were removed AND new statements inserted at the same location. Inside each region, deleted and inserted statements are paired positionally (1st with 1st, up to the smaller count); each pair takes a character-overlap similarity test (integer Jaccard, threshold 30%). At or above threshold the pair is CHG (edited in place); below it, REWRITE (torn out, different content written in its place). Unpaired leftovers are pure deletions or pure additions.

Verify it yourself on any scan: REWRITE + PURE_DEL must equal DEL_LLOC, and REWRITE + PURE_ADD must equal ADD_LLOC — these identities hold on every run or the implementation is broken. The four composition figures sum to CRN_LLOC only when REWRITE is counted twice (CHG + 2×REWRITE + pure deletions + pure additions = CRN_LLOC) — each pair is one tile but two statements of churn. And REWORK + REP_CHURN = 1 exactly: they are complements (tiles round for display). Known limits, stated before you find them: the 30% threshold is a calibrated dial (statements near the boundary can flip); positional pairing can mis-pair inside a heavily rearranged block (aggregates barely move); moved-and-tweaked code counts as pure del + pure add, not REWRITE; and mechanical reformat sweeps inflate CHG. These metrics characterise a development process over a period — never a verdict on an individual change or author.

Disk space for large scans

Measured figures from a 1,400-scan campaign across the largest public codebases (2010–2026), so you can plan before scanning a big estate. The rule of thumb for git mode (codedelta --git a..b): peak disk ≈ repository clone + two extracted snapshot trees + output files — the engine extracts both versions to a temporary folder for the scan and deletes them afterwards. For two-directory mode the trees are already on disk, so the cost is outputs only.

Verified examples: curl (six-month scan) — clone 0.3 GB, peak under 1 GB, seconds to run. Linux kernel (one-year window, ~2 million logical statements of churn) — clone ~3 GB, peak ~7 GB. WebKit (half-year window, ~4 million statements of churn) — clone ~12 GB, peak ~17–20 GB. A full half-year WebKit scan completes on a consumer laptop.

Two further sizes to know: the results database grows with each recorded run (a few MB per large scan — tens of KB for typical projects), and the Code Browser embeds the full source of every changed file (and, within a 25 MB budget, of unchanged files too). Measured guidance: roughly 26 KB of report per changed file — about 80 MB / 5 seconds to open at 3,000 changed files, 210 MB / 19 seconds at 8,000. Past ~1.5 million display lines the generator automatically switches to embedding changed regions with context instead of whole files (each report states this in its story lines), which keeps very large scans openable; use the main report (much smaller) for a first look either way. Machines with 256 GB disks comfortably run any normal project scan; the multi-gigabyte figures above apply only to whole-history scans of the world’s largest repositories.

File Churn Metrics (project level only)

Data Metrics — code churn vs data churn (v1.8.8)

Large codebases carry data wearing code’s syntax: generated instruction tables, firmware images and lookup tables committed as single initializer statements (NVIDIA’s open GPU modules embed firmware as C arrays up to 3MB per statement — 28% of that tree’s source lines are data). Data metrics separate this from engineering change. A data statement is one whose initializer body holds 16 or more top-level elements (comma-separated values; a nested {…} or a call’s argument list counts as one element). Churned statements partition exactly: CRN_LLOC = code + data.

Coverage: C, C++, C#, Java, Objective-C, JavaScript and TypeScript (brace initializers), plus Erlang collection literals ([ ], { }, #{ }, << >>). The code/data churn partition (DATA_CHG…) applies to the semicolon languages only — Erlang reports composition and element churn. These metrics never alter CHG/DEL/ADD_LLOC, CRN or REWORK; they appear as additional CSV columns, terminal lines and an HTML report row, and are not yet stored in the trend database.

File Status Codes

Two-Pass LLOC Algorithm

LLOC is computed in two passes. Pass 1 strips all comments and string literals and identifies statement boundaries — semicolons in C-family languages, or statement-ending newlines (respecting brackets, strings and line continuations) in newline-terminated languages such as Python, JavaScript/TypeScript, Go, Ruby and Shell. Braces never count: a line holding only { or } is not a logical line in any language, and a closing brace neither ends nor starts a statement (ruled 2 Sep 2026). Pass 2 identifies function boundaries using brace counting and signature detection, allowing CodeDelta to attribute LLOC to specific functions. The two-pass approach resolves the common ambiguity where a single logical statement spans multiple physical lines.

When LLOC diverges significantly from SLOC (ratio > 3.0 or < 0.3), CodeDelta flags the file with an LLOC warning in the report. This usually indicates unusual formatting — very long chained expressions, or highly condensed single-line code.

Per-Language Parsing — Why the LLOC Is Accurate

Most churn tools apply a single generic rule to every language — count physical lines, or count semicolons. That is quick to build but wrong for any language whose statements do not end in a semicolon. Python, Go, Ruby, Shell and modern (semicolon-free) JavaScript all break a naïve counter: it either inflates the count (treating one statement spread over several lines as many) or collapses it (merging a whole function body into a single logical line). Both corrupt the churn figure.

CodeDelta instead ships a dedicated logical-line parser for each language family, encoding that language's real rules for where a statement begins and ends. The payoff is directly observable: the same logical change lands at a near-identical Replacement Churn in every language — the bundled multi-language demo (the same Account class in seven languages) demonstrates this side by side.

This is why CHG_LLOC is the headline metric: it measures real statement-level change, invariant to formatting, and it is comparable across a polyglot codebase. Where a language has no dedicated lexer, CodeDelta falls back to LLOC = SLOC rather than guessing — and any of those can be promoted to full logical-line parsing on request (see Supported Languages above).

Start the GUI server from the Terminal:

python3 /Applications/CodeDelta/codedelta_server.py

Then open http://localhost:7654 in your browser. The GUI runs entirely locally — no internet connection required, no data leaves your machine.

Analysis Mode Selector

The Run Analysis tab is split into two columns. Pick whichever fits the work you're doing:

Compare Projects (left column)

Single Project (right column) — requires only one directory

Every single-project mode (AI Audit, AI Code Scan, AI Agent Scan) also runs the engine as a snapshot, so each one shows the same project-metrics tiles — you can always confirm how much code was parsed, whichever scan you ran. The Code Browser has a light/dark toggle in its top-right corner, defaulting to light.

Run Analysis Fields

Metric Sets

A Metric Set is a named subset of metric columns. When active, only the selected metrics appear in the HTML report table and CSV output. This is useful for management reports that only need CHG_LLOC and ADD_LLOC, without the full detail of every metric.

To create a Metric Set:

1. Click Manage Sets next to the Metric Set dropdown.
2. Enter a name for the set (no spaces — underscores are fine).
3. Tick the metric codes you want to include.
4. Click Save Set.

The set is saved in the database and appears in the dropdown for future runs. To edit an existing set, click Edit beside it — it loads into the editor. To delete, click Delete.

To run without a metric set filter, leave the dropdown on — All metrics (no filter) —.

Available metric codes for sets: LOC, SLOC, LLOC, PLOC, COM_LOC, J_COM, C_COM, EOL_COM, Bytes, CHG_SLOC, DEL_SLOC, ADD_SLOC, CRN_SLOC, CHG_LLOC, DEL_LLOC, ADD_LLOC, CRN_LLOC, REP_CHURN, REWORK, REWRITE_LLOC, PDEL_LLOC, PADD_LLOC, CHG_COM, DEL_COM, ADD_COM, CRN_COM, CHG_FILE, DEL_FILE, ADD_FILE, CRN_FILE

Excluded Directories

Enter a comma-separated list of directory names to exclude from both the old and new scans. For example: vendor,tests,third_party,generated. The names are matched against each path component — you do not need to provide full paths.

Built-in excluded directories (always skipped): .git, .svn, .hg, node_modules, __pycache__, vendor, dist, build, Debug, Release

Symbolic links are never followed, whether they point at a file or a directory: each is skipped and counted among the files not measured. The build-file change alert in Threat Detection looks inside build/ even though the churn scan skips it.

Excluded directories are stored in the database run record and shown in the report header, so you always know what was and wasn't included in a historical run.

Extension Overrides

Some organizations use non-standard file extensions — for example .h2 for C++ headers, .inc for PHP include files, or .ksh for shell scripts. By default CodeDelta ignores files with unrecognized extensions. Extension overrides let you map any extension to an existing language parser without recompiling.

Enter a comma-separated list of ext=lang pairs in the Extension Overrides field:

h2=cpp,inc=php,ksh=sh

The target language can be any known extension (cpp, py, java, sh etc.) or a language name. Unknown target languages are silently ignored. The override takes effect before directory scanning, so all file matching uses the updated map.

Complete extension reference

When mapping a custom extension via the override field, the target side of the ext=lang pair can be any of the codes above (e.g. cpp, py, java, sh, f90). Both the alias and the destination must already be known to CodeDelta — unknown destinations are silently ignored.

Results Tiles

After a run, results appear as coloured tiles in four groups:

• LLOC Change — CHG_LLOC (amber), DEL_LLOC (red), ADD_LLOC (green), CRN_LLOC (purple)
• SLOC Change — same colour scheme for SLOC metrics
• Project Totals — Total SLOC, Total LLOC, PLOC, COM_LOC (all grey/neutral)
• File Churn — NFILE, CHG_FILE, ADD_FILE, DEL_FILE, CRN_FILE

History Tab

Shows all previous runs stored in the selected database. Columns include run date, snapshot date, project, old/new labels, file counts, SLOC/LLOC totals, and churn metrics. Click any row to open its HTML report.

Trend Tab

Charts CRN_SLOC and CRN_LLOC over time for a selected project. A declining trend indicates the codebase stabilising toward release. An increasing trend near a release deadline is a quality risk.

Every scan generates a Code Browser (*_diff.html, beside the report) — a self-contained page that reads the scanned code. Five tabs stay at the top of every screen: Changes (comparisons only), Overview, Files, Classes and Visualiser; the browser’s Back button retraces your steps and every screen carries a breadcrumb. For a churn comparison the Changes tab is the side-by-side diff — the place to read the change and the evidence behind every number the scan reported. Its organising rule: every counter is a claim you can click, walk, and cite. A single-project scan has no Changes tab: the same page is the project’s code browser — structure, classes, files and their relationships.

The Overview

The page opens on the Overview. For a comparison it begins with the scan overview: one plain-language sentence of totals, then the changed files ranked by how much happened in them, each with a one-line story (“Mostly new content — 564 lines added … 15 statements moved within the file”); click any file to open it in the diff. Below that (and first, for a single-project scan) comes the project’s structure: languages, top-level directories with their include links, every class (language, files, methods, who it talks to), every file (filter, sort, churn chips for changed files) and the strongest relationships — directory include links and class “talks-to” pairs.

Files, Classes, Visualiser

Files is the directory tree (changed files wear C/D/A chips and open in the diff; directories show how many of their files changed) with a reader for any file: its classes, its functions in line order, what it includes and who includes it, and its source with line numbers. Classes lists every class or namespace container found (C++, C# and Java) — files, methods with file and line, the classes its code mentions (a textual name match, a pointer for review, not a resolved call graph, each mention cited by file and line) and the classes that mention it. Visualiser draws the include map (directories) and the class ego view in 3D. Source is embedded for unchanged files up to a 25 MB budget; past it, files show structure only and the page says how many.

The Changes tab

Comparisons only: the changed-file list on the left (sort by path, churn or moves; MOV filter; per-function counts), the file’s diff on the right.

Reading a file

Under the toolbar, a story line describes the file in words before any code. Colours follow the CodeDelta convention: red changed, blue deleted, green added, yellow comment-only churn, violet moved. On changed rows the exact tokens that differ are shaded; when a pair of lines is mostly different the whole line is shaded instead — that pair is effectively a removal and an addition that met at the same diff position, not an edit. Alignment gaps (a line that exists on only one side) show as hatched space.

Walking the numbers

Click any counter in the toolbar — CHG, DEL, ADD, MOV, XMOV, AI% — and the stepper (◀ ▶) walks exactly the rows that counter counts, e.g. “changed 3/106”. The Ledger button decomposes every counter into its rows — each entry jumps to its line, and “Copy as text” exports the lot with citable links. Where the displayed rows and the engine’s counted total differ (comment-adjacent alignment), the ledger shows both numbers side by side.

Moves — within and between files

A moved statement (identical text deleted at one position, added at another, at least 12 characters and unique on both sides) paints violet at both ends, each end carrying a chip naming its counterpart (“→ L163”); click the chip to jump. The stepper walks moves as pairs (“move 4/9”), and the ☰ button lists every move in the file. Cross-file moves (dashed chips, XMOV counter) are statements that left for, or arrived from, another file — clicking follows across files. XMOV is a reporting overlay: the churn counters still count the deletion and the addition, so per-file numbers never depend on unrelated files.

Git-derived overlays

When the scan can see git history — always in --git mode, or when a scanned directory lies inside a git work tree — three further overlays appear. AI provenance: lines authored in commits signed by an AI tool (Claude Code, Copilot, Cursor, Aider and others) carry a teal mark on the line number and the code edge; the AI% counter walks them, and hovering names the tool. Age of destroyed code: the story line reports what share of the churned code was under 30 days old — rework of recent work. People: the overview lists, per author, how many lines of their code were churned away and how many of the new lines they wrote. All three are reporting overlays; none of them changes a churn counter, and none appears when scanning plain directories with no git history.

Getting around

The minimap strip on the right shows every change in the file as a coloured mark — click it to jump. Search in file marks its matches in the landed row (Enter / Shift+Enter cycle). Double-click any line number to copy a link that reopens the report at exactly that line — the address bar always reflects where you are, so a finding can be pasted into a ticket. Keyboard: j/k step the selected counter, m moves, a AI-signed lines, f the file filter, / search; the ? button holds the full legend. Large, sparse files (changelogs) open in Changes Only automatically, with the collapse stated in the story line; the … separators expand in place. The file list sorts by path, churn, or moves, filters by name, and the bar between the list and the code drags to resize (double-click resets).

Basic Usage

codedelta <old-dir> <new-dir> [options]
codedelta --git <oldref>..<newref> [options]   # run inside your git repo

Git Mode

With --git there is no need to check out two copies of the project — CodeDelta extracts both committed snapshots itself (via git archive, so the state of your working tree never affects the result), compares them, and removes the temporary trees afterwards. Refs can be tags, branches, or hashes: --git v1.7..v1.8, --git HEAD~10..HEAD, or a bare --git v1.7 meaning v1.7 against HEAD. Labels, the project name, and the snapshot date default to the refs and the new ref's commit date — useful for backfilling a longitudinal database from historical releases. Requires git and tar on the PATH (both standard on macOS, Linux, and Windows 10+). New in v1.8.2.

Full Options

Exit Codes

CSV Output Format

The CSV has one header row and one or more data rows per file. For changed files, three rows are output:

• C row — new file metrics
• O row — old file metrics (what the file looked like before)
• X row — arithmetic diff (new minus old)

The CSV output format is compatible with standard spreadsheet tools. Unchanged and deleted files have one row only. The file ends with a TOTAL row and a NFILE summary row.

If a Metric Set is active via --metric-set, only the specified columns appear in the CSV header and data rows.

Example: Nightly Build Integration

#!/bin/bash
codedelta /builds/project-v1.1 /builds/project-v1.2 \
  --project "MyApp" \
  --old-label "v1.1" \
  --new-label "v1.2" \
  --snapshot-date "$(date +%Y-%m-%d)" \
  --exclude "vendor,node_modules,generated" \
  --db /var/lib/codedelta/myapp.db \
  -o /var/www/reports/myapp-latest.html \
  --csv /var/www/reports/myapp-latest.csv \
  --threshold-churn 5000 \
  -q

if [ $? -eq 2 ]; then
  echo "ALERT: churn exceeds threshold — build is hot"
  exit 1
fi

Threat Detection — the security view

For the security reader — the auditor, the AppSec engineer — CodeDelta’s scans are five threat-detection instruments in one pass. Everything dangerous that hides in a repository — an implant, a rogue agent, a leaked key — leaves hard, checkable evidence; each instrument looks for one kind of it and reports file-and-line facts, never verdicts of malice.

1. Build-file change alert — every two-version scan lists the build, CI and packaging files that changed (the xz-utils entry route). Install hooks (code that runs on install) ride first; below them, build files that fetch remote content at build time — and for a changed fetcher the alert prints the URL delta itself (+ new-source / − old-source), because one edited download URL redirects the build’s supply chain.
2. Build & deployment surface inventory — the standing map of what build machinery exists in the tree, changed or not, in every agent report.
3. Agent Scan — the AI inside the software: SDK imports and model calls by name, raw endpoints, and the rogue pattern (model output flowing into exec or a shell — how prompt injection becomes code execution), plus the artifacts agents leave behind, down to tier-3 residue. The same layer detects committed credentials with a fixed table of documented key formats (AWS, GitHub, OpenAI, Anthropic, Google, Hugging Face, Slack, Stripe live keys, PEM private keys) — no entropy scoring: a string matches a vendor’s published format or it is not flagged. Findings are redacted everywhere, including the report’s embedded source viewer, because reports travel. Rotate the key first, then remove it: removal alone leaves it valid in git history.
4. AI Bill of Materials — --bom emits the record (native JSON or CycloneDX): every provider, jurisdiction, sovereignty risk, with files named.
5. The merge gate — --fail-on-new blocks pull requests that add findings against your baseline; --gate fails builds on policy. The rogue pattern and denied jurisdictions gate by default; three further switches ship off so a test fixture can never break a build uninvited — enable them in your --gate-policy file:

{
  "fail_on_committed_credentials": true,
  "fail_on_new_install_hook": true,
  "fail_on_new_fetcher": true
}

“New” is computed against the old side of the diff: a project that has always fetched does not fail — only the diff where fetching started does. All of it runs in one scan (GUI: Churn + Agent Scan; headless: --mode churn_agent --bom --gate --fail-on-new) and inside your own infrastructure.

At the command line

One line runs all five layers:

./codedelta-gui scan new/ old/ --mode churn_agent --bom --gate --gate-policy policy.json --fail-on-new

What comes back on the terminal: [build] ALERT: with per-file status lines, ** install hook ** / ** fetches remote content at build time ** markers and the +/− URL delta lines beneath a changed fetcher; [agent] tier counts, artifact and ALERT: N committed credential(s) lines (values redacted), followed by the gate-off notice naming the exact policy key to flip; [bom] summary; and [gate] pass or an itemised violation list. Exit code 0 clean, 3 on a --fail-on-new regression or a gate failure — the exit code is what makes CI block the merge. The reports — the agent HTML with the red boxes, the AI-BOM JSON — are written alongside for the humans.

The standalone threat-detection mini guide covers each layer in depth, with the report screenshots and the full policy reference.

Headless Batch CLI (scan / trend)

Everything above drives the C++ engine directly. The batch CLI runs that same engine and adds the rest of the product headlessly — the AI scans, the pass/fail gates, SARIF, the AI-BOM and the longitudinal database. Two subcommands: scan and trend. Note the argument order: the engine takes old new; the batch CLI takes new old.

codedelta-gui scan <new_dir> [old_dir] [options]   # from the installed bundle
codedelta-gui trend <db> [--out FILE] [--project NAME] [--limit N]

The full scan --help, verbatim:

CodeDelta batch scan (headless — no GUI)

Usage:
  codedelta-gui scan <new_dir> [old_dir] [options]

  <new_dir>   directory to scan (required)
  [old_dir]   previous version, for churn/diff (optional; omit for snapshot)

Modes (--mode M — the same choices the GUI offers):
  churn         churn only                 (default when two dirs are given)
  churn_agent   churn + Agent Scan, no ML  (the GitHub Action's default)
  agent         Agent Scan only
  ai            AI code audit only
  ai_audit      AI audit + Agent Scan on one dir (default when old_dir omitted)
  both          everything: churn + AI audit + Agent Scan

Output (default: all formats):
  --out-dir DIR     where to write outputs        (default: current dir)
  --bom FILE        write an AI Bill of Materials (providers, jurisdictions,
                    risk/cost/sovereignty flags) for the Agent Scan
  --bom-format F    native (default) or cyclonedx (CycloneDX 1.6)
  --gate            fail (exit 3) on the default policy: egress to a non-allied
                    jurisdiction (CN/RU/KP/IR) or the rogue exec-on-model pattern
  --gate-policy F   fail using a custom JSON policy (deny_jurisdictions,
                    allow_providers, deny_flags, max_risk,
                    fail_on_agent_artifacts — off by default; true fails on
                    tier-3 agent artifacts: rogue residue / agent credentials)
  --html            HTML reports (churn + audit + agent)
  --csv             raw CSV (engine metrics + audit + agent per-file)
  --json            raw JSON (audit + agent)
  --xml             engine EPM-compatible XML
  --db PATH         longitudinal SQLite DB
  (if none of --html/--csv/--json/--xml given, ALL are produced)

Labels / trending:
  --project NAME    --note TEXT   --old-label TEXT   --new-label TEXT
  --threshold N     AI sensitivity 0-100            (default 50)

Baselining (suppress known findings; alert only on new ones):
  --write-baseline FILE accept the current flagged files; snapshot to FILE
  --baseline FILE       compare this scan to FILE; report only what got worse
  --fail-on-new         exit 3 if any new finding vs --baseline (CI merge gate)

CI integration (with --mode ai/agent/both):
  --sarif               write SARIF 2.1.0 for GitHub code-scanning
  --pr-comment          write a markdown summary for a pull-request comment

Performance:
  --jobs N              parallelise the AI audit across N processes (or 'auto'
                        for all CPUs). Big speed-up on large scans; default 1.

Cron / alerting:
  --quiet               errors only
  --fail-on-critical    exit 3 if any agent-scan CRITICAL file
  --fail-on-ai N        exit 3 if AI%% >= N
  -h, --help

Stopping a run:
  Press Ctrl-C (or send SIGTERM) to terminate cleanly. The scan stops within a
  second, prints a notice, and discards partial results — nothing is written
  (the engine's run rolls back; reports/DB are written only on completion).

Exit codes: 0 ok · 2 usage/error · 3 threshold/new-finding tripped · 130 terminated by user

Example: Metric Set for Management Report

codedelta /src/old /src/new \
  --metric-set "SLOC,LLOC,CHG_LLOC,ADD_LLOC,CRN_LLOC,CHG_FILE,CRN_FILE" \
  -o management_report.html \
  --csv management_report.csv

CodeDelta detects AI-generated code via two complementary scans:

• AI Code Scan — analyzes source files for patterns associated with AI-generated code (the GSS + MLS combination producing an AIC score). Asks the question: "was this code written by an AI?"
• Agent Scan — covered in section 06. Looks for code that initiates AI agents at runtime (SDK imports, dynamic exec patterns, prompt-injection vulnerabilities). Asks the question: "does this code USE AI at runtime?"

The AI Audit mode in the GUI runs BOTH scans in a single pass, producing two separate HTML reports (codedelta_ai_code_scan.html and codedelta_agent_scan.html).

How GSS Works

Each file receives a Generation Signature Score (GSS) from 0 to 100. The score is the weighted sum of several signals. A high score indicates the file exhibits many of the structural patterns associated with AI-generated code. A low score does not prove the code is human-written — it means no unusual patterns were detected.

Risk Ratings

The score used for classification is AIC where an ML model exists for the file's language, and GSS alone otherwise. Languages without an ML model are capped at ELEVATED — the heuristics can never declare HIGH without ML confirmation. (The single exception: a user-defined custom pattern with the override flag forces HIGH.)

Sensitivity Setting

Sensitivity excludes and includes nothing. Every file is always scanned, every signal always computed, and the ML model always runs — a file's scores are identical at every setting. The slider only moves the two classification lines drawn over those fixed scores:

Two useful corollaries. First, the flagged sets nest: everything flagged at Conservative is also flagged at Strict — lowering the threshold only adds files further down the ranking; it never changes any file's score. Second, because the report embeds source evidence for every flagged file, stricter settings produce larger reports and longer report-generation times.

• Strict (30) — flags more files, more false positives. Use for high-assurance audits.
• Balanced (50) — recommended for general use.
• Conservative (70) — only flags files with very strong signals.

Validation Results

GSS was validated against two corpora. A set of 26 human-written C++ files produced a mean score of 0.0 with no HIGH ratings. A set of 12 AI-generated files across multiple languages produced a mean score of 48.9 with 2 HIGH and 3 ELEVATED ratings. Zero false positives were observed on the human corpus.

Important Caveats

GSS measures patterns, not intent. A highly disciplined human developer who writes uniform docblocks and systematic null checks will score higher than average. The score is a signal for review, not a determination of authorship. It is most useful when scores are unexpectedly high for files in a codebase where the baseline is known.

ML Score (MLS) and AI Confidence (AIC)

When the ML plug-in is installed, the AI Code Scan report shows two additional columns alongside GSS:

• MLS — Machine Learning Score (0–100). A per-language Random Forest classifier trained on human + AI code samples. Returns the probability the file matches AI-generated code patterns.
• AIC — AI Confidence Score (0–100). Weighted blend of MLS (60%) and GSS (40%). This is the score used for final risk classification when ML is available.

Language coverage

When MLS is unavailable for a language, the AIC column shows — and risk classification uses GSS alone. All other functionality is unaffected.

Risk Bands

Files are placed into risk bands based on the AIC score (or GSS where MLS is not available):

The AI% metric — what it means

AI% is the headline project-level number on the AI report and GUI. It is the proportion of code, measured in lines, that sits in files flagged HIGH or ELEVATED:

• Single-snapshot scan (one folder): source lines (SLOC) in flagged files ÷ total source lines, × 100.
• Old-vs-new comparison (two folders): added logical lines (ADD_LLOC) in flagged files ÷ total added logical lines, × 100.

So “AI% = 29” means 29% of the codebase, by lines, lives in files the scan flagged HIGH or ELEVATED — in a snapshot, 29% of total source lines are in HIGH/ELEVATED files.

AI Detection Config

The AI Detection Settings card on the Run Analysis page (visible in any AI Audit or AI Code Scan mode) opens a configuration dialog where you can fine-tune detection per language. The card's status line shows "X/Y signals active · N custom patterns" — a quick view of how much of the default scoring is in effect.

Language tabs

The dialog has six tabs: C/C++, Java, Python, C#, JavaScript, Go. The tab bar is sticky — it stays visible as you scroll through long signal lists.

Built-in signal toggles

Each language has a set of built-in signals. You can toggle individual signals on or off. This matters because some signals are context-dependent:

• File header comment — files without an author/copyright header score higher. Toggle this off (recommended, indicated by an amber pill in the dialog) if your coding standards mandate headers on all files. With headers mandated, AI tools instructed to follow your standards will produce them, making this signal unreliable.
• Low macro usage (C/C++) — disable if your codebase has few macros by design.
• Excessive std:: prefix (C/C++) — disable if your style guide requires it.
• Missing Javadoc (Java) — disable if your team uses Javadoc on all methods.
• Uniform operator spacing (Python) — disable if your team enforces spacing via a linter.
• Pascal case ratio (C#) — disable if your style guide enforces strict PascalCase naming.

Signal configuration is saved to ml_config.json in the CodeDelta directory and takes effect on the next analysis run.

Custom patterns

Add patterns specific to your codebase. Four pattern types:

• Keyword / phrase — flags files containing the text. Example: # AI-generated.
• Regex — flags files where the pattern matches. Example: (?i)auto.?generated.
• File path / directory — flags files whose path contains the pattern. Example: /generated/ or _ai.py.
• Structural — records that a structural pattern is expected. Noted in signals for review.

Each custom pattern can be set to Override — when the pattern fires, the file is always rated HIGH regardless of the ML score. Use this for definitive markers in your codebase.

Custom patterns apply across all AI Code Scan and AI Audit runs until removed. Saved to ml_config.json.

In plain terms: Agent Scan finds the files that actually use AI — code that calls or runs an AI model while your program runs (for example, importing an AI library or sending it a prompt). It answers one question — "does this code talk to AI?" — not "was this code written by AI?" (that's the AI Code Scan). It flags where AI is wired into your software and highlights the riskier uses.

The Agent Scan analyzes source files for code that initiates AI agents at runtime — code that imports AI SDKs, orchestrates agents, executes dynamic code, or constructs prompts from user input. This is entirely distinct from the AI Audit: Agent Scan detects code that runs AI agents, not code that was written by AI.

How It Works

Agent Scan reads each source file and looks for four categories of pattern using regular expression matching. Each pattern category carries a weight. Files whose total weight exceeds the configured threshold are flagged.

The scan is entirely static — it reads source text only and never executes any code. It works on files even when dependencies are not installed.

AIS Signal Categories — the exact points table

Every file starts at an Agent Initiation Score (AIS) of 0. Signals add points, capped at 100. The table below is the complete, current scoring model — there are no other inputs, and no randomness: the same file always produces the same score.

How the score becomes a rating

Three fixed cut-offs, applied to the capped score:

CRITICAL is the reserved top tier; the current deterministic scan rates files HIGH at most, so a CRITICAL count of 0 is expected. Data-sovereignty, cost-risk and agent-artifact findings are reported alongside but deliberately do not move the AIS — they are compliance information, not initiation evidence.

The Rogue Agent Pattern

The most serious finding is the Rogue Agent pattern: a dynamic code execution call (eval, exec, or subprocess) that appears within 10 lines of an AI API call. This pattern indicates code where an AI model's output may directly influence what gets executed on the host machine — a significant and specific security risk.

A file flagged for the Rogue Agent pattern has its AIS rating escalated to HIGH regardless of its total score.

Example of Rogue Agent pattern:

response = client.chat.completions.create(...)   # AI API call
code_to_run = response.choices[0].message.content
exec(code_to_run)                                 # within 10 lines — ROGUE AGENT

CRITICAL Risk Rating

A file that scores HIGH on both GSS (appears AI-generated) and AIS (initiates AI agents) receives a CRITICAL rating. This is the highest-risk scenario: code that nobody may have fully reviewed or understood, which autonomously initiates AI agents at runtime.

Source Viewer

The Agent Scan report includes an inline source viewer. Click View Source on any flagged file to see it with dangerous lines highlighted:

• Red — Rogue agent pattern (eval/exec within 10 lines of AI API call)
• Orange — Agent orchestration pattern
• Amber — AI SDK import
• Blue — Prompt injection vector

SDK Inventory

When AI SDK imports are found, the Agent Scan report includes an SDK Inventory — a list of each recognized AI framework detected and the number of files importing it. This gives a quick overview of which AI dependencies are present across the codebase.

Governance & compliance flags — data sovereignty and cost

Beyond which AI a file uses, Agent Scan flags two things that matter to compliance and budget owners, rolled up in a Governance & Compliance panel at the top of the report:

• Data sovereignty — when code calls a model hosted in a foreign jurisdiction, the report names the country and counts the files (e.g. “3 files send data to a China-hosted model”). Calls to a non-allied jurisdiction (CN / RU / KP / IR) are highlighted in red. This surfaces data-residency exposure: your prompts — and anything in them — leaving the country. Detected from both known endpoints and foreign SDK imports (DeepSeek, Qwen/dashscope, Zhipu, ERNIE/qianfan, Moonshot). Per-file signals: data_egress(model_hosted_in_<country>:<host>) and data_sovereignty_risk(non-allied_jurisdiction).
• Cost risk — an AI API call made inside a loop with no cap is a runaway-bill pattern; the report counts how many files do it. Per-file signal: cost_risk(ai_calls_inside_loop).

Both are informational compliance/cost flags — they do not change a file’s AIS risk score. Endpoint matching ignores comments and docstrings, so a hostname that appears only in a comment is not flagged.

AI Bill of Materials & CI policy gate

From the command line, Agent Scan can export an AI Bill of Materials — a machine-readable inventory of every AI provider the code touches, with jurisdiction, file usage, and the risk / cost / sovereignty flags:

python3 codedelta_server.py scan ./src --mode agent --bom ai-bom.json
python3 codedelta_server.py scan ./src --mode agent --bom ai-bom.json --bom-format cyclonedx

Two formats: native (CodeDelta-AI-BOM, the richest) or cyclonedx (CycloneDX 1.6 — SDK libraries become components, model endpoints become services with an outbound “prompt” data flow, for existing SBOM tooling).

The same data drives a CI policy gate. --gate fails the build (exit code 3) on the default policy: any egress to a non-allied jurisdiction (CN/RU/KP/IR) or the rogue exec-on-model pattern. --gate-policy policy.json uses your own rules and implies the gate:

{
  "deny_jurisdictions": ["CN", "RU"],
  "allow_providers": ["openai", "anthropic"],
  "deny_flags": ["rogue_pattern", "cost_risk"],
  "max_risk": "ELEVATED",
  "fail_on_agent_artifacts": true
}

Each violation is listed and the process exits non-zero, so it drops straight into a CI step (the gate needs an Agent Scan: --mode agent, both, or ai_audit).

Recognized providers & extending the list

Agent Scan ships with a broad built-in list of AI SDKs and frameworks — OpenAI, Anthropic, Google, Cohere, Mistral, LangChain, CrewAI, AutoGen, and many more, including enterprise cloud routes (AWS Bedrock, Azure OpenAI), Model Context Protocol SDKs (mcp, fastmcp), and non-Western providers such as DeepSeek, Alibaba Qwen (dashscope), Zhipu GLM (zhipuai), Baidu ERNIE (qianfan), Moonshot Kimi, Sber GigaChat and YandexGPT. It also detects raw HTTP calls to known model endpoints (e.g. api.openai.com, bedrock-runtime, gigachat.devices.sberbank.ru) even when no SDK is imported.

You can extend detection without waiting for a release. Drop a codedelta_agents.json file in your application-support folder (or next to the engine, or your project root) to add your own AI SDK import names and API endpoints — useful for internal AI wrappers or private gateways. It is additive on top of the built-ins:

{
  "providers": [
    { "name": "Internal LLM", "lang": "python",
      "imports": ["acme_llm"], "endpoints": ["llm.acme.internal"] }
  ],
  "artifacts": [
    { "name": "AcmeAgent", "tier": 3,
      "paths": ["acme-agent/", "acme.agent.key"] }
  ]
}

The artifacts array adds your own entries to the Agent Infrastructure scan (next section): a trailing slash means a directory name, otherwise a file name.

Agent Infrastructure — artifacts in the tree

Alongside detecting code that calls AI, Agent Scan inventories agent infrastructure committed to the tree — the files AI agents leave behind, evidence that an agent operates on this repository. The scan walks the full tree (including dot-directories the source scan skips), is deterministic, and reports every hit as a named path. Findings appear in the Agent Infrastructure section of the agent report and as agent_artifacts entries in the AI-BOM. They never change any file’s risk rating.

Tier 3 findings are reported, never build-failing, by default — many teams run agents such as OpenClaw deliberately. To make the CI gate fail on them, set "fail_on_agent_artifacts": true in your --gate-policy JSON. Artifacts flow through every headless output too: the console prints a per-run artifact line, --csv appends ARTIFACT rows after the per-file rows, --json carries an agent_artifacts block, and the AI-BOM and SARIF outputs include them. As everywhere in Agent Scan: pointers for review, not verdicts.

Git History Evidence

When the scanned folder is a git repository, the Agent Scan report adds a Git History Evidence section — commits carrying verifiable agent signatures: Co-Authored-By trailers (Claude Code, GitHub Copilot, Cursor, Aider, and others), generation footers, and agent bot accounts. Unlike the pattern-based scans, this is documentary: a match proves an agent participated in that commit. The reverse does not hold — signatures can be stripped or never written, so the absence of evidence proves nothing. The section shows the share of agent-signed commits, a breakdown by agent, the most recent signed commits, and the files most often touched by them. In batch mode the raw data also exports as *_git_evidence.json. New in v1.8.2.

Build & Deployment Surface — the build-file alerts

Every agent report also watches the files that control how the project builds and ships. A change to build machinery can alter the shipped artifact without touching application source — the mechanism behind supply-chain backdoors such as xz-utils, where the payload entered through an autoconf .m4 file rather than readable source. Two tables cover it:

Build Files Changed In This Diff — the change alert, shown whenever the scan compared two versions. Of the files that control how the project builds and ships, these differ between old and new. It is 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. The count in the title is the red-alarm entries; dependency manifests sit in a quieter line below because they change constantly and red-flagging them would desensitise the alert.

Build & Deployment Surface — the presence inventory: what build machinery exists in the scanned tree, changed or not, in the same categories. It renders in every agent report, snapshot or pair.

Install / build hooks head both tables regardless of category. package.json and setup.py are read and checked for install-time execution (a postinstall script, a cmdclass override) — code that runs the moment someone installs the package, the classic supply-chain vector.

Where each appears, by scan mode — the change alert follows churn (it needs two versions); the presence inventory follows the agent scan (it describes one tree):

Every scan that compares two versions carries the change alert; no snapshot scan does (the single-project modes deliberately run the engine with old = new, so there is nothing to diff). A churn-only scan shows the alert in the GUI and CLI output but not in an HTML report — the section lives in the agent report, and churn-only does not produce one. A pair where no build file changed shows an explicit grey “no build-file changes” line, so an empty result never looks like a missing feature. As everywhere in CodeDelta, this is a pointer for review, not a verdict — it flags that the build machinery changed, not whether the change was malicious.

Honest Limitations

False Positives

Agent Scan will produce false positives in some situations:

• Test files that import AI SDKs to mock them will be flagged even though they don't invoke real agents. Use the Exclude Directories field to skip tests and test directories.
• Configuration and example files that reference SDK names in comments or strings may occasionally trigger import detection.
• Documentation generators that import SDKs to build API docs will be flagged.

The source viewer is the most effective tool for investigating potential false positives — it shows exactly which lines triggered each flag.

Languages Supported

Agent Scan analyzes all source files regardless of language but SDK import detection patterns are primarily calibrated for Python, JavaScript, and TypeScript — where AI agent frameworks are most commonly used. C++, Java, C# and Go projects that call AI APIs via HTTP without a recognized SDK will have lower AIS scores, but may still be flagged when they hit a known model endpoint or use dynamic execution patterns.

CodeDelta integrates with any CI/CD system or version control system that can export source files to a local directory. It does not interface directly with any CMVC system — it requires plain directory copies of your source.

Churn Threshold Gate

Use --threshold-churn <n> to fail the build if CRN_LLOC exceeds a threshold. Exit code 2 means the threshold was exceeded.

Jenkins Example

stage('Code Metrics') {
  steps {
    sh """
      codedelta ${WORKSPACE}/old ${WORKSPACE}/new \
        --project "${JOB_NAME}" \
        --old-label "${OLD_TAG}" \
        --new-label "${NEW_TAG}" \
        --snapshot-date "${BUILD_DATE}" \
        --exclude "vendor,tests" \
        -d ${WORKSPACE}/codedelta.db \
        -o ${WORKSPACE}/report.html \
        --threshold-churn 10000 -q
    """
  }
}

GitHub Actions Example

- name: Run CodeDelta
  run: |
    codedelta ./old ./new \
      --project "${{ github.repository }}" \
      --old-label "${{ github.event.before }}" \
      --new-label "${{ github.sha }}" \
      --snapshot-date "$(date +%Y-%m-%d)" \
      --exclude "vendor,node_modules" \
      -o report.html --csv report.csv -q

Jenkins, Docker and Kubernetes

The engine also ships as a public container image — ghcr.io/code-delta-app/codedelta, republished with every release — which is the easiest route in CI systems other than GitHub Actions: nothing is installed on the runner. The licence rides in as an environment variable (CODEDELTA_LICENSE_B64, the base64 of your codedelta.lic) or a mounted file; all arguments pass straight to the batch CLI described above.

docker run --rm -v "$PWD:/work" -e CODEDELTA_LICENSE_B64 \
    ghcr.io/code-delta-app/codedelta \
    scan /work/new /work/old --mode churn_agent --html --csv

In a Jenkins pipeline that command is a single sh step: store the base64 licence as a secret-text credential, git worktree add the base branch, scan workspace against base, and let exit code 3 (from --gate or --fail-on-new) fail the stage. On Kubernetes, run the identical image inside your CI agent pods, or as a scheduled CronJob snapshot scan with the licence in a Secret and reports written to a volume. Copy-paste recipes for all three: the CLI page and Jenkins, Docker and Kubernetes — where measurement fits.

Baselining — alert only on new findings

The first scan of an established codebase flags many files at once, and most of them are pre-existing — not something the current change introduced. A baseline records the accepted current state so later scans surface only what got worse: files newly flagged, or flagged at a higher severity than before. This is what makes CodeDelta usable as a merge gate rather than a one-time audit. New in v1.8.2.

Accept the current state once and commit the baseline file to your repository:

python3 codedelta_server.py scan ./src --mode both \
      --write-baseline codedelta-baseline.json -q

Then, on every run (or every pull request), compare against it. Only files that regressed are reported; --fail-on-new sets exit code 3 so a build can block the merge:

python3 codedelta_server.py scan ./src --mode both \
      --baseline codedelta-baseline.json --fail-on-new -q

A finding counts as new when its risk exceeds its baselined level (absent from the baseline counts as lowest, so genuinely new flags and severity regressions both surface). Files that dropped below their baselined level are reported as resolved — positive feedback, never a failure. With --json, the comparison is also written to *_baseline_diff.json. Re-run --write-baseline whenever you want to accept the current state as the new normal.

Executive Summary & Trends

The longitudinal database accumulates every run, which makes it the source for a one-page executive summary — the artifact you forward to whoever approves the purchase, rather than the detailed engineer's report. It shows headline numbers for the latest run, trend arrows versus the previous run, and inline charts of churn and AI% across recent runs. New in v1.8.2.

python3 codedelta_server.py trend codedelta.db \
      --out summary.html --project MyApp --limit 20

--project selects which project in the database to chart (defaults to the one with the most runs); --limit caps how many recent runs are shown. The page is self-contained HTML — no external libraries — so it emails and embeds cleanly. Backfill historical points with --git snapshots (the commit date becomes the run's date), then run trend to chart the whole release history at once.

Database Access

The SQLite database (codedelta.db) accumulates every run. You can query it directly:

sqlite3 codedelta.db "
  SELECT r.run_at, rt.crn_lloc, rt.total_sloc
  FROM run r JOIN run_totals rt ON r.id = rt.run_id
  WHERE r.project_id = (SELECT id FROM project WHERE name = 'MyApp')
  ORDER BY r.run_at DESC LIMIT 10;"

Key DB Tables

Database location, size & backups

Where it lives. The GUI uses a permanent per-user location that survives reinstalls (~/Library/Application Support/CodeDelta/codedelta.db on macOS, ~/.local/share/CodeDelta/codedelta.db on Linux, %APPDATA%\CodeDelta\codedelta.db on Windows). The command-line engine defaults to codedelta.db in the current directory — for cron jobs always pass an explicit -d /path/to/project.db. In WAL mode you will also see codedelta.db-wal and codedelta.db-shm alongside it; these are normal.

One database per project. Point each project at its own .db. This keeps history clean and avoids write contention — two scans writing the same database serialise (brief overlaps wait safely), but two long scans against one shared database can time out the second writer.

How big it gets. Size grows with files × runs at roughly 0.4 KB per file per run (the per-file detail rows). A 4,000-file project is about 1.5 MB per run; a year of nightly runs is a few hundred MB. The project-level totals that trend reports read are tiny (one row per run), so trend and history queries stay fast no matter how long you keep the database. For very large projects kept for many years, you can prune old per-file detail while keeping the totals.

Backups. The database is a single local file with no built-in replication, so back it up like any data you would not want to lose. Because of WAL mode, do not just copy the live .db file — use SQLite's safe online backup, which captures a consistent snapshot even while a scan is running:

# either of these produces a clean, single-file backup
sqlite3 /path/to/project.db ".backup '/backups/project-$(date +%F).db'"
sqlite3 /path/to/project.db "VACUUM INTO '/backups/project.db'"

Schedule that (e.g. a nightly cron right after the scan) and copy the backup to a second location or offsite for redundancy. Integrity is protected at runtime by write-ahead logging and atomic, all-or-nothing runs (an interrupted scan rolls back cleanly and never leaves a half-written run); you can confirm a database is healthy any time with sqlite3 project.db "PRAGMA integrity_check;".

AI Agents (MCP)

CodeDelta ships an MCP server (codedelta_mcp.py, in the install folder) so AI coding assistants — Claude Code, Claude Desktop, Cursor, and any other Model Context Protocol client — can call the real engine instead of improvising their own analysis scripts. The agent provides the conversation; CodeDelta provides the deterministic, reproducible numbers. New in v1.8.2.

Register it with your agent. Claude Code example (claude mcp add or in your MCP config):

{
  "mcpServers": {
    "codedelta": {
      "command": "python3",
      "args": ["/Applications/CodeDelta/codedelta_mcp.py"]
    }
  }
}

The server exposes three tools:

Once registered, asking your agent "how much churn between release 1.7 and 1.8?" or "does this codebase use AI agents?" invokes CodeDelta and cites its numbers. Licensing is unchanged — the engine verifies codedelta.lic locally no matter who calls it. Requires Python 3.8+ to run the server script.

The Myers Algorithm

CodeDelta uses the Myers diff algorithm for file comparison, which finds the shortest edit script between two files. This is more accurate than simple line-by-line comparison for files that have been significantly restructured.

Jaccard Similarity

Before running the full Myers diff, CodeDelta uses Jaccard similarity to detect file renames and large-scale moves. A file that appears deleted in the old snapshot and created in the new, but with high token similarity, is treated as a rename rather than a delete+add. This prevents inflated churn numbers from routine refactoring.

LLOC vs GNU diff

LLOC comparison works by tokenising each file's semicolon-terminated statements and running Myers on the resulting token stream rather than the line stream. This means a purely cosmetic reformatting — changing indentation, line breaks, or spacing within a statement — does not register as a change. Only actual logical changes increment CHG_LLOC.

PLOC Definition

PLOC counts lines beginning with # (after optional whitespace) in C/C++ and C# files. This includes all preprocessor directives: #include, #define, #ifdef, #ifndef, #endif, #pragma, #undef, #if, #else, #elif, #error, #warning. PLOC is included within SLOC and LOC — it is not subtracted, it is identified separately for clarity.

Comment Counting

J_COM counts /** ... */ Java-style docblock comments. C_COM counts /* ... */ C-style block comments. EOL_COM counts // to-end-of-line comments. Every line a block comment spans counts as a comment line (a three-line /* */ comment is 3 in C_COM); the tool reports comment lines, not comments. COM_LOC = J_COM + C_COM + EOL_COM.

Character Literal Handling

Single-quoted character literals are correctly excluded from LLOC counting. A semicolon inside a character literal — such as char c = ';' — is not counted as a logical statement. This applies to C/C++, C#, Java, and JavaScript. Escape sequences ('\\', '\n', '\0') are also handled correctly. This was a known limitation corrected in v1.4.1.

CodeDelta requires a valid license to run. Your license is a signed file named codedelta.lic, verified entirely offline — no license server, no internet connection needed. License types:

Installing a License

GUI: on first launch, the activation screen asks for your license — select the codedelta.lic file you were sent. It is saved to your application support folder and verified locally.

Command line: install the license file with:

./codedelta --activate /path/to/codedelta.lic

Or place codedelta.lic in any location the engine searches (first valid match wins):

1. The file named by the CODEDELTA_LICENSE environment variable
2. The folder containing the codedelta binary
3. ~/.codedelta/
4. Your platform's configuration directory

Contact

For licensing, volume pricing, or academic licenses: codedelta.app