Plan Mode remains enforced after resuming a thread even though the CLI reports Default mode

What version of Codex CLI is running?

The thread was created and left in Plan Mode with:

codex-cli 0.144.5

The same thread was resumed the next day with:

codex-cli 0.146.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.6-sol, medium reasoning

What platform is your computer?

Linux 7.0.0-15-generic x86_64

What terminal emulator and version are you using (if applicable)?

• Codex CLI/TUI
• TERM=xterm-256color
• Not running inside tmux
• Terminal emulator and version were not captured

Codex doctor report

Not captured.

What issue are you seeing?

After resuming a thread that had been left in Plan Mode before exiting Codex, the visible/current client mode no longer indicated Plan Mode and the interaction layer reported Default mode. However, the agent continued to receive Plan Mode constraints. The agent repeatedly refused to modify repository files because its system-level thread instructions still required Plan Mode.

Using /plan to toggle the mode did not resynchronize the two states. The client and interaction tooling indicated Default mode, while the agent continued to receive and obey the persisted Plan Mode constraint.

This makes the resumed thread permanently unable to perform implementation work.

What steps can reproduce the bug?

1. Start Codex CLI 0.144.5.
2. Open a thread and enable Plan Mode with /plan.
3. Continue working in Plan Mode.
4. Exit Codex while the thread is still in Plan Mode.
5. Resume the same thread later using Codex CLI 0.146.0.
6. Observe that the client no longer displays Plan Mode or otherwise reports Default mode.
7. Ask Codex to modify a file in the active repository.
8. Observe that the agent refuses because its system-level thread instructions still require Plan Mode.
9. Use /plan to toggle Plan Mode and try again.
10. Observe that the client-facing state changes, but the agent remains bound by the stale Plan Mode instruction.

What is the expected behavior?

The collaboration mode shown by the CLI, exposed by interaction tooling, and injected into the agent's system instructions should always be synchronized.

When a resumed thread is switched out of Plan Mode, the stale Plan Mode constraint should be removed before the next turn.

A thread created by an older CLI version should also migrate its collaboration mode state correctly when resumed by a newer version.

Actual behavior

The client reports Default mode, but the agent continues to receive a mandatory Plan Mode instruction and refuses all repository mutations.

The state cannot be repaired from within the affected thread.

Workaround

Start a completely new thread in Default mode. Forking or continuing the affected thread may preserve the stale state, so a fresh thread is safer.

Impact

• Existing long-running threads can become unusable for implementation.
• The UI and the agent disagree about whether file modifications are permitted.
• Users may repeatedly toggle /plan or change models without resolving the problem.
• The failure is confusing because there is no visible indication that a stale Plan Mode constraint is still active.

Additional information

This appears related to:

• #10570, which reports mixed Plan and code mode instructions in resumed threads.
• #35237, which reports a split between the CLI-visible mode, tool/backend enforcement, and injected collaboration-mode instructions.
• #22773, which includes stale Plan state in mobile/desktop Remote Control, although that issue focuses mainly on Remote Control.

This reproduction is specific to Codex CLI/TUI session resume, with a version change between session creation and resume.