GitHub · Pull requests · Code owners · Checked October 26, 2026

GitHub: a pull request waits for a code owner's review

A branch protection rule or a ruleset can require review from code owners. Then a pull request that changes a file with a code owner in the repository's CODEOWNERS file must be approved by one of that file's owners before it can be merged into the protected branch, however many other approvals it has (GitHub's about code owners and about protected branches). Until then GraphQL's reviewDecision for the pull request is REVIEW_REQUIRED ("A review is required before the pull request can be merged"), and the REST mergeable_state is blocked (checked October 26, 2026).

GET  /repos/OWNER/REPO/rules/branches/BRANCH         → rule "pull_request": parameters.require_code_owner_review
GET  /repos/OWNER/REPO/codeowners/errors?ref=BRANCH  → errors[].line, kind, message, path
POST /graphql   pullRequest(number: N) { reviewDecision
                  reviewRequests(first: 100) { nodes { asCodeOwner requestedReviewer { ... on User { login } ... on Team { combinedSlug } } } } }

Who the code owner is

Which file: GitHub looks for CODEOWNERS in .github/, then the repository root, then docs/, and uses the first one it finds.
The base branch: each CODEOWNERS file assigns the owners for its own branch, and a pull request uses the file on its base branch, the branch it would modify when merged. A change to CODEOWNERS inside the pull request is not the version it uses.
The last match: patterns follow most of the rules of gitignore files, and the last matching pattern takes precedence. In GitHub's example, after * @global-owner1 @global-owner2, a line *.js @js-owner makes @js-owner the only owner of JavaScript files.
Several owners: all the owners of one pattern must be on the same line; on separate lines the pattern matches only the last owner mentioned. When code owner review is required, an approval from any one of a file's owners is enough.
No owner: a pattern with no owner after it leaves those paths without one, and changes there can be approved by anyone with write access.

Why the owner was not asked, or does not count

Write access: code owners must have write permission for the repository. A team must be visible and have write permission itself, even if all of its members already have write access directly, through the organization or through another team. A user or team that does not exist or has insufficient access is not assigned as a code owner.
A skipped line: a line with invalid syntax is skipped. Three gitignore rules do not work in CODEOWNERS: escaping a pattern that starts with # with \, negating with !, and character ranges with [ ]. Paths are case sensitive, even on a case-insensitive system such as macOS.
Too large: a CODEOWNERS file over 3 MB is not loaded: no code owners are shown, and none are asked to review.
An email address: an owner can be named by an email address added to their account, but a managed user account cannot be named that way.
A draft: code owners are not automatically asked to review a draft pull request; they are notified when it is marked ready for review (see why a review request is not shown).
A fork: a pull request from a fork into the upstream repository uses the CODEOWNERS file of the upstream base branch. With a base branch in the fork, it uses the fork's file, and asks for reviews only if the code owners have write access to the fork.

The owner approved, and it is still blocked

Approved before a push: with "Dismiss stale pull request approvals when new commits are pushed", a change to the diff dismisses the approval and someone must approve again; with "Require approval of the most recent reviewable push", the last person to push cannot be the one who approves it (see why an approval does not count).
Another pull request on the same commit: even after all required reviewers have approved, collaborators cannot merge if another open pull request has a head branch pointing to the same commit with pending or rejected reviews. Someone with write permissions must approve or dismiss the blocking review there first.
Another rule: code owner review is one requirement among others: required checks (see a required check stuck at "Expected"), a branch that must be up to date, resolved conversations.

What to do

Read the errors: GET /repos/OWNER/REPO/codeowners/errors lists the syntax errors in the CODEOWNERS file (line, column, kind, message, a suggestion), for the branch named in ref or by default the default branch (GitHub's REST reference). Opening the file on GitHub also highlights them.
See a file's owner: browse to the file on the base branch and hover over the shield icon, which names the owner and the CODEOWNERS line.
Give write access: add the user or team to the repository with write permission, and make the team visible.
Protect the file itself: GitHub recommends a CODEOWNERS file in .github/ owned by the repository owner (/.github/CODEOWNERS @owner_username), so the rule cannot change without their review.
Where the rule is: in a ruleset, require_code_owner_review in the pull request rule (available rules for rulesets), which "Get rules for a branch" returns among the active rules for the branch; in a branch protection rule, "Require review from Code Owners".
Admins: by default the restrictions of a branch protection rule do not apply to people with admin permissions or roles with the "bypass branch protections" permission, unless "Do not allow bypassing the above settings" is on.

In IntelliJ IDEA: code owners are not read

How the GitHub support built into IntelliJ IDEA deals with code owner reviews, in its source (checked October 31, 2026; IntelliJ IDEA: pullRequestMergeability.graphql, refUpdateRule.graphql, pullRequestInfo.graphql, GraphQL files, GithubApiRequests.kt):

Not the rule: for the rule on the base branch it asks for the number of required approving reviews, the required status checks, signatures, linear history, force pushes, deletions and whether the account can push, but not requiresCodeOwnerReviews.
Not the owners: none of its 78 GraphQL files asks asCodeOwner, which marks a review request made for a code owner, and its list of REST requests (GithubApiRequests.kt) has none for code owners, so nothing it requests says which reviewer is a code owner.
The decision: it does ask for the pull request's reviewDecision, GitHub's code review status for it (approved, changes requested or review required).

GitHub pull requests in IntelliJ IDEA

Pull Request Inbox for GitHub, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists everyone asked to review and where each one's review stands (approved, changes requested, asked to review, on an earlier commit). When GitHub calls the pull request blocked, its merge checks say the rules of the target branch are not met yet (required reviews or required checks). When GitHub says a review is still required (reviewDecision is REVIEW_REQUIRED), it says so there and names those asked to review as code owners who have not reviewed yet; read with GraphQL, so not without a token, and team names need the organization's read permission. The review inbox, diffs and conversations are free; approving, commenting and merging are Pro (US$1.50 a month, with a 30-day trial).

GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitHub, Inc. or JetBrains.