Mixed plan and code mode instructions in resumed threads

Summary

When resuming a thread that has switched between collaboration modes (e.g., plan → code or code → plan), the model's reasoning trace indicates it sees conflicting instructions:

"the system and developer messages show mixed plan and code modes, but I'll proceed in code mode"

Observed Behavior

• User is in code mode at the time of observation (using CodexMonitor)
• Several mode switches during the session
• No custom AGENTS.md or user instructions mention plan mode
• The model explicitly notes seeing mixed mode instructions in its reasoning

Investigation Findings

This was discovered while debugging CodexMonitor, but the issue appears to originate in the Codex CLI/app-server.
Here's an image

<img width="1272" height="176" alt="Image" src="https://github.com/user-attachments/assets/3fece406-64e1-4499-bc5f-c1850142d3ec" />

Session data analysis (from a session with mode switches):

• 573+ occurrences of collaboration_mode in the session JSONL
• Both the full plan mode template (~121 lines) AND code mode instructions appear in the conversation history
• Old mode instructions appear to persist after mode switches causing model confusion and display issues with plans.

Potential location (please verify - this is best guess using OpenCode CLI to debug):

• codex-rs/core/src/codex.rs around build_initial_context()
• When modes switch, new instructions are added but previous mode instructions may remain in the conversation history

Environment

• Codex CLI (app-server mode)
• macOS
• Thread resumption with a few mode switches within CodexMonitor. Didn't try in Codex App because can't see reasoning trace and agent calls.

Reproduction

1. Start a thread in one collaboration mode (e.g., code mode)
2. Switch to a different mode mid-conversation (e.g., plan mode)
3. Switch back or continue using the thread
4. Resume the thread in a later session
5. Observe the model's reasoning trace mentioning mixed mode instructions

Notes

• This issue was discovered via CodexMonitor but appears to be in the Codex CLI layer
• Please double-check these findings - we may have misread the code flow
• Happy to provide additional session data or logs if helpful