01 / Context budgeting
Limits on the model context
Model history is incremental to preserve prompt caching. Every injected item has a hard size cap, anything over 1,000 tokens needs review, and fragments use 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
A section arguing against the largest crate
The file says codex-core grew because adding code was easier than moving it out. New work should use an existing crate or a new workspace member, and reviewers are told to push back on further growth.
Source excerpt starting at line 76.76To that end: **resist adding code to codex-core**!
03
A line budget on the diff
Non-mechanical changes stop at 800 lines and complex logic at 500. Work over either limit returns as a staged proposal based on the diff, dependencies, and call sites, starting with the smallest coherent change.
Source excerpt starting at line 127.127Unless the change is mechanical the total number of changed lines should not exceed 800 lines.
04
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
Explain protected sandbox variables
Two environment variables are off limits because existing tests use them to skip cases the agent cannot run in its sandbox. That rationale keeps the checks from looking like 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. Common, core, or protocol changes require the full suite after user approval, and slow Rust commands must not be killed 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.