How to Set Up CODEOWNERS in GitHub for Automatic Review Requests
As a codebase grows, nobody knows who should review what. Pull requests sit waiting for the right reviewer, or get approved by someone who does not know the area. GitHub's CODEOWNERS file solves this by mapping paths in the repository to the people or teams responsible for them, and automatically requesting their review when those paths change.
This guide walks through where the file lives, how patterns work, how to assign teams instead of individuals, and how to require code owner approval before merging. It is useful for engineering leads setting up ownership and for PMs who want to understand why some changes take longer to land than others.
Working in GitHub? Turn your spec into dependency-ordered tickets.
Paste the feature or spec. Vantage pulls out the requirements and breaks them into tickets, ordered by what blocks what, ready to groom with your team.
How this works
- We save what you typed. No AI runs on this page.
- You create a free account.
- Vantage builds a PRD and dependency-ordered tickets from it inside your own workspace.
Why ask for an account? We’re a small team, and a full generation runs a multi-step AI pipeline that costs us real money. So we tie it to a free account instead of running it anonymously. You also get to keep the result and edit it.
Your text is only used to create your project, and it stays private to your account. If you don’t sign up, we delete it after 7 days. Privacy policy
Step-by-step guide
Decide on ownership boundaries
Before writing the file, decide how ownership maps to your code. Common boundaries are services, packages in a monorepo, or layers such as frontend, API, and infrastructure. Ownership should follow the teams that will be paged or held accountable when something breaks.
- List the major directories or packages in the repository
- Assign each to the team that maintains it
- Identify shared files, such as CI config, that need a separate owner
Create the CODEOWNERS file
Create a file named CODEOWNERS in the repository's .github directory, the root, or the docs directory. GitHub looks in those locations. The file must exist on the base branch of pull requests for review requests to work, so merge it into your default branch first.
Write ownership patterns
Each line has a file pattern followed by one or more owners. Patterns use syntax similar to .gitignore. Order matters: when multiple patterns match a file, the last matching line wins. Put broad defaults at the top and more specific paths below.
- Start with a default owner: * @your-org/eng-leads
- Add directory rules: /apps/web/ @your-org/frontend
- Add file-type rules where useful: *.sql @your-org/data
- Place the most specific rules at the bottom
Use teams, not individuals
Owners can be users or teams in the form @org/team-name. Teams are almost always better: ownership survives vacations and people changing roles, and GitHub can distribute review requests within a team. The team needs write access to the repository for ownership to apply.
Require code owner review
CODEOWNERS on its own requests reviews but does not enforce them. To require approval from a code owner before merging, enable the 'Require review from Code Owners' setting in a branch protection rule or ruleset for your default branch. Pair it with a required number of approvals.
- Open the repository settings and go to branch protection rules or rulesets
- Target your default branch
- Enable required pull request reviews
- Enable the requirement for review from code owners
Check for errors in the file
GitHub shows errors in the CODEOWNERS file when you view it on GitHub, such as unknown users or teams without access. Check the file after every change. An invalid owner means files may end up with no effective owner.
Review ownership quarterly
Teams reorganize and directories move. Review CODEOWNERS each quarter alongside team changes, and treat it like any other code: changes go through a pull request reviewed by engineering leads.
Common mistakes
Wrong pattern order
Because the last matching pattern wins, a broad rule placed at the bottom overrides every specific rule above it. Put general rules first.
Assigning individuals to large areas
When a single person owns a whole service, every PR touching it waits on that person. Assign a team so reviews can be shared.
Owners without write access
Users or teams without write access are not valid code owners. GitHub flags this, but only if someone looks at the file.
Tips
Make the CODEOWNERS file itself owned by engineering leads so ownership changes get reviewed.
Use team review assignment settings to spread review load across team members.
Keep a default owner at the top so no file is left without a reviewer.
Mention code ownership in onboarding so new engineers know who to ask about each area.
How Vantage helps
CODEOWNERS tells you who owns which parts of the code. When Vantage generates tickets from a PRD, PMs can query the codebase through the GitHub integration to see which areas a requirement touches, which makes it easier to anticipate which teams need to review the work before the tickets reach Linear or Jira.