Codex replies to earlier messages instead of latest one in conversations

What version of Codex is running?

0.77.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.2-xhigh

What platform is your computer?

No response

What issue are you seeing?

In multi-message conversations with Codex, the assistant sometimes responds to an earlier message instead of the most recent one. For example, I had a conversation with six messages. By the sixth message, I had moved on to asking a different question, but Codex's final summary acted as if it was still on the third message. The third message asked about a question A and its solution, while the sixth asked about question B. Even though the topic changed at the sixth message, Codex still responded about question A. This happens frequently and suggests that Codex may be referencing the wrong message in the conversation history.

What steps can reproduce the bug?

Start a conversation in Codex and send several messages (e.g., six messages).
In an earlier message (e.g., the third message), ask question A and wait for a response.
In a later message (e.g., the sixth message), ask a different question B.
Observe that Codex's summary or response refers back to question A rather than answering question B.
This suggests that Codex is using the wrong message as context.

What is the expected behavior?

Codex should respond to the current message, acknowledging the latest context. After a user moves from question A to question B, the assistant should answer question B and not revert to a previous question. The summarization should maintain the correct message pointer in the conversation.

Additional information

the pattern is randomly happening, and it has a higher chance to happen after we compacting the context within the conversation

I also frequently see this behavior. Codex repeats previous responses (at least 1) although it didn't work on the same topic in the last task. Here, too, it is in the context of a huge project (GPT-5.1-Codex-Max with High effort, Local Agent mode, ~60% context window. I never tried to "compact the context" (didn't even know that this is possible)

Please use the /feedback slash command to upload your session and post the thread ID here.

I've been seeing this too - only since updating to the latest version of the plugin.

My feedback thread ID: 019b1a35-5b10-7741-93bb-58589661a52c

Thanks for reporting. We are aware of this issue with compacted conversations and are working on a fix.

Reporting the same issue after a session where it was particularly bad. In my experience Codex has been bad at tracking which questions are "new" and which issues it has already responded to even in its early days. It has been quite typical to see conversations of this style as long as I have been using Codex:

User - Fix issue A
Codex - Fixed issue A
User - Fix issue B
Codex - Fixed issue A. Fixed issue B.

I have never seen the same issue with other agent harnesses, although I have not really explored codex models through Cursor for instance. It also now seems to worsen after compaction (I would rarely let conversations run to the point of compaction before, so unsure if recent changes to compact earlier is just making this problem more visible).

Submitted the conversation through /feedback with the following tracking number:
019bdad1-8b88-7c82-bd9e-48a0b4ba835f

Yeah after summarization, the chat is unusable and the model just loses context or fixes previously fixed bugs

This issue is getting worse and worse all the time. It's made 5.3 pretty much unusable.

I’m seeing the same issue since 0.98. It’s burning through my Pro limits, roughly 0.5–1% of the weekly limit per prompt.

Yesterday, a very small change took 23 minutes and modified ~20 files instead of a single line. Most of those edits were redundant (same change repeated with only minor style differences).

Right now, it’s completely unusable with gpt-5.3-codex and barely usable with gpt-5.2-codex.

If this isn’t fixed ASAP, I’ll have to switch to Claude or Gemini. I’m a big fan of Codex, but I need a tool I can actually ship work with.

This is also happening to me. But with Context compact. i did open a ticket, but it got closed. So I am adding it here.
When doing tasks with Codex and Context compact, it does its thing. Codex jumps to previous tasks and starts redoing things it has already completed. It's getting really annoying now; I have to stop it or allow it to carry on at the risk of breaking the project. It's a waste of my time and wastes my usage/money allowance. This needs fixing. It's been like this now for the last couple of updates. Using Codex with Node CLI in the terminal.

This is getting serious now. I am editing grub menu settings. And I get a context compact. Right after it finishes, instead of carrying on editing, Codex has switched context from a day ago and started editing, something that's nothing to do with what i am doing now.

+1 I also see this issue, and I've only seen it happen after context compact. thread id: 019c98cb-6021-7da3-90e9-2eb092b6fe49

Seeing this issue a lot lately, didn't have much problem with it before. It got substantially worse with the release of gpt-5.4

I am actually have a question about context compaction itself. I am trying to make codex do some long running experiment work and there's a lot of instructions for that which are injected (by making codex read some files) at the start of the session itself. Then i start codex with /goal to work through the experiments. The issue is after compaction, codex completely looses any understanding of the original experiment/exploration work that ius being done. It just focuses on the current job. What i want to do is to preserve these instruction sets verbatim. One way I could do that is by launching codex with developer_instructions like so, codex --yolo -c developer_instructions="$(cat ./prompts/developer_instruction_file.md). But i am not sure if this prompt will be preserved after compaction. That's what I am hopping somebody sheds light on. And, in my experiments codex refuses to say what's in its developer instructions once the context has compacted even once.

You can use user hooks to force a reload of files which contain your context data. Choosing which context data to reload is the trick.

I am actually have a question about context compaction itself. I am trying to make codex do some long running experiment work and there's a lot of instructions for that which are injected (by making codex read some files) at the start of the session itself. Then i start codex with /goal to work through the experiments. The issue is after compaction, codex completely looses any understanding of the original experiment/exploration work that ius being done. It just focuses on the current job. What i want to do is to preserve these instruction sets verbatim. One way I could do that is by launching codex with developer_instructions like so, codex --yolo -c developer_instructions="$(cat ./prompts/developer_instruction_file.md). But i am not sure if this prompt will be preserved after compaction. That's what I am hopping somebody sheds light on. And, in my experiments codex refuses to say what's in its developer instructions once the context has compacted even once.

You can use user hooks to force a reload of files which contain your context data. Choosing which context data to reload is the trick.

Thanks. I'll try PostCompact Hook. For which files to load, my system is an auto-research agent, so I have the instruction_set that I want to load defined, and its running an auto-research loop , so what to do at each step is defined and the agent is expected to (via an instruction in the instruction_set) to read the relevant prompt.

I am actually have a question about context compaction itself. I am trying to make codex do some long running experiment work and there's a lot of instructions for that which are injected (by making codex read some files) at the start of the session itself. Then i start codex with /goal to work through the experiments. The issue is after compaction, codex completely looses any understanding of the original experiment/exploration work that ius being done. It just focuses on the current job. What i want to do is to preserve these instruction sets verbatim. One way I could do that is by launching codex with developer_instructions like so, codex --yolo -c developer_instructions="$(cat ./prompts/developer_instruction_file.md). But i am not sure if this prompt will be preserved after compaction. That's what I am hopping somebody sheds light on. And, in my experiments codex refuses to say what's in its developer instructions once the context has compacted even once.

You can use user hooks to force a reload of files which contain your context data. Choosing which context data to reload is the trick.

Thanks. I'll try PostCompact Hook. For which files to load, my system is an auto-research agent, so I have the instruction_set that I want to load defined, and its running an auto-research loop , so what to do at each step is defined and the agent is expected to (via an instruction in the instruction_set) to read the relevant prompt.

That seems about right - I think the correct approach is like sessions in stateless web development. The trick is figuring out what to reload and how compressed it should be.

I am actually have a question about context compaction itself. I am trying to make codex do some long running experiment work and there's a lot of instructions for that which are injected (by making codex read some files) at the start of the session itself. Then i start codex with /goal to work through the experiments. The issue is after compaction, codex completely looses any understanding of the original experiment/exploration work that ius being done. It just focuses on the current job. What i want to do is to preserve these instruction sets verbatim. One way I could do that is by launching codex with developer_instructions like so, codex --yolo -c developer_instructions="$(cat ./prompts/developer_instruction_file.md). But i am not sure if this prompt will be preserved after compaction. That's what I am hopping somebody sheds light on. And, in my experiments codex refuses to say what's in its developer instructions once the context has compacted even once.

In general, AI is stateless. That means with every prompt, or with every step Codex takes, the full context has to be sent again and again.

So every tool call and its result, every lookup, every search, every image analysis, every write command, every read command... all of that gets sent over and over. Let’s ignore cached tokens for now, because that is basically just an optimization.

When the context is almost full, it has to be compressed. And this is basically as simple as it sounds.

Something like:

“You are a context compressor for a Codex agent context. Compact the following context, preserve this and that, keep this format, make it at least half the size,” and so on.

The problem is that this is completely non-deterministic. The compression is only as good as the model and the system prompt. This is also true for basically every coding environment. The main difference is that some tools have started to pre-compress or clean up the context before handing it to the model for compression.

If you need a reliable instruction set, the solution is actually pretty simple: use Skills.

Every installed skill has a description that lives in the context, and those descriptions survive context compression. If an agent is doing something that matches a skill description, it reads the skill content. And if the actual skill content gets lost during compression, the agent can simply read it again.

So the trick is not to rely on a bigger context window. The trick is to store recurring improvement instructions in skill files and keep each skill focused on one specific task.

That also means it is better to have multiple small, focused skills instead of one huge catch-all skill.

And here’s my current publication position.

Perhaps, point to your fork/branch?

It's more to say, it's real defect, I fixed it by expending a lot of time, obviously whoever is maintaining this part of the project has a lot of work to do and I don't want to get more involved than I have to. I gave enough info for someone's coding agent to fix it.

codex generated analysis:

This still reproduces in the Codex App with GPT-5.6 Sol Max.

Feedback ID: 019f48b9-86a4-74e3-abda-5a45bb45f6d2
Second affected task: 019f48b9-7824-7d72-a756-1e0034bd9601
App: 26.707.62119 (5211)
CLI: 0.144.1
Platform: macOS

In the first task, the affected /goal remained one inProgress turn across several later user messages. It underwent three context compactions and emitted a final_answer without the turn completing. After compaction, a completed earlier manual steer was repeatedly treated as the current request, even after newer steering messages.

The second task shows the same lifecycle failure independently. A user prompt was answered once. A later automatic goal continuation crossed contextCompaction and answered that consumed prompt again. The next automatic continuation repeated it once more without a new user message.

This looks like goal/turn lifecycle state being restored incorrectly during compaction, rather than a model-attention failure: a consumed steer regains actionable status while the current goal checkpoint and consumed-steer state do not.

I encountered a closely related failure in a long-running Codex Desktop task, but with one notable difference: the incorrect final response was not a replay of any earlier response in the local conversation history.

Environment:

macOS
Codex app version: 26.721.81911 (build 5973)
Model: gpt-5.6-sol
Occurred: August 12, 2026, at approximately 22:52 JST

What happened:

I asked Codex to send a previously reviewed message to a Slack channel.
Codex correctly resolved the channel and recipient, sent the message through the Slack connector, and received a successful result containing the Slack message link.
Instead of returning a short completion report, the final assistant response suddenly contained a long, completely unrelated explanation of Jacobian matrices and how to prove that a function is C^1.
A readback of Slack confirmed that the external write completed correctly and that the unrelated mathematical text was not sent to Slack.
The unrelated response was persisted in the local rollout JSONL as the assistant message for that turn, followed by task_complete. This therefore does not appear to be only a renderer or display problem.

I also searched the local Codex session files for a distinctive phrase from the mathematical response. It appeared only in this erroneous response; I found no earlier local conversation containing that answer. This differs from the stale-answer replay described in this issue and in #17301: the final answer appears to have been newly generated or incorrectly attached from a source not present in the visible or local conversation history.

The thread was long-running and had undergone multiple context compactions before the failure. The tool execution itself was correct; only the post-tool final response was unrelated.

Expected behavior:

After a successful connector write, Codex should return a completion report grounded in the current turn and tool result.

Actual behavior:

The connector write succeeded, but the final response was a completely unrelated mathematical article and was persisted as the official assistant response for the turn.

I can provide the thread ID, turn ID, and a redacted rollout JSONL excerpt privately if OpenAI staff need them for server-side log correlation.

Context correctness must precede mutation

Author: Almási Andor Aladár

This context/focus bug becomes materially more serious when the same agent has file-system mutation authority.

I observed a separate file-management incident now tracked in #42115 where Codex lost the original task focus while working among similar/duplicate files and could not reliably preserve which files were actually being identified. In a chat-only context, stale-task behavior produces a wrong answer. In a file-system context, the same failure class can produce a wrong move, overwrite, rename, or deletion.

For that reason, context correctness should be treated as a precondition for mutation, not only as response quality. Before any write/move/delete operation, the runtime should verify that the proposed action is still grounded in the latest user instruction and active task state. If the task pointer is stale, ambiguous, or inconsistent with the current plan, mutation should hard-stop.

Public-safe prompt pattern: Latest Instruction Guard

Author: Almási Andor Aladár

A small userland mitigation for stale-context / wrong-message replies:

Identify the latest explicit user task or correction before answering or acting.
Compare any pending response/action against that latest instruction, not merely against the most salient earlier context.
If an older task conflicts with the latest instruction, stop the older path and re-evaluate.
Treat explicit user corrections and overrides as higher-priority task context than earlier conversational momentum, subject to platform/system constraints.
If ambiguity would materially change the result, ask one concise clarification instead of guessing.
Before any consequential tool or filesystem mutation, revalidate that the action is still required by the latest user instruction.

This is intentionally only a public-safe prompt-level pattern. It is not a substitute for a runtime-enforced context pointer / task-focus invariant.

happened to me again on latest codex version with gpt-6-astra max

Still happening on codex-cli 0.154.0 with gpt-5.6-sol.

I observed a similar stale-question recurrence in a long-running Codex desktop task on macOS on September 13, 2026. I inspected the local rollout rather than relying only on the assistant's explanation.

The clearest inspected turn has this sequence (UTC; task details paraphrased to remove private information):

Time	Observed event
02:42:47	Turn started. The assistant committed to inspecting the current workflow and completing a pending check.
02:46:14	A `compacted` event was recorded. Its `replacement_history` had 30 items; the last retained user message was an older question about a third party's previous reply.
02:47:06	Turn completed after an answer to that older question, rather than the workflow/check result promised at the start.

A second inspected occurrence in the same conversation also had a compaction event followed by an answer to the same older question. These are two selected occurrences, not a measured incidence rate or a deterministic minimal reproduction.

Limits: the replacement history includes an opaque compaction item. I cannot conclude that the complete input supplied to the model lacked the current objective. I also have not isolated model behavior from context reconstruction or continuation-message handling. The incident-time desktop/runtime build has not been established; I am not substituting today's installed version for it. The local turn metadata identifies the model as gpt-6-astra.

Would a regression test covering a continuation turn with a previously answered user question, followed by mid-turn compaction, be useful here? Expected behavior: retain the active objective and latest steering, complete the pending check or identify its actual blocker, and do not reactivate the answered question.

This issue has reproduced again in a long-running Codex Desktop task with an active persisted goal.

Environment:

Codex Desktop: 26.908.40834 (build 8881)
Embedded CLI: 0.154.0
Platform: macOS
Model: gpt-5.6-sol, high
Affected task: 019f437b-cf03-7a83-a5e1-4245f6abe775

Sanitized sequence:

The user asked a model-selection question, and it was answered.
During later automatic goal continuations, Codex repeatedly answered that settled question instead of reporting new progress on the active corpus-audit goal.
The user then asked why the old answer kept recurring, and that question was answered.
Subsequent automatic continuations alternated between re-answering the original model-selection question and re-explaining why it had been repeated, while omitting the requested work-progress report.
This continued even after an explicit project rule required the agent to identify the actual turn trigger, treat settled questions as context, and never reactivate answered questions during goal continuations.

The local rollout records 17 compaction events between 2026-09-13T23:18:50Z and 2026-09-15T13:59:39Z in the inspected interval. The final recurrence occurred after repeated compactions. No private project content is included here.

This looks particularly consistent with the July 15 report in this issue: a consumed steer regains actionable status after compaction or automatic goal continuation, while the active goal checkpoint is not selected as the response target. A regression test should cover an active persisted goal, a previously answered user question, a later answered meta-question about that recurrence, and a post-compaction automatic continuation. Expected result: emit only new goal progress or a real blocker, without re-answering either consumed question.

Navigation Menu

Repository navigation

Codex replies to earlier messages instead of latest one in conversations #8648

What version of Codex is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

78 remaining items

Context correctness must precede mutation

Public-safe prompt pattern: Latest Instruction Guard

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Codex replies to earlier messages instead of latest one in conversations #8648

Description

What version of Codex is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

g3grau commented on Jan 1, 2026

etraut-openai commented on Jan 1, 2026

MineshK commented on Jan 3, 2026

sayan-oai commented on Jan 5, 2026

STAlfsen commented on Jan 21, 2026

sentialx commented on Feb 6, 2026

alc1986 commented on Feb 9, 2026

svendvd commented on Feb 10, 2026

Rhino-85 commented on Feb 11, 2026

henry-dowling commented on Feb 26, 2026

dzigz commented on Mar 8, 2026

78 remaining items

lagordon70 commented on Jul 6, 2026

gordonrust commented on Jul 6, 2026

lagordon70 commented on Jul 6, 2026

svendvd commented on Jul 6, 2026

numpde commented on Jul 11, 2026

lagordon70 commented on Jul 11, 2026

joshp123 commented on Jul 15, 2026

hirokidaichi commented on Aug 12, 2026

hyperbetteri commented on Sep 1, 2026

Context correctness must precede mutation

hyperbetteri commented on Sep 1, 2026

Public-safe prompt pattern: Latest Instruction Guard

Gusarich commented on Sep 11, 2026

abdulfatir commented on Sep 11, 2026

canglang-social commented on Sep 13, 2026

Jacoba1100254352 commented on Sep 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions