When Codex Should Ask Instead of Guessing

A session that guesses confidently at an ambiguous instruction and gets it wrong has cost you a wasted turn and a diff to discard. A session that asks a clarifying question at the right moment has cost you thirty seconds. The difference between those two outcomes is entirely about whether the ambiguity actually got surfaced before the work happened, and that's something you can influence.

Why models default toward guessing rather than asking

A model generating a confident, complete-looking answer reads as more helpful, in the moment, than one pausing to ask a question — and that bias toward producing forward progress is baked into how these systems are generally built and evaluated. Left to its own judgment, Codex will often resolve an ambiguity silently, picking a reasonable interpretation and running with it, rather than stopping to check. That's often fine. It's costly specifically on the ambiguities where a wrong guess is expensive to unwind.

The kinds of ambiguity worth explicitly inviting a question about

Not every ambiguity deserves a pause — a genuinely trivial naming choice or a minor stylistic decision is fine left to the model's judgment, and stopping to ask about every small thing would be its own kind of friction. What's worth explicitly flagging as "ask me if unsure" are decisions with real, hard-to-reverse consequences: which of two plausible database schema changes to make, whether a breaking API change is actually acceptable here, which of several reasonable architectural approaches to commit to for something that'll be expensive to unwind later.

How to actually invite the question

Simply telling a session, at the start of a task, that you'd rather be asked than have it guess on anything genuinely ambiguous measurably changes its behavior — it's a real, effective instruction, not just a hopeful request into the void. Pairing that with a concrete example of what you consider "genuinely ambiguous enough to ask about" versus "fine to decide independently" sharpens the calibration further, since "ask if unsure" without any sense of the bar for "unsure" can still swing too far in either direction.

Recognizing when a session guessed instead of asking

The tell is usually in the diff or the summary: a session that silently picked one of several reasonable interpretations tends to mention its choice matter-of-factly, without flagging that alternatives existed. Reading a summary for phrases like "I assumed" or "I chose to" is worth doing specifically on tasks where you know there was genuine ambiguity — those are the moments a guess happened, whether or not it was flagged as one, and worth a deliberate check on whether the assumption matches what you actually wanted.

What to do once you notice a guess you disagree with

Correcting a wrong guess quickly, as soon as you notice it, is far cheaper than letting several more turns build on top of it — an incorrect assumption early in a session tends to propagate forward into everything built afterward, and the longer it goes uncorrected, the more has to be unwound to fix it. Treat catching a bad guess early as a normal, expected part of the workflow rather than a sign something went badly wrong; it's a much smaller course-correction than discovering the same wrong assumption at the very end of a long session.

Why "ask more" isn't universally the right tuning either

It's worth resisting the instinct to push every session toward maximal caution and constant clarification — a session that stops to ask about every minor decision produces a worse, slower experience than one that makes reasonable calls on genuinely low-stakes ambiguity and only surfaces the ones that actually matter. The goal isn't more questions in general; it's the right questions, on the decisions where a wrong guess is genuinely expensive, and confident independent judgment everywhere else.

Building this into how you scope tasks generally

Over time, the tasks worth flagging "ask if unsure" on tend to have a recognizable shape — anything touching a public interface, anything hard to reverse once shipped, anything where two team members might reasonably disagree about the right call. Recognizing that shape before starting a task, rather than only reacting after a wrong guess, is what turns this from a reactive fix into a proactive habit that saves the wasted turn in the first place.

Asking is also a cost, and it's worth being honest about that

A clarifying question, however cheap relative to a wasted turn, still isn't free — it costs a round trip, and for a genuinely unattended workflow like CI, a question with nobody present to answer it is worse than a reasonable guess, since it stalls the pipeline rather than producing an imperfect-but-reviewable result. This is part of why approval mode never is appropriate specifically for unattended contexts: it's implicitly accepting that guesses, not questions, are the right default when no one's there to answer, which makes scoping those tasks tightly enough that a wrong guess is cheap to recover from all the more important.

How this interacts with sandbox and approval mode

It's worth noticing that this page is about a different kind of "asking" than approval prompts — an approval prompt asks permission to act within the bounds of what's technically allowed; a clarifying question asks about intent, what the right action even is in the first place. A session can be under the most permissive sandbox and approval settings and still benefit enormously from being told to ask about genuine ambiguity, because that instruction addresses a different kind of uncertainty than either dial does.

Calibrating this over time with a specific collaborator

If you work with Codex regularly on a specific codebase, it's worth paying attention to which kinds of guesses it tends to get right on its own and which kinds it tends to get wrong — that pattern, once you notice it, is more useful calibration for future "ask if unsure" instructions than a generic rule, since it reflects the actual gaps in context a session has for your specific project rather than a theoretical list of risky decision categories.