CODEOWNERS: Who Gets a Review Request and What Blocks a Merge

A CODEOWNERS file identifies the people or teams responsible for parts of a repository. GitHub can use those assignments to request reviews automatically. Requiring code-owner approval before a pull request can merge is a separate, optional rule.

For maintainers designing bug-report forms, that separation suggests a useful first question: Was the reporter expecting an owner assignment, a review request, or a merge requirement? These outcomes are related, but GitHub documents them as distinct responsibilities.

The three responsibilities

The practical conclusion is narrow but important: receiving an automatic review request does not, by itself, make that review a condition of merging. GitHub describes required code-owner approval as an additional option that an administrator or owner can enable when required reviews are configured.

What CODEOWNERS defines

A CODEOWNERS file associates path patterns with GitHub users or teams. Those entries express responsibility for matching repository content and give GitHub ownership information it can use to request reviews.

Ownership is branch-specific. Each CODEOWNERS file assigns owners for one branch, so a repository can define different owners on different branches (About code owners).

Being named in the file is not enough to establish a valid assignment:

• An individual code owner must have write permission for the repository.
• A code-owner team must be visible and have write permission.
• A nonexistent user or team, or one with insufficient access, is not assigned as a code owner.

These eligibility conditions are part of GitHub’s documented CODEOWNERS behavior (About code owners). Consequently, seeing the expected username or team in the file does not establish that the assignment is effective. Permissions and team visibility are useful facts for an intake form to collect.

The base branch supplies the applicable file

For automatic requests, GitHub uses the CODEOWNERS file from the pull request’s base branch. The base branch is the branch that would receive the changes if the pull request were merged (About code owners).

Suppose main assigns /docs/ to one team while release-v2 assigns it to another. For a pull request targeting release-v2, the ownership information on release-v2 applies—not the version on main or the contributor’s head branch.

The same principle applies to forks. If the base branch is in the upstream repository, GitHub uses the CODEOWNERS file from that upstream branch. If the base branch is in a fork, GitHub uses the file from that branch in the fork; review requests are triggered only if the code owners have been added specifically to that fork (About code owners).

A report that omits the base branch may therefore send maintainers to inspect the wrong file.

Draft pull requests are an explicit exception

GitHub does not automatically request code-owner reviews on draft pull requests. When a draft is marked ready for review, GitHub says code owners are automatically notified (About code owners).

An absent request on a draft is therefore not sufficient evidence of a broken configuration. Intake wording should ask whether the pull request was still a draft or had been marked ready for review.

Notification claims should also remain precise. The documentation supports saying that GitHub requested a review or notified code owners. It does not establish that every team member received, noticed, or acted on a notification.

Required approval is separately configured

When required reviews are enabled, an administrator or owner can optionally require approval from a code owner before a pull request can merge. For classic branch protection, GitHub names the option Require review from Code Owners (About code owners).

GitHub also documents rulesets as an alternative to classic branch-protection rules. The supplied documentation does not establish a complete model for how every ruleset, branch-protection setting, repository plan, organization policy, fork, or overlapping ownership pattern interacts.

General review decisions should not be confused with the code-owner requirement. Reviewers can comment, approve, or request changes (Pull request reviews). A request for changes is informational unless a ruleset or classic branch-protection rule has the “require a pull request” option configured. Under that condition, a request for changes from a collaborator with admin, owner, or write access prevents merging until the same collaborator submits an approving review (Approving a pull request with required reviews).

A concise CODEOWNERS intake form

Start by making the expected outcome explicit:

Expected CODEOWNERS outcome: Choose one—owner assignment, automatic review request, or required code-owner approval before merge.

Then collect the facts needed to evaluate that expectation:

• Pull request URL and base branch
• Paths changed by the pull request
• Location of the applicable CODEOWNERS file
• Pattern expected to match
• Expected user or team
• Draft or ready-for-review status
• Whether assignment, review request, or required approval was missing
• Whether the user or visible team had write permission
• Whether the relevant required-review rule applied
• Any syntax errors displayed for the file

Two documented file conditions deserve explicit checks. GitHub skips a CODEOWNERS line containing invalid syntax. The file must also be smaller than 3 MB; an oversized file is not loaded, ownership information is not shown, and the appropriate review requests are not generated (About code owners).

This framing turns “CODEOWNERS did not work” into a specific, answerable report without assuming that ownership, review routing, and merge enforcement are the same feature.

Scope: This article explains the supplied GitHub documentation retrieved September 30, 2026. No repository experiment was performed. It does not provide a complete precedence or enforcement model.

Sources and further reading

• https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
• https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews
• https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/approving-a-pull-request-with-required-reviews