AGENTS.md Says ‘Do Not Edit’. What Does CODEOWNERS Actually Enforce?

An AGENTS.md instruction can tell a coding agent to stop before editing a sensitive file. CODEOWNERS routes review to the people responsible for that file. Neither, by its mere presence, makes the local file read-only. If you need a merge restriction, check the repository’s actual protection settings as well.

This distinction matters when a task looks harmless: rename a helper, regenerate a client, update a dependency. The requested change may be small while the resulting diff crosses an ownership boundary. The useful question is not just “did the agent read the instructions?” It is “which files changed, who must review them, and what prevents an unreviewed merge?”

We checked the official documentation linked below on October 7, 2026. The ownership example is a proposed workflow, not a claim that we changed or tested your GitHub settings. We verified the four Git commands below in a temporary repository containing separate committed, staged, unstaged, and untracked changes.

Three decisions to make before the first edit

Write down three answers in the task itself:

1. Editing scope: Which paths may the agent change in this task? Which require a separate decision?
2. Review ownership: Who is responsible for evaluating the resulting changes?
3. Merge requirements: Which requirements must GitHub enforce before accepting the change?

For example, “update the login button label” can reasonably allow a translation file and a component. It does not automatically authorize a refactor of the session validator. If the agent discovers that the label is generated from another source, it should identify that source and ask for a scope decision before editing a protected area.

That is a more actionable instruction than “be careful with authentication.” It provides a stopping point and a useful deliverable when work cannot continue.

Use AGENTS.md for the handoff decision

Here is an original instruction block to adapt after agreeing the paths with your maintainers:

## Sensitive changes

For ordinary UI and documentation tasks, do not modify src/auth/,
infra/identity/, or .github/CODEOWNERS without explicit task approval.

If a requested fix appears to require one of these paths:
- identify the file and explain why the change is necessary;
- describe the smallest proposed change;
- continue independent work within the authorized scope;
- leave the sensitive file unchanged until scope is resolved.

Before reporting completion, list changed files and identify any
ownership boundary crossed by generated files or lockfile changes.

These are project instructions. Do not describe them as an operating-system access control. In Claude Code, instruction loading also depends on the supported configuration; our AGENTS.md support guide covers that separate question. Anthropic describes memory files as context rather than enforced configuration in its memory documentation.

Use CODEOWNERS for review routing

An illustrative .github/CODEOWNERS might contain:

*                     @example/maintainers
/src/auth/            @example/identity
/infra/identity/      @example/platform @example/identity
/.github/CODEOWNERS   @example/repository-admins

Replace the example teams with real eligible owners. GitHub evaluates the CODEOWNERS file from the pull request’s base branch; the last matching pattern wins. Required code-owner review must be enabled separately. Multiple owners on a line do not mean every listed owner must approve. See GitHub’s CODEOWNERS reference.

For the sample above, build a review checklist before adopting it:

The “both teams” question is a policy decision, not something to infer from two names appearing next to each other. Document the requirement first, then have the repository administrator verify that the chosen controls enforce it.

Inspect the actual patch, including unfinished edits

At handoff, use more than a summary written from memory. These read-only commands expose different parts of a local working tree:

# Current tracked and untracked changes
git status --short

# Tracked changes not staged
git diff --name-status

# Changes staged for the next commit
git diff --cached --name-status

# Changes in the branch since its common ancestor with origin/main
# Use the actual target branch if it is not main.
git diff --name-status origin/main...HEAD

The three-dot comparison uses the merge base. It does not include unfinished working-tree edits; that is why the preceding commands remain useful. Fetch the target branch through your normal workflow when its local reference is stale. Git documents the diff forms here.

Review the file list before reading only the expected component. A formatting command may have touched an entire directory. A code generator may have updated an authentication client. If either crosses the agreed scope, stop that part of the handoff and identify the exact files. Do not silently restore someone else’s pre-existing changes to make the list look cleaner.

Verify the merge requirement with the repository owner

Ask for an observable answer: the target branch, the applicable protection rule, the required review policy, and any actors allowed to bypass it. GitHub’s protected-branch documentation explains the configurable merge requirements. An instruction file is not evidence that those settings are enabled.

A useful acceptance check uses an approved, harmless test PR in a suitable test repository: inspect the expected review request and whether merging is blocked before the required approval. Record what was actually checked. Do not report a production repository as protected merely because an example file passed a local syntax check.

A completion report maintainers can act on

Prefer a report with concrete boundaries:

Changed: src/ui/login-label.tsx and locales/en.json
Sensitive paths changed: none
Validation: the targeted component test passed
Review: maintainer review still pending
Merge: not performed
Remaining: identity team must decide whether the session message
should change; no files under src/auth/ were edited

This makes “done” refer to the authorized implementation, while preserving outstanding review. For additional instruction examples, browse the rules gallery. Adapt the smallest relevant rule instead of copying a whole policy whose owners and paths do not exist in your repository.