A CODEOWNERS file can look right and still assign nobody. The usual causes are pattern order, owners split across lines, owners without write access, unsupported gitignore syntax, and a file over the size limit. Each one fails quietly, so test the file after you edit it.
Last matching pattern wins
GitHub's documentation says "the last matching pattern takes the most precedence". Put the general rule first and specific rules below it.
* @org/engineering
/auth/ @org/security
/auth/docs/ @org/docs
Reverse those and the catch all line would own everything, including the auth folder. A common slip is adding a new broad pattern at the bottom of the file.
Owners must share one line
Owners for the same pattern must be on one line. If you split them across lines, the pattern matches only the last owner listed. Write /scripts/ @alice @bob, not two lines.
When there are multiple owners, approval from any one satisfies the requirement, not all of them. If you need two different teams to sign off, CODEOWNERS alone does not express that.
Owners need write access
Owners must have write access. Teams must be visible and have write access, even if their members already have it another way. Users or teams that do not exist or lack access are not assigned, and the line is effectively ignored.
Syntax that does not work
Not everything from gitignore carries over. The documentation lists three that fail: escaping a leading hash, negating a pattern with an exclamation mark, and character ranges in square brackets. Invalid lines are skipped silently.
Paths are case sensitive, even on case insensitive systems such as macOS. A pattern for /Docs/ will not match /docs/.
One more gotcha: docs/* matches direct children of docs only, not deeper files. Use docs/ to cover the whole tree.
An empty owner is a decision
If a more specific pattern lists no owner, files there have no owner, and anyone with write access can approve changes. That can be intended for a docs folder, but is easy to do by accident.
Which file is read
GitHub looks in .github/, the root, then docs/, and uses the first one it finds. Each file applies to one branch, and review requests use the file on the pull request's base branch.
Size and drafts
The file must be under 3 MB. Over that and it is not loaded at all. Owners are also not requested on draft pull requests, only once they are marked ready.
Does it block merges
Not on its own. Enable "Require review from Code Owners" in a branch protection rule or ruleset. See how to require code owner review.
A free scan of your dependencies is available at gold.safeguard.sh/scan.
Quick check
Why did my team not get a review request?
Likely causes: the team lacks write access, a later pattern overrides yours, the pull request is a draft, or the file is on a different base branch than you edited.
Sources
Last reviewed: 19 October 2026.
