Codex Desktop: multi-turn single session returns/persists a previous-topic answer for the latest turn

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

26.623.13972.0

What subscription do you have?

oai

What platform is your computer?

WIN11

What issue are you seeing?

Summary

In a long-running Codex Desktop session, a latest user turn was answered with content from a previous topic. The incorrect output was not only a stale UI render: it was persisted into the session JSONL as both agent_message and task_complete.

Environment

• Codex Desktop version: 26.623.13972.0
• Codex CLI version: 0.142.5
• OS: WIN11
• Model: gpt-5.5

What happened

The final answer for turn xx should answer the npm/npx package usage question.
What actually happened
The final answer for that turn was a previous-topic response about Claude Code statusline rate_limits schema.
Additional observations
This was a long-running session with multiple compactions and resumes.
The session had 7 compaction events by the time of inspection.
There were 2 earlier turn_aborted and 2 thread_rolled_back events, but not immediately adjacent to the bad turn.
I checked for duplicate response_item.id; none were found.
This does not look like a simple JSONL line overwrite or duplicate response id issue.
It looks more like a turn output/context routing mix-up in a long multi-turn session, possibly involving resume/compaction state.
Desktop log observations
Around the bad turn:
15:33:42 turn/start for conversation xx
15:34:53 turn-complete notification for turn seesionid
15:35:13 app-server transport stopped
15:35:42 maybe_resume_success marked latestTurnId=xx latestTurnStatus=completed markedStreaming=true
Workaround
Starting a new session avoids relying on the corrupted/possibly confused long-running session state.

What steps can reproduce the bug?

The final answer for turn xx should answer the npm/npx package usage question.
What actually happened
The final answer for that turn was a previous-topic response about Claude Code statusline rate_limits schema.
Additional observations
This was a long-running session with multiple compactions and resumes.
The session had 7 compaction events by the time of inspection.
There were 2 earlier turn_aborted and 2 thread_rolled_back events, but not immediately adjacent to the bad turn.
I checked for duplicate response_item.id; none were found.
This does not look like a simple JSONL line overwrite or duplicate response id issue.
It looks more like a turn output/context routing mix-up in a long multi-turn session, possibly involving resume/compaction state.
Desktop log observations
Around the bad turn:
15:33:42 turn/start for conversation xx
15:34:53 turn-complete notification for turn seesionid
15:35:13 app-server transport stopped
15:35:42 maybe_resume_success marked latestTurnId=xx latestTurnStatus=completed markedStreaming=true
Workaround
Starting a new session avoids relying on the corrupted/possibly confused long-running session state.

What is the expected behavior?

_No response_

Additional information

_No response_