Message-level fork after context compaction uses the compacted state instead of the selected pre-compaction history

Summary

In the Codex desktop app, forking from an earlier message after a later context compaction appears to use the latest compacted thread state, not the actual conversation/context state at the selected message.

This makes message-level forking much less useful for context management.

Clarification

The issue is not that the fork includes messages after the selected point.

The problem is that after compaction happens later in the thread, forking from an earlier pre-compaction message no longer reconstructs the original detailed history up to that selected message. Instead, the pre-compaction prefix itself seems to be represented by the later compacted summary/checkpoint.

For example, this is not about messages 8..21 appearing when forking from message 7. It is about messages 1..7 being restored in compacted form instead of their original detailed form.

What happened

I had a long Codex conversation where the context was around 140k tokens at an earlier point. Later in the same thread, Codex performed context compaction, reducing the active context to around 7k tokens.

After that compaction, I tried to fork from a message that was before the compaction happened. I expected the fork to preserve the original context up to that selected message.

Instead, the fork started with the compacted context.

Expected behavior

If compaction happened after message X, and I fork from message Y before X, the fork should use the original history/context up to Y.

It would make sense to use the compacted state only when forking from a point after the compaction happened.

Actual behavior

Forking from a pre-compaction message still seems to inherit the later compacted state. This causes major context loss. In my case, I expected a fork from a roughly 140k-token context point, but got something closer to the later 7k-token compacted state.

Why this matters

The fork feature is extremely valuable for context management. But if later compaction changes what older fork points mean, then older messages are no longer reliable restore/fork points.

Possible improvement

When forking from a message before a compaction checkpoint, Codex should reconstruct the history from the original rollout/transcript prefix before that compaction.

Alternatively, the UI could offer a choice:

• Fork with original history at this message
• Fork with current compacted summary

But silently using the later compacted state for a pre-compaction fork feels wrong.