When /goal is used in Plan Mode, defer goal creation until the plan is finalized

What variant of Codex are you using?

Codex Desktop on Windows.

UX evidence

The Codex Desktop composer currently presents Plan and Goal as independent controls that can be enabled together in the same prompt composer.

<img width="413" height="111" alt="Image" src="https://github.com/user-attachments/assets/dbd5cf57-e9a3-4e14-ab54-8f529553efbe" />

From that UX, I expected the combined behavior to be:

1. Use Plan Mode first to clarify the request and produce the final <proposed_plan>.
2. After that plan is accepted/finalized, create or update the active Goal from the finalized plan.
3. Track execution against that finalized plan, not against the initial raw prompt.

In other words, the UI suggests that Plan Mode and Goal mode are composable. If they are composable, Goal creation should be staged from the finalized plan rather than created immediately from the initial prompt.

Summary

When Goal mode and Plan Mode are both active, /goal currently appears to create or activate the goal immediately, before Plan Mode has produced a decision-complete plan. This makes the goal track the initial planning prompt or meta-question rather than the finalized implementation objective.

I expected the two features to compose differently: Plan Mode should first produce the final <proposed_plan>, and only after that plan is accepted/finalized should Codex automatically create or update the active goal from the finalized plan/execution objective.

Current behavior observed

In a Codex Desktop thread with Goal + Plan Mode active:

• The composer UI allowed both Plan and Goal to be selected at the same time.
• A goal became active immediately from the user's prompt.
• Plan Mode still constrained the assistant to planning behavior, so no implementation should happen yet.
• Because the goal already existed, the goal lifecycle could complete against the planning/meta prompt instead of becoming a durable execution goal for the eventual implementation plan.

This is adjacent to #21512, but the request here is not only that Plan Mode should prevent direct file edits. The requested behavior is that goal creation should be staged until Plan Mode has finished producing the plan.

Expected behavior

When a user combines /goal with Plan Mode:

1. Treat the user prompt as a plan-intent request, not as the final active goal yet.
2. Run Plan Mode normally until a decision-complete <proposed_plan> is produced.
3. After the user accepts/finalizes the plan, automatically create/update the active Goal from the finalized plan or implementation objective.
4. The active goal should preserve the finalized plan as the execution contract and completion criteria.
5. The goal should not be marked complete merely because the planning conversation ended; completion should require the planned work to be implemented and verified.

A good UI option might be something like:

• Set this plan as Goal and implement

or the existing plan-implementation confirmation could implicitly stage the Goal after plan acceptance.

Why this matters

Goal mode is useful as a durable execution tracker, but Plan Mode is specifically for turning an ambiguous request into a concrete implementation plan. If Goal mode starts before the plan exists, it can track the wrong artifact: the initial prompt rather than the final execution contract.

Deferring goal creation until after the plan is finalized would make the combined workflow much more predictable:

• Plan Mode handles clarification and plan generation.
• Goal mode tracks execution of the accepted plan.
• The user does not need to manually copy the final plan into a new /goal prompt.
• Goal completion criteria become tied to the final plan instead of a loose initial request.

Related

• #21512 reports that /goal can edit files directly while Plan Mode is on. This request is complementary: Plan Mode should remain the planning gate, and Goal creation should happen after that gate produces an accepted plan.