CODEOWNERS Coverage Analyzer

{{ field.label }}:

CODEOWNERS file:

Use the base-branch CODEOWNERS content. Rules stay case-sensitive to match GitHub behavior.

Drop CODEOWNERS or TXT onto the textarea.

Changed files:

One changed path per line. Status prefixes such as M, A, D, R100, and tab-delimited rename rows are normalized.

Drop TXT, DIFF, PATCH, or CSV onto the textarea.

Review input

{{ error }}

{{ field.label }}:

{{ header }}	Copy
{{ cell.value }} {{ displayCell(cell) }}
{{ emptyTableTitle(tab.key) }} {{ emptyTableNote(tab.key) }}

No owner groups charted

Paste changed files and usable CODEOWNERS rules to build the owner coverage chart.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

CODEOWNERS turns repository paths into review responsibility. A rule such as /infra/ @org/platform-infra tells the repository host which person or team should be asked to review a pull request when files under that path change. The file is small, but it sits close to branch protection, release safety, and team accountability because it can decide who is notified before code reaches a protected branch.

The important detail is that CODEOWNERS is path routing, not a full approval policy by itself. The ownership file says who owns a path, while branch protection or rulesets decide whether a code-owner approval is required before merge. A repository can have accurate rules and still be weakly protected if required review is off, and a protected branch can still miss the right team if a broad fallback rule owns too much of the tree.

Coverage checks are useful before a pull request is merged because ownership errors usually hide in ordinary-looking diffs. A root-level * owner may request someone for every file, but that fallback does not prove that database migrations, infrastructure files, release workflows, or the CODEOWNERS file itself have a specific maintainer. Ownerless rules can be intentional exceptions, yet they also create review gaps when they match sensitive paths.

The changed-file list matters as much as the ownership file. A base-branch comparison, a saved name-status diff, or a focused working-tree review should describe the files that will actually land in the target branch. Stale diffs, mixed pull requests, and generated-file exclusions can change the denominator, so ownership coverage is strongest when the checked paths match the real merge scope.

Common CODEOWNERS coverage questions
Question	Why it matters
Does every changed path match a usable rule?	Unmatched paths can be merged without a code-owner request unless another review rule catches them.
Is the match specific or only the catch-all rule?	Fallback ownership can hide parts of the repository that need a narrower owner.
Are there ownerless or invalid lines?	Exceptions and skipped syntax change who is actually requested for review.
Is the ownership file protected by ownership too?	A CODEOWNERS edit can weaken future review routing if the file has no direct owner.

CODEOWNERS review routing from changed paths and base branch rules through last-match precedence to review owner requests or gaps.

A useful coverage review checks four facts before merge: the changed path, the winning rule, whether the owner is specific or catch-all, and whether an exception needs human review.

How to Use This Tool:

Run one pull request or changed-file set at a time so the coverage percentage, path ledger, and remediation queue describe one review decision.

Enter a concise Repository label for the report and exported JSON.
Set Coverage target to the owner-assigned percentage expected for the review, such as 95%.
Use Protected path prefixes for paths where the catch-all owner should not be enough. Commas and new lines are accepted.
Leave Require CODEOWNERS self-owner enabled when changes to .github/CODEOWNERS, CODEOWNERS, or docs/CODEOWNERS need a direct owner check.
Paste, drop, or browse for the base-branch CODEOWNERS file. The badge above the field shows active rules, ownerless overrides, and skipped lines.
Paste, drop, or browse for Changed files. Plain path lists, git status --short, git diff --name-status, tab-delimited rename rows, and simple changed-file exports are normalized.
Open Advanced only when generated, vendored, or snapshot files should be excluded through Ignored path patterns. Review this carefully because ignored files are removed before the denominator is calculated.
Read Coverage Gate Metrics first, then use Path Owner Ledger and Owner Remediation Queue to see which paths or rules need attention.

If the warning area says Changed files are required or At least one usable CODEOWNERS rule is required, restore the missing input before using the percentage or chart.

Advanced Tips:

Use a base-branch diff when the result will support a pull request decision. CODEOWNERS review routing depends on the ownership file from the branch receiving the merge, so a feature-branch-only copy can give a false sense of coverage.
Set Protected path prefixes to the parts of the repository where broad fallback review is not enough, such as infrastructure, migrations, deployment workflows, release automation, or security-sensitive configuration.
Keep Ignored path patterns narrow. Excluding generated files can make a review clearer, but excluding too broadly removes paths from the coverage denominator and can hide ownership gaps.
Check Direct owner coverage whenever a repository uses a broad * rule. The owner-assigned percentage can meet the target while still routing important paths through a general team.
Use the Owner Coverage by Group chart after the tables when a pull request touches many folders. Clusters of owner gaps usually point to a missing directory rule rather than isolated file mistakes.

Interpreting Results:

The headline percentage is Owner-assigned coverage: checked changed files with an owner-bearing winning rule divided by all checked changed files. The owner gate clear badge appears only when there is at least one checked file, the target is met, no owner remediation is queued, and no CODEOWNERS syntax was skipped.

Direct owner coverage is stricter because it ignores the catch-all * rule. A high owner-assigned percentage with low direct owner coverage means the pull request is leaning on a broad fallback reviewer instead of path-specific ownership.

Missing owner means no usable rule matched the changed path.
Ownerless override means the winning rule matched but listed no owner.
Baseline only means a protected path matched only the catch-all rule.
Skipped line means a CODEOWNERS rule used syntax this check rejects, such as negation or bracket ranges.
Ignored files should be reviewed whenever the count is nonzero because they no longer contribute to coverage.

Do not treat a green percentage as proof that owners exist, teams are visible, or branch protection will require their approval. Verify the listed owners and repository rules when the result will support a merge decision.

Technical Details:

CODEOWNERS matching is ordered path matching. Each usable rule starts with a pattern and then lists zero or more owners. When several rules match the same changed path, the last matching rule wins, so a broad fallback can be replaced by a later, narrower rule.

GitHub evaluates CODEOWNERS paths case-sensitively and skips lines that contain invalid CODEOWNERS syntax. The local check follows the same high-risk boundaries for negation and bracket ranges, strips inline comments that begin after whitespace, and treats a rule with a pattern but no owners as an ownerless override rather than owner-assigned coverage.

Formula Core

Two percentages describe different levels of ownership confidence. Owner-assigned coverage answers whether a winning rule listed at least one owner. Direct owner coverage answers whether the owner came from a rule other than the catch-all fallback. Both percentages are displayed to one decimal place.

Owner-assigned coverage = \frac{Changed files with an owner-bearing winning rule}{Checked changed files} \times 100

Direct owner coverage = \frac{Changed files with a non-catch-all owner rule}{Checked changed files} \times 100

For a seven-file pull request, six owner-bearing winning rules produce 85.7% owner-assigned coverage. If only four of those seven files have a non-catch-all owner, direct owner coverage is 57.1%, which points to fallback ownership even though most paths technically have an owner.

Rule Core

CODEOWNERS matching classifications
Condition	Shown outcome	Recommended reading
No usable rule matches the changed path.	Missing owner	Add a CODEOWNERS rule or route the pull request to explicit maintainers.
The winning rule matches but has no owners.	Ownerless override	Confirm the exception is intentional; protected paths should receive a specific owner.
The winning rule is `*` and the path is not protected.	Catch-all owner	Request the fallback owner and consider a narrower rule if the path recurs.
The winning rule is `*` and the path matches a protected prefix.	Baseline only	Add a scoped owner rule before treating that path as covered.
The winning rule has owners and is not the catch-all rule.	Covered	Use the listed owner or team as the review routing evidence.

Changed-file input is normalized before matching. Rename rows use the new path because that is the file path that will exist after merge. Duplicate paths are counted once, and Ignored path patterns are applied before coverage metrics, the ledger, the remediation queue, the chart, and JSON are built.

CODEOWNERS analyzer inputs and outputs
Item	Accepted or reported form	Use in the result
`CODEOWNERS file`	Rules, owners, ownerless overrides, comments, and skipped syntax.	Provides the ordered rule set checked against each changed path.
`Changed files`	Plain paths, short status rows, name-status rows, rename rows, and simple changed-file exports.	Defines the review surface and coverage denominator.
`Protected path prefixes`	Comma- or newline-separated prefixes.	Marks paths where a catch-all owner is reported as `Baseline only`.
`Coverage Gate Metrics`	Coverage, target, active rules, owner gaps, and ignored-file counts.	Summarizes whether the configured owner gate is clear.
`Owner Coverage by Group`	Specific owner, catch-all owner, protected catch-all, and owner gap counts by path group.	Shows where ownership weakness clusters across a broad pull request.

The result is deterministic for the supplied ownership text, changed-file list, protected prefixes, self-owner setting, ignored patterns, and target percentage. The check does not contact the repository host to verify users, teams, write access, branch protection, rulesets, file-size acceptance, or actual review approvals.

Privacy and Accuracy Notes:

The CODEOWNERS text and changed-file list are analyzed in the browser. File browsing and drag-and-drop read local text files into the form, with a 1 MB limit per selected source file.

Use the CODEOWNERS content from the pull request base branch when the result will be used as merge evidence.
Check skipped syntax directly in the repository host if the affected rule is important to the review.
Confirm owner visibility, write access, and required code-owner review separately in repository settings.

Worked Examples:

Platform pull request below target

A pull request changes seven files, including .github/CODEOWNERS, db/migrations/20260501.sql, infra/main.tf, README.md, and apps/github/experimental.js. The ownership file has direct rules for /.github/, /db/, /src/frontend/, and /infra/, plus an ownerless /apps/github exception. Coverage Gate Metrics shows Owner-assigned coverage at 85.7% against a 95% target, and Owner Remediation Queue lists the ownerless exception and target shortfall.

Infrastructure file covered only by fallback

A repository has * @org/platform and *.js @org/js-reviewers, while Protected path prefixes includes infra/. A review changes infra/main.tf and src/deploy.js. The owner-assigned percentage can look complete, but Path Owner Ledger marks infra/main.tf as Baseline only. The fix is to add a scoped /infra/ owner rule before treating the protected path as covered.

Skipped syntax before review

A draft ownership file includes !generated/ to exclude generated files and /packages/[ab]/ @org/pkg for a character range. The warning area reports those lines as skipped, and the remediation queue includes syntax rows. Replace the unsupported rules, or place intentionally excluded generated paths in Ignored path patterns so the changed-file denominator matches the review decision.

FAQ:

Which CODEOWNERS file should I use?

Use the CODEOWNERS content from the pull request base branch. That is the ownership text used for review requests against the branch receiving the merge.

Why did a file with an owner still appear in the remediation queue?

A file can have an owner-bearing rule and still be weakly covered. Protected paths that match only *, ownerless overrides, CODEOWNERS self-owner gaps, and skipped syntax all create remediation rows.

Can I paste Git output instead of a clean path list?

Yes. Changed files accepts one path per line, git status --short, git diff --name-status, tab-delimited rename rows, and simple changed-file exports. Rename rows use the new path.

Why does the tool reject some CODEOWNERS lines?

Negation patterns and bracket character ranges are skipped because CODEOWNERS does not support those gitignore features. Fix those rules or handle intentional exclusions with Ignored path patterns.

Why are there no checked files?

The changed-file field may be empty, the pasted rows may not contain paths, or Ignored path patterns may have excluded every parsed path. Restore the changed paths or narrow the ignore pattern.

Glossary:

Winning rule: The last usable CODEOWNERS pattern that matches a changed path.
Owner-assigned coverage: The percentage of checked changed files whose winning rule lists at least one owner.
Direct owner coverage: The percentage of checked changed files whose owner-bearing winning rule is not the catch-all rule.
Ownerless override: A matching ownership rule with no owners listed.
Protected prefix: A path prefix where catch-all ownership is treated as too broad for the review.
Catch-all rule: A broad * rule that can match any changed path not replaced by a later rule.

References:

About code owners, GitHub Docs.
gitignore documentation, Git project documentation.
How to review changes against a base branch with Codex, simplified.guide.
How to review uncommitted changes with Codex, simplified.guide.