Codex's GitHub integration can run a review of a pull request and honor repository-specific Code Review Rules from the nearest AGENTS.md. This turns the review from a general "look at the code" into a check against rules the team considers important specifically for its project. But the value of such a review depends entirely on the quality of the rules: good rules catch real risk, bad ones create noise that is soon ignored.
The main rule about rules: they must describe meaningful behavior, not duplicate the linter. The linter already catches formatting, unused variables and style - moving this into Code Review Rules is pointless, it only adds noise to the review. Rules pay off where the static analyzer is powerless: in authorization logic, trust boundaries, contract compatibility, data handling. What cannot be expressed by a linter rule but is critical to correctness - that is the material for Code Review Rules.
It helps to see a meaningful rule in full once. Below is a Code Review Rules block about authorization: flag any endpoint that reads tenant data without deriving tenant_id from the authenticated principal; a route parameter is not a trusted tenant boundary; the safe path is to authorize the principal first, then constrain every query by the authorized tenant. This is not style but a behavioral invariant whose violation is a real vulnerability.
A good rule is arranged as a checkable statement about risk, not as a wish. It names a specific antipattern ("reads tenant data without deriving tenant_id from the principal"), explains why it is dangerous ("a route parameter is not a trusted boundary") and sets the safe path. Such a rule the agent can apply unambiguously: there is a clear sign of violation and a clear correct variant. A vague "write secure code" is not a rule - by it you can neither catch a violation nor explain it.
Enforcement at the repository level is what makes rules a force rather than a document. When Code Review Rules live in AGENTS.md under version control, they apply to all PRs the same way and evolve with the project through the ordinary review process. A rule added after an incident starts catching its recurrence automatically. This is cheaper than hoping each time that a human reviewer remembers a specific class of risk on a specific piece of code.
The review from the GitHub integration obeys the same caveat as any review from the model. It is useful as another layer of attention catching omissions by the named rules, but it is not independent evidence of correctness. The person responsible for the merge remains: the review's findings are hypotheses about risk that are checked, not a final stamp. An automatic review strengthens the team's discipline but does not replace a test, a static analyzer and a conscious decision to merge the change.
The point of this integration is to fix the team's knowledge of risks in a checkable, version-controlled form. Instead of relying on reviewers' memory of "where our authorization usually breaks", the team describes this with a rule once, and the review applies it to every PR. Rules grow with the project: each analyzed incident can turn into a rule that catches its class further on. This is institutional memory of risks, not a one-off check.
The typical failures around Code Review Rules are predictable. Duplicating the linter in them and adding noise to the review until it stops being read. Writing a vague rule by which a violation cannot be unambiguously caught. Taking a green automatic review for independent evidence and merging a PR without a test and a person. And not turning analyzed incidents into rules, losing institutional memory. Write rules about behavior, not style, make them checkable, keep a human at the merge and grow the rules with the project.
## Code Review Rules
### Authorization
- Flag any endpoint that reads tenant data without deriving tenant_id
from the authenticated principal.
- A route parameter is not a trusted tenant boundary.
- Safe path: authorize the principal first, then constrain every query
by the authorized tenant.
# Rules - about behavior, not duplicating lint; live in the nearest AGENTS.md