Codex replies to earlier messages instead of latest one in conversations

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

agree this seems to be happening much more often now

Since 5.4 this has become a NIGHTMARE.

Happens literally every day. Keeps answering previous messages and ignoring my actual latest message

This issue is burning through my tokens so badly it's not even funny. Codex just worked on "fixing bugs" for 30m only to end up replying about the previous prompt. This is approaching a show stopper real quick.

Here's a thread ID I reported /feedback on with the issue: 019cee34-5e10-76a3-8c8c-42ff92321027. Using Codex App on macos with 26.311.21342 (993)

The thread was something like:

user: How is the persistence currently implemented? Would the be better as something like a local sqlite database?

In the current working tree, worker-local persistence is a simple file-backed state store, not a database. It works like this: Runtime state lives in memory as a BTreeMap under an RwLock in state.rs (line 18).

user: Please use SQLite and benchmark it and compare directly. I feel like it would be cleaner to implement for the data. Also, consider using it for the resume state too

Current worker-local persistence in the working tree is: In-memory state is a BTreeMap under an RwLock in state.rs (line 18). Startup reads a full snapshot from worker-state.json, replays an append-only j

Seeing something egregious happening as well, especially with the review.

/review pr1

here is my pr1 review

/review pr2

here is my pr2 review

/review pr3

here is my pr1 review <---- Issue

---

This seems to get worse over time. It also seems somewhat random and inconsistent, but what even doesn't help is when I run /new

So there's some weird complex session or state management issues going on.

This has gotten significantly worse in the past week with 5.4, making Codex near-unusable with anything but the shortest of chats.

This has gotten significantly worse in the past week with 5.4, making Codex near-unusable with anything but the shortest of chats.

It's even happening with 5.3-codex now, which is a huge regression. Switched to Claude Code for now.

+1, this has happened to me on a daily basis. It doesnt seem to be an instruction or attention issue, more like compaction-issue. Once it happens, next few turns will basically keep ignoring my last message.

I have a few thread ids to share with the team if that helps.

Opened #15889 with a narrower hypothesis for this bug.

Short version: after tracing the current OSS code, this looks less like blind steering into an old active turn and more like a compaction/reconstruction problem:

• app/TUI turn/steer is guarded by expectedTurnId
• OpenAI compaction uses a handoff summary for another LLM to resume the task
• resume reconstructs from surviving replacement_history / turn baselines after compaction

If that is the same underlying bug, feel free to close/merge #15889 back into this issue.

I've uploaded logs that reproduce this. See thread ID: 019d240e-99a6-76e1-8b35-8e349ffc468

This really should be one of the top if not the top priority issue. It's hard to trust it with any kind of serious work with hallucinations this bad. It's not quite unusable, but it's close.

@etraut-openai how can we help here? Does providing those feedback UUIDs give you enough to investigate? I'm happy to provide whatever context you need, I tend to hit this issue anywhere from 1-8 times (across probably 5-10 session) a day, so if you're still in the triaging phase where more data helps, happy to assist.

This issue is extremely infuriating and annoying...

Why are OpenAI consistently refusing to address this? It's been months now, and no comment.

I've been seeing this too

Codex frequently renders what looks like internal tool-call / execution payloads directly in the chat UI instead of normal assistant output.

Examples of leaked strings include:

• write_stdin
• session_id
• chars
• yield_time_ms
• max_output_tokens

In my case, this is not a one-off glitch. It happens very frequently and disrupts normal usage.

What did you expect to happen?

I expected Codex to show only the assistant's user-facing response, and never expose internal tool-call payloads or execution metadata in the conversation UI.

What actually happened?

The chat UI intermittently shows raw internal-looking content such as:

• assistant to=functions.write_stdin
• JSON-like payload fragments
• execution/session parameters like session_id, yield_time_ms, and max_output_tokens

Sometimes these fragments appear mixed into the assistant reply, making the response unreadable.

Steps to reproduce

I cannot guarantee 100% deterministic reproduction, but the issue occurs frequently during normal use.

Typical pattern:

1. Open Codex app
2. Start or continue a coding conversation
3. Ask Codex to perform a multi-step task / tool-assisted task
4. Wait for the assistant to respond
5. Observe that raw internal tool-call text may appear in the chat instead of a clean answer

Frequency

Frequently / repeatedly in normal usage.

Platform

• App: Codex desktop app
• OS: macOS
• Subscription: 20$ plus plan
• App version: 26.311.21342 (993)

Additional context

This looks like an internal rendering / event-stream / tool-call exposure bug rather than model content.

I have attached a screenshot showing the leaked payload text in the UI.

Impact

• Breaks readability of responses
• Exposes internal execution metadata that should not be user-visible
• Reduces trust in the app because it looks like system internals are leaking into the conversation

I switched to Codex because of reliability issues with Claude a couple months ago. This issue is orders of magnitude worse than whatever API reliability and usage limit issues Claude has and forced me to switch back.

Codex completely loses the thread, tries to repeat work, is not at all aware of the last few messages I sent, and spends the rest of the conversation with markedly worse output while it tries to not make the same mistakes again (and inevitably does). I can no longer trust Codex to work independently, and the issue not being addressed in months only makes things worse.

Why is this not addressed yet? We can't let Codex work in automations, it will trip on itself because of this bug. This should be given high priority. It breaks Codex. This is a major breaking bug for long sessions, it totally break skills and long workflows.

This problem still exists and is very serious, completely disrupting the workflow.

steering the agent while its working also breaks the chronology. I ask it to do A, then add note B and after working it gives an answer only to the B part. example: 019d5479-40cd-7ef3-b10d-b52b1378ec2b

This problem happens on OpenCode client as well, not just on Codex CLI. So this is a server-side issue?

confirm this is still an issue. it looks like occurring without auto compaction is going on

This appears to be a model behavior that occurs when the context window is nearly full. You may be able to reduce the occurrence by manually overriding the context window size (model_context_window). We'll work to eliminate or minimize this behavior in future models.

This appears to be a model behavior that occurs when the context window is nearly full. You may be able to reduce the occurrence by manually overriding the context window size (model_context_window). We'll work to eliminate or minimize this behavior in future models.

Unfortunately, it happens more often than when the context window is nearly full to me. I got this problem 2 minutes ago with 350k/950k used context window

This is frustrating and contradicts the core idea of agentic work. Suddenly, at some point, you get an agent who is completely stopped and has forgotten what it is doing.

In my tests, I saw even subagents do this. The initial prompt was something, and the response was another thing, a completely different story (I have no idea what it was responding to; it was reassuring me on something)

Once, I asked to spawn a subagent and instruct it to do an adversarial blind review; it did what I asked. The second time, I've used the same prompt after fixing the previous findings. It never spawned any subagent and replied with exactly the same findings with the same wording. This might be a repro case

I've attempted the 3rd review request (which ended up with no subagent spawned) to debug this within Codex by talking to the agent. This is GPT-5.4's own feedback about the problem and solution

The model appears to successfully call `spawn_agent` and receives an `agent_id`, but the sub-agent is not reliably visible to the user in the UI. From the model’s perspective, the tool call succeeds and sometimes later emits a notification/event, but from the user’s perspective there may be no visible sub-agent thread, panel, or result surface at all.

This creates a coordination failure mode:
- the model can believe a sub-agent was launched successfully
- the user cannot verify that the sub-agent exists
- the model may then mistakenly treat the sub-agent’s work as “delivered” even though the user never saw any corresponding sub-agent activity

The key distinction is:
- “the backend/tool accepted `spawn_agent`”
- vs.
- “the user has a visible, auditable sub-agent run and result”

Those are not the same thing right now.

## What the model experiences

- `spawn_agent` returns success and an `agent_id`
- sometimes a later sub-agent notification arrives to the model
- but there is no guarantee that the user sees the spawned agent or its output in the interface

## Why this is problematic

- the model may reference “a sub-agent review” as if it is externally observable
- the user may reasonably conclude that no sub-agent was ever launched
- this breaks trust and makes the agent/orchestration layer feel inconsistent or deceptive, even when the tool call technically succeeded

## What would help

- a clear UI guarantee that spawned sub-agents are visible to the user
- or, if that is not guaranteed, an explicit API/UI signal telling the model that the sub-agent is not user-visible
- or a delivery acknowledgement model where the assistant can distinguish:
  - `spawn accepted`
  - `user-visible`
  - `result delivered`

Without that distinction, the model can only infer backend success, not user-visible success, and that is the root of the confusion.

This appears to be a model behavior that occurs when the context window is nearly full. You may be able to reduce the occurrence by manually overriding the context window size (model_context_window). We'll work to eliminate or minimize this behavior in future models.

I don't agree with this, from my experience.

Also, 5.2 and 5.4 had this behaviour, but 5.3 appears to be completely immune to it, if that helps. To the point where it's endemic with 5.2 and 5.4, but I've never experienced it once with 5.3, which I've used exclusively since quickly discovering 5.4 has the same issue as 5.2.

This is just embarrassing

This is just embarrassing

It really is... Coming from Claude and using Codex, it's a night and day difference in terms of bugs. Codex is just sloppy and broken.

Can confirm 5.3 is goated and either never or almost never has this
I also found 5.4 overall worse than 5.3 and 5.4 very often just refuses to do something for unknown reason falling back to this and similar weird behavior like "I looked at this but didn't fix it, tell me if you want me to proceed" and just goes in circles
However I remember at least once that 5.3 had this behavior after talking to 5.4 and switching to 5.3, it got fixed on the next turn after compaction

The bug has not been resolved yet ！It's too painful

@etraut-openai

Just a heads-up: today it got the worst. In my last encounter, 3 occurrences out of 10 messages! It jumped to the same answer on the same request 3 times in a row, even though it says "I won't jump this time" assures.

What I notice is that some days it doesn't occur, and some days it gets completely bewildered.

No surprise that people got annoyed more over the last few days

Edit: I've uploaded my thread

Uploaded thread: 019d8101-d0d5-7a31-92ca-d75f4477758c

Pretty much every other message in the last few days is a repeat of the last message the model sent. On pre-release and released version (26.415.20818) of VS code plugin but its same with the latest CLI. Using GPT-5.4. Feeback 019d984a-891b-77f3-bcff-0d0d0dc9a767

I'm noticing this behavior on many threads of late across both codex cli and codex app surfaces, timing coincident with @cantecim.

019d9f84-66bc-7bc0-b7c8-14812962d039

the problem is still not being fixed right now, and i think the worst case scenario i can imagine is when you first want codex to help you implement in direction 1, and then you suddenly realize direction 1 is actually not right, and you want the codex to implement the thing in direction 2. and now you have multi rounds of conversation with the codex, and then codex helps you to do something, but now you don't know if codex will still consider the direction 1 in the actual implementation because based on the behavior, it is always considering all the previous messages.

I'm not sure if it's always about context summarization, though. I have seen this bug at 5x%-6x%-7x%-8x% of the context window, more frequently at 7x-8x%.

我也看到了这种情况。 Codex 经常直接在聊天界面中渲染看起来像是内部工具调用/执行有效载荷的内容，而不是正常的助手输出。 泄露字符串的示例包括： write_stdin session_id chars yield_time_ms max_output_tokens 就我而言，这不是个偶然故障。它经常发生，严重影响正常使用。 ### 你预期会发生什么？ 我期望 Codex 只显示助手的用户界面响应，而永远不会在对话界面中公开内部工具调用有效负载或执行元数据。 ### 究竟发生了什么？ 聊天界面会间歇性地显示一些看似原始的内部内容，例如： assistant to=functions.write_stdin 类似 JSON 的有效负载片段 执行/会话参数，例如session_id，yield_time_ms和max_output_tokens 有时这些片段会混杂在助手回复中，导致回复无法阅读。 ### 重现步骤 我无法保证 100% 能够重现该问题，但该问题在正常使用过程中经常发生。 典型模式： 1. Open Codex 应用 2. 开始或继续编程对话 3. 请 Codex 执行多步骤任务/工具辅助任务 4. 等待助理回复 5. 请注意，聊天记录中可能会显示原始的内部工具调用文本，而不是清晰的答案。 ### 频率 在正常使用中频繁/反复。 ### 平台 应用：Codex桌面应用 操作系统：macOS 订阅：20 美元起 应用版本：26.311.21342 (993) ### 补充信息 这看起来像是内部渲染/事件流/工具调用暴露错误，而不是模型内容错误。 我附上了一张截图，显示了用户界面中泄露的有效载荷文本。 ### 影响 降低回复的可读性 暴露不应向用户可见的内部执行元数据 * 这会降低用户对应用程序的信任度，因为它看起来像是系统内部信息泄露到了对话中。

你可以把codex给你执行任务的步骤包装成一个skill，然后让codex自己在与你交流的过程中设置输出的级别。参考我和codex的对话，看看能否对您有帮助：我需要确认一下，1、在skill执行的过程中，你是否会将A、B两个团队过程中返回的信息输出到对话中？2、当你的cli指令下发完毕后，我看到会持续监控，你会把监控的结果也输出到对话中吗？

• 会，但默认是“有筛选地输出”，不是把所有原始日志无差别刷到对话里。

1. 关于 A、B 两个团队返回的信息

会输出到对话中，但通常分 3 层：

• 我实际下发了什么指令
• 团队回复的关键信息摘要
• 我基于回复做出的判断和下一步动作

默认我会把关键内容同步到对话里，例如：

• 当前分支、commit、worktree 状态
• 修改了哪些文件
• 他们声称完成了什么
• 还缺什么
• 是否通过验收
• 我准备继续让谁做什么

如果你要求，我也可以额外输出：

• 原始 CLI 命令
• 原始日志片段
• 原始团队回报全文
• 我发到 PR 里的评论正文

1. 关于持续监控的结果

也会输出到对话中，但默认只在有意义的状态变化时输出，不会每次轮询都刷屏。

默认我会同步这些监控事件：

• 会话已启动
• 团队已回复
• 出现 blocker
• 我要求他们整改
• 某一轮验收通过 / 不通过
• 任务完成 / 失败
• PR 评论已发布

默认不会做的事是：

• 每 10 秒贴一次 ps / logs
• 把所有 polling 结果原样灌进对话
• 把大段无变化日志持续贴出来

如果你希望更透明，我可以切成任一种模式：

• 简洁模式

只报关键节点和结论

• 审计模式

每次 CLI 下发、每次团队回复、每次监控判断都同步到对话

• 全量模式

连原始日志片段和 PR 评论正文也一起贴

如果你愿意，我可以直接把这个 Skill 再补一条规则：
默认使用审计模式，把 A/B 回复摘要 + 监控关键节点都实时输出到对话中。

› 将你的skill名称改为：“dual-cli”，然后将启动的时候增加一个参数："dual-cli --1"，后面的数字1代表简介模式，2代表审计模式，3代表全量模式。

• 我会把 Skill 重命名为 dual-cli，并把 --1/--2/--3 三种启动模式写进 Skill 协议里，同时更新它的元数据。

this is happening consistently now when sessions are around 200k, and worse over 300k, whether sessions have been compacted or not - 1M context is completely unusable.

Same issue with both gpt 5.4 and the brand spanking new 5.5 this happened on the 3rd message on 5.5 on codex cli. This makes it completely unusable. Will switch back to claude never had this issue

Same issue with both gpt 5.4 and the brand spanking new 5.5 this happened on the 3rd message on 5.5 on codex cli. This makes it completely unusable. Will switch back to claude never had this issue

Codex is an actual joke... This is a huge major issue yet OpenAI still cannot manage to fix this issue...

This happens to me every day.

I’m using Codex CLI 5.4 (model: xhigh, 1M context, ChatGPT Pro). It started about 3 weeks ago, right after I switched to the 1M context window. Auto-compaction doesn’t seem to kick in — the dialog never reaches that threshold.

What I see:

• It can happen even around ~30% context usage
• At ~60–70% it becomes very frequent (every 3–5 messages)

Typical flow:

1. I send an instruction
2. Codex starts processing it
3. A horizontal separator appears
4. It replies to a previous message instead
5. If I resend the same message, it works correctly

As a workaround to solve the problem, do not set "model_auto_compact_token_limit" and "model_context_window"; use the default context window. Otherwise, the compaction is broken.

The strength is not in having a longer context, but having a smart context. I've personally started to use a custom compaction prompt found in https://github.com/openai/codex/discussions/17330 by @Zaczero. I'm not sure if that helped, but the prompt seemed very mature and complete to me. I haven't seen a problem related to compaction so far.

So let it run compaction often, but use conversations smarter.

Info for latecomers: The root cause is that compaction isn't starting. GPT-5.3-Codex gives an obvious error saying something like "there was no room left in context", while others are silently failing and randomly jumping to older responses

Codex and I put together a small tests-only branch that documents one suspected pending-input ordering path around mid-turn auto-compaction:

https://github.com/openai/codex/compare/main...numpde:fork-of-codex:pending-input-compaction-spec

It does not fix this issue. The intent is to make the suspected client-side invariant reviewable:

• ambient queued context, such as mailbox context, should not be promoted ahead of required post-compact continuation
• role=user alone is not a reliable signal for active human steering
• explicit active-turn steering should eventually survive compaction and be sampled with the first post-compact continuation

One desired-behavior test is intentionally ignored because current main still sends an extra later request for that case.

One related case is not covered exactly in this non-invasive branch: active-turn queued injected context via the internal Session::inject_response_items path. That is the closest path for “injected context pending inside the active turn,” but it is not reachable from this top-level integration test without touching existing crate internals or adding a test hook. The branch instead triangulates the invariant through public paths: mailbox queued context during compaction, raw role=user injected context, and an ignored explicit-steering desired-behavior spec.

frequently see this too with gpt 5.4 on the later parts of the context window, here is an example 019dda04-4e61-7530-b978-85309b023508, i usually just compact by then, but it is annoying...

As a workaround to solve the problem, do not set "model_auto_compact_token_limit" and "model_context_window"; use the default context window. Otherwise, the compaction is broken. The strength is not in having a longer context, but having a smart context. I've personally started to use a custom compaction prompt found in https://github.com/openai/codex/discussions/17330 by @Zaczero. I'm not sure if that helped, but the prompt seemed very mature and complete to me. I haven't seen a problem related to compaction so far. So let it run compaction often, but use conversations smarter. Info for latecomers: The root cause is that compaction isn't starting. GPT-5.3-Codex gives an obvious error saying something like "there was no room left in context", while others are silently failing and randomly jumping to older responses

I am 100% sure now this is due to codex compaction prompt. I've been going back and forth and this issue is gone with the changed compaction prompt for me. gpt 5.5. The new prompt fixes this issue and much more for me.

Interesting data point @zaczero, I think that lines up with my experience. I have been using the custom model context settings per that Shipping at Inference Speed blog post recommendation back in late Dec 2025.

I have since disabled it with 5.5 and I don't think I've hit this problem again.

> As a workaround to solve the problem, do not set "model_auto_compact_token_limit" and "model_context_window"; use the default context window. Otherwise, the compaction is broken. > The strength is not in having a longer context, but having a smart context. I've personally started to use a custom compaction prompt found in #17330 by @Zaczero. I'm not sure if that helped, but the prompt seemed very mature and complete to me. I haven't seen a problem related to compaction so far. > So let it run compaction often, but use conversations smarter. > Info for latecomers: The root cause is that compaction isn't starting. GPT-5.3-Codex gives an obvious error saying something like "there was no room left in context", while others are silently failing and randomly jumping to older responses I am 100% sure now this is due to codex compaction prompt. I've been going back and forth and this issue is gone with the changed compaction prompt for me. gpt 5.5. The new prompt fixes this issue and much more for me.

I've also been using 5.5 for quite a long time; that's enough for a good observation so far. I've never had a problem with this prompt on the default context window

For me this only happen for xhigh. I used GPT-5.5 medium by accident for a longer time now and the issue was gone. After switching to GPT5.5 xhigh I had this issue instantly again. In general it did not followed the context well in xhigh and forgot a lot of important stuff it was able to follow for days now. 🤔 It could be random but I really don't think so

For me this only happen for xhigh. I used GPT-5.5 medium by accident for a longer time now and the issue was gone.

I use 5.5 medium and it happens a few times a day.

any progress?

<img width="1866" height="1705" alt="Image" src="https://github.com/user-attachments/assets/d5fa3a64-5d9c-4828-a850-9b421862396d" />

Wasn't happening for me for a few weeks already.

For me also not happening since a while and never happened in the Codex App.

But my usage limit degraded extremely.
Around 3M token usage burned 19% of my 20x Pro account. This is a no go. Have to cancel my account.

it still happens for me in almost every session. thus I ask codex to number every turn, when I see the number is duplicated, I know it is happened, then I resend the last message, then number become correct in most time.

I just discovered this independently and did a root cause analysis on the codex code (in main).

My Agentic harness produced the resultant analysis.
<SNIP> - having it do a full root cause analysis and repro which I'll post later

It's important to note that context compaction is not a part of the error I'm seeing - I assume context compaction makes it much worse. I am running with a million context GPT 5.4 model.
An exit and resume of a codex interactive session (codex resume --last) _may_ mitigate the failure.

It seems that an exit and resume from codex appears to make the error temporarily recoverable -- it doesnt appear to DO anything in the old turn, it seems to partially complete to new turn and then reports the old turn, but exiting and doing a resume --last allows at least to continue the new turn without failures. It isn't long before it happens again. YMMV.

FWIW, something strikingly similar just happened to me using ChatGPT Pro on the web site using GPT5.5 Instant.

I was asking a thread of questions within a project, and changed to a similar topic, and then to a largely different one and the answer ignored my question and reiterated the answer from the first topic.

Paraphrasing the issue:

Prompt 1: How good of an engineer is Tom based on his resume?

Answer1: Tom is a great engineer and has good teeth.

Prompt2: Is it possible for an electrician in France to emigrate to Canada and work as an electrician?

Answer2: Sure, but you may have to take your license tests again...etc.

Prompt3: What is the easist way to send money to France from Canada

Answer3: Tom is a great engineer and has good teeth.

So this patch did not solve the issue for me -- I'm wondering whether it is an LLM issue and not an agent issue - I will keep investigating.
Note that I had the long duration run for 50% of context in a 1M context GPT-5.4 and then i exited and did a resume --last with the fixed version, so that might not have been a valid case - I will try again with a full long duration test to see if I can replicate the behavior.

( - The fix did not primarily patch resume --last / replay-state filtering. It patched “previous turn still settling” behavior. So if the stale ownership is already serialized into old thread state or reconstructed during resume replay, the fixed binary may not retroactively clean that up just by resuming.)

I think this is a context compression system prompt issue.

Right now, context compression is handled in a completely non-deterministic way. Whenever compression happens, the entire context is sent to an LLM together with a system prompt that instructs the model to compress it.

This can lead to translation errors and semantic drift, as the Model is sometimes compressing the wrong things. In my opinion, this should be combined with a more deterministic approach.

Instead of compressing the entire context blindly, tool outputs, logs, errors, and other noisy data should already be truncated or summarized in a structured way. Ideally, this should be done so that the AI can still retrieve the original data later if needed.

The PI Agent already has a plugins for this (ex. ContextMode), and it works very well. It significantly reduces token usage while also making context compression faster. So this would basically solve two problems at once.

I tested this with a local model, Nex-N2-mini. In the Codex harness, the model basically dies during every context compression step. In the PI Agent harness together with ContextMode however, the same model works surprisingly well in GPT 5.4-mini quality. That strongly suggests that the issue is not only the model itself, but also how the harness handles context compression.

I think this is a context compression system prompt issue. Right now, context compression is handled in a completely non-deterministic way. Whenever compression happens, the entire context is sent to an LLM together with a system prompt that instructs the model to compress it. This can lead to translation errors and semantic drift, as the Model is sometimes compressing the wrong things. In my opinion, this should be combined with a more deterministic approach. Instead of compressing the entire context blindly, tool outputs, logs, errors, and other noisy data should already be truncated or summarized in a structured way. Ideally, this should be done so that the AI can still retrieve the original data later if needed. The PI Agent already has a plugins for this (ex. ContextMode), and it works very well. It significantly reduces token usage while also making context compression faster. So this would basically solve two problems at once. I tested this with a local model, Nex-N2-mini. In the Codex harness, the model basically dies during every context compression step. In the PI Agent harness together with ContextMode however, the same model works surprisingly well in GPT 5.4-mini quality. That strongly suggests that the issue is not only the model itself, but also how the harness handles context compression.

Absolutely not for me. Compression is definitely not happening as I have user hooks for context compression configured. This is happening at around 50% or less of context available for a 1 million token GPT-5.4.

If you allow context compression to happen, you're done.

> I think this is a context compression system prompt issue. > Right now, context compression is handled in a completely non-deterministic way. Whenever compression happens, the entire context is sent to an LLM together with a system prompt that instructs the model to compress it. > This can lead to translation errors and semantic drift, as the Model is sometimes compressing the wrong things. In my opinion, this should be combined with a more deterministic approach. > Instead of compressing the entire context blindly, tool outputs, logs, errors, and other noisy data should already be truncated or summarized in a structured way. Ideally, this should be done so that the AI can still retrieve the original data later if needed. > The PI Agent already has a plugins for this (ex. ContextMode), and it works very well. It significantly reduces token usage while also making context compression faster. So this would basically solve two problems at once. > I tested this with a local model, Nex-N2-mini. In the Codex harness, the model basically dies during every context compression step. In the PI Agent harness together with ContextMode however, the same model works surprisingly well in GPT 5.4-mini quality. That strongly suggests that the issue is not only the model itself, but also how the harness handles context compression. Absolutely not for me. Compression is definitely not happening as I have user hooks for context compression configured. This is happening at around 50% or less of context available for a 1 million token GPT-5.4. If you allow context compression to happen, you're done.

I wonder if you have tried PI Agent with the GPT5.4 Model (using the login mode for sure) instead of Codex.

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.

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.

I removed my comments with prior fixes since they were not the root cause.

Here’s the summary of the actual fix, which I am not providing. I did a lot of semi-closed loop codex testing with additional telemetry data added in order to nail this down and root cause and effect the change. No one will be able to understand what I did to fix this, so publishing the patch is not the correct thing to do.

The real fix is not another narrow /status patch or another stale-copy-source workaround. The useful change is a broader long-thread task-isolation hardening pass:

• anchor each turn more aggressively to the latest explicit user request,
• stop carrying forward prior update_plan bodies as live prompt history,
• and defer task completion until stream / plan consolidation is actually finished, so the UI/runtime boundary does not finalize against partially settled prior-turn state.

That is the part that seems generally meaningful. It addresses the actual failure class: old workflow state surviving long enough to contaminate the next turn.

Here’s what from the other fixes is not especially helpful.

• Narrow slash-command settling fixes help with one seam, but they are not the core answer to the broader long-thread contamination issue.
• Replay- or transcript-specific local patches are easy to mistake for a root-cause solution when they are really only treating one visible manifestation.

And here’s my current publication position.

I’m not planning to post this proactively, but will provide it to someone from the Codex project asks me directly. This part of Codex still looks immature enough that the side effects of a behavior change here are likely to be significant. The hardening direction seems right, but I do not think the current evidence supports presenting it as a clean, low-risk upstream recommendation without direct engagement from the maintainers.

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.

This class of bug usually needs an explicit “current user intent” boundary in the stored turn state. The model transcript alone is not enough if summarization, replay, or recovery can accidentally anchor to an earlier request.

I would expect each assistant turn to bind to: triggering user message id, conversation revision, active task/goal id if any, replay cursor, and the exact context bundle used for generation. If the latest user message changes while a turn is queued or recovered, the stale continuation should be canceled or marked superseded rather than allowed to answer the old intent as if it were current.

I maintain Better Agent (https://github.com/ofekron/better-agent), where restart/replay work makes this boundary explicit because stale continuation is otherwise easy to confuse with model confusion. If useful, a star helps other agent-runtime builders find it.