Codex CLI Loop: Repeat Work With Clear Stop Conditions

A Codex CLI loop is a shell script that calls the CLI more than once on the same codebase. Done well, it applies a fix across many files, retries until tests pass, or runs a nightly review. Done poorly, it burns tokens on circular edits and leaves the repository in an uncertain state. The fix in both cases is the same: define what each iteration is trying to accomplish, how you will know it succeeded, and what makes you stop.

A tool like fenbs keeps a record outside the loop of what was attempted, what passed, and what remains. When the loop stops short, the next session picks up from that record instead of rerunning everything from the beginning.

Codex CLI does not loop on its own

Codex CLI runs one task to completion and exits. It does not retry on failure, repeat until a condition is met, or schedule itself. To loop, you write a shell script that calls the CLI repeatedly and checks the result between calls.

That script is where most problems live. Without a clear exit condition the loop runs until you interrupt it, leaving partial edits in the repository. Without a validation step between iterations, each run builds on whatever the previous one produced, right or wrong.

Three iteration patterns

• Apply-and-stop: call Codex CLI once per file in a list with a fixed prompt. No retry, no condition check. Use this for mechanical transforms where you review the diff afterward.
• Try-until-pass: call Codex CLI, then run a test or linter, then stop when both pass or a retry limit is reached. Use this for tasks with a clear automated pass or fail.
• Review-and-continue: call Codex CLI, pause for a human review, then continue or stop. Use this when the correctness check requires judgment rather than a script.

The try-until-pass pattern is the one most likely to loop forever. Protect it with a maximum iteration count and log the reason every time it retries. If it reaches the limit, treat that as a failure and record what the last state was.

How to set task bounds

Each iteration needs a narrow scope. A prompt like "fix all the bugs" gives the CLI no boundary and produces unpredictable results across iterations. A prompt like "update the function parseDate in src/utils.ts to return null instead of throwing when the input is empty" gives a clear target and a reviewable outcome.

When the loop processes multiple files, generate the list before the loop starts and pass one item per iteration. This keeps the scope constant and makes failures easy to isolate. A task that fails on file 7 of 20 should not cause files 8 through 20 to run with wrong assumptions inherited from the failure.

Codex CLI's --approval-mode flag controls how much it acts on its own. In a loop that runs without supervision, full-auto removes the approval prompts that would otherwise let you catch an unexpected direction. Consider whether each iteration is safe to run unattended before removing manual approvals. The Codex CLI commands guide covers the available flags.

Validation and stop conditions

A stop condition is the signal that the loop achieved its goal. Common ones are a test suite passing, a linter returning zero errors, or a diff that matches an expected pattern. If none of these exist for your task, set an explicit maximum number of iterations and treat hitting that limit as a reason to pause and check the results manually.

Run the validation step outside Codex CLI, in the shell between iterations. This separates the agent's action from the result check and gives you a clean record of what each iteration produced. Piping test output to a log file makes it straightforward to review without rerunning the loop.

If you use Codex CLI hooks, a post-turn hook is a good place to run a fast validation check after each agent turn. It keeps the check close to the action without rewriting your shell loop.

Common problems and how to fix them

• Circular edits: two iterations undo each other's work. Fix by narrowing the prompt scope or adding a check that detects a repeated diff before running the next iteration.
• State drift: later iterations read changes that earlier ones made incorrectly. Fix by running the full test suite between iterations, not just the test closest to the change.
• Token waste: the loop retries a task that needs a human decision, not another AI pass. Fix by checking for a known-unsolvable condition and stopping instead of retrying.
• Silent failure: the loop finishes without error but the goal was not met. Fix by asserting the expected outcome explicitly in the validation step rather than checking only for an error code.

How to do this with fenbs

1. Create a free account and add a task for the goal the loop is meant to achieve.
2. Write the scope in the task's description: which files, which prompt, which validation step, and the maximum iteration count.
3. After each loop run, add a comment to the task with the iteration count, which files changed, and whether validation passed.
4. If the loop stops before the goal is met, record the last known state and next step in Where we left off so the next session can continue without rerunning completed work.
5. Record any rules that came from the run — for example, "do not run full-auto on migration files" — as a Decision in fenbs so the next session starts with them already in context.

For scheduling a loop to run on a repeating basis, see Codex CLI scheduled tasks. For using Codex CLI as a component inside a larger agent system, the Codex subagents guide covers delegation patterns.