Auto-Assign Reviewers with the GitHub CODEOWNERS File (2026)

GitHub’s CODEOWNERS file doesn’t assign reviewers; it dictates who will be automatically requested to review a pull request based on the files changed.

Let’s see it in action. Imagine you have a project with distinct areas: frontend, backend, and documentation. You want specific teams to review changes in their respective domains.

Here’s a sample CODEOWNERS file located at the root of your repository:

# This is a comment.
# By default, everyone in the 'web-dev' team reviews any PR.
*       @my-org/web-dev

# But if a PR touches backend files, the 'backend-engineers' team must also review.
/backend/ @my-org/backend-engineers

# Documentation changes should be reviewed by the 'docs' team.
/docs/  @my-org/docs

# Specific critical files require explicit individual reviewers.
.github/workflows/deploy.yml @my-user/deploy-approver

When a developer opens a pull request, GitHub scans the CODEOWNERS file. If a PR modifies a file matching a pattern in CODEOWNERS, the specified owners are automatically added as required reviewers.

For instance:

• A PR changing src/components/Button.js would request reviews from @my-org/web-dev.
• A PR changing backend/api/users.py would request reviews from both @my-org/web-dev (from the * rule) and @my-org/backend-engineers (from the /backend/ rule).
• A PR modifying docs/README.md would request reviews from @my-org/web-dev and @my-org/docs.
• A PR changing .github/workflows/deploy.yml would request reviews from @my-org/web-dev, @my-user/deploy-approver.

The patterns in CODEOWNERS are glob patterns, similar to those used in shell commands. They are evaluated in order from top to bottom, but the most specific match wins. If multiple lines match, the last matching line takes precedence for a given file.

The primary benefit is ensuring that changes are always seen by the right people, reducing the chance of regressions in specific areas and streamlining the review process by eliminating the manual step of selecting reviewers. It’s a declarative way to enforce code ownership and maintain quality.

The order of lines matters, but the last matching pattern for a given file is the one that applies. This means a broad rule like * should typically appear before more specific rules that might override it for certain directories or files.

If you’re using teams, they must be GitHub teams within your organization, denoted by @org-name/team-name. Individual users are specified by their GitHub username, prefixed with @.

When you add a CODEOWNERS file, it doesn’t retroactively apply to existing pull requests. It only affects new pull requests opened after the file is committed to the repository.

The next thing you’ll likely want to explore is how CODEOWNERS interacts with branch protection rules, specifically to enforce that all required reviewers from CODEOWNERS must approve a PR before it can be merged.