Codex Desktop fork aborts duplicated active turn while parent rollout completes, hiding the reply #32980

What version of the Codex App are you using?

26.707.31428, build 5059. Embedded codex-cli 0.144.0-alpha.4.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

Darwin 25.3.0 arm64.

What issue are you seeing?

A user follow-up was duplicated into both a parent thread rollout and a newly created fork. The fork became the visible thread, immediately recorded the duplicated turn as aborted, and never received an assistant message. The parent rollout continued in the background, produced two assistant messages, and completed successfully. Because those replies remained in the parent rollout, the visible fork looked as if Codex had stopped with no answer.

This is durable state, not only a stale visual render:

• parent rollout: task_started, user message, assistant output, second assistant output, task_complete
• child rollout: session metadata points to the parent through forked_from_id
• child rollout: the same turn ID and same user message are copied
• child rollout: task_started and turn_aborted are written at the same timestamp
• child rollout: no assistant message exists for that turn

The user-visible symptom was a follow-up receiving no response even though Codex had generated and persisted the reply in the parent rollout.

What steps can reproduce the bug?

The exact UI trigger is intermittent and is not yet isolated. The observed sequence was:

1. Continue a long-running local Codex Desktop thread.
2. Submit a short follow-up message.
3. About four seconds later, Codex Desktop creates a fork whose metadata points to the original thread.
4. The fork copies the already-running turn and immediately aborts it.
5. The original parent continues for about two minutes and completes with assistant output.
6. The UI remains on the fork, so the parent output is not shown.

Sanitized UTC timeline from the two local rollout files:

• 01:12:39.774 parent task_started
• 01:12:39.863 parent user message persisted
• 01:12:43.496 child fork session created
• 01:12:43.558 child copies the same task_started and user message, then writes turn_aborted
• 01:13:54.527 parent writes first assistant message
• 01:15:00.700 parent writes final assistant message
• 01:15:00.775 parent task_complete

What is the expected behavior?

A single user turn should have one active owner.

If the fork becomes active, the turn should run in the fork and the parent should be canceled. If the parent remains active, its assistant output should stay visible and the fork should not duplicate the turn. Codex should never leave the visible branch aborted while completing the same turn in a hidden parent branch.

Additional information

I searched existing issues before filing. This appears related to session routing issues, but is distinct from:

• Forked Codex sessions copy user messages from after the selected fork point #21025, which copies messages from after a selected fork point
• Codex Desktop writes empty assistant messages when continuing an older resumed thread #28751, which persists empty assistant messages in an older resumed thread
• Codex Desktop: multi-turn single session returns/persists a previous-topic answer for the latest turn #31042, which persists a previous-topic answer into the latest turn

No user prompt content, usernames, absolute paths, thread IDs, or image artifacts are included here. I can share the two private rollout IDs and logs through in-product feedback if maintainers need them.