Private live plan file for Plan Mode

Good issue. Additionally, the plan should be accessible post compaction to the models. Compaction is lossy and a plan is a strong point of alignment that should be preserved across this process. I'm currently manually writing it out to a file to avoid this issue.

The "private, untracked agent directory" + host-managed durable artifact pattern in this proposal is the same architectural slot as a feature request I just filed (#20138) for a session-scoped notes panel — both are host-owned, durable, separate from the repo workspace, and both serve as a stable reference that survives compaction.

Worth thinking about whether the underlying primitive (host-managed per-session durable artifacts) is the same and could be one subsystem with two surfaces (your plan file + a notes panel) on top of it, rather than two unrelated implementations. Not pushing a redesign on this issue — just noting the convergence in case maintainers want to look at them together.

Cross-linking for context.

need it so bad, only part where cursor plan mode is much better

I want to add a concrete failure case that makes this feature feel more like a reliability requirement than a convenience feature.

I have went through open and closed issues, tagging a few individuals who participated in those: @etraut-openai @fcoury-oai @aibrahim-oai

Summary

Plan Mode currently treats the generated plan as a transient chat/UI artifact rather than a durable handoff artifact. That breaks down when a planning session is long enough to trigger compaction, or when the user needs to review, refine, or hand off the plan before implementation.

The current Yes, clear context and implement flow helps one narrow happy path, but it does not solve the more general problem this issue describes: the plan should exist as a host-owned durable artifact before any clear/compact/implement transition happens.

Concrete failure case

I recently used Plan Mode for a non-trivial repository design session. The task was intentionally design-only:

• research current Codex marketplace/plugin behavior
• compare Claude Code and Codex marketplace compatibility
• design a dual Claude/Codex marketplace compiler
• preserve existing Claude behavior first
• produce a standalone implementation plan and a /goal artifact later

The plan was long and detailed. During or after planning, context compaction occurred before the plan was written to a file.

After leaving Plan Mode and asking the agent to write the plan artifact, the agent had to reconstruct the plan from the compacted context. The resulting file preserved the broad shape, but it lost important fidelity compared to the original plan shown in Plan Mode.

I then pasted the original plan text back into the session and asked the agent to reconcile the saved artifact. The agent found material differences and had to update the plan file.

That is the core problem: once compaction happens, the transcript is no longer a reliable source of truth for a detailed plan. If Plan Mode cannot write a durable plan artifact, the user has to manually copy/paste the plan or risk implementation from a lossy summary.

Why the current clear-context implementation is not enough

I inspected the current Plan Mode handoff behavior and the relevant merged implementation for Yes, clear context and implement.

The current design appears to keep the most recent proposed plan in live TUI state, currently under a field like:

latest_proposed_plan_markdown: Option<String>

and then passes that cached Markdown into the ClearUiAndSubmitUserMessage flow when the user immediately selects Yes, clear context and implement.

That helps if all of these are true:

• the finalized plan is still present in the live TUI cache
• the user immediately selects the popup option
• the TUI process stays alive
• no later task resets the relevant transient state
• the user does not need to inspect, edit, export, checksum, or reuse the plan elsewhere

But it is not a durable plan artifact.

In current source, the transcript state resets the cached proposed plan on a new task turn:

self.latest_proposed_plan_markdown = None;

So continuing the conversation after the plan can clear the transient plan cache. The cache is also not model-visible after compaction, not exposed as a tool-accessible artifact, and not something a future resumed session can reliably read.

That means the current mechanism is a popup handoff buffer, not a preservation mechanism. Honestly it might be better utilized live during a planning session to reduce hallucination from compaction in-flight within the planning session itself.

Why this matters

For small plans, this may not matter much. For serious planning work, it matters a lot.

A good Plan Mode session often includes:

• read-only repo exploration
• current documentation checks
• decision points
• accepted assumptions
• rejected approaches
• phased implementation steps
• validation commands
• stop conditions
• release or migration constraints

Those details are exactly the things most likely to be degraded by summarization. They are also exactly the things an implementation agent needs to preserve.

The user should not have to choose between:

1. implementing immediately from a context-heavy planning thread
2. clearing context and trusting a transient UI cache
3. relying on a compacted summary
4. manually copying the plan into a file outside Plan Mode

The plan itself is the important artifact. It should be first-class.

Proposed behavior

When Plan Mode produces or updates a proposed plan, Codex should maintain a durable Markdown copy in a host-owned private location, for example:

$CODEX_HOME/plans/<thread-id>/PLAN.md

or another session-scoped path under CODEX_HOME.

This file should be:

• outside the repository by default
• untracked by git
• owned by the Codex host/runtime, not by the model as a workspace edit
• updated whenever the proposed plan changes
• available to the model after compaction as an explicit durable reference
• available to the user for review in an external editor
• clearly marked as temporary/private until the user explicitly exports it

This preserves the no-workspace-mutation guarantee of Plan Mode while still giving the plan durable storage.

Desired UX

After a plan is produced, the Plan Mode completion UI should support actions like:

Yes, implement this plan
Yes, clear context and implement from saved plan
Export plan to file...
Copy plan
No, stay in Plan mode

The important distinction is that clear-context implementation should be seeded from a durable saved plan artifact, not only from transient TUI state.

There should also be a way to view the current private plan path, such as:

Plan saved to: ~/.codex/plans/<thread-id>/PLAN.md

Relationship to existing issues/features

This is related to, but not fully solved by, the existing clear-context handoff flow.

The merged clear-context implementation appears to submit the approved plan into a fresh thread from live TUI state. That is useful, but it does not address:

• compaction before final handoff
• reviewing a plan outside the terminal
• resuming later
• using the plan with /goal
• preserving exact plan fidelity after continued discussion
• exporting the accepted plan into the repo only when explicitly requested

This issue is about a durable host-owned plan artifact, not about adding another manual compaction knob.

Acceptance criteria

A minimal version of this feature would satisfy:

• Plan Mode writes the current proposed plan to a private host-owned Markdown file outside the repo.
• The path is shown to the user.
• The file survives compaction.
• The file survives normal continued discussion in the same Plan Mode session.
• The file is not committed or tracked unless the user explicitly exports it.
• Yes, clear context and implement uses the saved plan artifact as the source of truth.
• The implementation prompt tells the fresh agent to read the saved plan.
• If the TUI process exits unexpectedly, the latest saved plan can still be recovered from the host-owned path.
• A user can optionally export the plan to a repo path after leaving Plan Mode or through an explicit export action.

Stretch Goal - /goal

/goal is extremely powerful, I ship thousands of lines of code that not only conform to the plan, but the condition allows the agent to stay in the loop and have back pressure from tool enforcement like linters, formatters, static code analysis, tests, reinforcing directives in AGENTS.md in context, it is how you stop prompting and start making the tool do serious work. If you have standards, tooling, tests and good hygiene in the project and then have a model write the goal and condition against the durable plan file, the /goal feature is GOATED. I was not surprised to see Claude Code immediately have it after you guys released it.

If you could make Plan mode have another exit option where the planning agent, or another agent reviews and emits the right /goal prompt | condition that matches and satisfies the plan and your AGENTS.md / Skills directives, the feature and your Plan mode would be unstoppable. No other harness has it, none of your competitors have it, all of you are talking about "loop engineering", iykyk.

Yes, implement this plan
Yes, clear context and implement from saved plan
>> Yes, generate goal and condition, clear context and invoke /goal with saved plan <<
Export plan to file...
Copy plan
No, stay in Plan mode

Why this fits Plan Mode

Plan Mode is already meant to produce an implementation contract before edits begin. Treating that contract as ephemeral chat text is the fragile part.

A private host-owned plan file keeps the safety property of Plan Mode while making the plan reliable enough for long, serious engineering tasks.

The key invariant should be:

Once Codex asks the user whether to implement a plan, the exact plan being offered for implementation should already exist as a durable artifact that can survive compaction, clearing context, resume, or handoff.

Strong +1 on this. This is honestly one of the main reasons I still reach for Claude Code on planning-heavy work.

Once I’ve spent time refining and approving a plan, I want that exact plan saved somewhere durable—not left as chat text that can get blurred or lost during compaction. It should survive compaction, restarts, and handoffs, and the agent should always be able to find it again.

Codex is otherwise ridiculously good. If plans were file-backed and reliably carried into implementation, I could genuinely see myself dropping Claude Code entirely.