Write rules Codex follows instead of rules it ignores

You’ve got a first AGENTS.md and you know how Codex layers several of them. Now the part that decides whether any of it works: which rules Codex actually follows. Because AGENTS.md is guidance — prose the model reads and interprets, not a config flag it’s mechanically bound to — two rules that look equally reasonable on the page can land very differently. One changes Codex’s behavior every session. The other gets skimmed and forgotten. The difference is almost always concreteness.

The economics of a rule

Start with the framing that makes every “should this go in?” decision easy. A rule is context you pay for once instead of re-establishing every session — but it’s also a line loaded into every session, spending tokens before you’ve typed your task. The file is a budget. A rule has to earn its slot twice: by being worth the tokens, and by being concrete enough that Codex can act on it.

The morning ritual — “money is cents, here’s the category list, dates are day-first” — is you spending keystrokes to re-teach the same facts daily. Move them into AGENTS.md and you pay once. That’s a brilliant trade. But it only works when the entry is true, durable, and specific. Pad the file with vague filler and you invert it: now you’re paying rent every session for lines that change nothing. A bloated AGENTS.md is worse than a lean one — and not only on cost. As the file grows, the signal drowns and Codex follows it less reliably. There’s a hard ceiling too: past the size cap, content is silently dropped, which the next lesson covers.

What Codex follows

The rules that land share a shape: specific, verifiable, and particular to budgetcli. Each one you could check afterward. Look at how the money rule reads when it’s written to be followed versus written to be ignored:

# Ignored — vague, nothing to act on
- Be careful with money values.
- Handle currency correctly.

# Followed — concrete, gradeable
- Money is integer cents. A $10.00 charge is the integer 1000.
- Never divide by 100 in business logic; format to dollars only at the API boundary.

The second pair tells Codex exactly what to type and exactly what not to. You could grade a diff against it in seconds. The same upgrade applies across the file:

The domain fact that bites, with the value. “Money is integer cents — $4.99 is 499” beats “money is stored carefully.” The agent can’t infer it and gets it wrong without it.
The exact command, not the gist. “Run pytest before committing” beats “test your changes.” A command Codex can run verbatim beats an instruction it has to interpret.
The closed list, stated as closed. “Categories are exactly these eight; invent none” beats “use sensible categories.” Naming the set and forbidding additions is what stops the phantom "dining".
The thing it must never touch. “Never write to ledger.db directly; go through the repository layer” — a guardrail Codex would otherwise trip over.

The tell of a good rule is that it’s gradeable. If you couldn’t write a test or eyeball a diff to confirm Codex obeyed it, it’s probably too vague to obey.

What Codex ignores

The entries to keep out are the ones that feel responsible but move nothing:

Generic best-practice filler. “Write clean code.” “Follow best practices.” “Handle errors properly.” Codex already aims for these; the words just spend tokens.
Anything the code already states. The framework, the language, the directory names — Codex reads those from the repo. Don’t transcribe budgetcli into the file that describes budgetcli.
One-off task notes. “We’re refactoring the CSV importer this week.” True for a week, then it’s stale context misleading every session after. If it isn’t a standing fact, it’s not a rule.

The honest test for any candidate line: would I have to tell a new teammate this, and will it still be true in three months? Yes to both — it’s a rule. Vague, obvious, or temporary — leave it out. You’re curating, not dumping.

You now know what to write, where to put it, and how to phrase it so Codex follows. The last thing to understand is what AGENTS.md can’t do — the size cap that quietly eats rules past a limit, and the line you must never cross: treating guidance as if it were a security boundary. That’s the final lesson of the chapter.