Codex review rules need safe paths

AI code review gets useful when it stops pretending every repository is the same.

OpenAI's new Codex Code Review rules point in the right direction. The feature lets Codex read AGENTS.md guidance during pull-request review and cite the relevant rule when it flags a problem. The docs tell teams to put repository-wide rules at the root and service-specific rules closer to the code they govern. OpenAI says its internal eval recovered 98% of required custom findings with rule-guided variants, compared with 58.3% in a baseline control.

That is a real improvement. It is also easy to ruin.

A bad rule file turns the reviewer into a policy parrot. A good one preserves the context a senior reviewer keeps repeating: don't rename this wire event, don't log that customer field, don't change this cohort definition after exposure.

Sources: OpenAI developer note on custom Codex review rules, Codex GitHub code review docs, GitHub docs on OpenAI Codex in Copilot, GitHub Actions workflow execution protections GA note.

A rule without an exit becomes noise

The most important part of the feature is not that Codex can read AGENTS.md. Agents have been reading instruction files for a while. The useful part is that review guidance can be scoped to the files that changed and cited in the finding.

That only works if the rule has a safe path.

Compare these two rules:

### API compatibility

Do not break API compatibility.

### Public response fields

Preserve existing JSON field names in `/api/public/*` responses. External clients cache these fields.
Safe path: add a new field, keep the old field for one release cycle, and document the deprecation.

The first rule asks the model to perform taste. It will either miss the issue or comment on everything. The second rule gives it a specific invariant, why the invariant matters, and what a compatible change looks like.

That is the shape I would use for almost every repository rule:

When you see X in files Y, protect Z because R. Safe path: S.

If the rule cannot fit that shape, it probably belongs in docs, tests, or a human review checklist.

Keep mechanical checks out of the rule file

OpenAI's docs say to leave formatting, lint, and other deterministic checks in CI. That is not a small detail.

Review rules are tempting because they feel cheap. Add a paragraph, get another reviewer. But the more generic policy you pack into AGENTS.md, the less useful Codex becomes. "Prefer clear names" is not a rule. "Do not include patient identifiers in logs from services/intake" is.

The line I use is simple: if a script can check it reliably, write the script. If a reviewer keeps explaining a local invariant that cannot be expressed cleanly in a script, write a review rule.

That keeps the AI reviewer focused on the narrow gap between tests and tribal memory.

Trigger policy matters too

Repository rules solve only half the problem. The other half is deciding when the review runs and which workflow is allowed to run around it.

GitHub's workflow execution protections are relevant here. They let organizations control who can trigger Actions workflows and which events can start them. GitHub's September GA note also says public repositories that do not already have an applicable event policy will get a default rule that disables pull_request_target, first in evaluate mode, with automatic enforcement planned for November 2, 2026.

That matters because agent-heavy review workflows often collect too much trust in one place. A PR comment can summon a reviewer. A workflow trigger can run code. A pull_request_target workflow can expose secrets if it executes untrusted fork code in the base repository context.

The product lesson is not "turn everything off." It is to separate review from execution.

A Codex review rule can say, "this diff changes a public API contract." A workflow policy should decide whether the untrusted PR gets to run privileged automation. Those are different gates. Treating them as one big AI review moment is how teams end up giving a helpful comment bot a dangerous amount of implied authority.

Start with three rules, then stop

If I were adding Codex review rules to a repository today, I would not write a constitution.

I would start with three rules:

• one compatibility invariant users would notice if broken;
• one data boundary the team cannot afford to leak;
• one workflow or deployment assumption that has caused real review comments before.

Then I would open three test pull requests: one that should trigger the rule, one safe counterexample, and one unrelated change. If Codex comments on the first and stays quiet on the other two, keep the rule. If it sprays advice everywhere, narrow the scope or delete it.

That sounds slow. It is still faster than teaching every future agent, contractor, and tired teammate the same lesson after they have already opened a PR.

AI review should not replace approval. It should move local memory closer to the diff, early enough that the author can still fix the thing without a meeting.