Forked Codex sessions copy user messages from after the selected fork point

Update

There's been no update on the app but I see the issue isn't happening anymore for me when I take a fork in the codex app.

Not sure exactly what changed. 🤔

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

26.429.30905 (2345)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

When creating a fork from an earlier point in a Codex session, the new fork includes user messages that were sent after the selected fork point.

Those copied messages also get rewritten with the new fork creation timestamp, which makes them look like they were sent fresh in the fork.

This makes it hard to trust the forked session history and makes debugging session timelines confusing.

Example

Parent session:

019df362-aa9f-7011-903e-4a0878d49fa0

Fresh fork:

019df3d2-6edb-7322-b537-34d4f10cb129

The fork session file:

~/.codex/sessions/2026/05/04/rollout-2026-05-04T21-59-07-019df3d2-6edb-7322-b537-34d4f10cb129.jsonl

The fork metadata says:

{
  "id": "019df3d2-6edb-7322-b537-34d4f10cb129",
  "forked_from_id": "019df362-aa9f-7011-903e-4a0878d49fa0",
  "timestamp": "2026-05-04T16:29:07.679Z"
}

But the fork contains these parent user messages, all rewritten to around 2026-05-04T16:29:08Z:

Now I want to have a completely branch new implementation...
Okay then based on this...
do not swap...
Use @Computer...
scroll and see everything

In the parent, those same messages originally happened earlier:

2026-05-04T14:29:36Z  Now I want to have...
2026-05-04T14:44:27Z  Okay then based on this...
2026-05-04T14:45:27Z  do not swap...
2026-05-04T14:57:37Z  Use @Computer...
2026-05-04T14:58:51Z  scroll and see everything

Expected Behavior

When I fork from an earlier point in a session:

1. The fork should include only messages/events up to the selected fork point.
2. Messages after the selected fork point should not be copied.
3. Copied historical messages should preserve their original timestamps, or clearly be marked as copied history.
4. Synthetic entries like <turn_aborted> should not appear as normal role=user messages.

Actual Behavior

The fork includes user messages from after the selected fork point.

The copied messages are written into the new fork with the fork creation timestamp, so they look like new messages in the fork.

The fork also includes synthetic entries like:

<turn_aborted>...</turn_aborted>

as role=user.

Impact

This breaks trust in session history. It becomes unclear which messages were actually sent in the fork and which were copied from the parent. It also makes timeline debugging and auditing user messages much harder.

What steps can reproduce the bug?

1. In a codex session in mac app, take a fork from a previous message point in history.
2. Compare the messages in context for both the original session and forked session.
3. Ideally the forked session should have messages only till the point where it was forked in the original session but currently it copies all the messages (including one's from after the fork point)

What is the expected behavior?

_No response_

Additional information

_No response_