Skip to content

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

Closed as duplicate
Closed as duplicate
gpt-5.4 generates response to earlier messages not the last user message#13864
Labels
appIssues related to the Codex desktop appbugSomething isn't workingmodel-behaviorIssues related to behaviors exhibited by the model

Description

@cheulyop
cheulyop
opened on Mar 7, 2026

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

Image

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

Image

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

Activity

  1. cheulyop
    added
    appIssues related to the Codex desktop app
    on Mar 7, 2026
  2. github-actions
    added
    bugSomething isn't working
    model-behaviorIssues related to behaviors exhibited by the model
    on Mar 7, 2026

  3. github-actions commented on Mar 7, 2026

    @github-actions
    github-actionsBot
    on Mar 7, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. etraut-openai commented on Mar 7, 2026

    @etraut-openai
    etraut-openai
    on Mar 7, 2026
    Contributor

    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.

  5. openresearchtools commented on Mar 7, 2026

    @openresearchtools
    openresearchtools
    on Mar 7, 2026

    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.

  6. cheulyop commented on Mar 8, 2026

    @cheulyop
    cheulyop
    on Mar 8, 2026
    Author

    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.

  7. cheulyop
    changed the title [-]gpt-5.4 generates response to the second to the last message not the last user message[/-] [+]gpt-5.4 generates response to earlier messages not the last user message[/+] on Mar 8, 2026

  8. openresearchtools commented on Mar 9, 2026

    @openresearchtools
    openresearchtools
    on Mar 9, 2026

    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.

  9. openresearchtools commented on Mar 9, 2026

    @openresearchtools
    openresearchtools
    on Mar 9, 2026

    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.

  10. metaxasa commented on Mar 11, 2026

    @metaxasa
    metaxasa
    on Mar 11, 2026

    I'm getting this repeatedly too on long running threads, compaction also seems to be a trigger. Raised feedback, latest one is 019cd18a-12b6-7c21-a8d4-fca2d315cb43.

  11. cheulyop commented on Mar 12, 2026

    @cheulyop
    cheulyop
    on Mar 12, 2026
    Author

    same. this behavior happens a lot more often on long threads, which has been compacted multiple times. much less on new threads. maybe this is tradeoff that comes with gpt-5.4 being great at understanding / summarizing full context of long threads.

  12. andrewlucas-bg commented on Mar 12, 2026

    @andrewlucas-bg
    andrewlucas-bg
    on Mar 12, 2026

    I'm seeing this a lot since switching to GPT-5.4 and enabling the 1 million token context window. Not sure if the context window is related. It just happened to me multiple times in a single thread around the 75% context remaining mark, which should be comparable to the old limit. This happened in a thread that had not experienced any compaction. Basically the thread is busted and I need to start over. It does not feel like a model behavior. It feels like some sort of context injection / memory issue. I tried "/feedback" and it just said:

    Noted. The failure mode you’re describing is: the assistant latches onto an older turn and answers that instead of the latest user message, and you’ve seen it repeatedly since
  moving to 5.4 with 1M context enabled.

  I can’t file product feedback directly from here, but that’s a crisp bug report as written.

    Also, the model is still able to access the correct user message somehow, but its memory seems all kinds of messed-up.

    *Okay, back to the task at hand. What's the last task I gave you?*
Your last task was to fix the drag interaction bug where a failed drag, like trying to drag a folder into itself, could leave drag effectively broken until the app was restarted.
*No, that's not it*
The last concrete task you gave me was to change the checkbox text to Completed.
*After that*
The last bigger task you gave me after the drag work got sidetracked was:
Add a substring search bar to the list, using the pattern from the sibling app.
*Yess there you go*
I’m picking that back up now.
...

    UPDATE: Here's a good example. Note how Codex acks the user request and then there's a solid line and it snaps back to a previous request about a merge conflict.

    In this case: gpt-5.4 high fast · 68% left · 65.3M in (1 mil context enabled).

    Image

  13. haydenkwak commented on Mar 12, 2026

    @haydenkwak
    haydenkwak
    on Mar 12, 2026

    If these responses are inherent to the model’s characteristics, should we wait for GPT-5.5?😭😇🥹😂🤬🫠😵

  14. JJLiebig commented on Mar 14, 2026

    @JJLiebig
    JJLiebig
    on Mar 14, 2026

    Encountering this a fair few times recently, threadid: 019ce89f-a1a4-7e11-b2c8-c6c5d1e4487d

    Interestingly this was before compaction with context at 14% left after the wrong response was finished.

  15. mehulparmariitr commented on Mar 19, 2026

    @mehulparmariitr
    mehulparmariitr
    on Mar 19, 2026

    Happening with me as well. It usually occurs when the context becomes very large—around 300k tokens or so. Is OpenAI looking into this?

  16. andrewlucas-bg commented on Mar 20, 2026

    @andrewlucas-bg
    andrewlucas-bg
    on Mar 20, 2026

    Happening with me as well. It usually occurs when the context becomes very large—around 300k tokens or so. Is OpenAI looking into this?

    Agreed. I've started always manually compacting by around 300k, and I don't think I've seen the issue since. Basically using the 1mil context window to eek out a little buffer compared to the default 250k window.

  17. luispittagros commented on Mar 27, 2026

    @luispittagros
    luispittagros
    on Mar 27, 2026

    Same thing happenings Using 1M Context.

  18. etraut-openai
    marked Codex seemed to re-answer an earlier prompt when I gave it a new prompt #14486 as a duplicate of this issue on Mar 29, 2026
  19. etraut-openai
    closed this as a duplicateof Codex replies to earlier messages instead of latest one in conversations #8648 on Mar 29, 2026
  20. etraut-openai
    unmarked Codex seemed to re-answer an earlier prompt when I gave it a new prompt #14486 as a duplicate of this issue on Mar 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingmodel-behaviorIssues related to behaviors exhibited by the model

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions