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:
- The fork should include only messages/events up to the selected fork point.
- Messages after the selected fork point should not be copied.
- Copied historical messages should preserve their original timestamps, or clearly be marked as copied history.
- 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?
- In a codex session in mac app, take a fork from a previous message point in history.
- Compare the messages in context for both the original session and forked session.
- 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
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:
Fresh fork:
The fork session file:
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:In the parent, those same messages originally happened earlier:
Expected Behavior
When I fork from an earlier point in a session:
<turn_aborted>should not appear as normalrole=usermessages.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:
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?
What is the expected behavior?
No response
Additional information
No response