gpt-5.4 generates response to earlier messages not the last user message

[cheulyop]

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.305.950 (863)

What subscription do you have?

pro

What platform is your computer?

Darwin 25.2.0 arm64 arm

What issue are you seeing?

not sure if this is the codex app issue or the model issue but

gpt 5.4 (xhigh, without /fast) is keep straying off the reasoning path, and ends up producing response not to the last user message but to the one before that.

in the first screenshot, i asked codex to check for the full parity between korean and english docs, and it did what i asked

but in the second screenshot, i asked codex to give me a summary of our conversation in the current session so far, and it started to reason towards that, only to stray off the path and generate response about the parity between the eng and kor docs

so i'm resending the message until it gets right (which definitely doesn't help my usage limits) didn't have this happen yesterday and earlier today, only started seeing this since this afternoon :/

What steps can reproduce the bug?

just send messages

What is the expected behavior?

the model should respond to the last message, not second last

Additional information

[github-actions]

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

• gpt-5.4 in Codex CLI appears to inject unrelated context/patterns into responses during coding tasks #13823
• Codex stuck in Loops #11897

Powered by Codex Action

[etraut-openai]

I think this is model behavior, not something that's under control of the Codex harness. If you see this again, please use /feedback to upload your session details and post the thread ID here. That will allow us to determine for sure.

[openresearchtools]

GPT-5.4 xhigh seems more biased toward the overall thread and previous tool call context than the user’s most recent message. My workaround is to start a new thread whenever I switch to a task that is not directly related to the current goal. It is a very strong coding model, but it struggles to distinguish between what I’m asking now and what I asked earlier in the thread and what it read in the repo files that don't directly affect what we are working on now. It made me swear at it when it started refactoring non-related parts of codebase, so I won't share the thread 😆 but it's definitely something what was much less present in 5.3 xhigh. I still prefer 5.4 over 5.3 for coding, but it keeps you on your toes.

[cheulyop]

Just had this happen again and submitted a feedback report (019cb7c8-ffb6-7583-9608-66aadce3ebe1):

---

Model reverts to earlier instruction during reasoning phase instead of responding to latest user message

I’m observing a recurring behavior where the model begins a reasoning phase for a new instruction but ends up responding to an earlier message in the conversation instead of the latest user message.

In the session where this occurred, I previously asked the model to check the parity between Korean and English documentation. The model completed that task and we continued the conversation afterward.

Later in the session, I gave a handoff-style message asking the model to begin implementation. This should have triggered a longer reasoning phase because the task is non-trivial.

However, the model only reasoned briefly (around ~16 seconds) and then produced a response addressing the earlier instruction about checking parity between the Korean and English docs — even though that task had already been completed earlier in the conversation.

This pattern appears to repeat:

1. The user provides a handoff-style message expecting the model to start a longer task (e.g., implementation).
2. The model starts reasoning.
3. The reasoning phase stops unexpectedly after a short period.
4. The model generates a response addressing an earlier instruction instead of the latest user message.

Notably:

• The earlier instruction had already been completed.
• The response looks like the model is reattempting or falling back to that earlier task.
• This occurs even though the latest message clearly initiates a new task.

I’ve observed this behavior on gpt-5.4 with:

• reasoning=high
• reasoning=xhigh
• /fast both enabled and disabled

The issue therefore does not appear to depend on reasoning depth or fast mode.

[openresearchtools]

The more I use it, the more this looks like a pattern: after a thread accumulates a fair share of complexity, the model starts choosing the easiest thing it can address right away instead of the most important thing to do next. In coding tasks, that is visible when progress falls from substantial multi-file implementation to tiny, low-value edits in a full turn, or just repeated summaries of previous messages. I cannot prove the cause, but my suspicion is that it is too influenced by general training signals that encourage minimal-effort responses (potentially not intended consequence of I assume merged training data for coding + the rest of GPT training data). Workaround is starting new threads and keeping implementation docs updates per every turn, but this burns so many more tokens, every new thread start becomes half an hour investigation of how everything works so it's not only counterproductive and time wasting, but it's unnecessary load of infrastructure.

[openresearchtools]

Another note: this issue seems to become more prominent when a new run goes through auto-compaction. It almost feels as though auto-compaction is nudging the model away from the current user message, or at least not prioritizing it strongly enough. If that is the reason, then the bug may be simpler than core model behavior.