[Windows app] Plan approval controls disappear after revising proposed plan

Open 💬 3 comments Opened Jul 19, 2026 by ayushrocks012
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Codex variant and version

  • Surface: Codex desktop app for Windows
  • Package: OpenAI.Codex 26.715.4045.0 (x64)
  • Executable file version: 150.0.7871.124
  • Windows build: 10.0.26200.0
  • Project environment: local WSL-backed project
  • Observed: 2026-07-19

Summary

After a user rejects an initial proposed plan and asks Codex to revise it, the revised response is still emitted as a complete <proposed_plan>...</proposed_plan>, but the Implement this plan? approval controls no longer appear.

The revised plan renders as an ordinary assistant response even though it explicitly stops pending approval.

Steps to reproduce

  1. Enter Plan mode in the Windows Codex app.
  2. Ask Codex to create an implementation plan.
  3. Wait for the first proposed plan.
  4. Confirm that the UI displays:
  • Yes, implement this plan
  • No, tell ChatGPT what to do differently
  1. Click No, tell ChatGPT what to do differently.
  2. Enter corrections to the plan and send them.
  3. Codex returns a revised response wrapped in <proposed_plan>...</proposed_plan>, ending that work is stopped pending approval.
  4. Observe that the implementation/revision controls are no longer displayed.

Expected behavior

Every revised <proposed_plan> response should display the same approval controls as the first plan, or an equally clear Approve revised plan action.

Actual behavior

The revised plan appears as ordinary output with no approval affordance. The user has to infer that they should leave Plan mode and type a separate implementation authorization.

Impact

  • The plan state is ambiguous.
  • Users may believe the revised plan was not recognized.
  • Users may repeatedly re-plan, start another task, or remain stuck in Plan mode.
  • Explicit implementation authorization becomes unnecessarily indirect.

Workaround

Turn off Plan mode and manually send an implementation-authorization message.

Suggested fix

  • Recreate or preserve the approval controls after every plan revision.
  • Treat every final <proposed_plan> item consistently, regardless of whether it is the first plan or a revision.
  • If losing the controls is intentional, show an explicit state transition and a clear implementation action.

Diagnostics

  • Original Windows-app task ID: 019f77e1-993e-7692-9888-8686f5805498
  • Uploaded feedback/diagnostic thread ID: 019f7832-79cf-7b01-961a-71bd130538af
  • The diagnostic upload was created from Codex CLI 0.144.1 because the side task could not automate the Windows feedback dialog. The original Windows-app task ID above is the reproduction source.
  • Repository plan contents are intentionally omitted because they are not needed to reproduce the UI-state problem.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #33831

Powered by Codex Action

ayushrocks012 · 1 month ago

I reviewed #33831. It is related, but this report has a different trigger and exercises a different state transition.

| | #33831 | #34101 |
|---|---|---|
| Trigger | Restart/update the Codex app after the first plan controls appear | Click No, submit plan corrections, and receive a revised <proposed_plan> |
| Session lifecycle | Process/task is reloaded | Same uninterrupted live task; no restart, update, navigation, or resume |
| State being tested | Persistence/hydration of an existing approval prompt across restart | Creation/re-arming of approval controls for a new revised-plan result |
| Failure point | Controls disappear after reopening | Controls are never rendered for the second plan |

A persistence fix for #33831 could still leave the live plan-revision transition broken, and a revision fix here would not necessarily restore controls after restart.

Suggested separate regression cases:

  1. Restart case: first plan → controls visible → restart app → controls still visible.
  2. Revision case: first plan → click No → send corrections → second <proposed_plan> → fresh controls visible, without any restart.

Please keep #34101 open as a separate-but-related reproduction unless maintainers confirm that the same root cause and fix cover both paths.

ikiddoi · 10 days ago

same issue fix this