Skip to content

Add a clarification-first mode and native ask-human tool #22066

@alexchexes

Description

@alexchexes

What variant of Codex are you using?

App, IDE Extension, CLI

What feature would you like to see?

In my day-to-day Codex usage, I use it not only for well-scoped implementation work with clear and unambiguous instructions, but also for more exploratory development where the request may not have strict boundaries. Sometimes the request may even be a mistaken one (wrong branch or even workspace, etc). In those cases, I still expect Codex to avoid making risky assumptions or doing something nonsensical just to keep moving.

To support that workflow, I use the ask-human-for-context MCP because request_user_input is not available for Default mode turns. I pair it with these instructions:

## Ask human tool
If a missing fact, design choice, or user preference is not 100% clear, and a wrong assumption could materially
affect correctness, safety, architecture, or user intent, use `ask-human-for-context` mcp/tool before proceeding.

If the tool is unavailable or times out without a human response, do not proceed and do not roll back changes unless
it is absolutely necessary (e.g. a broken live/production system, runaway resource consumption, etc.). Instead, stop,
report the current state, repeat the context and question, and let the user answer normally.

Do not optimize for completing the task in one uninterrupted run if clarification would lead to a better decision. 
Making correct design decisions is more important than finishing a subtask without interruptions.

Use `ask-human-for-context` especially for ambiguous requirements, risky tradeoffs, irreversible actions, external 
side effects, and situations where multiple reasonable approaches exist and the preferred one is not 100% clear.
Keep the question consise where possible, but include necessary context details so the user is properly informed.

When a task requires many decisions from the user, or when the user explicitly asks you to ask questions or use
`ask-human` tool, do not limit that to the initial planning phase. Continue talking with the user via that tool
during implementation whenever a new assumption, design choice, external value, or behavior decision appears that
was not already answered. Do not treat early answers as broad permission to infer the remaining details silently.

## Contradictions and questionable requests
If the user's request appears to contradict earlier instructions, previous work, the current state, or a known
constraint, do not silently choose one interpretation. Briefly explain the conflict using `ask-human-for-context`.

If the request seems technically wrong, unsafe, or likely to cause unintended consequences,
always use `ask-human-for-context` to confirm that the user really means it before proceeding.

Common source of confusion: the user may think they're on one branch or workspace when they're actually on another.

But, Codex often ignores these instructions unless I explicitly ask for this behavior in the current session (probably because the default goal is to prioritize completing the task and inferring missing details whenever possible).

I understand that this is preferable for some users and use cases. At the same time, this does not seem to be a niche workflow; searching for terms like "ask human MCP" shows that many users want agents to pause and ask for clarification instead of silently inferring missing context, especially when the task is ambiguous, contradictory, risky, or likely to cause unintended consequences.

It would be very useful if Codex had a native "clarification" or a "missing context" tool, and a configurable mode that teaches it to ask the user in situations like the ones described above. Users who prefer the current behavior could keep clarification disabled or limited by a "calls-per-turn" setting.

Additional information

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    agentIssues related to the core agent loopenhancementNew feature or requestmcpIssues related to the use of model context protocol (MCP) servers

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions