Plan mode appears to bind to the next runnable task instead of the queued prompt it was selected for
Open 💬 3 comments Opened Apr 16, 2026 by jlsegb
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of the Codex App are you using (From “About Codex” dialog)?
26.409.20454 (1462)
What subscription do you have?
Pro
What platform is your computer?
Darwin 24.6.0 arm64 arm
What issue are you seeing?
I’m seeing behavior in Codex where plan mode does not appear to stay attached to the specific queued prompt I selected it for.
What steps can reproduce the bug?
Prompt A → executing
Prompt B → queued
Enable Plan mode
Queue Prompt C
Prompt A finishes
Prompt B starts → runs in Plan mode (unexpected)
Disable Plan mode
Prompt B finishes
Prompt C starts → runs as a normal prompt (not Plan)
What is the expected behavior?
When I queue Prompt C with plan mode enabled, plan mode should apply only to Prompt C, regardless of when it executes
Additional information
_No response_
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I went through the file codex/codex-rs/tui/src/chatwidget.rs. The bug occurs because queued prompts read the global UI state at dispatch time, meaning a later UI toggle (like enabling Plan Mode) unintentionally alters an already-queued task.
I added a queued_collaboration_mask to the UserMessage struct to snapshot the exact collaboration mode at the moment the user hits Enter. The dispatcher now prioritizes this stamped state, ensuring prompts always execute in their intended mode regardless of subsequent UI changes.