Handling a Codex Session That Goes in Circles

A session that fixes a problem, breaks something else fixing it, fixes that, and reintroduces the original problem — three or four turns deep and somehow no closer to done than where it started — is a specific, recognizable failure pattern, and recognizing it early is worth more than any amount of patience waiting for it to resolve itself.

Why this happens at all

A circular session is usually a symptom of the model reasoning locally, turn to turn, without a stable, correct model of the whole problem it's actually holding onto. Each individual fix looks locally reasonable given what the model is currently attending to, but without a consistent understanding of the constraints all fixes need to satisfy simultaneously, successive local fixes can trade off against each other indefinitely rather than converging. It's less "the model is confused" and more "the model is repeatedly re-deriving a partial understanding from scratch each turn, and each partial understanding is missing something different."

The tell that distinguishes circling from genuine progress

Slow, genuine progress on a hard problem looks like each turn narrowing the problem or ruling something out, even if the fix itself isn't complete yet. Circling looks like the same handful of symptoms recurring — an error that gets fixed and then reappears two turns later in a related form, a test that passes then fails then passes again as unrelated changes shift around it. If you can't point to something concretely different about the state of the problem between turn two and turn five, that's the signal, more reliable than turn count alone.

Why continuing to iterate rarely breaks the cycle on its own

The instinct, understandably, is to keep going — the model got close before, maybe one more turn gets there. In practice, a session that's genuinely circling usually needs an external intervention to break the pattern, because whatever's causing the local-reasoning trap doesn't tend to resolve itself by simply running the same process again. More turns inside the same session, without a change in approach, mostly means more tokens spent reproducing the same oscillation.

Naming the actual constraint that's being missed

The most effective single intervention is usually stopping and stating, explicitly, the full constraint the fixes need to satisfy simultaneously — not a new instruction to try something different, but a precise restatement of what "correct" actually requires, including the part that's been getting traded away each cycle. A session circling because a fix for A keeps breaking B needs to be told, plainly, that the actual task requires A and B to both hold at once, not implicitly expected to infer that from watching its own fixes fail.

When a full restart beats a correction

If naming the constraint explicitly doesn't break the cycle within another turn or two, restarting with a fresh session — carrying forward your own understanding of what's actually going wrong, not the drifted session's accumulated attempts — is usually faster than continuing to patch a session that's already deep in an unproductive pattern. The accumulated context of several failed attempts isn't neutral; it can actively bias a continuing session toward repeating the same local reasoning that produced the cycle in the first place.

Reducing scope as a way out

A circular session is sometimes a signal that the task, as scoped, is genuinely too large or too tangled for a single continuous pass — the interacting constraints causing the cycle might resolve more easily if tackled as two separate, sequential steps rather than one step trying to satisfy everything simultaneously. Splitting the task, fixing the piece that's actually causing the oscillation in isolation first, and only then addressing the rest, often succeeds where continuing to iterate on the combined problem doesn't.

What this looks like from the human side, done well

Catching a circular session early means watching for the pattern actively during the first several turns, not just letting a session run unattended and checking back after a long stretch — the earlier you notice the oscillation, the cheaper the fix, whether that's naming the missed constraint, restarting, or splitting the task. Treating "is this actually converging" as a question worth asking every few turns, rather than only once a session feels like it's taking unusually long, is the practical habit that keeps a circling session from running far longer than it needed to before someone intervened.

Why this is worth understanding rather than just tolerating

A session that circles for many turns before someone notices and intervenes is expensive in both time and tokens, and it's avoidable expense — the pattern is recognizable once you know what to look for, and the fixes are neither exotic nor difficult. Building the habit of watching for genuine convergence, not just watching for a session to eventually stop, is a small discipline that prevents a real, recurring, and otherwise invisible cost.

The cost side of a circling session, made concrete

A session oscillating for a dozen turns before someone intervenes isn't just a time cost — every one of those turns is accumulating context, and depending on the model, potentially approaching or crossing a long-context repricing threshold purely from unproductive back-and-forth rather than genuine progress. Checking a suspiciously long-running session's accumulated size against the context-window planner is worth doing the moment you suspect circling, since a session that's both stuck and expensive is a stronger case for immediate intervention than one that's merely stuck.

Prevention is cheaper than the cure

The best fix for a circling session is a task scoped clearly enough that the pattern doesn't have room to start in the first place — a well-stated definition of done and an explicit list of constraints that must hold simultaneously reduce how often a session ends up trading one constraint off against another without realizing it. None of the intervention techniques above are as cheap as simply not triggering the pattern to begin with, which is the strongest argument for investing effort in task scoping up front rather than treating circling as an inevitable cost to manage after the fact.