Proposal: Hybrid Codex CLI mode that combines coding with interactive planning

I would like to suggest a hybrid mode for Codex CLI that combines the strengths of coding mode and planning mode.

The main advantage of planning mode is that it is interactive. When the model reaches an important uncertainty or decision point, it can stop, ask clarifying questions, and then continue planning with the new information taken into account.

Coding mode, on the other hand, is much more autonomous. This is useful when the task is straightforward, but it becomes a problem when the model reaches a fork in the implementation and makes assumptions on its own. Sometimes those assumptions affect architecture, database structure, public APIs, file organization, dependencies, migrations, or other decisions that are expensive to undo later.

The current limitation is that these two modes are separated:

Planning mode can ask questions and refine the approach, but it cannot write files.

Coding mode can write and modify files, but it usually does not pause to ask for clarification when an important decision appears.

It would be very useful to have an optional hybrid mode where Codex can write code, but is also allowed to pause during implementation and ask the user targeted questions before continuing.

For example, the model could continue autonomously for small local decisions, but ask before making higher-impact choices such as:

  • choosing between different architectural approaches

  • changing the database schema

  • introducing a new dependency

  • modifying public interfaces

  • applying destructive migrations

  • reorganizing project structure

  • making a security-sensitive decision

  • choosing behavior that was not clearly specified in the original prompt

This could work as a separate mode or setting, for example:

  • interactive coding mode

  • plan-aware coding mode

  • ask-before-major-decisions mode

  • a configurable approval policy for coding tasks

The goal is not to make coding mode slower for everyone. The goal is to provide an optional workflow for users who want Codex to implement code, but still collaborate with them when the task contains meaningful ambiguity.

In practice, this would make Codex CLI much more useful for larger real-world projects, where implementation often requires several decisions that are hard to fully describe in the initial prompt.

A possible workflow could be:

  1. The user gives Codex a coding task.

  2. Codex starts analyzing and implementing.

  3. When Codex reaches an important uncertainty, it pauses and asks a concise question.

  4. The user answers.

  5. Codex continues writing files with the clarified context.

  6. This repeats only when the decision is significant enough.

This would combine the best part of planning mode — interactive clarification — with the best part of coding mode — actually modifying the project.

I think this would be especially valuable for complex refactors, new feature implementation, database-related work, agent workflows, and multi-step project changes where autonomous assumptions can easily lead to the wrong result.

I think this idea could also be useful as an optional setting for /goal mode.

I understand that /goal is designed for continuous autonomous work until the target result is achieved. That is a strong and useful concept. However, full autonomy is not always the best choice.

Sometimes a task reaches a point where a human decision is needed. Without that checkpoint, the agent may continue trying potentially wrong approaches again and again, either failing to reach the result or eventually producing a result based on an incorrect assumption.

So it would be useful to have two ways to run /goal:

  • full autonomous /goal mode, when the user fully trusts the agent to make decisions and keep working until the result is reached

  • /goal with critical-decision confirmations, when the user wants the agent to continue working autonomously but pause before important choices

For example, the agent could ask for confirmation before changing architecture, adding dependencies, modifying database schema, applying destructive changes, or choosing between several unclear implementation paths.

This would preserve the main purpose of /goal, but give users more control when the task contains important ambiguity.

In other words:

If I fully trust the agent, I run /goal in full autonomous mode.

If I want control over key decisions, I run /goal with confirmation checkpoints.