Summary
Plan Mode should support a first-class "reject with feedback" path when the user declines a proposed plan.
Right now, rejecting or declining a plan is too coarse for a common real workflow: the user does not want to abandon the plan, they want to explain what is wrong with it so Codex can revise it. The missing piece is an inline feedback input immediately after rejection.
Current behavior
When Codex proposes a plan, the approval UI generally treats rejection as a decision separate from the user's actual critique. The user then has to manually type a follow-up in the normal composer, and the model may or may not interpret it as structured plan revision feedback.
In practice, users reject plans because of specific defects:
- scope is too broad or too narrow
- implementation order is wrong
- tests or validation are too weak
- a risky migration is missing
- UI/UX details are underspecified
- assumptions are wrong
The UI does not make that critique path explicit.
Expected behavior
After the user chooses Reject / Revise / Do not implement, the TUI should move focus into an inline feedback composer tied to that plan decision.
A minimal version would be enough:
- User receives a proposed plan.
- User selects Reject / Revise.
- TUI opens a focused feedback input.
- User types a short reason such as
testing is too weak; include device validation.
- Codex receives this as plan-revision feedback and produces a revised plan, instead of treating the turn as an unrelated chat message.
A keyboard path such as Tab from the rejection choice into the feedback input would make this especially smooth.
Why this matters
Plan Mode is most useful when the user can steer the plan before implementation. A binary accept/reject interaction is too low-bandwidth for large engineering work.
For serious refactors, rejecting a plan almost always means "revise this with these constraints," not "discard this topic." Making that explicit would reduce repeated plan loops and make the approval step much more useful.
Related issues
Related but not the same:
This issue is specifically about the human UI path for giving structured feedback when rejecting a proposed plan.
Summary
Plan Mode should support a first-class "reject with feedback" path when the user declines a proposed plan.
Right now, rejecting or declining a plan is too coarse for a common real workflow: the user does not want to abandon the plan, they want to explain what is wrong with it so Codex can revise it. The missing piece is an inline feedback input immediately after rejection.
Current behavior
When Codex proposes a plan, the approval UI generally treats rejection as a decision separate from the user's actual critique. The user then has to manually type a follow-up in the normal composer, and the model may or may not interpret it as structured plan revision feedback.
In practice, users reject plans because of specific defects:
The UI does not make that critique path explicit.
Expected behavior
After the user chooses Reject / Revise / Do not implement, the TUI should move focus into an inline feedback composer tied to that plan decision.
A minimal version would be enough:
testing is too weak; include device validation.A keyboard path such as
Tabfrom the rejection choice into the feedback input would make this especially smooth.Why this matters
Plan Mode is most useful when the user can steer the plan before implementation. A binary accept/reject interaction is too low-bandwidth for large engineering work.
For serious refactors, rejecting a plan almost always means "revise this with these constraints," not "discard this topic." Making that explicit would reduce repeated plan loops and make the approval step much more useful.
Related issues
Related but not the same:
This issue is specifically about the human UI path for giving structured feedback when rejecting a proposed plan.