No AI change merges unapproved: 4 points beyond naming code owners
Code owners on GitHub only get review requests; to stop AI changes, also require approval and restrict admins.
Key points
- Code owners get just a review request
- Require approval via branch protection
- Separate AI account; restrict admins too
- Verify: check who approved recent merges
Contents
Naming a code owner only sends a review request
From the sources
CODEOWNERS is a file that says who reviews which files. It sits in each repository on GitHub, the service where your code is stored and where changes to it are proposed.
A&A perspective
On GitHub, a proposed change to the code is called a pull request, and bringing that change into the main code is called a merge. This article uses those two words throughout; when your developers say "PR", they mean the same thing.
From the sources
According to GitHub's documentation, the code owners listed in CODEOWNERS are automatically asked to review whenever someone opens a pull request that changes code they own.
From the sources
Making a merge impossible without the owner's approval is a different setting. The documentation says an administrator first turns on required reviews, and can then choose whether to also require approval from a code owner.
Hypothetical example
Take a hypothetical company with four employees. The owner asks Claude Code to fix things and has it open pull requests, and an outside development contractor opens pull requests on the same repository. In CODEOWNERS, the contractor's lead is listed as the owner of the payments folder.
Hypothetical example
At this company, the contractor's lead does receive review requests. But because the lead was only listed as an owner, a pull request opened while the lead is on holiday can still be merged without waiting for that approval.
From the sources
How the owners are written can also send requests to the wrong person. According to the documentation, when one file matches several lines, the owners on the last matching line are the ones chosen. A person or team without permission to change the repository's code (write access) does not become an owner, even if listed.
A&A perspective
Automate & Augment (A&A), which writes this article, sees listing an owner as choosing an addressee. Choosing an addressee does not create a rule that anyone must wait for a reply. And if the contractor lead's account has no write access, the lead does not even get the request.
Required approval is a separate branch protection setting
From the sources
Requiring the owner's approval is a separate setting called branch protection. On GitHub, the line of code that pull requests merge into is called a branch, and branch protection is the set of protection settings you choose for each branch.
From the sources
According to the documentation, when this setting requires code owner review, a pull request that touches owned code cannot be merged until that owner approves it.
From the sources
You can build the same thing with rulesets. A ruleset is a named list of rules applied to a repository.
From the sources
According to the documentation, rulesets and branch protection rules can both protect branches; they work alongside each other, and all applicable rules are enforced. Only one branch protection rule applies to a branch, while several rulesets can apply at the same time.
A&A perspective
If you are trying this on one repository first, A&A thinks either one on its own is enough. In both, when a file has several owners, approval from any one of them is sufficient.
From the sources
There is a plan condition too. According to the documentation, using branch protection and CODEOWNERS on private repositories requires a paid plan. On the free plan, they work only on public repositories.
From the sources
You can also choose what happens when changes are added after an approval. One setting blocks the merge until someone other than the person who pushed the latest change approves it again.
A&A perspective
A&A thinks the gap between the owners file and the protection settings is where people most easily assume that writing a name stops a change. The owners file starts delivering requests the day you add it, so the system looks like it is working. Whether anything actually blocks a merge only shows on the settings screen.
Hypothetical example
At the hypothetical company, requiring code owner approval on the target branch means only pull requests that touch the payments folder wait for the contractor's lead. A pull request that fixes wording in a part with no owner listed does not wait for the lead.
A&A perspective
If you run private repositories on the free plan, A&A thinks the place to start is checking the plan, before any setting.
| Setup | When a pull request opens | Can it merge without approval? |
|---|---|---|
| Code owners listed only | The code owner gets a review request | Yes |
| Approval required (AI on the owner's account) | Waits for the code owner's approval | Yes: the owner can merge as an admin |
| AI on a separate account, admins restricted too | Waits for the code owner's approval | No, admins included |
Run AI under its own account and restrict admins too
A&A perspective
Have AI open pull requests from an account separate from the owner's, with write access only, and restrict admins too. A&A suggests this because of how admins are treated by default and the gap left when AI runs on the owner's account.
From the sources
According to the documentation, by default the restrictions in branch protection do not apply to repository admins. An option in the protection settings applies the same restrictions to admins, shown on screen as Do not allow bypassing the above settings.
From the sources
Under GitHub's rules, the author of a pull request cannot approve it, and administrators can merge without an approval.
Hypothetical example
Suppose the owner has Claude Code open pull requests while signed in to the owner's own GitHub account. The pull requests appear under the owner's name, and the owner is an admin of the repository.
A&A perspective
A&A reads this setup as leaving a path for changes to go in with nobody's approval, even when approval is required. The owner cannot approve pull requests under the owner's own name, but as an admin can merge without approval, so if Claude Code carries on to the merge with the owner's permissions, nothing stops it.
From the sources
According to the documentation, requiring one approval usually means two people are involved: the one who wrote the change and the one who approved it. GitHub writes that this assumption does not hold when Copilot, GitHub's own AI, opens a pull request under its own identity instead of on behalf of a person. So rulesets have an option that adds one approval, only for those pull requests.
From the sources
It is on by default, but it is still in public preview, and GitHub says it may change.
A&A perspective
This option has no effect on Claude Code's pull requests. Even so, A&A thinks the same holds for Claude Code: when AI opens the pull request, one approval does not mean two people checked it.
A&A perspective
So A&A suggests setting up one account just for AI and having Claude Code open pull requests from it. Also turn on the option that restricts admins, and the path for the owner to merge with admin rights and nobody's approval is closed.
A&A perspective
Even with a separate account, if the person who asked AI for the work approves it, only one person has checked it. So A&A suggests that someone other than the person who asked does the approving, such as, at the hypothetical company, the contractor's lead listed as owner of the payments folder.
A&A perspective
The trade-off is that changes the owner makes also wait for someone's approval. Whether a separate account raises your bill is something to check on GitHub's pricing page, against the terms of your plan.
Check it works by looking at who approved recent merges
A&A perspective
To tell whether the settings work, look at the settings screen alongside who approved the pull requests merged recently. The settings screen alone will not show you changes an admin merged without approval. There are four things to check.
A&A perspective
Owner assignment: in the owners file, look at the last line that matches. If it is wrong, requests go to the wrong person.
A&A perspective
Required approval: look at the protection settings or rulesets for the target branch. If it is missing, pull requests can merge without the owner's approval.
A&A perspective
Limits on admins: look at the Do not allow bypassing the above settings option and the permissions of the account AI uses. If they are missing, changes go in with the owner's rights and no approval.
A&A perspective
Approvers of merged pull requests: look at who approved the pull requests merged recently. If you skip this, you will not notice a gap in the settings.
A&A perspective
The check A&A recommends is to open a few recently merged pull requests and see who approved each one, and whether any went in without approval. After you change the settings, look again the same way.
From the sources
The documentation says that to fully protect against unauthorized changes, you also need to name an owner for the CODEOWNERS file itself.
A&A perspective
Since AI or a contractor can open a pull request that edits this file, A&A thinks the file itself should be covered by approval too, so that a pull request changing the owners' names cannot pass without approval.
A&A perspective
You do not have to check every repository at once. Start with the one where AI opens pull requests most often, and go one at a time. Rather than lining everything up at once, cover the parts that touch payments or customer data first.
A&A perspective
Which changes stop for whose approval is decided together with your view of how far you can trust AI today. A&A watches what AI can do in its own daily operations. From that position it draws the line between people and AI, and the same people who draw the line take on the settings, helping owners with this decision.
Summary
A&A perspective
The owners file only delivers review requests; it does not stop merges without approval.
A&A perspective
Required approval is a separate setting, in branch protection or a ruleset. On private repositories it assumes a paid plan.
A&A perspective
Running AI on the owner's admin account leaves a path to merge without approval. Running AI on a separate account and restricting admins too closes that path.
A&A perspective
Check that it works by looking at who approved recently merged pull requests.
The owners file only chooses who gets asked; it does not stop merges without approval. To keep AI changes from merging unapproved, turn on required approval, run AI under an account separate from the owner's, restrict admins too, and check who approved the pull requests merged recently.
FAQ
I run the company alone. What if there is no one to approve?
Required approval may not fit. Even with AI on its own account, only you can approve its pull requests, so just one person checks. You cannot approve your own, so restricting admins stops your changes too. A&A thinks reviewing after merging and reverting fits better. Deciding by whether it can be undone is covered in "Letting AI take action: decide by whether you can undo it, not the amount".
If I list several owners, do all of them have to approve?
No. According to the documentation, when code owner approval is required and a file has several owners, approval from any one of them is enough. Also, if you put the owners on separate lines instead of the same line, only the owner on the last matching line counts.
Can I require approval on the free plan?
Yes, on public repositories. According to the documentation, using branch protection and CODEOWNERS on private repositories requires a paid plan.
Sources & editorial note
Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.
- About code owners
GitHub Docs · Publication date not stated on page
Accessed 2026-10-21 - About protected branches
GitHub Docs · Publication date not stated on page
Accessed 2026-10-21 - Approving a pull request with required reviews
GitHub Docs · Publication date not stated on page
Accessed 2026-10-21 - Available rules for rulesets
GitHub Docs · Publication date not stated on page
Accessed 2026-10-21 - About rulesets
GitHub Docs · Publication date not stated on page
Accessed 2026-10-21