codebase-doctor
Codebase Doctor's MCP server offers read-only, offline tools to audit codebases, explain findings, verify fixes, and describe its capabilities.
audit_codebase: run full or changed-scope audits on a repository path, optionally against a Git base ref, returning JSON or summary reports.verify_changes: compare a fresh read-only audit against a prior schema-1 JSON baseline to report findings as resolved, unchanged, or unresolved.explain_finding: return evidence, remediation guidance, and verification command for a finding by fingerprint or rule ID.describe_capabilities: list available tools, the nine audit domains, capability vocabulary, and permissions the server never grants.Audits cover secrets, dependencies, source impact, workflows/infrastructure, PostgreSQL/Supabase RLS, Drizzle hazards, agent surface, frontend a11y/SEO, and backend auth.
Read-only and offline by default; never enables
--run-checksor live database access (--with-database).
Integrates with Git repositories to audit changed scope, merge-base diffs, and commit history for secrets without checking out branches, enabling changed-file and PR-oriented audits.
Publishes audit findings as SARIF to GitHub code scanning and supports PR review output with GitHub-compatible annotations.
Runs as a GitHub Action to perform audits in CI, annotate pull-request diffs via workflow commands, upload SARIF, and fail builds based on configured severities.
Provides live PostgreSQL catalog access for database schema audits, including RLS checks when enabled with --with-database.
Codebase Doctor
Models build. Codebase Doctor verifies.
It finds the thing, and it never guesses.
Most repository scanners fail in one of two ways: they flood you with false positives, or they silently skip the hard case and report "clean." Codebase Doctor does neither. Every finding carries evidence, every audit reports what it couldn't analyze, and a clean run means the scope was actually checked.
npx -y codebase-doctor audit . --changed --format briefcodebase-doctor brief
scope=full findings=1 shown=1 coverage=incomplete score=80
[high] security/secrets/provider-token src/config.ts:12 —
Have an authorized human or external coding agent remove the value and rotate it,
then rerun the audit.
coverage-limitations: validation: skipped, database: skipped, security: partialThat last line is the point. Most tools print findings and stop. This one tells you what it didn't check, every single run.

Why this exists
Coding agents ship code faster than review can keep up. The failure isn't that agents can't write code — it's that nothing verifies what they wrote before it merges.
Codebase Doctor is that verification step. It builds a source graph, scans for committed secrets, dependency drift, unsafe Dockerfiles, workflow injection, RLS mistakes, and accessibility regressions — then tells you exactly what it could not verify.
Benchmarked, not vibes: 17 seeded single-defect fixtures score 100% rule recall and zero medium+ false positives (results, reproducible with npm run benchmark).
Red-teamed: an adversarial mutation corpus tries to hide each defect in a different shape — 11/11 mutants caught, 7/7 controls clean, gated in CI (corpus, reproducible with npm run red-team).
Cross-checked: two independently written offline analyzers (this repo's sql-rls and rls-doctor) run over the same SQL corpus — 10 findings matched, 0 severity mismatches, 1 documented coverage difference, safe schema clean under both (scoreboard, npm run differential).
Field study: of 100 agent-configured public repositories, 23% ship at least one high-severity finding — 10% have broken imports, 4% committed key material, 11% risky agent configuration (report, anonymized and reproducible).
Related MCP server: opzyai
Install
npx -y codebase-doctor audit . # no install
npm install -g codebase-doctor # globalQuick start
codebase-doctor demo # disposable fixture: secret, broken import, blast radius
codebase-doctor bisect security/secrets/provider-token . # when did this enter history?
codebase-doctor audit . --json # full audit
codebase-doctor audit . --changed --json # just my diff
codebase-doctor audit . --changed --base main --json # PR review
codebase-doctor audit . --format sarif # GitHub code scanning
codebase-doctor audit . --format html > report.html # shareable standalone report
codebase-doctor verify . --baseline before.json # confirm fixes landeddemo needs no configuration and no repository: it builds a disposable git
fixture with a tracked secret and a broken import, audits the simulated agent
edit with the real pipeline, prints the blast radius, and exits 1 to show the
CI gate. Nothing outside a temp directory is touched.
Options
--run-checks Permit configured validation commands
--changed Audit Git changes and their affected scope (implied by review)
--base <ref> Compare changed scope from the merge base with this ref
--json Emit schema-versioned JSON
--format <format> Output format: text, json, sarif, brief, or html (review adds markdown, github)
--all-findings Review only: include findings outside the changed lines
--output <file> Review only: write the report to a file as well as stdout
--exclude <glob> Exclude a repository-relative path glob; repeatable
--baseline <path> Compare with a prior Codebase Doctor JSON report
--timeout <ms> Per-command timeout (default: 120000)
--fail-on <severity> info|low|medium|high|critical|none (default: high)
--require-complete Exit 2 when audit coverage is incomplete
--max-findings <n> Cap brief output (default: 100)
--score Print only the Repo Health score
--badge Print a shields.io badge URL for the Repo Health score
--receipt <path> Write a portable coverage receipt (digest-verified)
--receipt-key <path> Sign the receipt with an Ed25519 private key (PEM)
--pheromone <path> Write a privacy-bounded signal (rules and counts only)
--with-database Permit live PostgreSQL catalog access
--with-advisories Opt-in OSV advisory lookup over lockfile packages
--database-schema Schema to inspect; repeatable (default: public)
--database-timeout Catalog statement timeout in ms (default: 10000)Code review
review is the pull-request command. It always audits changed scope, narrows
findings to added diff lines, and prints a verdict — APPROVE, COMMENT, or
REQUEST_CHANGES — so unrelated old issues never fail a PR:
codebase-doctor review . --base origin/main --format markdown > review.md
codebase-doctor review . --base origin/main --format github
codebase-doctor review . --format json # includes a machine-readable review envelope--format markdownrenders a PR-comment-ready body with the verdict, findings, source impact, and coverage limitations.--format githubemits::error/::warning/::noticeworkflow commands that annotate pull-request diffs inline from Actions logs, with no network access.A finding on an unchanged line is out of scope for the verdict and counted as omitted; the full
auditstill reports it.--all-findingsdisables narrowing, and--output <file>writes the report to a file as well as stdout.With
--baseline, only new findings in the diff gate the verdict.Exit
1means the review requests changes; exit2is an operational failure, never a clean result. Inspect coverage before calling the reviewed diff verified or clean.
GitHub Action
permissions:
contents: read
security-events: write
steps:
- uses: actions/checkout@v4
- uses: subhajitlucky/codebase-doctor@v0.1.10
with:
format: sarif
upload: "true"
fail-on: highFindings appear in the Security tab. See docs/github-action.md.
What it checks
Secrets — working tree and history
Precision-first and not exhaustive: it detects private-key material, provider-token shapes, paired AWS credentials, credential-bearing URLs, and high-confidence sensitive assignments. A Git-ignored .env is normal storage and is not a finding; a tracked one containing a real credential is.
security/secrets-history catches the case that matters most: a secret committed and later deleted from the working tree, so a rotated-looking repo doesn't hide an exposure. It inspects the most recent 200 commits across all branches without ever checking out, rewriting, or executing repository content. Changed audits scope the history log to changed paths, so deleting a leaked file cannot review clean.
Matched values are withheld from every finding, fingerprint, error, and report. Codebase Doctor never prints your secrets — including in its own SARIF. An external authorized human or agent must remediate the shareable content and rotate or revoke the credential, then rerun the same audit.
Dependencies
security/dependencies is read-only and offline. Lockfile-aware for npm lockfile versions 2 and 3, pnpm (v5+), Yarn (classic and Berry), Bun, and Python poetry and uv locks. Remaining ecosystems stay explicitly unsupported rather than receiving guessed findings.
Rule families: security/dependencies/missing-lockfile, security/dependencies/manifest-lock-drift, security/dependencies/insecure-source, security/dependencies/mutable-git-source, security/dependencies/missing-integrity, security/dependencies/workspace-registry-resolution, security/dependencies/competing-npm-lockfiles, and security/dependencies/competing-lockfiles.
A normal semver range such as ^5.0.0 is not a finding when the lock agrees. Raw dependency specifications and resolved URLs are withheld from reports and never enter a fingerprint. An external authorized human or agent must correct the metadata and rerun the same scope. Inspect coverage before calling the dependency graph clean or verified.
It never invokes npm, another package manager, a shell, an installer, or a lifecycle script, and makes no network request. It makes no CVE or advisory claim on its own. Python coverage parses poetry.lock and uv.lock package blocks and pyproject.toml Poetry and PEP 621 declarations with a bounded line scanner (no TOML dependency): insecure transports, unpinned git references, missing hash evidence, missing lockfiles, competing lockfiles, and decidable manifest-lock drift are reported, while undecidable specifiers, markers, direct-URL drift, transitive-only entries, and requirements-only layouts stay visible as partial coverage.
--with-advisories performs one bounded OSV lookup against resolved packages. Only names, versions, and ecosystems leave the machine.
Source impact — what breaks if I change this file
repository/source-graph uses a real syntax parser (never executes your code) to build a static import graph across JS/TS, Python, Go, Java, and Rust. In changed mode it walks reverse edges and reports a deterministic shortest impact path from each changed file.
Changed mode is mixed-scope per doctor, not a universal file filter: Project Doctor structural rules run with the full repository snapshot and may report findings outside changed paths for manifests, lockfiles, workspaces, and test visibility. File-local doctors (backend, frontend, infrastructure, agent surface, performance) examine only changed files present in the inventory, so changed audits stay proportional to the change. Configured validation check plans are built from full project topology and then filtered to affectedProjectIds. Static SQL selects affected migration streams and replays full current history for every selected stream. Live database remains a full observed schema-set audit only with separately requested --with-database. Zero changed findings is not a full clean result.
repository/source-graph recognizes static import, re-export, type-only import, literal require, and literal dynamic import edges across JavaScript and TypeScript (plus Python, Go, Java, and Rust) with a real syntax parser that never executes repository code. Cycles are valid topology, not findings, and this module is finding-free by design.
A separate precision-first repository/source-integrity Doctor emits only the source/import-target-missing rule, keeping topology limitations from becoming guessed bugs. It diagnoses only four proof classes: an explicit relative target with a supported source extension; a single deterministic alias whose configured target explicitly names a supported source file; a unique workspace package whose explicit entry names a supported source file; and an internal Go package under a module path without a replace directive.
Extensionless, JSON, custom-loader, conditional, ambiguous, external, and dynamic references and cycles are not findings. It does not check named exports or validate that a referenced export name exists.
Full mode examines all qualifying edges; changed mode examines changed importers and complete reverse-impacted importers. A deleted or renamed target selects its unchanged importer.
It emits at most 1,000 findings per audit and reports partial coverage whenever that ceiling or any upstream graph limitation applies. Partial coverage is not a clean source-integrity result. Raw import specifiers and source text are withheld from findings, which expose only normalized paths, import kind, proof class, and safe location.
An external authorized human or agent must correct or restore the intended target and rerun the same scope.
codebase-doctor audit . --changed --base mainsrc/db/schema.ts → src/repositories/user.ts → src/api/users/[id]/route.ts
→ src/app/dashboard/page.tsx → tests/integration/user.test.tsCycles are valid topology, not findings. The graph module intentionally emits no bug findings — repository/source-graph is finding-free by design, and the separate precision-first repository/source-integrity Doctor reports only provably missing import targets, so topology limits never become guessed bugs.
Schema-1 reports may include sourceImpact (schema 1). Changed mode walks reverse internal edges, adds impacted projects to affectedProjectIds, and reports a deterministic shortest impact path per changed source root. Reports preserve full impacted-file counts while serializing only bounded impact records. A path proves only the static edge chain, not a bug in the dependant. Raw import specifiers and source text are withheld; the module uses no plugins, network requests, or writes.
Local tsconfig and jsconfig files contribute a deterministic subset of relative aliases; this is not complete Node or TypeScript module resolution. Dynamic non-literal imports, ambiguous targets, unsupported configuration or syntax, unreadable input, and graph ceilings are coverage limitations, not findings.
Workflow and infrastructure
script-injection (attacker-controlled ${{ github.event.* }} in a run: step), pull-request-target-checkout, write-all-permissions, unpinned action refs, unpinned Docker base images, pipe-to-shell, root-user, and world-writable files. Workflows are never dispatched and images are never built.
PostgreSQL and Supabase RLS
Offline database/sql-rls runs automatically when a supported PostgreSQL migration stream is discovered: it requires no credentials, makes no network request, and never executes migration SQL, reconstructing expected table, policy, RLS, and grant state from supported migrations. Partial coverage is not a clean static SQL result.
Live database/rls inspects observed database state through a read-only catalog of policies, privileges, roles, memberships, enforcement, and bypass paths, permissioned separately with --with-database using environment credentials and a read-only, repeatable-read transaction.
database/rls-drift compares the two — expected migration state against observed live state — and reports table-missing-live, rls-disabled-live, force-rls-disabled-live, policy-missing-live, grant-missing-live, rls-enabled-live-only, and policy-unmanaged-live.
Database and Drizzle hazards
The read-only, offline database/drizzle module and its database/drizzle/raw-sql-date-parameter rule catch a runtime boundary: a JavaScript Date interpolated into a raw Drizzle sql template can bypass the column's timestamp encoder, so postgres-js may throw ERR_INVALID_ARG_TYPE, while equivalent SQL can still work in psql.
// Before: raw interpolation can bypass the timestamp column encoder.
const rows = await db.execute(sql`select * from jobs where run_at <= ${date}`);
// After: guidance for a human or separately authorized external coding agent.
const rows = await db.select().from(jobs).where(lte(jobs.runAt, date));Applicability requires an exact drizzle-orm/postgres-js adapter import, or scoped owning/workspace evidence for both drizzle-orm and postgres. It reports only statically proven Date flows and never infers from a variable name. Findings are medium severity, high confidence.
Not findings: Date(), Date.now(), an encoded toISOString() string, typed comparisons such as lte(column, date), and a fresh inline encoder object passed directly to sql.param(value, encoder). Encoder identifiers and aliases are not statically proven safe even when declared const, because their objects may be mutated elsewhere; those interpolations and unresolved flows become partial coverage limitations rather than guessed findings. Partial coverage is not a clean Drizzle audit. Raw SQL and parameter values are withheld from findings, fingerprints, and reports. An external authorized human or agent must make the repair and rerun the same scope.
Agent surface — the newest attack target
Audits the agent configuration surface without executing or contacting any of it:
MCP client configs: unpinned package runners, shell commands, inline credentials, broad filesystem grants
SKILL.md: unscopedallowed-toolsgrants (Bash(*), bareWrite)Permission bypass:
bypassPermissions,--dangerously-skip-permissions,--yolo,yes-always, broadpermissions.allow
Frontend
JSX/TSX and static HTML accessibility (img-missing-alt, iframe-missing-title, html-missing-lang, positive-tabindex) and static SEO (missing-title, missing-meta-description). No browser, no build.
frontend/security is read-only and offline over JSX sources: dangerously-set-inner-html fires for a dynamically computed value without a provable sanitizer call (DOMPurify.sanitize, sanitizeHtml). Static literals are safe and spread props suppress the check.
Backend and auth
backend/auth is read-only and offline over JavaScript and TypeScript sources. It never starts a server, sends a request, or issues a token — it reads source text only.
Rules: cors-wildcard-origin-with-credentials (wildcard origin: "*", reflected origin: true, or an allowlist containing *, with credentials enabled), session-cookie-security-disabled (cookie secure or httpOnly explicitly false), jwt-decode-without-verify (a decode call in a file containing no verify call), and jwt-verify-algorithm-unrestricted (no algorithms allowlist).
backend/api is read-only and offline over the same sources: sql-string-concat-query fires for concatenated or interpolated SQL text passed to a provably bound pg, postgres, mysql, mysql2, better-sqlite3, or sqlite3 query call (parameterized queries with a values array are safe), and child-process-exec-dynamic fires for non-static commands passed to a provably bound child_process exec/execSync (including spawn with shell: true), while execFile and plain spawn never fire. Instance calls through new Pool()-style construction resolve like direct imports. Unresolvable query text stays a coverage limitation.
A rule fires only when the callee provably resolves to the audited package through an import declaration or CommonJS require, so an unrelated local helper named cors or decode is never reported. Configuration that cannot be resolved statically — a non-literal options expression, a computed cookie flag, or a spread property that could supply the value — is a coverage limitation, never a guessed finding, so inspect backend coverage before calling a codebase clean. The decode and algorithm rules are file-scoped: a verify call in middleware in another file does not suppress them. Configured origin and secret literals are withheld from reports and never enter a fingerprint.
Not covered: API shape validation, worker, webhook, cron, and rate-limit analysis. An external authorized human or agent corrects the configuration, then reruns the same scope.
Current coverage versus north star
This is the part most scanners skip.
There is one unified auditor — one doctor for the whole codebase, not a collection of separate products. Framework- and domain-specific knowledge lives inside it as built-in internal audit modules.
A full audit examines the full requested repository scope for applicable implemented modules. It is not complete or universal — it is not every-domain analyzer coverage. Inspect coverage before calling a codebase verified or clean.
Every report includes domainCoverage — a checklist of nine domains separating applicability from status, so not-detected differs from detected-but-unsupported, skipped, failed, or not-selected, with module-level status details, evidence, and limitations. coverageComplete does not mean the code is bug-free or correct.
That means:
A clean run means the scope was actually checked.
--require-completeexits2rather than letting a skipped area report as clean.A truncated or bounded scan says so in
coverageSummarywith exacttotal/emitted/omittedcounts and deterministic sample paths.
Domain | Current source coverage | North star |
Repository structure | Inventory, framework detection, manifests, workspaces, lockfiles, test visibility, JS/TS + Python + Go + Java + Rust impact graph | Cross-language dependency and behavioral topology |
Configured validation | JS/TS and Python command planning; execution only with | Sandboxed validation across ecosystems |
Database | Offline migration RLS, Drizzle Date hazards, live RLS, static-to-live drift | Schemas, queries, permissions, more engines |
Frontend | JSX/HTML a11y, static-HTML SEO, and raw-HTML sinks | React, Next.js, bundle analysis, broader a11y |
Backend and authz | Read-only, offline | Worker, webhook, cron, rate-limit analysis |
Security | Secrets (tree + history), dependency rules, opt-in OSV | Secrets, permission, vulnerability, supply chain |
Infrastructure | Dockerfile and GitHub Actions | Hosting and deployment analysis |
Performance | Static file hygiene: committed build artifacts, oversized sources | Cache, query, memory, profiling |
AI systems | Agent-surface audit: MCP configs, | Prompt, token, grounding analysis |
North-star entries are planned modules, not shipped behavior. Built-in source-impact graph, secrets analysis, and dependency analysis ship together in 0.1.4 and are not part of the historical 0.1.3 package.
Precision and bounded-report contract
Workspace publication entries, generated targets, and fixture-controlled paths are coverage limitations unless independently proven broken; they are not missing-target findings by themselves. Detected pnpm, Yarn, and Bun scopes never receive npm-specific findings. Only a cryptographic match to an inventoried localhost-only certificate can classify a private key as an intentional local test key; every other matched private key remains high severity.
Schema-1 reports bound repeated evidence without hiding its size: coverageSummary preserves exact total, emitted, and omitted counts, and limitationGroups preserve each reason, deterministic sample paths, and omitted path counts.
Inspect coverage before calling a codebase verified or clean. Read docs/architecture.md for the full contract.
Read-only by design
Codebase Doctor reports. It exposes no direct target-file write API, has no direct filesystem-write capability, and includes no remediation executor. It can never be granted direct target-write or remediation authority, and never modifies, fixes, or repairs target files. A human or a separately authorized agent makes changes, then reruns the same scope to verify.
Separately authorized --run-checks launches repository-owned validation subprocesses; they are not filesystem- or network-isolated and may have side effects. That is validation execution, not Doctor repair authority.
--changedgrants no command execution, network, or database accessvalidation commands need
--run-checks; live database needs--with-database; OSV lookup needs--with-advisoriesdatabase credentials come from
DATABASE_URLorSUPABASE_DB_URL, never a connection-string flagsource analysis parses syntax and never executes source; lockfile analysis never invokes a package manager
apart from an explicitly requested OSV lookup, it makes no external network calls
Shadow audits
shadow audits a disposable copy of the repository. Validation commands
(--run-checks) execute inside the copy, so repository-owned side effects —
file writes, caches, hooks — cannot touch your working tree:
codebase-doctor shadow . --run-checks --fail-on high --receipt shadow.jsonThe copy is always removed, the original is never modified, and the receipt
is marked environment: shadow (disposable copy). This is the safe way to
run untrusted validation commands.
Verifier swarm
swarm verifies multiple repositories with parallel read-only workers and
composes a fleet verdict. Verdicts are honest by construction:
findings— gating findings (at--fail-onor above) are presentunknown— evidence was lost: failed or partial coverage, or a failed workergaps— no gating findings, but some domains were not attempted by designverified— every applicable domain completed or was not applicable
codebase-doctor swarm ../api ../web ../worker --workers 4 --receipt-dir receipts/
codebase-doctor swarm ../api ../web --require-complete # exit 2 on unknown or gapsThe fleet verdict is the worst of its members; a clean verdict is never claimed over lost evidence. Each worker can emit a coverage receipt.
Chronological bisect
bisect finds the commit where a rule or fingerprint first appeared by
auditing history oldest-first in disposable git worktrees:
codebase-doctor bisect security/secrets/provider-token .
codebase-doctor bisect <fingerprint> . --max-commits 500 --jsonOutput carries the commit, author, message, location, fingerprint, and the
parent-absence evidence: the parent commit was scanned immediately before
and did not contain the target. Each commit is audited in a disposable
worktree; the working tree is never modified. --all-history scans merges
too; the default is first-parent.
Repo Health score
Every report carries a deterministic score: 100 minus severity penalties —
critical 25, high 10, medium 4, low 1, info 0 — minus 10 when applicable
coverage did not complete, clamped to 0–100. Bands: green ≥ 80, yellow ≥ 50,
red < 50. Acknowledged (suppressed) findings never count, and the score never
replaces the report: inspect coverage before calling a codebase verified.
codebase-doctor audit . --score # Repo Health: 71/100
codebase-doctor audit . --badge # https://img.shields.io/badge/Repo%20Health-71%2F100-yellow--score and --badge print only the score or badge; exit codes still follow
--fail-on. JSON reports always include the score object with its
findingPenalty and coveragePenalty breakdown, and brief output carries
score= in its header.
Exit codes
Code | Meaning |
| Requested audits completed and no finding met the threshold |
| Requested audits completed and at least one finding met the threshold |
| An audit could not complete, or coverage was incomplete under |
Exit 2 is an operational failure, not a clean result.
Baselines and SARIF
--baseline classifies fingerprints as new, unchanged, or resolved, and applies --fail-on only to new findings. After an external fix, confirm it:
codebase-doctor audit . --json > before.json
# ... fix happens elsewhere ...
codebase-doctor verify . --baseline before.jsonverify reports each fingerprint as resolved, unchanged, unresolved, or new, and exits 1 unless everything is verifiably resolved. unresolved means absent under incomplete coverage — never a repair. The fresh verify scan runs the same offline audit scope as audit so security and database findings are comparable; live database access stays ungranted.
Coverage receipts
Every audit can emit a portable coverage receipt — what was checked, what was not, the deterministic score, and finding fingerprints — with a SHA-256 digest over the canonical body and an optional Ed25519 signature:
codebase-doctor audit . --receipt receipt.json
codebase-doctor audit . --receipt receipt.json --receipt-key key.pem
codebase-doctor verify-receipt receipt.json # exit 0 valid, 2 tamperedReceipts never contain secret values or source text. A digest proves tamper evidence; a signature proves the key holder issued it. See docs/receipts.md.
Pheromone signals
An audit can emit a pheromone signal — rules, severities, and counts only, never paths, fingerprints, source text, or repository names:
codebase-doctor audit . --pheromone signal.json
codebase-doctor pheromone merge signals/*.json --min-signals 3 --out index.jsonmerge verifies every signal's digest (and signature, if present), fails
closed on tampered input, and excludes patterns observed in fewer than
--min-signals signals (k-anonymity). The result is a public pattern index
of what actually occurs — without exposing anyone's code. See
docs/pheromones.md.
Intent verification
intent verify checks declared intent against audit evidence — it never
interprets prose. Claims live in JSON or a fenced intent block in a PR
body:
```intent
{ "intentVersion": "1", "claims": [
{ "id": "no-secrets", "kind": "rule-absent", "ruleId": "security/secrets/provider-token" },
{ "id": "score", "kind": "score-at-least", "value": 90 }
] }
```codebase-doctor intent verify pr.md . --require-verifiedEach claim is verified, violated (with evidence locations), or
undecided — undecided means the claim depends on coverage that did not
complete, and it is never counted as verified. Exit 1 on any violation;
--require-verified exits 2 on undecided. See docs/intent.md.
Economic verification
economy verify replays a transaction journal in a disposable shadow
ledger — nothing is submitted, nothing moves — and proves or witnesses
economic invariants before real value does:
codebase-doctor economy verify journal.json --policy policy.jsonnon-negative-balances— overdraft / double-spend, with the exact operationper-operation-limitandwindow-volume-limit— size and velocity limitsallowlist— transfer counterpartiesdeclared-balances— the journal's reported balances must match the replay
Violations carry witnesses (operation id, index, balance snapshot); exit 1 on
any violation, --require-proved exits 2 on undecided. See
docs/economy.md.
Proof-carrying repairs
fix generates a repair for a finding and verifies it in a disposable
copy before writing anything:
codebase-doctor fix <fingerprint> . --patch fix.patch --receipt fix.jsonFor source/import-target-missing it finds the unambiguous existing
candidate (exact stem match first, same directory preferred), applies the
one-line change in a shadow copy, re-audits, and writes the patch only if
the finding fingerprint disappears and no new medium+ finding appears. The
patch is a real git diff; the receipt binds the fingerprint to the patch
SHA-256 and the before/after verdicts. The original repository is never
modified. See docs/repairs.md.
Exploit witnesses
witness turns a risky-pattern finding into a concrete exploit — the
payload, the transformed sink text it produces, and why it violates the
boundary:
codebase-doctor witness <fingerprint> .
# Payload: ' OR '1'='1' --
# Transformed: select * from users where id = '' OR '1'='1' --'Supported rules: backend/api/sql-string-concat-query,
backend/api/child-process-exec-dynamic, and
frontend/security/dangerously-set-inner-html. A small concatenation
evaluator handles literals, template literals, +, parentheses, and TS
casts; anything else is undecided, never guessed. The artifact is bound
to the finding fingerprint with a digest, and nothing is ever executed. See
docs/witness.md.
Acknowledged findings (suppressions)
A finding a human has reviewed and accepted can be acknowledged inline without hiding it from any report:
const API_KEY = "..."; // codebase-doctor-ignore: security/secrets/provider-token -- rotated test credentialThe directive names rule ids, doctor ids, or
doctor/*prefixes, and applies on the finding's own line or the line immediately above it. Findings without a location cannot be acknowledged inline, and directives that match nothing are ignored.Acknowledged findings leave
findings(so failure gates pass) but stay fully listed undersuppressedwith their reason and directive location. They still count as present: baseline comparisons report themunchangedandverifynever reports themresolved. Removing the directive brings the finding back as new.Suppressed findings are excluded from SARIF uploads by design; inspect
suppressedin JSON, text, or brief output instead.
MCP server and agents
claude mcp add codebase-doctor --scope user -- npx -y codebase-doctor@0.4.13 mcpRead-only tools, each annotated readOnlyHint: true, destructiveHint: false, idempotentHint: true: audit_codebase, review_changes, verify_changes, explain_finding, verify_intent, build_receipt, describe_capabilities. Responses are bounded at roughly 50 KB; the server never enables --run-checks or live database access. Failures return structured JSON shaped as { error: { code, message, nextAction } }. Setup for Codex CLI, Gemini CLI, and generic stdio clients is in docs/agents.md.
Registry metadata ships in server.json (io.github.subhajitlucky/codebase-doctor); publishing steps for the official MCP registry, Smithery, and Glama are in docs/mcp-registries.md.
Live listings: Glama · official MCP registry (io.github.subhajitlucky/codebase-doctor).
A Claude Code plugin ships in this repository (.claude-plugin/ + skills/):
/plugin marketplace add subhajitlucky/codebase-doctor
/plugin install codebase-doctorcodebase-doctor instructions prints ready-to-paste snippets for AGENTS.md, CLAUDE.md, .cursor/rules/, .windsurfrules/, .clinerules/, and copilot instructions. It only prints — it never writes files.
Workflow: audit . --changed --format brief after edits, review . --base main --format brief for a PR verdict, full audit . at trust boundaries, verify after an external fix.
Roadmap
Built-in backend, performance, and AI semantic audit coverage
Per-domain coverage guarantees beyond the global
--require-completegatePull-request annotations, hooks, and agent plugins on the same report schema
Approved validation in read-only mounts or disposable copies
Deterministic doctor benchmark (
npm run benchmark, see docs/benchmark.md): recall, medium+ false-positive rate, review verdicts, and suppression honesty on seeded fixturesCross-model benchmarks: defects found, verification success, token cost
Dogfooding
CI audits this repository with Codebase Doctor itself:
node dist/cli.js audit . --baseline .codebase-doctor-baseline.json --format brief --fail-on highThe baseline records this repository's accepted findings — currently none:
the self-audit is clean. Any new finding fails CI. All fixture sources
are split so the token never appears contiguously in the working tree or in
history — the generated fixture still contains it, so demo keeps
demonstrating a real secret finding.
Rival scanner scoreboard
Most benchmarks are self-run on self-authored fixtures. This one is too — and says so — then puts the same corpus through independently installed rival scanners:
npm run rival-differential -- --markdown docs/rival-scoreboard.mdIt seeds disposable repositories with the same 17 deterministic cases plus advisory and control rows, runs codebase-doctor and pinned Semgrep CE, gitleaks, Trivy, and osv-scanner over each, and publishes a dated snapshot of caught, missed, noise on clean controls, and out-of-scope cells — including where codebase-doctor loses. Rival results are not a CI gate; registries and advisory databases move.
Snapshot + methodology: docs/rival-scoreboard.md
A weekly workflow publishes the latest run to the Actions job summary (
.github/workflows/rival-scoreboard.yml).
Development
npm install && npm run build && npm run typecheck && npm testReleases are checked with npm pack, installed into a clean temporary project, and run through the generated binary.
License
MIT
Available Tools
4 toolsaudit_codebaseARead-onlyIdempotent
Run the full built-in Codebase Doctor audit on a repository and return the evidence-backed report. Read-only and offline by default; it never enables validation commands (--run-checks) or live database access (--with-database).
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Git ref to compare against from the merge base; requires changed. Mirrors the CLI --base option. | |
| path | No | Repository path to audit. Defaults to the server working directory. | |
| format | No | Report rendering: "json" returns the schema-version-1 JSON report; "summary" returns the deterministic text report. | |
| changed | No | Audit Git changes (staged, unstaged, untracked, and branch work) and their selected scope instead of the full repository. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive/closed-world, so the description earns credit by adding what those hints cannot: the audit is offline by default and will never enable validation commands (--run-checks) or live database access (--with-database). It stops short of disclosing runtime cost, repo-size limits, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero padding. The primary action is front-loaded and the safety constraints follow immediately, and every clause carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema the description still conveys the return artifact and the two rendering options, and all four optional parameters are documented in the schema. It omits what the audit actually checks and how large a repo it can handle, minor gaps for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already explained in the schema (base ref, path default, format enum, changed scope). The description adds no syntax or format detail beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Run the full built-in Codebase Doctor audit on a repository') and names the artifact returned ('the evidence-backed report'). It is easy to distinguish from siblings like verify_changes or explain_finding, though the description never explicitly contrasts itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The default-scope statement ('Read-only and offline by default') and the two explicitly disabled modes give implicit guidance on how the tool behaves, but there is no explicit when-to-use statement or routing advice versus verify_changes/describe_capabilities. Usage must be inferred from the schema's 'changed' flag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_capabilitiesARead-onlyIdempotent
Describe this MCP server: available tools, the nine audit domains in the domainCoverage inventory, the Doctor capability vocabulary, and the permissions this server never grants.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and a closed-world posture, so the safety profile is covered. The description adds genuinely extra context by promising disclosure of 'the permissions this server never grants,' which tells the agent about hard capability boundaries rather than just restating read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; each listed item (tools, audit domains, capability vocabulary, never-granted permissions) is load-bearing information about what the caller receives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description carries the burden of describing the return content and does so by enumerating the four sections the response contains. It is nearly complete for a low-complexity read-only meta tool; only the guidance on when to invoke it is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters and 100% schema coverage, so there is nothing for the description to clarify at the input level. Baseline 4 applies for a no-argument tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Describe') and resource ('this MCP server'), then enumerates the exact content returned (tools, nine audit domains, Doctor capability vocabulary, never-granted permissions). It is clearly distinct from the audit/verify/explain siblings, though it never names them or explicitly contrasts itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use statement, no mention that this is the recommended first call for orientation, and no exclusions. Usage is only implied by the self-descriptive nature of the tool (an agent wanting an inventory of the server would infer this is the right call).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_findingARead-onlyIdempotent
Return the full evidence, remediation guidance, and verification command for one finding, selected by fingerprint or rule id. Read-only and offline.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Git ref to compare against from the merge base; requires changed. | |
| path | No | Repository path to audit. Defaults to the server working directory. | |
| ruleId | No | Rule id, for example database/drizzle/raw-sql-date-parameter. Returns the highest-severity match. | |
| changed | No | Audit Git changes and their selected scope instead of the full repository. | |
| fingerprint | No | Exact finding fingerprint from a prior JSON report. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered; the description adds that it is 'offline' and enumerates the returned artifacts (evidence, remediation, verification command), which is useful since no output schema exists. It doesn't cover the no-match or ambiguity case (e.g., what happens when a rule id matches multiple findings).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler; the primary purpose and the selection criterion are both front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does carry the return-value burden and handles it by naming the three artifacts returned. It remains silent on failure modes (unknown fingerprint, rule id with no match) and whether results are truncated, which leaves a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters, including the 'highest-severity match' behavior for ruleId. The description only reinforces the fingerprint/ruleId selection axis and adds nothing the schema lacks, which is the baseline 3 case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (return), resource (evidence, remediation guidance, verification command for one finding), and selector (fingerprint or rule id). This clearly distinguishes it from sibling tools audit_codebase and verify_changes, which perform audits rather than explain a single result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The selection mechanism ('by fingerprint or rule id') and the provenance of the input ('from a prior JSON report' per the schema) make the intended usage clear. However, it never explicitly contrasts itself with audit_codebase or verify_changes or states when *not* to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_changesARead-onlyIdempotent
Verify that findings from a prior schema-1 JSON report are repaired. Runs a fresh read-only audit, compares fingerprints, and reports each baseline finding as resolved, unchanged, or unresolved. Absence under incomplete coverage is unresolved, never resolved. Read-only and offline by default; it never enables validation commands or live database access.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Git ref to compare against from the merge base; requires changed. | |
| path | No | Repository path to verify. Defaults to the server working directory. | |
| format | No | Report rendering: "json" returns the structured verification result; "summary" returns the deterministic text report. | |
| changed | No | Verify against Git changes and their selected scope instead of the full repository. | |
| baseline | Yes | Path to a prior codebase-doctor schema-1 JSON report on this machine. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world; the description goes further by disclosing fingerprint comparison, the freshness of the audit, the conservative coverage rule (absence under incomplete coverage is unresolved, never resolved), and that it never enables validation commands or live DB access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four front-loaded sentences, each carrying distinct load: purpose, mechanism and outputs, the interpretive rule, and the safety posture. No filler or redundant restatement of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly supplies the result vocabulary (resolved, unchanged, unresolved) and the coverage caveat, so an agent knows what comes back and how to read it. Nothing needed to invoke this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline 3 applies, but the description adds real meaning: baseline is a prior codebase-doctor schema-1 JSON report on the machine, and the coverage caveat implicitly frames how results should be interpreted. This is slightly more than the schema conveys, though it does not detail base/changed/path interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (verify) and resource (findings from a prior schema-1 JSON report being repaired), plus the mechanism (fresh read-only audit, fingerprint comparison). This is clearly distinguishable from audit_codebase's fresh audit because it is explicitly baseline-relative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The requirement of a prior baseline report plus the resolved/unchanged/unresolved framing makes the post-repair verification context clear. It stops short of explicitly naming audit_codebase or state a when-not condition, so it lands just below a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v0.1.0- First observed
audit_codebase - First observed
describe_capabilities - First observed
explain_finding - First observed
verify_changes
TDQS
Scored across 4 tools
Each tool has a fairly distinct purpose: audit_codebase runs the full audit, verify_changes compares fingerprints against a baseline, explain_finding drills into one finding, and describe_capabilities is meta. The only mild overlap is that audit_codebase and verify_changes both execute a read-only audit, but their descriptions make the baseline-vs-verification distinction clear.
All four tools follow a clean verb_noun snake_case pattern (audit_codebase, describe_capabilities, verify_changes, explain_finding), with no mixed conventions or vague verbs.
Four tools is a tightly scoped, coherent set for a read-only audit workflow (run, explain, verify, describe). It is on the lean side but each tool earns its place, so it lands slightly below ideal breadth rather than being bloated.
The surface covers the core audit lifecycle: run an audit, inspect individual findings, verify repairs, and introspect the server's capabilities. A dedicated findings-listing tool is absent, but findings are surfaced through the report and explain_finding, so agents can work around it; read-only design legitimately omits write operations.
Maintenance
Related MCP Connectors
Audit GitHub repos for malicious and supply-chain code before you depend on them.
Lets coding agents check their own code for leaked secrets, risky dependencies and AI-code mistakes
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceLive codebase intelligence for AI agents. Import graph PageRank for file importance, git forensics for co-change coupling and fragile code, convention detection across 16 domains, and blast radius analysis.49 npm3Business Source 1.1
- AlicenseNot gradedqualityDmaintenanceLocal-first security check for AI coding agents — finds hardcoded secrets, exposed .env files, git-history leaks and vulnerable dependencies (OSV), entirely on your machine. Ask your agent "is this safe to ship?" and get a Launch Readiness score with a fix for every finding.MIT
- AlicenseNot gradedqualityCmaintenanceExposes repository reconnaissance tools — file listing and verbatim reading, regex search, dependency-tree parsing across Python/Node/Rust/Go, and test-coverage ingestion — so agents can gather line-numbered evidence from real source files. This lets an audit pipeline physically re-verify every claim and drop findings that cannot be located in the code.MIT
- AlicenseNot gradedqualityBmaintenanceLocal code-graph engine for AI coding workflows: static analysis of Rust, Cangjie, ArkTS, TypeScript/JavaScript, C/C++, Python, and Shell projects into symbols, imports, call graphs, and quality gates, with pre-commit change review and impact analysis. Read-only by design — never executes build scripts or uploads code.61MIT