Mostly rules rather than explanation: 122 bullets covering Rust idioms, module size limits, review criteria, snapshot testing and app-server API conventions. Several sections set limits on the change itself rather than on the code it touches.
Quoted passages are verbatim. Open one to see it in the source.
01 / Context budgeting
Limits on the model context
A review section governs the history Codex sends to the model: build it incrementally, do not rewrite it, avoid changes that cause cache misses, cap every injected item, and mark anything over 1,000 tokens for additional manual review. Injected fragments must be declared as structs implementing a named trait.
Source excerpt starting at line 97.
973. No unbounded items - everything injected in the model context must have a bounded size and a hard cap.
02 / From this file
A section arguing against the largest crate
The file states that codex-core grew because adding to it is easier than refactoring out of it, then instructs the agent to resist that and to push back in review on changes that add to it. Alternatives are listed: an existing crate, or a new workspace member with the refactor that requires.
Source excerpt starting at line 76.
76To that end: **resist adding code to codex-core**!
03 / From this file
A line budget on the diff
Non-mechanical changes are capped at 800 lines, and complex logic changes at 500. A change over the cap is expected to come back as a staging proposal based on the actual diff, dependencies and call sites, identifying the smallest coherent stage to land first.
Source excerpt starting at line 127.
127Unless the change is mechanical the total number of changed lines should not exceed 800 lines.
04 / From this file
Module size limits with the affected files listed
Modules target 500 lines excluding tests, and past roughly 800 new functionality goes in a new module. The rule names the specific files it applies to most, on the stated grounds that they already attract unrelated changes.
05 / From this file
The sandbox environment variables explained, not just protected
Two environment variables are placed off limits, followed by the reason the code reads them: existing tests use them to exit early from cases the agent cannot run under its own sandbox. The explanation is what distinguishes the checks from dead code.
Source excerpt starting at line 9.
9 - You operate in a sandbox where `CODEX_SANDBOX_NETWORK_DISABLED=1` will be set whenever you use the `shell` tool. Any existing code that uses `CODEX_SANDBOX_NETWORK_DISABLED_ENV_VAR` was authored with this fact in mind. It is often used to early exit out of tests that the author knew you would not be able to run given your sandbox limitations.
06 / Verification by change type
Test scope that escalates, with a permission gate
Run the changed project's tests first. If the change touched common, core or protocol, run the full suite, but ask the user before doing so because of its cost. A separate line tells the agent not to kill slow Rust commands by PID.
Source excerpt starting at line 62.
62- When running Rust commands (e.g. `just fix` or `just test`) be patient with the command and never try to kill them using the PID. Rust lock can make the execution slow, this is expected.
Put it to work
Borrow this for your repo
01Put a line budget on changes, and ask for a staging plan when one exceeds it.
02Name the modules that are already too big. An agent cannot infer which files attract unrelated changes.
03Where code exists because of a constraint the code cannot express, record the reason where an agent will read it before deleting it.
04Gate expensive test runs behind asking, and state which changes make them mandatory.
Codex's file tells an agent how the codebase works. It cannot tell it which bug three customers hit this week. Modem keeps that context current and attaches it to the work.
