Intermittent mismatch between displayed collaboration mode and actual model mode
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.417.41555 (1858)
What subscription do you have?
ChatGPT plus
What platform is your computer?
Darwin 25.3.0 arm64 arm
What issue are you seeing?
Description
I encountered a bug where the collaboration mode shown in the UI did not match the mode the model was actually operating under.
In the same thread, the UI appeared to indicate one mode, but the model behaved according to a different mode and enforced the wrong set of constraints. This affected whether the model would execute actions or only produce plans/explanations.
Later in the same thread, the mode behavior returned to normal and the UI and model appeared to be in sync again.
Observed behavior
The UI showed one collaboration mode
The model behaved as if it was in a different mode
This caused a mismatch in allowed behavior, especially around execution vs planning
The issue later resolved within the same thread without a clear user-visible reason
Expected behavior
The collaboration mode shown in the UI should always match the mode the model is actually following.
Actual behavior
The displayed mode and the model’s effective mode became inconsistent.
Impact
This makes mode switching unreliable and confusing. It becomes unclear whether the assistant is actually allowed to execute actions or is still constrained by a previous mode.
Frequency
Intermittent. This has happened multiple times, but I do not currently have reliable reproduction steps.
Additional note
This bug happened in the current thread, but the thread later returned to normal. That suggests the problem may be related to mode-state synchronization or propagation rather than a permanent UI display issue.
Possible cause
A state synchronization issue between the UI layer and the model’s active conversation context.
What steps can reproduce the bug?
Steps to Reproduce
Start a conversation in Plan Mode.
Switch the UI to Default mode.
Ask the model to perform an action that should be allowed in Default mode.
Observe that the model still refuses to execute and says it is in Plan Mode.
What is the expected behavior?
Expected Result
When the UI shows Default mode, the model should behave according to Default mode.
Actual Result
The model continues following Plan Mode constraints even though the UI shows Default mode.
Impact
Creates confusion about whether execution is allowed
Makes mode switching unreliable
Causes repeated user friction because visible state and actual behavior diverge
Frequency
Happens repeatedly; not a one-off incident.
Possible Root Cause
Mode changes appear to update in the UI layer but do not reliably propagate to the model’s active conversation context.
Attachments
screenshot of the UI showing the wrong mode
conversation snippet where the model explicitly says it is still in another mode
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
Adding another current Codex App reproduction of this issue.
Environment:
Observed behavior:
In a Codex App thread, the UI indicated that Plan Mode had been turned off, but the model continued receiving and enforcing a higher-priority Plan Mode instruction. The assistant repeatedly refused to perform mutations and said it was still constrained by Plan Mode, despite the user saying the UI showed Plan Mode was off.
The stale instruction visible to the model was effectively:
User-side actions that did not resolve it:
Expected behavior:
When the Codex App UI exits Plan Mode, the next model turn should receive an authoritative collaboration-mode update that either removes or supersedes the prior Plan Mode developer instruction. The UI should not show execution/default mode while the model context still contains a non-overridden Plan Mode hard rule.
Actual behavior:
The UI-visible mode and the model-enforced mode diverged. This deadlocked the task: the user believed execution was enabled, but the assistant could not perform file edits or other mutations because the stale Plan Mode instruction remained active.
Impact:
This blocks approved work after planning, causes repeated user frustration, and forces a new thread/session as the only practical workaround.
Likely area:
Mode-state propagation/synchronization between the Codex App UI and the collaboration-mode/developer-instruction context sent to the model. If the client updates the visible mode before the model-side state is acknowledged, the UI can become misleading.
I'm seeing the same issue in Codex Desktop.
The UI shows that Plan Mode has been turned off / the session is in Implementation Mode, but the assistant still refuses to edit files or execute implementation steps because it says the current thread is still under Plan Mode instructions.
What I tried:
Observed result:
# Plan Mode (Conversational)developer instruction is still active in the model context.This looks very similar to #27200 and possibly related to #25582, where stale Plan Mode developer instructions can remain visible even after the UI mode changes.
Expected:
Workaround: