[macOS Codex App] Ordinary follow-up silently reverts the thread and omits 13 completed continuation turns from UI history

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

26.818.61809 (build 7019)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

After an ordinary follow-up message in a completed local task, Codex Desktop issued an implicit thread/revert followed by turn/start.

The user did not edit a previous message, steer an active turn, request rollback, create a branch/fork, cancel a turn, or perform a worktree action.

The later turns completed successfully in a continuation rollout, but the task UI and paginated history projection remained pinned to the original rollout. As a result, 13 completed turns are absent from the visible task history even though they remain durably stored in the local session JSONL.

Affected task ID (masked): 01a032b9-…-61f4

Observed timeline:

• Last completion visible in the UI: 2026-08-24 11:33:16.321 UTC

(14:33:16.321 TRT)

• Desktop recorded method=thread/revert: 11:34:17.214 UTC
• Desktop recorded method=turn/start: 11:34:17.398 UTC
• First continuation turn started: 11:34:17.397 UTC
• Last hidden continuation turn completed: 20:54:48.060 UTC

(23:54:48.060 TRT)

Sanitized storage evidence:

• No thread/fork event exists for the affected task.
• The continuation session_meta uses the same thread ID and has

forked_from_id=null.

• The original rollout contains 20 completed turns and is 18,761,596 bytes.
• thread_history_projection_state remains at the original rollout EOF:

next_rollout_byte_offset=18761596,
next_rollout_ordinal=2155.

• thread_turns contains only those original 20 completed turns.
• The continuation rollout is 25,942,727 bytes and contains 13 additional

task_started / task_complete pairs.

• Those 13 completed turns are not materialized into the visible history.
• migrate-rollouts reported already_paginated with

bytes_processed: 0 and did not repair the projection.

For an end user, content that exists only in private JSONL or SQLite files but
is absent from the product UI is effectively lost. Users cannot be expected to
inspect Codex's internal storage to discover completed work.

What steps can reproduce the bug?

This is an observed recurring sequence, but I do not yet have a deterministic clean-room reproducer:

1. Open a local Codex task and let a turn complete.
2. Send a normal follow-up message.
3. Do not edit an earlier message, steer, fork, branch, cancel, or request a rollback.
4. Observe Desktop issue thread/revert, followed immediately by turn/start.
5. Let the new turn and subsequent turns complete.
6. Reopen or inspect the task history.
7. Observe that the UI stops at the earlier rollout even though the continuation JSONL contains completed later turns.

The same symptom has occurred in other project conversations, including a short conversation, so a long context is not a prerequisite.

What is the expected behavior?

An ordinary follow-up should append to the existing task without silently rolling back visible history.

If Codex internally creates a continuation rollout, every completed continuation turn must be materialized into the task's UI/history projection.

When the projection and canonical session records disagree, Codex should automatically reconcile or rebuild the projection. If reconciliation fails, the app should display an explicit synchronization error instead of silently showing truncated history.

Additional information

Related but not exact duplicates:

• #19975: Desktop replay/fork omits messages, but involves explicit steering/forking on Windows.
• #40112: stale thread_history projection after a process crash on Windows.
• #38792: paginated-history cursor desynchronization in the CLI.
• #40512: completed output exists in JSONL but is dropped from the live projection on Windows; also reproduces in a short/fresh task.
• #40563: projection/runtime disagreement on the same macOS app version, but follows a stream-disconnection incident.

This report does not publicly attach raw transcripts, databases, app logs, message bodies, project names, absolute local paths, or the full task ID. Sanitized extracts and the complete identifier can be supplied privately to OpenAI if needed.