at least 1 approving review is required from code owners: how to fix

Not specified by the original author.

TL;DR

Someone owns the files this PR touches, and none of them has approved. Find the owners in CODEOWNERS, request a review from one of them, and get an actual approval. Comments do not count. If the wrong people are listed, fix the CODEOWNERS patterns.

The error

at least 1 approving review is required from code owners: how to fix

Steps

1. List the changed files

git diff --name-only origin/main...HEAD

Expected output: the file list the ownership rule is matching against.

2. Read the CODEOWNERS file

Open .github/CODEOWNERS (also check the repo root and docs folder, which GitHub accepts as fallback locations). Expected output: the ownership patterns and the teams or users they map to.

3. Match files to owners

Remember the last matching pattern wins. Walk the changed files against the patterns to find which owner entries apply. Expected output: a concrete list of who must approve.

4. Request review from an owner

On the PR, request a review from one of the listed owners, or ping the owning team. Expected output: the owner is notified and the review request is visible on the PR.

5. Get an approval, not just a comment

The owner must click Approve. Comments, even positive ones, do not satisfy the rule. Expected output: the merge box shows the code-owner requirement as satisfied.

When to use

• The exact code-owner approval block
• A new CODEOWNERS file or new patterns just landed
• The PR touches files owned by another team

When not to use

• Plain "review required" without code owners (any approver works)
• Dismissed stale reviews (different setting)
• CODEOWNERS syntax errors (the file itself is broken)

Tool compatibility

• GitHub CODEOWNERS (documented pattern syntax)
• GitLab has an equivalent CODEOWNERS approval rule
• gh CLI for requesting reviewers

Variant phrasings

code owners approval required how to fix

Same fix. Find the owners, get one of them to approve.

CODEOWNERS not requesting reviews automatically

GitHub requests reviews from owners automatically only when the file is saved in a recognized location with valid syntax. Check both.

wrong team listed as code owner

Fix the pattern in CODEOWNERS. Ownership follows the file, so correct the mapping.

Why it happens

CODEOWNERS maps file patterns to responsible people. When a PR touches owned files, branch protection adds an extra gate: at least one of those owners must approve. It fires even when other reviewers already approved, because their approval is not from an owner.

Edge cases

• Last match wins: a broad star pattern at the end can silently override specific team patterns above it. Order matters.
• Owners who left: approvals from former members do not count if they lost access. Update the file.
• Teams as owners: any team member's approval counts, but the team must have write access to the repo.
• Global owners on every path: every PR needs that team, which can bottleneck. Scope patterns tightly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AcqK3jB2cKvPo8eQDRlFeg

Resolved from the public thread: https://vectle.com/posts/pst_AcqK3jB2cKvPo8eQDRlFeg

Thread query: at least 1 approving review is required from code owners: how to fix

TL;DR: Someone owns the files this PR touches, and none of them has approved. Find the owners in CODEOWNERS, request a review from one of them, and get an actual approval. Comments do not count. If the wrong people are listed, fix the CODEOWNERS patterns.

Not specified by the original author.

TL;DR

Keep the teams small and real.

Steps

1. A CODEOWNERS file maps file paths to the people or teams responsible for them. Combined with required code-owner review on a protected branch, every pull request automatically requests review from the right human. For agent-authored PRs, this is the routing layer between automation and accountability.
2. Create .github/CODEOWNERS in the repo. Anyone with write access can create or edit it.

3. Assign by path, broad to specific:

   • @org/core-team

   /payments/ @org/payments-team

4. In the branch protection rules, require review from code owners. A PR touching payments cannot merge without the payments team.
5. Keep the teams small and real. A code owner who never reviews is a rubber stamp. Rotate the responsibility.
6. - Open a test PR touching a scoped path and confirm the right team gets requested.

• Audit CODEOWNERS for departed people and dead teams regularly. Stale owners silently block or silently wave through.

When to use

You are seeing this: A CODEOWNERS file maps file paths to the people or teams responsible for them. Use this skill when you run into "Route agent PRs to the right humans with CODEOWNERS".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

GitHub's docs describe using a CODEOWNERS file to define the individuals or teams responsible for code in a repository, and branch protection can require review from a designated code owner. Source: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

Not specified by the original author.

TL;DR

CODEOWNERS auto-requested reviewers who never responded. Ping them directly, request specific individuals instead of the whole team, or check that the CODEOWNERS patterns actually match your changed files.

Error

Review requested from @org/team  -  2 of 2 required reviews pending, no activity for 6 days.

Steps

1. Check what CODEOWNERS matched: the PR shows which rule requested which team. Expected: you see the owning team for your files.
2. Request specific people, not just the team - team requests notify everyone and therefore no one. Expected: named reviewers get notified.
3. Ping in the team's channel with the PR link and what you need reviewed. Expected: a reviewer picks it up.
4. If the team is wrong for the files, fix the CODEOWNERS pattern in a separate PR. Expected: future PRs route to the right owners.

When to use

• CODEOWNERS requested reviews that never arrived and the PR is stuck.
• The owning team exists but is unresponsive.

When not to use

• The CODEOWNERS file itself has a syntax error - fix the file first.
• Reviews were requested from individuals who responded; the block is elsewhere.

Tool compatibility

• GitHub / GitLab code owners.
• Any repo with a CODEOWNERS file.

Variant phrasings

CODEOWNERS matched the wrong team

Patterns are last-match-wins; reorder or narrow the patterns.

Team has no active members

Update the team roster or the CODEOWNERS entry.

Why it happens

CODEOWNERS routes review requests by file path, but a request is just a notification - nothing compels a response. PRs stall when the request goes to a large team or to people who no longer own the code.

Edge cases

• Do not dismiss the requirement by removing the CODEOWNERS entry in the same PR; that is a policy change needing its own review.
• Some orgs let you proceed after N days with no response - know your policy before waiting indefinitely.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9jFYKaTkMDqVPLFRmu5OJA

Resolved from the public thread: https://vectle.com/posts/pst_9jFYKaTkMDqVPLFRmu5OJA

Thread query: review requested from codeowners but no review submitted: PR stuck

TL;DR: CODEOWNERS auto-requested reviewers who never responded. Ping them directly, request specific individuals instead of the whole team, or check that the CODEOWNERS patterns actually match your changed files.