[Bug] Windows: migrated paginated threads show empty history with EOF projection but zero turns/items

Environment

• Windows 11; installed Codex package inspected during investigation: 26.901.6511.0.
• Incident observed 2026-09-09, UTC+8.
• Two long-running pinned local threads; no pre-incident backup on another computer is available.
• This is a sanitized report. No private conversation text, repository names, usernames, thread IDs, local paths, authentication data, or raw attachments are included.

Observed behavior

Both threads remain listed, but their history is blank. Read-only application retrieval returns turns=[] with no more pages. Desktop logs show turnCount=0 and successful thread/read / thread/turns/list requests, not request timeout or protocol errors.

Both threads are marked history_mode=paginated. In consistent, read-only SQLite backup snapshots:

• thread_turns, thread_items, and thread_realtime_items each contain zero rows for both affected threads.
• thread_history_projection_state.next_rollout_byte_offset equals the end of each current rollout: 3,629,809 and 5,256,009 bytes.
• Both JSONL files still contain nonempty user/assistant messages and compacted replacement_history / guardian_history.
• SQLite quick_check returns ok; this does not establish logical history completeness.

One affected source previously had a metering-cache read offset of 710,450,171 bytes and thousands of historical token events; its current source is 3,629,809 bytes with retained metering timestamps collapsed to the old session creation time. Another affected source was previously about 267 MB and is now 5.26 MB. These cache observations establish a large source-format/content change, not recovery of the missing transcript.

Local evidence includes the legacy_to_paginated_v1 migration marker. The exact process that rewrote each file has not been proven by OS file-write auditing. No claim of malicious modification is made.

Expected behavior / impact

Existing conversation history should remain accessible through migration. A projection at EOF with zero turns/items should not silently present a nonempty stored thread as an empty conversation. If migration or projection is incomplete, the app should clearly report the condition and provide a supported, non-destructive recovery path.

These are important long-running work threads. Only partial plaintext has been extracted from the remaining structures; complete original conversation recovery has not been demonstrated.

Preservation / actions not taken

Affected source files, state/history databases with WAL/SHM, consistent SQLite backup snapshots, relevant desktop logs, and 487 related rollout files have been preserved locally. Readable plaintext fragments have been extracted offline only.

No source JSONL or source database has been manually edited by the investigator. No migration-mode change, projection rebuild, rollback, or recovery RPC has been attempted by the investigator.

A minimal synthetic reproduction is not yet available. The observations above are from the affected local installation; we have avoided potentially destructive reproduction attempts on the only original data.

Requested assistance

1. Is there a known legacy-to-paginated migration/projection defect that produces EOF projection state with zero persisted turns/items?
2. What is the supported, non-destructive recovery procedure for this exact state?
3. Can any missing history be recovered from the remaining compacted/guardian structures or other official storage?
4. How can further background migration be safely paused while preserving evidence?

Potentially related reports: #40342, #35746. Their reported projection failures may differ from this EOF-with-zero-rows state; we are not asserting an identical root cause.

Please request necessary diagnostics through a private channel. Full local logs and database snapshots contain sensitive project data and should not be posted publicly.

Start with the preserved SQLite backup snapshots, WAL/SHM files, JSONL sources, desktop logs, and the legacy_to_paginated_v1 migration marker. Compare the EOF projection state and zero persisted rows with the remaining history structures, then review related reports #40342 and #35746. Done means identifying the migration or projection defect and documenting a non-destructive recovery path or an explicit failure condition.