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

Open 💬 4 comments Opened May 23, 2026 by heelee912

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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.

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

Use Plan Mode first to clarify the request and produce the final <proposed_plan>.
After that plan is accepted/finalized, create or update the active Goal from the finalized plan.
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:

Treat the user prompt as a plan-intent request, not as the final active goal yet.
Run Plan Mode normally until a decision-complete <proposed_plan> is produced.
After the user accepts/finalizes the plan, automatically create/update the active Goal from the finalized plan or implementation objective.
The active goal should preserve the finalized plan as the execution contract and completion criteria.
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.

#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.

View original on GitHub ↗

4 Comments

heelee912 · 3 months ago

Related prototype reference:

https://github.com/heelee912/codex-desktop-patch

This shows a concrete UX shape for the interaction described above: after Plan Mode finalizes a plan, a Set as Goal action promotes that finalized plan into the Goal objective.

etraut-openai contributor · 3 months ago

Thanks for the feedback. We considered adding a "Set this plan as Goal and implement" feature, but we were reluctant to do so because goal mode is more of a power-user feature, but plan mode is used by nearly all users. You need to be careful when using goal mode because it can easily chew through your token usage. That's fine if that's your intent, but it can take users by surprise if they're not expecting it.

I do think there's an opportunity to better compose the plan and goal features, but we'll need to be careful in how we do it. Since /goal was just released, we'd like to wait and get a little more feedback from users before making a decision here.

0xc1f · 3 months ago

Thanks for the feedback. We considered adding a "Set this plan as Goal and implement" feature, but we were reluctant to do so because goal mode is more of a power-user feature, but plan mode is used by nearly all users. You need to be careful when using goal mode because it can easily chew through your token usage. That's fine if that's your intent, but it can take users by surprise if they're not expecting it. I do think there's an opportunity to better compose the plan and goal features, but we'll need to be careful in how we do it. Since /goal was just released, we'd like to wait and get a little more feedback from users before making a decision here.

Creating a plan is indeed a highly suitable /goal. The model should not stop if the plan does not actually match the expectation. Make /goal compatible with plan mode as this will increase the effectiveness of the planning process itself.

And thanks for that useful feature!

johnsilvavlogs · 2 months ago

Adding another user report in favor of this workflow.

I use /goal heavily for durable execution, but I also rely on Plan Mode to get a detailed, decision-complete plan before letting the agent run. After Plan Mode produces the final plan, the UI/workflow effectively leaves me with a binary choice: implement the plan or do not implement it. What I want at that point is a third, explicit power-user action:

Set this plan as Goal and implement

or equivalently:

Implement this plan as a Goal

Current workaround: after the plan is approved, I have to manually ask the agent to implement the plan and create/set a goal for itself. That is janky and easy to get wrong because the goal can end up being created from a meta-instruction, a paraphrase, or the wrong moment in the conversation rather than from the finalized <proposed_plan> and its completion criteria.

The important distinction for me is that the goal should be derived from the accepted plan, not from the original raw prompt. The accepted plan is the real execution contract.

I understand the concern mentioned above that Goal mode can burn tokens and should not surprise normal Plan Mode users. That seems solvable with an explicit opt-in action after the plan is finalized, possibly with a short warning such as “This will continue working autonomously until the goal is complete, blocked, or budget is exhausted.”

Suggested behavior:

Plan Mode runs normally and produces the final <proposed_plan>.
The user can choose a clear action: Implement, Set as Goal, or Set as Goal and Implement.
If Set as Goal and Implement is chosen, Codex creates the goal from the finalized plan summary and preserves the plan as the completion checklist.
Goal completion should require implementation and verification against that plan, not just the planning conversation ending.

This would make Plan Mode and Goal Mode compose cleanly for power users without changing the default Plan Mode path for everyone else.