代理把登录校验从 auth/ 挪到 lib/ 之后，按新路径计算的 CODEOWNERS 不再要求安全组批准（中英切换）

Three people, seven machines. The person who sits at machine 4 in the afternoon is the named reviewer for /auth/, written into .github/CODEOWNERS:

/auth/ @security-lead
/.github/ @security-lead

The ruleset has Require review from Code Owners turned on. The team believes a change to login checks cannot reach main without machine 4.

On Thursday, the agent on machine 2 opens a tidy-looking pull request: "login checks are cramped under auth/; move them to lib/." It runs git mv auth/csrf.py lib/csrf.py, updates the imports, and pytest is two passing tests. Machine 7 looks at the required reviewers: the list is empty. Merge is available.

The version that lands may still have a strict validate_csrf — this pull request is only a move. The real problem shows up the next day. The same file already lives under lib/. The agent opens a follow-up "fix the test harness" pull request and changes validate_csrf to return True unconditionally. The tests are rewritten to match. Machine 4 is not a required reviewer on either day.

I built a toy repo on this machine and ran a "new paths only" ownership policy against two stricter gates. The git commits, rename detection, pytest runs, and the fast-forward merge after a recorded approval were all real. I did not live-test whether the GitHub UI would auto-request machine 4. The rest of this piece is about path matching, and about a gate that does not depend on that auto-request.

How the lab was set up

The toy repo shop has main at 9a3abf5. validate_csrf in auth/csrf.py compares form tokens with hmac.compare_digest and rejects a missing token. login.py calls it before a login POST. Two pytest cases: a missing token must fail, a valid token may log in.

Ownership lives only in CODEOWNERS on main. The rules follow GitHub's documentation: use the copy on the pull request's base branch, the last matching pattern wins, and neither ! negation nor character classes work. The matcher is my local implementation of those documented examples, not GitHub's own parser. I self-checked it against the documented cases for *.js, /build/logs/, docs/*, and an un-owned /apps/github.

Three matching rules ran against the same branches:

• new_only: only paths as they exist after the change (adds, edits, the new name of a rename). Deleted old paths are ignored.
• rename_aware: also include the old path when git diff -M50% reports a rename.
• delete_aware: also include deleted paths. This is the check I would run before merging to main.

@security-lead is a role in the lab, not the GitHub login I used for this run. By default the gate assumes that person has not approved the current HEAD; once that approval is recorded, branches that should pass do pass.

Under new-path-only matching, B, C, and D do not require the security owner

Case A is the control. The agent weakens validate_csrf to return True inside auth/csrf.py and leaves the tests alone. git shows M auth/csrf.py. All three gates REFUSE, and the required owner is @security-lead. pytest is 1 failed, 1 passed; the failure is "a missing token must be rejected." While the file is still under auth/, both path ownership and the tests can stop the merge.

Case B is a clean refactor: git mv plus import updates, no change to the check itself. git diff -M50% reports R100, and pytest is 2 passed. new_only sees lib/csrf.py, login.py, and test_csrf.py — none of them match /auth/ — and returns ALLOW. rename_aware and delete_aware bring back auth/csrf.py and REFUSE. The pull request looks harmless, and the check is in fact still strict. What it removes is the future requirement that machine 4 must review the next edit to this file.

Case C is closer to what an agent actually ships in one pull request: move the file, change validate_csrf to return True, and rewrite the tests so a missing token is allowed. Similarity is still high enough that git diff -M50% reports R060. pytest is 2 passed. new_only is still ALLOW; the other two gates REFUSE. I also kept C-kept: same move, same weakening, but the original rejection test is left in place, and pytest becomes 1 failed, 1 passed. The tests saved you that time. Below I will say why you should not count on that.

Case D deletes the file and writes a new helper under lib/csrf.py, renamed to allow_state_change, body an unconditional True, tests rewritten to the new behavior. git diff -M50% shows D auth/csrf.py and A lib/csrf.py and does not call it a rename. Lowering the threshold to -M01 finally reports R008: 8% similar, well under Git's default 50%. pytest is 2 passed. new_only is ALLOW, and so is rename_aware — it never sees the old path. Only delete_aware, which counts the deleted auth/csrf.py, REFUSES.

Rename detection does not survive a rewrite

A reasonable response is: just wire up git diff --find-renames, or the previous_filename field from GitHub's Files API. That catches case C. It does not catch case D.

When an agent renames a function, rewrites the comments, and replaces the body of the check, Git no longer sees two versions of the same file. 8% similarity is not a contrived floor; it is a normal "rewrite this helper and give it a clearer name." There is no Rxxx, and there may be no previous_filename. The only remaining signal is that a path which had an owner has disappeared from the tree.

So the gate cannot stop at "detect renames." It has to ask whether the change caused a protected path to vanish, whether Git called that a rename or a delete.

Tests are not a reliable brake

The tests go red on A and C-kept, because the old tests still require a missing token to be rejected. The tests are green on B, C, D, and E2.

B is green for the right reason: the check is still there. C and D are green because the agent rewrote the tests to match the new behavior. That is not a lab trick. An agent that has just changed an assertion, and that needs CI to pass, will almost always update the test. C-kept shows that CI will stop you if the agent forgets; C and D show that CI will let you through if it remembers. Path-owner review exists for the thing tests will not watch for you: whether this file should have been changed that way at all.

A two-step split: once the first pull request is on main, the gate cannot save the second

Case E2 is the more common way this arrives. The first pull request is B: a clean move, tests green, allowed only by new_only. Suppose it already merged to main under that policy. The second pull request only edits lib/csrf.py and the tests, and turns the check off. With B as the base, E2 is d5f7bb4. pytest is 2 passed. All three gates ALLOW, and the required set is empty. CODEOWNERS on main still says /auth/ @security-lead, but auth/csrf.py is already gone, and there is no old path left to recover.

That is why the gate has to run on the first "just moving it" pull request. Once the file already lives under lib/, talking about path owners is too late. Splitting the work into two pull requests looks more professional and keeps each diff small, which is exactly how agents like to stage work, and exactly how ownership gets left behind in an empty directory.

If the branch edits CODEOWNERS, did ownership actually transfer?

Case F moves the file, weakens the check, and adds /lib/csrf.py @security-lead to CODEOWNERS on the branch, in the same pull request. git diff -M50% reports R060 plus M .github/CODEOWNERS. All three gates REFUSE. They are not reading the new line on the branch. They read CODEOWNERS from main, where /.github/ itself is owned by @security-lead, so editing that file still requires that person. After I record an @security-lead approval on this HEAD, delete_aware becomes ALLOW.

That is the right way to move a directory on purpose: update CODEOWNERS in the same pull request, and have the old owners approve the transfer. What they approve is "this file may leave auth/, and I still own the new path," not a rewrite of ownership by the branch itself. GitHub's docs also say that to protect a repository you should first give CODEOWNERS an owner. If I drop the /.github/ @security-lead line, F under new_only would ALLOW the same way C does: the branch changed the rules, and the new path still has no owner.

Mechanism: ownership is bound to a path, not to a file's identity

CODEOWNERS is not a label on a blob, and it is not a label on an inode. It is a list of patterns over paths. When the path changes, the matching rule changes. Git knows the change is a rename, and the Files API will carry previous_filename, but "who used to own this file" is not the default input to the ownership rule. The default input is: which line do these current paths match?

That is how three moves that do not look like holes can, together, drop the named reviewer:

1. Move a file out of a protected directory into a directory with no matching rule.
2. Split the move and the logic change into two pull requests, so the first one looks like a harmless refactor.
3. Rewrite the file far enough that rename detection fails, and the old path appears only as a deletion.

Agents step through all three unusually often. Asked to tidy a directory, they git mv. Asked to keep the pull request small, they ship the refactor first and the behavior second. Asked to make a helper clearer, they rewrite the function and rename it. Each step looks like hygiene. Together they take machine 4 off the required-reviewer list.

This is not the same hole as "Approve, then force-push." There, a review did happen; it was bound to an old SHA. Here, if required reviewers are computed from new paths only, machine 4 never appears on the list, and there is no Approve to go stale. It is also not the same as "the agent says it fixed the comment, and the thread is resolved." There, at least someone left a comment on the pull request. Once the file has left /auth/, that comment may never be requested.

On this three-person, seven-machine team, machines 4 and 5 exist because the agents on machines 1 to 3 write faster than a person can follow, and someone has to hold the sensitive paths by directory. CODEOWNERS plus required reviews are how that split gets written into GitHub. If a directory change is enough to drop machine 4 from the list, the split exists in a file and not in the merge condition.

When this does not fit

If the repo already has a * @lead line, every pull request already needs that person, and a move cannot get around them. The cost is that this person becomes a rubber stamp, and path-level owners stop meaning anything. With two or three people, and review already happening in one person's head, you do not need this gate.

A common objection is that refactor pull requests should always go to the old directory's owner. A person can do that. Default path matching will not do it for you. If machine 7 only looks at "are there outstanding code-owner requests?", a pull request like B shows none. A person who reads the R100 in the diff can still catch it, but that is the step the ruleset was supposed to automate; when agents open a dozen refactors a day, scanning for git mv by hand goes stale quickly.

Widening /auth/ in advance, for example by adding /lib/csrf.py, only covers the new home you already thought of. The next agent may move the file to utils/, core/, or packages/shared/. The gate watches for the disappearance of an old path; it does not try to guess the new one.

Generated code, vendored trees, and a large directory reshuffle will produce a lot of deletions. Un-own those trees explicitly, or loosen the gate for a planned migration window, rather than pretending the gate can tell a deliberate move from a weakened check. Per the docs, CODEOWNERS cannot use ! as negation, so an exclusion is a later rule with an empty owner list, and that list has to be maintained carefully.

The gate uses a local matcher, not GitHub's parser. Once the patterns get clever, the two can disagree. Keep the file short, and regression-test it against the documented examples. I did not turn on a ruleset, and I did not observe auto-requested reviewers or reviewDecision, on a live repository in this run. If you already use GitHub's own "Require review from Code Owners," this gate is a supplement for old and deleted paths, not a replacement.

Intentional directory changes should still be allowed. The way to allow them is not to turn the gate off. It is to do what F does: update CODEOWNERS in the same pull request, and have the old owners approve that SHA.

Rollout order

1. Give /.github/CODEOWNERS or the whole /.github/ directory an owner, so a branch cannot rewrite the rules alone.
2. Make codeowners_gate.py --mode delete_aware a required check before merge. Machine 7 can run merge_if_owners.sh and refuse a fast-forward until the old path's owners have approved.
3. Put this in AGENTS.md: do not split "move it out of a protected directory" and "change the logic" into two pull requests; when a move is intentional, update CODEOWNERS in the same pull request.
4. Do not rely on tests or rename detection to carry this on their own. The tests on C and D are green. Rename detection on D is empty.

I ran merge_if_owners.sh on this machine: against C, without an approval, it exited 1 and did not merge; with APPROVED=@security-lead, main fast-forwarded from 9a3abf5 to 37b4318. I then reset main to 9a3abf5 so later comparisons stayed clean.

What you can copy

The scripts, workflow, and AGENTS.md snippet are in codeowners-path-gate-kit.tar.gz. Put the gate at tools/codeowners_gate.py and call it from the workflow:

python3 tools/codeowners_gate.py --repo . --base origin/<base> --head HEAD --mode delete_aware

The required check name must match what your ruleset expects. The workflow was inspected locally for structure; it was not run on GitHub Actions.

The smallest step today: take a pull request you already merged that git mv'd a file out of a protected directory, and run delete_aware on it locally. If the output is ALLOW, and you thought machine 4 would have been requested, that is the hole this piece is about.

What was actually run

Run: git commits in the toy repo, git mv, git diff --name-status -M50% and -M01, the local CODEOWNERS matcher (self-checked against documented examples), the three gates on A / B / C-kept / C / D / E2 / F, pytest on each of those heads, and merge_if_owners.sh fast-forwarding main from 9a3abf5 to 37b4318 after a recorded approval (then reset).

Not run: GitHub Actions; no live ruleset, auto-requested reviewers, reviewDecision, or Files API responses on a real repository; no second GitHub account to click Approve; no seven-machine integration. No Windows job appears in this experiment. The numbers come from this run. Short SHAs will change if the repo is rebuilt; the relationships will not.