Codex delegate patterns that survive a real codebase

Why a Codex delegate handoff usually fails

Watch a developer delegate to Codex for the first time and the prompt is almost always a wish, not a task. "Fix the flaky tests in the payments module." The agent then has to guess which tests count as flaky, then guess whether it is allowed to change the code under test or only the test. It picks one interpretation, works for eight minutes, and hands back a diff that answers a question nobody asked.

The second failure is quieter. The task was fine, but nobody defined done. So the reviewer reads 400 lines of diff with no idea what to check against, gets tired around line 150, and approves on vibes.

Write the acceptance check before the prompt

The single habit that moves the needle: before you type the task, write down the command that proves it worked. One line.

• pytest tests/payments -q passes 20 runs in a row with no reruns
• npm run typecheck is clean and no @ts-expect-error was added
• The endpoint returns 409 instead of 500 when the idempotency key repeats

Now paste that into the prompt as the definition of done. The agent gets a target it can verify itself, and you get a review that takes two minutes instead of twenty. If you cannot write the check, the task is not ready to delegate. Do it yourself or break it up.

Match the sandbox to the blast radius

Codex CLI lets you control how much the agent can touch: read-only inspection, writes confined to the workspace, or full access with approvals turned off. Teams tend to pick one setting on day one and never revisit it, which is how you end up either approving every file read for a month or letting an unattended run reach the network.

Pair the mode with the task. Investigation and code reading get read-only. Refactors and test writing get workspace writes. Anything that installs packages or touches infrastructure gets a human in the loop, every time. Put the defaults in ~/.codex/config.toml so nobody has to remember flags, and override per run when the task justifies it.

Give it the context you would give a contractor

An AGENTS.md at the repo root is the cheapest win available, and most teams write it once and let it rot. Ours stay short. Build and test commands. The two directories that are legacy and should not be touched. The logging convention. What the CI actually enforces. Anything longer than a page gets skimmed by humans and diluted by the model.

Where this breaks down honestly: cross-cutting changes. A rename that spans 60 files, a dependency upgrade with behavioural changes, anything requiring judgement about a deprecation you have not documented. Agents produce plausible diffs on these and the plausibility is the problem. Keep those in a pair session with a human driving.

Try this on your next ticket

Pick one ticket from your current sprint. Write the acceptance command first. Run it against the current code and watch it fail. Then delegate with that command in the prompt, in read-only mode for the investigation phase, switching to workspace writes once you agree on the plan. Compare the review time against your last agent-generated PR.

If your team keeps landing agent diffs that pass CI and still feel wrong, that is a process gap, and it is the thing we spend most of a training day on.

If you want help putting this into practice, talk to us.