[Windows] Recent task history returns empty items: rollout uses original thread ID but projection rows use another UUID

What version of the Codex App are you using?

Windows installed package: OpenAI.Codex 26.901.6511.0 (queried via Get-AppxPackage, not the About dialog). The affected rollout's session_meta reports cli_version: 0.153.4.

What subscription do you have?

Not verified during this investigation.

What platform is your computer?

Windows 11 Pro, 10.0.22631, x64.

What issue are you seeing?

Recent conversation messages repeatedly disappear from the desktop history of a long-running local task. The messages still exist in the raw rollout AND in the history database, but recent history rows are keyed under a different thread ID from the one used to open/read the task.

The desktop read_thread tool returns completed turn metadata with items: [], including for a completed turn whose final assistant message is present in both storage layers. The missing message tells the user the task is blocked and asks them to free memory before continuing, so the missing history hides an actionable next step. This is an observed workload message, not evidence that memory pressure caused the history bug.

What steps can reproduce the bug?

The triggering transition is not yet reproducible on demand. This is a read-only diagnostic reproduction on an affected existing task, observed September 7, 2026:

1. Open the affected long-running local task. The user reports a missing recent section of its conversation, and reports this has happened before.
2. Call the desktop read_thread tool with its original ID, turnLimit: 8, includeOutputs: true, and maxOutputCharsPerItem: 10000.
3. Observe completed recent turns with timestamps and durations but empty items arrays. A later repeat also returns empty items for newer turns.
4. Locate the missing final message in the raw rollout at 2026-09-07T09:01:56.287Z, followed by a normal task_complete event at ordinal 38877.
5. Compare the thread ID used in state_5.sqlite, the rollout metadata, and thread_history_1.sqlite. The IDs disagree as detailed below.

No database or original rollout was modified in this investigation. No restart, forced crash, or recovery command was attempted. Earlier recovery/history of this task has not been reconstructed, so this report does not claim that a particular native operation created the split.

What is the expected behavior?

Reading/opening a task should recover its persisted messages under a consistent thread identity. If storage contains conflicting identities, surface a recoverable history error instead of silently presenting empty turn bodies. A supported reconciliation/rebuild path would help.

Additional information

Identifiers below are abbreviated as A (the original visible task ID) and B (a different UUID appearing as a suffix in its current rollout filename). Local usernames, project paths, and unrelated conversation contents are omitted.

Observed storage mapping:

state_5.sqlite / threads:
  id = A
  rollout_path = sessions/2026/09/07/rollout-<timestamp>-A_B.jsonl
  No threads row exists for B.

Current rollout first record:
  type = session_meta
  ordinal = 30942
  payload.id = A
  payload.forked_from_id = null
  payload.cli_version = 0.153.4

thread_history_1.sqlite / thread_history_projection_state:
  A: next_rollout_byte_offset = 420401846
     next_rollout_ordinal = 30949
  B: next_rollout_byte_offset = 108246479
     next_rollout_ordinal = 38950

Older physical rollout named ...-A.jsonl:
  size = 420401846 bytes (exactly A's saved projection offset)

Recent missing completed turn, starting at ordinal 38856:
  thread_turns: exists under B, not A
  thread_items under B:
    2 agentMessage, 2 commandExecution, 1 reasoning
  The final agentMessage text is intact under B.

read_thread(A) for this same completed turn:
  status = completed
  items = []

At the inspected snapshot, A's latest projected agentMessage was at ordinal 30936, while B's was at 38943. The task can continue running even while history reads return empty bodies.

This suggests an identity mismatch between task/rollout resolution and projected item lookup. That is a diagnostic hypothesis, not a confirmed code-level root cause. In particular, this evidence does not establish whether the filename suffix is being interpreted as an identity, or whether an earlier recovery operation introduced inconsistent state.

Related: #42387 describes a cursor left at an older rollout's EOF after file rotation. This report adds a distinct observation: newer turns and item bodies are successfully materialized under B while the visible task and session_meta still identify A. #42197 and #42241 describe explicit ordinal mismatch errors; no matching projection/ordinal-error lines were found in the inspected September 7 desktop text logs here.

Full rollout/database files are not attached because they contain private project content. The issue is supported by read-only SQL results and a recovered message, rather than an assumption that the original data was deleted.

Start by comparing the thread mappings in state_5.sqlite and thread_history_1.sqlite, then trace the read_thread entry point using the original task ID A and projection ID B. Done means persisted turns resolve under a consistent identity, with conflicting storage surfaced as a recoverable history error rather than empty items.