CODEOWNERS review coverage: find the effective owner before delegating a PR

Decide who must review the proposed change

Before handing a coding task to an agent, establish who should review its proposed changes and whether the target branch requires that person's approval. A CODEOWNERS file can route review requests, but its presence alone does not establish an enforced review requirement. GitHub documents required code-owner approval as an optional setting alongside required reviews.[1][2]

Use the procedure below before relying on automatic routing in your review plan. It produces an explanation for each changed path: the selected ownership file, the effective rule, eligible owners and the approval requirement that applies to the intended merge actor. This is a planning method derived from GitHub's documentation, not a workflow we tested. It asks for existing authorized read-only evidence, not a test PR or a permission change.

1. Select the ownership map on the PR's base branch

The base branch is the branch the pull request would modify if merged. Identify its repository and branch, then establish the complete proposed changed-path list. Do not substitute the default branch or the agent's head branch. For a fork PR into an upstream repository, GitHub uses the upstream base branch's CODEOWNERS. For a base branch inside the fork, it uses that fork's file, with code owners assigned write access to that fork.[1]

• In that base branch, look for .github/CODEOWNERS first, then CODEOWNERS at the repository root, then docs/CODEOWNERS. Stop at the first existing file. Rules from the other files do not add coverage.[1]
• Keep a reference to the selected file's revision and your observation time. These are proposed recordkeeping choices, so a later change can be distinguished from the map you inspected.
• Check the file's size and highlighted syntax errors. GitHub requires CODEOWNERS to be under 3 MB and does not load an over-limit file. Invalid syntax lines are skipped. Finding a filename is not enough to establish usable coverage.[1]

GitHub's file-ownership tooltip reflects whichever repository and branch you are viewing. Keep that context on the PR's base. A tooltip on another branch does not answer this inspection.[1] If the destination or changed-path list is still unclear, pause the coverage conclusion until the task owner establishes it.

2. Find the last matching rule for every changed path

Preserve each path's exact casing and read the whole selected file. Identify the matching lines, then retain the last valid match. Order determines precedence; a more specific earlier rule does not win over a later broad match. Multiple owners for one pattern must appear on the same line. Repeating a pattern on separate lines does not accumulate its owners.[1]

Check the pattern's actual coverage. In GitHub's examples, docs/* matches direct files such as docs/getting-started.md but not docs/build-app/troubleshooting.md; /docs/ covers the root docs directory and its subdirectories. A later matching line with no owners can leave a subtree without an assigned code owner.[1]

CODEOWNERS is not unrestricted gitignore syntax. Escaping a leading # with a backslash, using ! for negation and using [ ] for character ranges do not work. Paths are case sensitive even if your local file system is not.[1] Record the literal effective pattern and its owner list, including an empty list, rather than replacing it with the team you expected.

3. Establish that the named owner is eligible

GitHub requires users and teams to have explicit write access to the repository. A team must also be visible; its members' individual write access does not substitute for the team's own access. A nonexistent identity or insufficient access means a code owner will not be assigned.[1] A name in the file is therefore an input to this check, not its result.

Use existing authorized access information to establish eligibility. If you cannot see it, ask the responsible maintainer to confirm the team's visibility and explicit repository write access, with a reference to the evidence. Do not infer access from the team's name or create a test PR to find out. Confirm separately that someone is available to review; eligibility is not a staffing commitment.

Include the ownership map itself if the proposed change touches it. GitHub recommends assigning an owner to CODEOWNERS and gives /.github/CODEOWNERS @owner_username as an example.[1] That is a documented recommendation, not proof that this line alone fully secures a repository.

4. Separate requested review from required approval

GitHub automatically requests code-owner review when a non-draft pull request changes owned code. Draft pull requests do not automatically request it; marking one ready for review notifies the owners.[1] These routing behaviors do not establish a required approval. Have the responsible maintainer identify the protection that actually applies to the target branch, rather than inferring it from a requested-review badge.

• Establish the required general approval count and whether Require review from Code Owners is enabled. General required reviews can remain mandatory when owner-specific approval is off.[1][2]
• For a matching rule listing multiple owners, GitHub's documented example allows approval from either owner, not both. Do not extend that example into a claim that one approval always covers separately owned paths or every other merge requirement.[1]
• Identify the intended merge actor and applicable bypass conditions. Branch-protection restrictions exclude repository administrators and custom bypass roles by default; Do not allow bypassing the above settings can apply those restrictions to them too.[2]
• Identify the actual applicable branch protection rule. GitHub says only one can apply at a time, unlike rulesets. Do not infer overlapping-rule precedence or a universal ruleset model from this overview. If rulesets govern the answer, obtain their exact applicable requirements before concluding enforcement.[2]

Keep approval freshness separate from owner identity. Dismiss stale pull request approvals when new commits are pushed can dismiss approvals when changes affect the reviewed diff. Require approval of the most recent reviewable push instead requires approval by someone other than its pusher; it is a distinct optional control.[2] Inspect the actual settings and current review state. An earlier approval does not by itself establish that the current proposed change satisfies them.

A completed hypothetical example: the later broad rule wins

Everything in this example is fictional and unexecuted: the repository, teams, files, permissions and protection settings. Assume a proposed non-draft PR targets an upstream main branch containing both .github/CODEOWNERS and a root CODEOWNERS. GitHub's documented location order selects only .github/CODEOWNERS. An ownership edit on the head branch does not replace that current base-branch map.[1]

Assume every named team is visible and has explicit write access. That is a fictional input, not a permission result. Treat each row below as a separate path-level exercise; this table does not claim one approval satisfies a combined multi-path PR. The outcomes follow the documented matching order, subtree coverage and ownerless-rule behavior.[1]

The result worth catching before delegation is charge.ts: the effective owner is platform, not payments. For generated documentation, the result is a coverage gap if your team intends every changed path to have an owner. That policy decision belongs to the maintainer; an empty owner list does not grant unrestricted merge permission.

The same owner map can support different approval requirements

Continue the fictional example with two alternative branch-protection scenarios. In both, assume required general reviews need one write-access approval, the intended merge actor is a normal writer without bypass, and no other rules affect the illustration. No repository setting or merge outcome was observed. The comparison concerns only the owner-specific part of review.[1][2]

For docs/generated/api.md, neither scenario creates an owner missing from the selected file. The assumed general review requirement remains. Under a proposed policy requiring owner coverage for every changed path, pause that part of the review plan and ask the maintainer to decide the intended owner coverage. This pause is our planning recommendation, not a claim that GitHub universally blocks ownerless files.

5. Write the conclusion you will rely on

Finish the inspection with a short explanation for each path, not a list of team names. For the fictional charge.ts change, a completed conclusion is: On upstream main, .github/CODEOWNERS line 3 makes platform the effective eligible owner under the assumed permissions. Scenario A requests platform review but requires a general write-access review, not platform-specific approval. Scenario B requires platform approval for this path under the stated non-bypass actor assumptions. No merge was attempted.

A real eligibility gap needs an equally clear next action: The selected base-branch rule names the payments team, but its visibility and explicit repository write access have not been established. The responsible maintainer must supply that evidence before the plan treats payments as an eligible code owner. That is a model conclusion for a missing input, not an audit result for any repository.

• Proceed with the proposed owner-review plan only when the ownership and approval assumptions it depends on have evidence. If the plan needs enforced owner approval, requested-only routing does not satisfy it.
• Recheck affected conclusions when the destination, changed paths, ownership file, owner access, protection settings or merge actor changes. Check approval freshness again as the diff evolves.
• Keep this decision bounded. Eligible owner coverage and an approval requirement do not establish code correctness, CI isolation, secret remediation or permission to merge. Those decisions need their own evidence.

Evidence and limits

The two linked GitHub Docs pages were retrieved on 9 October 2026 KST. Their editorial publication and last-update dates were not established, so this resource reports a documentation check rather than an October launch. They are complementary descriptions from one provider, not independent measurements of enforcement.[1][2] The procedure and planning stop conditions are Palanthos recommendations; the example supplies fictional assumptions so readers can complete the reasoning without an account experiment.