Where does the CODEOWNERS file go?

GitHub looks for it in the repository root, in the .github directory, or in the docs directory. Most teams use .github/CODEOWNERS. Only one location is used, with .github taking priority if several exist.

How does matching work when patterns overlap?

CODEOWNERS uses last-match-wins. GitHub reads the file top to bottom and the final matching line decides the owners for a file, so place broad catch-all rules first and the most specific rules last.

What owner formats are valid?

Owners must be a GitHub username like @alice, a team like @org/team-name, or an email address that belongs to a repository member. Plain names without an @ or a team without the org prefix are invalid and silently ignored.

Do code owners become required reviewers?

Only if you enable the require review from Code Owners branch protection rule. Without that setting CODEOWNERS still auto-requests reviews from the matching owners but does not block merging.

Is anything uploaded by this tool?

No. The CODEOWNERS file is built entirely in your browser from the rules you enter, so you can safely use it for private repositories without sending data anywhere.

What is the CODEOWNERS File Builder?

Map file path patterns to GitHub users and teams and generate a valid CODEOWNERS file that auto-assigns the right reviewers on every pull request, with validation for the @owner syntax, last-match-wins ordering, and a default catch-all rule. It runs free in your browser on Gera Tools, with nothing uploaded.

CODEOWNERS File Builder

Name: CODEOWNERS File Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

A CODEOWNERS file tells GitHub which people or teams should automatically review changes to specific parts of a repository. This builder maps path patterns to owners, validates the @owner syntax, and emits a correctly ordered file that auto-requests the right reviewers on every pull request.

How it works

CODEOWNERS uses gitignore-style path patterns followed by one or more owners:

Each line is pattern @owner1 @owner2, where owners are GitHub usernames (@alice), teams (@org/team), or member emails.
GitHub evaluates rules top to bottom and applies last-match-wins — the final matching line decides ownership — so general rules go first and specific ones last.
A * pattern acts as a default catch-all so no file is left without a reviewer.

The tool warns when an owner is missing its @, when a team has no org/ prefix, or when a rule has no owners at all.

Pattern syntax quick reference

Pattern	What it matches
`*`	Every file in the repository
`/src/`	All files under the `src` directory
`*.ts`	Every TypeScript file anywhere
`/infra/*/.tf`	Any Terraform file under `infra/`
`docs/`	All files in the `docs` directory

Example CODEOWNERS file

# Default catch-all — every unmatched file goes to the infra team
*                         @myorg/platform

# Backend API owned by the server team
/src/api/                 @myorg/backend @alice

# Frontend components — two specific engineers
/src/components/          @bob @carol

# All Terraform files need an infrastructure review
**/*.tf                   @myorg/infrastructure

# Security-sensitive files: require security and a senior lead
/src/auth/                @myorg/security @alice

Rules are evaluated top to bottom, so a file at /src/api/auth/token.ts matches both /src/api/ and /src/auth/ — but the last matching rule (/src/auth/) wins.

Tips and notes

Put the broad * default at the top and narrow rules below it so specificity wins.
Directory patterns should end with / to match everything inside, e.g. /src/api/.
Teams must be written as @org/team-name and the team must have write access to the repo.
Enable the “Require review from Code Owners” branch-protection rule to make owners’ approval mandatory before merging.
GitHub supports CODEOWNERS in three locations: the repository root, .github/, or docs/. Most teams use .github/CODEOWNERS.
Adding a new code owner does not retroactively open review requests on existing open PRs — it applies to new pushes only.

Common CODEOWNERS patterns

Requiring a security review on sensitive paths:

/src/auth/        @org/security-team
/.env.example     @org/security-team
/infra/           @org/infrastructure @org/security-team

Splitting ownership by technology:

*.go              @org/backend
*.ts *.tsx        @org/frontend
*.tf              @org/infrastructure
*.yml *.yaml      @org/devops

Shared core packages that many teams depend on:

/packages/core/   @alice @bob @carol   # senior engineers only

When to set this up

CODEOWNERS pays for itself the first time a security-critical file changes without the right person being notified. Set it up early, when it is easy to reason about ownership, rather than retroactively after a missed review causes an incident. If your repository already has hundreds of contributors and thousands of files, start with the highest-risk paths (auth, payments, infra, core packages) and expand from there.