Desktop history projection offset is not reset when rollout_path changes, hiding most of a long-running thread

Environment

• Codex Desktop on Windows 11 (build 26200), bundled codex-cli 0.153.4
• Local project thread with paginated history
• Observed on 2026-09-08 (Europe/Warsaw)

Problem

After keeping one task active and continuing it across several days, almost a week of messages disappeared from the Codex Desktop history view. The source rollout JSONL still contained the missing user and assistant messages, so the source conversation was not deleted. The user had to spend additional Codex usage diagnosing and repairing an application indexing problem.

Technical diagnosis

The thread record in state_5.sqlite pointed to the newest continuation rollout (771,514,229 bytes), but thread_history_1.sqlite retained an old projection checkpoint:

• next_rollout_byte_offset: 5,780,683
• next_rollout_ordinal: 568

The saved byte offset was exactly the size of the initial rollout file from 2026-08-27, not a valid checkpoint for the newer continuation rollout. When applied to the current rollout, it landed 505,028 bytes inside a valid JSONL event. Only about 0.749% of the current rollout was projected, which explains why most of the history disappeared from the UI.

Likely reproduction

1. Keep a local Desktop task active over multiple days.
2. Continue/resume it so the thread's rollout_path changes to a newer continuation file.
3. Reopen the task or reload the app.
4. The history projection reuses the checkpoint belonging to the previous rollout file and most later messages are absent from the history view.

Recovery used

1. Preserve the source rollout JSONL.
2. Make a backup of thread_history_1.sqlite.
3. Remove only the derived rows for the affected thread from thread_items, thread_turns, and thread_history_projection_state.
4. Reopen/reindex the thread from the current rollout.

This recovered access without modifying the source conversation.

Proposed fix

• Associate a projection checkpoint with both thread_id and rollout file identity/path, not thread_id alone.
• Reset or migrate the checkpoint whenever threads.rollout_path changes.
• Before resuming, verify that the byte offset belongs to the current file, is within bounds, starts at a JSONL record boundary, and parses successfully.
• If validation fails, automatically rebuild the derived projection from the source rollout and notify the user without consuming model usage.

Expected behavior

All messages in a continued long-running task remain visible after reopening the task, and changing rollout files cannot leave the history projector at an offset from an older file.

Usage impact and request

The user had to spend paid Codex usage investigating and repairing a Codex Desktop indexing defect. Please review whether that usage can be restored or credited. Since this report includes a reproducible root cause and a validated recovery procedure, the user also asks whether it qualifies for any bug-report recognition or reward program.

Start by tracing how thread_history_1.sqlite stores projection state for threads and how threads.rollout_path changes when a continuation is selected. Inspect the thread_items, thread_turns, and thread_history_projection_state rows, then reproduce the stale-offset case with a changed rollout file. Done means the checkpoint is validated or reset for the current rollout and the complete history is visible after reopening.