Codex Agentic Engineering Part 01 | Why Agents Go in Circles and Play Whack-a-Mole: Two Failure Modes That Burn Tokens

A Codex run can look busy for ten minutes and still leave the bug exactly as mysterious as it was at the start. Search results arrive, files open, tests rerun, imports lead to more imports. The transcript gets longer. The set of plausible causes does not necessarily get shorter.

OpenAI describes a Codex turn as potentially containing many rounds of model inference and tool use, with earlier messages and tool activity carried into later turns as conversation history.[1] Inference consumes tokens, and tool output can leave more context for later inference to process. A run that keeps exploring without producing evidence spends time now and can make the next round heavier as well.

A long debugging run can waste effort in two different ways. In wandering, the search keeps expanding without narrowing the diagnosis. In whack-a-mole, visible failures are patched one at a time before the run has established whether they are separate bugs or downstream symptoms of something earlier.

A long search can leave the diagnosis unchanged

OpenAI’s Harness Engineering write-up describes stalled agent work as an environment problem rather than a request for more effort. When Codex could not progress reliably, the team added tools, structure, guardrails and feedback loops. They also made the application easier for Codex to inspect through UI state, logs, metrics and traces.[3] The agent had observable system state to inspect instead of another round of guesswork.

After a search, file read or rerun, ask:

Which explanation is no longer compatible with the evidence we have now?

Sometimes none. That is acceptable during reconnaissance. It just means the diagnosis has not narrowed yet.

Google SRE frames troubleshooting as an iterative process of observations, candidate causes and tests that provide confirming or disconfirming evidence.[4] A check is especially valuable when different outcomes separate different explanations. Repeating a failing test unchanged tells you little unless nondeterminism is itself under investigation. A new repository search helps only when it tests something the previous search did not.

For a sprawling run, keep five lines of state under the shorthand Evidence Ladder. The label is editorial, not an OpenAI term or a Codex feature.

Field	Record	Warning sign
Problem statement	The observable mismatch: input, output, failed invariant, test or reproducible behaviour	The suspected cause is already embedded in the statement
Current evidence	Trace, test result, code path, log, repro or diff already observed	Speculation outweighs observation
Hypotheses ruled out by current evidence	What the present evidence excludes, and why	“Probably not X” without a discriminator
Remaining hypotheses	The small set of explanations still compatible with the evidence	Every file read creates another theory
Next discriminating test	A check whose possible outcomes separate the remaining explanations	Repeating an unchanged check

Suppose the final output is missing a field. Retrieval may never have returned it, or retrieval may have succeeded and the mapping layer dropped it. A broad repository search does not distinguish those stories. The seam between retrieval output and mapping input does.

If the field is present at that seam, retrieval is ruled out for that reproduction. If it never arrives, there is still no evidence for changing the mapper. A focused trace, fixture, breakpoint, targeted query or single-path command is enough if the result changes what can still plausibly explain the failure.

Sourcegraph’s CodeScaleBench offers a larger example of the same problem. The published results cover 1,281 scored runs across more than 40 large open-source repositories. On one Kubernetes task, ordinary local file exploration ran for 6,000 seconds without producing an answer. With indexed keyword search, semantic search and find-references available, the same agent and task completed in 89 seconds.[2]

Those numbers are not a Codex benchmark, and Sourcegraph sells the context infrastructure used in the comparison. They should not be turned into a speed estimate for another repository. The example is useful because it shows how a sequence of defensible local actions can still amount to a poor global search strategy.

Figure 1 | A wandering loop can stay active without adding evidence. Evidence-driven progress narrows what remains plausible.

A green case can hide the wrong patch layer

Whack-a-mole feels different because something really does become green.

Consider this illustrative path:

Input
  ↓
Retrieval
  ↓
Normalisation
  ↓
Mapping
  ↓
Verification
  ↓
Output

Output A is wrong, so the formatter gets a branch. A passes. Output B then fails and gets another branch. A third case appears, attention moves to the grader, and case-specific logic begins to accumulate. The diffs prove that code changed. They do not prove whether the failures are independent or whether an earlier mismatch is travelling downstream.

OpenAI’s Tax AI case study shows why keeping the intermediate path changes the investigation. The product records source material, extracted fields, provenance, downstream submission and practitioner corrections. Repeated field-level differences are reviewed and grouped before becoming targeted evals. Codex can inspect source packages, extraction schemas, mapper behaviour, grader behaviour, repository code and the evals together. That lets the team distinguish unsupported fields, extraction misses, source-selection problems, mapping gaps and expected workflow noise that a grader might otherwise count as failure.[5]

The final output shows that the path failed, but it does not locate the break. Intermediate state gives the next test a concrete seam to inspect.

For one observable processing path, Earliest Divergence means:

The first point we can observe where the actual state meaningfully stops matching the expected state.

The term is only shorthand for this article. It is not a Codex-native capability, and the first mismatch we can observe is not automatically the ultimate root cause.

There is also no guarantee that a system has one global first divergence. A race condition, asynchronous fan-out or distributed workflow may produce several causal paths. In those cases, follow a concrete execution or trace, locate the earliest mismatch on each relevant path, and then test whether any of those mismatches actually converge on a common cause.

For a linear example, the expected path might be:

Source contains field
→ Retrieval returns field
→ Normalisation preserves field
→ Mapping emits field
→ Verification accepts field
→ Output is correct

The observed path might be:

Source contains field
→ Retrieval returns field
→ Normalisation preserves field
→ Mapping drops field   ← first divergence
→ Verification fails
→ Output is wrong

Verification and output are both broken, but mapping is the first observed mismatch in this trace. A formatter or verifier change may hide the visible symptom while leaving the earlier mechanism untouched.

Figure 2 | Surface patching adds case logic before a shared cause is proven. Earliest Divergence locates the first observable mismatch and patches the layer supported by evidence.

Google SRE separates symptoms, what is broken, from causes, why it is broken.[6] Delta Debugging reduces failure-inducing input or isolates differences between passing and failing cases.[7] Google later used automated bisection to locate the commit where a fuzzing crash first appeared; in the reported experience, developers fixed bugs 2.23 times faster on average when that localisation information was available.[8]

The patch still belongs where the evidence puts the defect. If the parser is the first broken seam, fix the parser. If every upstream state is correct and the formatter violates a clear output contract, fix the formatter. A special-case branch may also be the right representation of a genuine domain rule.

Before keeping a patch, check four things:

1. Is the patch at the first divergence currently visible on this trace?
2. Does it explain a cluster of related failures, or only remove one symptom?
3. Is there a focused check that fails before the change and passes after it?
4. Did the implementation improve, or did the grader, expected output or acceptance threshold become easier to satisfy?

If the grader, expected output or acceptance threshold moved with the patch, a green check no longer shows that the implementation improved.

Before another edit, compress what the run knows

Once a run has read a large part of the repository, collected several failures and accumulated local fixes, “look harder for the root cause” is too vague to steer the next edit. Give it a smaller starting point:

Before changing code, report:

1. The current problem statement.
2. New evidence obtained since the previous step.
3. Which hypothesis that evidence supports or rules out.
4. The earliest observable layer where expected and actual behaviour diverge.
5. The smallest test that can distinguish the remaining hypotheses.

If there is no new evidence, do not repeat the same search or rerun unchanged checks.
Do not present a downstream symptom patch as the root-cause fix unless the evidence supports that layer as the cause. A downstream containment, mitigation, guardrail, or explicit domain rule may still be justified; label it as such and keep the upstream diagnosis open.

Reserve that prompt for investigations that have already started to sprawl. A small bug with a clean reproduction and an obvious cause should normally be fixed directly.

By the time another edit is proposed, the run should be able to say which explanations no longer fit the evidence and what check would separate the ones left. If it cannot, stop editing and get that evidence first.

References

1. OpenAI, Unrolling the Codex agent loop, 23 January 2026.
2. Sourcegraph, Why coding agents fail in large codebases (and what to do about it), 8 May 2026.
3. OpenAI, Harness engineering: leveraging Codex in an agent-first world, 11 February 2026.
4. Google SRE, Effective Troubleshooting.
5. OpenAI, Building self-improving tax agents with Codex, 27 May 2026.
6. Google SRE, Monitoring Distributed Systems.
7. Andreas Zeller and Ralf Hildebrandt, Simplifying and Isolating Failure-Inducing Input, IEEE Transactions on Software Engineering 28(2), February 2002.
8. Google Research, Reducing Time-To-Fix For Fuzzer Bugs, 2021.