List teams instead of individuals in CODEOWNERS, and update the file before the person's access ends. GitHub assigns no code owner when a listed user or team lacks write access, so a departed owner can silently remove a review requirement. Check the file, then check branch protection.
What CODEOWNERS does
A CODEOWNERS file defines who is responsible for code in a repository. When a pull request changes files that a pattern covers, GitHub requests review from the owners. Administrators can also turn on "Require review from Code Owners" in branch protection or use rulesets, and approval from any one listed owner satisfies the rule.
Those details, from GitHub's documentation, explain the offboarding risk.
How a departure breaks it
Three documented behaviors combine badly:
- Owners must have write access. If a user or team does not exist or lacks access, no code owner is assigned.
- Invalid lines are skipped, with errors shown in the repository UI and API.
- The file is read from the pull request's base branch, and each branch can have its own.
When a developer leaves and loses access, any pattern that named only them stops assigning anyone. If the rule that requires owner review depends on that pattern, the path is now covered by nobody, and the pull request may merge with weaker review than you intended. No alarm fires.
Steps to hand over review duty
- Search the CODEOWNERS file on every long lived branch for the person's handle or email.
- Replace individuals with a team that has write access. Teams survive staff change because you edit membership, not the file.
- Where a path truly needs two kinds of reviewer, put both owners on the same line. GitHub says only the last mentioned owner applies if you split them across lines.
- Remember that later matching patterns win. A broad pattern at the bottom can override a careful one above it.
- Protect the file. GitHub suggests assigning the repository owner to
/.github/CODEOWNERSor the/.github/directory so the file cannot be changed without review. - Open the repository's CODEOWNERS view and confirm there are no error markers.
- Make a test pull request touching a covered path and confirm the right team is requested.
Design choices that help
| Choice | Benefit |
|---|---|
| Team owners | Membership changes without file edits |
| At least two people per team | One departure does not leave a gap |
| A catch-all owner at the top | Every path has someone, even new ones |
| Owner review required in a ruleset | Missing review blocks the merge |
One caution: a team must be visible and have write access to count, even if its members already have access another way.
Try it yourself
Open the pull request gate demo below and watch how a rule can block a change that lacks the required review.
Click through it at your own pace, or open it full screen.
Quick check
What happens if a code owner has left?
If they no longer have write access, GitHub assigns no code owner for that pattern. Replace them with a team before they go.
Do all owners need to approve?
No. Approval from any one listed owner satisfies the requirement.
Safeguard policies and gates can add rules on pull requests, such as blocking merges with risky dependency changes, alongside review requirements you set in your source host. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
