Safeguard
Developer Tools•

CODEOWNERS for bot opened pull requests: route fixes to owners

How to use a CODEOWNERS file so automated fix pull requests reach the team that owns the code, with pattern order, branch rules and common mistakes.

Safeguard Security Team
3 min read

A CODEOWNERS file makes sure an automated fix pull request is reviewed by the team that owns the changed files. Put the file on the base branch, list owners per path, and turn on required code owner review in branch protection. Without that last setting, owners are only asked, not required.

The problem it solves

Automated fixes often land in a central security queue. The people in that queue do not know whether upgrading a library will break the billing service. The people who own billing do. CODEOWNERS sends the PR to them.

How GitHub applies the file

According to GitHub's documentation, owners named in the file are automatically requested for review when a pull request modifies files they own. They are not requested while the PR is a draft. Owners must have write access to the repository.

The file can live in .github/, the repository root or docs/, and GitHub uses the first one it finds in that order. Each file applies to one branch, and for review requests to fire it must exist on the pull request's base branch.

Write the file for dependency changes

Fix PRs mostly touch manifests and lockfiles. A rule for src/billing/ does not cover package.json in the root. Decide who owns the root manifests and lockfiles, and add those paths explicitly.

# Default owner for everything
*                      @example-org/platform

# Service specific manifests
/services/billing/     @example-org/billing
/services/search/      @example-org/search

# Root dependency files
/package.json          @example-org/platform
/package-lock.json     @example-org/platform

# Protect the file itself
/.github/CODEOWNERS    @example-org/security

Patterns are evaluated in order and the last matching pattern wins. Put broad defaults first and specific overrides below. GitHub says patterns mostly follow gitignore rules, but negation with an exclamation mark and character ranges do not work.

Make it binding

Enable "Require review from Code Owners" in a branch protection rule. Then a pull request touching owned code needs approval from an owner before merging. If a line lists several owners, approval from any one of them satisfies it. Assign an owner to the CODEOWNERS file itself so it cannot be quietly rewritten.

Pair this with the "approval of the most recent push" option so a bot cannot push a new commit after the owner approved. Details are in approval tiers for automated fix PRs.

Common mistakes

  • Owners without write access. The request is silently useless.
  • A giant team as default owner. Everyone is responsible, so nobody reads the PR.
  • Monorepo lockfile at the root. A single lockfile touches every service, so every fix PR needs the platform team. Consider whether that is acceptable, or split lockfiles by workspace. See how to secure a monorepo without slowing every team down.
  • Stale teams. A renamed or deleted team breaks the rule. Review the file when org structure changes.

Quick check

Does CODEOWNERS block merging by itself?

No. It requests reviewers. To block merging until an owner approves, enable required code owner review in branch protection or a ruleset.

Where should the file go?

In .github/, the repository root or docs/ on the base branch of the pull request. GitHub uses the first location it finds.

Safeguard's fix PRs are ordinary pull requests, so your existing ownership rules apply to them.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.