Compaction may leave Codex responding to an earlier request after the user has moved on

Related to #8648, #14131, #14253, #14486, #13864, and #9505.

I originally opened this as a compaction-specific hypothesis. After reading the related issues, I think that was too narrow.

My current guess is:

• this probably is not a simple turn-steering bug in the local app/TUI path
• the symptom is more likely coming from long-thread context handling
• compaction is probably one trigger or amplifier, but maybe not the only one

Why I changed my mind

• In the app/TUI path, same-turn steering is guarded by expectedTurnId, and stale-turn races fall back to turn/start. That makes a simple "new message got silently attached to the wrong active turn" explanation less convincing.
• In #8648, a maintainer said they were already aware of the issue specifically with compacted conversations.
• In #13864, a maintainer said the same symptom might be model behavior rather than harness behavior, and several users there reported the problem in long threads, with large context windows, and sometimes even before compaction.
• In #9505, a maintainer said much of compaction had moved to the cloud and that they prefer model-driven compaction over local heuristics. That makes me think the most important failure may be in the remote handoff / compaction output, not just in local history trimming.

So the narrower hypothesis I would keep is this:

When a thread gets large and the user has already moved on from an earlier request to a later one, Codex sometimes keeps centering the earlier request. If compaction has happened, that may be because the compacted handoff still centers the earlier request, or because resume/reconstruction picks the wrong prior turn as the baseline for the next turn. If compaction has not happened yet, the same overall symptom may still be possible from long-thread/model behavior.

In other words, compaction still looks important, but more as a likely trigger or amplifier than as the entire explanation.

The OSS code paths that still seem most relevant are:

• codex-rs/tui_app_server/src/app.rs
• codex-rs/tui_app_server/src/app_server_session.rs
• codex-rs/core/src/compact_remote.rs
• codex-rs/core/templates/compact/prompt.md
• codex-rs/core/src/codex/rollout_reconstruction.rs

A minimal repro pattern would be:

1. Work on one request in a long thread.
2. Move clearly to a different request in the same thread.
3. Keep going until the thread is large, and either let compaction happen or stay just below compaction.
4. Send another message that is clearly about the later request.
5. Codex responds to the earlier request, or acts as if the earlier request were still current.

If you have affected thread IDs internally, the most useful comparison seems to be:

• sessions where this happened after compaction
• sessions where this happened before compaction
• the compacted replacement_history when compaction did happen
• the reconstructed reference_context_item / chosen prior turn baseline after compaction or resume

If this is not distinct enough from #8648, feel free to close it as a duplicate and just treat this as a root-cause note attached to that issue.