In a GitHub CODEOWNERS file, what can appear as an owner and what access must it have?
answer
- Three shapes of identity
- One needs an organization prefix
- Read access is not enough
- Grant the permission to the team itself
basics
~20 sOwners are GitHub usernames (@octocat), organization teams (@my-org/backend), or a user's email address. Every owner must have write access to the repository, and a team needs that access granted to the team itself, not only to its members.
solid answer
~50 sA CODEOWNERS line is a path pattern followed by one or more owners. An owner is a GitHub username prefixed with `@`, an organization team written as `@org/team-name`, or the email address of a user on the account. Two rules trip people up. First, an owner must have **write** access to the repository — read access is not enough, and an owner without it is silently useless. Second, for a team the write permission must be granted to *the team* on that repository; a team whose members happen to have write access individually still does not qualify. Invalid entries (typos, unknown users, teams from another organization) are not fatal to the file, but GitHub flags them in the CODEOWNERS errors view and no review is requested for those paths. Prefer teams over individuals so ownership survives people changing roles or leaving.
code
text · 4 lines* @my-org/platform
/docs/ @my-org/tech-writers
/infra/ @my-org/sre @my-org/security
/.github/CODEOWNERS @my-org/platformgo deeper
Recall the three owner forms — @username, @org/team, and a user's email — and that the leading @ and the org prefix are not optional. Be able to read a CODEOWNERS line aloud and say who it makes responsible.
Explain the write-access rule precisely, including that a team needs the permission granted to the team on that repository, and that multiple owners on a line are alternatives rather than a joint requirement.
Show that you check the CODEOWNERS errors view after edits and treat invalid entries as an outage of the review control: paths people believe are protected quietly stop requesting anyone.
Argue the policy: teams over individuals so ownership survives reorgs, code review assignment to keep notification load sane, and the ownership file itself owned so changes to accountability are reviewed.
## What an owner entry is A GitHub `CODEOWNERS` file is a plain-text file of lines shaped like `<path-pattern> <owner> [<owner>…]`. Lines starting with `#` are comments. The pattern half uses gitignore-style path matching; the owner half is a whitespace-separated list of identities GitHub will hold responsible for files matching that pattern. GitHub accepts three owner forms: - **A user**: `@octocat` — a GitHub account handle, always with the leading `@`. - **A team**: `@my-org/backend` — an organization team, always fully qualified with the organization that owns the repository. A bare `@backend` is read as a *username*, not a team, and will normally fail to resolve. - **An email address**: `[email protected]` — matched to the user whose account carries that email. This form exists mainly for environments where identities are provisioned externally; it is the least common and the easiest to get wrong. Multiple owners on one line are an OR, not an AND: any one of them being requested and approving satisfies the rule for those files. ## The write-access requirement An owner must have **write** permission on the repository. This is the single most common reason a CODEOWNERS file "does nothing": someone adds a team of stakeholders who only have read access, and GitHub never requests them. For teams there is a sharper version of the rule: the permission must be granted **to the team** on that repository. If every member of `@my-org/security` happens to have write access through some other team or through direct collaborator access, but `@my-org/security` itself has never been added to the repository, the team is not a valid code owner. Fixing it means adding the team to the repository with at least write permission. Teams must also belong to the organization that owns the repository. You cannot name a team from a different organization, and a personal (user-owned) repository has no teams at all, so only usernames and emails work there. ## Why teams beat individuals Naming individuals is tempting and almost always regretted. A username in CODEOWNERS is a single point of failure: that person goes on holiday, changes teams, or leaves, and every pull request touching their paths stalls or is merged by bypass. A team entry keeps working through personnel changes because membership is managed in one place, and it makes ownership legible — a reader of the file learns which *group* is accountable, which is the point of the file. Teams also unlock **code review assignment**: a team can be configured so that instead of notifying everyone, GitHub picks a subset of members using a routing algorithm such as round robin or load balancing, and requests those individuals. That keeps a twenty-person team from getting twenty notifications per pull request while still satisfying the ownership requirement, since an approval from any member of the owning team counts. ## When entries are wrong GitHub validates the file and surfaces problems in a CODEOWNERS errors view when you browse the file in the repository, and in an annotation on pull requests that change it. Typical errors are an unknown user or team, a team missing write access, a team not in the owning organization, and a syntax error in the pattern. An invalid line does not invalidate the whole file — the other rules still apply — but the invalid line owns nothing, which is exactly the failure mode where people believe a path is protected and it is not. Because a bad entry fails quietly from the perspective of everyday work, it is worth treating CODEOWNERS as code: give the file itself an owner so changes to it get reviewed, and check the errors view after any edit that renames a team or removes a person. ## Reading a real file A typical file gives everything a default owner, then reassigns specific trees: a catch-all pattern owned by a platform team, `/docs/` owned by technical writers, `/infra/` owned by two teams so either can approve, and `/.github/CODEOWNERS` owned so that changes to ownership itself are reviewed. Every team named there must have write access on the repository for the line to have any effect — the file is a mapping of paths to accountable groups, not a grant of permission.
- Why is @backend usually wrong when you meant a team?GitHub reads a bare `@name` as a username. A team must be fully qualified as `@org/team-name` with the organization that owns the repository. An unqualified team name normally resolves to nothing (or, worse, to an unrelated user account with that handle) and shows up in the CODEOWNERS errors view rather than requesting anyone.
- Two teams are listed on one line — do both have to approve?No. Owners on a line are alternatives: a review from any one of the listed users or teams satisfies that rule. If you genuinely need two independent sign-offs, you need a different control — a higher required-approval count, or splitting the paths so different rules own them — not a second name on the same line.
- How do you stop a twenty-person owning team from being spammed on every pull request?Enable code review assignment on the team, which makes GitHub request a chosen subset of members — via round robin or load balancing — instead of the whole team. The ownership requirement is unchanged, because an approval from any member of the owning team counts.
saying these in an interview costs you the question
- Writing a team as @backend without the organization prefix
- Assuming read access is enough for an owner
- Listing individuals so ownership dies when they leave
- Believing an invalid owner line blocks the pull request
- Thinking two owners on a line both must approve