Understand one turn of the Codex loop

You’re authenticated and standing at a live prompt inside budgetcli, and your instinct is to throw the date bug at it right now. Hold that for two minutes. Every task you’ll ever give Codex — from this date fix to a multi-file refactor four chapters from now — runs through the same small loop, and the cheapest possible place to see that loop is on a question that can’t break anything. Watch it once here and the real change in the next lesson will feel like something you’ve already done.

Make your first turn a question, not a command

You’ve just inherited this repo. So has the agent — it knows nothing about budgetcli that it hasn’t read yet. A read-only question costs you almost nothing and shows you exactly how it gathers context before it’s ever allowed to write:

> what does this service do, and where does it parse dates out of imported CSVs?

  • Read README.md, app/main.py, app/importers/csv.py            (3 files)

  budgetcli is a FastAPI service for personal budgeting — accounts,
  transactions, CSV import, and monthly reports. CSV import lives in
  app/importers/csv.py; that's where each row's date string is parsed
  into a date before the transaction is stored. The parsing assumes a
  single fixed date format, which won't hold across different banks.

Watch what that one turn bought you. The agent went and read files — you can see which ones — and came back with a map: what the service is, where the CSV importer lives, and even an early hunch about why dates might be going wrong. You’ve learned the lay of the land for your ticket, and you’ve learned something more useful — how this agent behaves when it needs context. It reads first, then answers.

The four beats under every task

That single turn is the whole loop in miniature. Strip away the specifics and every Codex turn has the same shape:

1. Read — it gathers the context it needs, pulling in the specific files relevant to your request rather than guessing from the prompt alone.
2. Propose — it tells you what it intends to do. For a question that’s an answer; for a task it’s a concrete plan and the exact edits or commands it wants to run.
3. Approve — it stops and waits for you. By default, nothing touches your disk and no command runs until you’ve said yes. This is the checkpoint between the agent’s intent and your filesystem, and it’s there on every change.
4. Apply — only after you approve does it actually write the edit or run the command — and then it checks its own work, typically by running whatever verifies the change.

Read, propose, approve, apply. When a task goes well it’s because all four beats happened in order; when one goes wrong it’s usually because a beat got skipped — it proposed without reading enough, or applied something you didn’t really look at. Learning to see those beats is most of what makes you good at driving the agent, and you just watched a clean instance of the first two on a question where a wrong answer couldn’t cost you anything.

The reason this matters on budgetcli specifically: this is your financial data, in code you didn’t write. The approve beat is not a formality you’ll want to rush past — it’s the only thing standing between a confident-sounding wrong edit and your ledger. Lead with a write as your very first move and you’d be trusting a tool you’ve watched do nothing yet, on a codebase it hasn’t shown you it understands. Spend one read-only question first and that trust is earned instead of assumed.

You now know where the date parsing lives and how the agent behaves when it works — which is exactly what you need to hand it the actual bug and watch all four beats close on a real fix. Next: ship your first reviewed change.