[Windows][Desktop 26.908.4834.0] Compaction rewrote three rollouts and history projection left 13 threads unindexed

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

Microsoft Store package OpenAI.Codex_26.908.4834.0_x64; bundled codex-cli 0.154.0-alpha.6.2.

What subscription do you have?

Not included in the local diagnostic evidence; I can provide it if required.

What platform is your computer?

Windows x64, OS build 26100.

What issue are you seeing?

Summary

Three long-running Windows Codex Desktop threads now begin at a compacted snapshot rather than their original transcript. Earlier assistant messages are absent from the current rollout files, while retained user/developer inputs survive inside replacement_history with one encrypted compaction item. Two rollout files were recreated on September 9 even though their filenames encode August session starts.

The same investigation found a second failure: 13 threads still had completed message events in their rollout JSONL but had no projected history items. Rebuilding the SQLite projection restored 209 later message items, but it could not recover assistant messages absent from the three rewritten rollouts.

This closely matches #44363. I am filing a separate case because this provides three Windows examples, exact before-repair comparison, full source/index parity checks, and evidence that destructive compaction and projection migration are separate layers of the failure.

Environment

• Windows x64, build 26100
• Microsoft Store package: OpenAI.Codex_26.908.4834.0_x64
• Bundled codex-cli: 0.154.0-alpha.6.2
• Affected rollouts record CLI versions 0.146.0-alpha.9.2 and 0.147.0-alpha.6.6
• Same account throughout; no task deletion, account switch, or project-directory move
• All three affected records use paginated history and originated as delegated/subagent tasks

Sanitized rollout evidence

Each rollout starts with session_meta, immediately followed by one compacted record. There are no ordinary messages before that record. Its message field is empty.

The initial compacted records are byte-identical to a backup created before the local history repair. The repair did not edit any rollout. This rules out the repair as the writer of those snapshots.

For comparison, two other long-running local threads also contain compaction events but retain 91 and 54 indexed messages before their first compaction marker, and their complete visible history remains scrollable. Compaction by itself therefore does not require the UI transcript to begin at the compaction marker.

Secondary history-projection failure

• 13 threads had completed source message events but zero corresponding history items.
• After backing up the databases and rollouts, rebuilding the projection restored 209 message items.
• SQLite quick_check passes for the state and history databases.
• A post-repair source/index audit found no missing source message events or orphan history items across 55 ordinary threads.
• Complete thread/turns/list pagination succeeded for 53 content-bearing threads.
• Reindexing only restored messages that still existed in the rollout; it did not recreate missing pre-compaction assistant turns.

Recovery sources checked

No predecessor rollout or earlier assistant transcript was found in active sessions, archived sessions, Codex browser/cache storage, Windows package storage, app logs, temporary files, Recycle Bin, older state databases, or local backups. Windows File History was not configured. An elevated vssadmin, Win32_ShadowCopy, and restore-point check returned no snapshots.

Suspected sequence

The evidence is consistent with this sequence:

1. A compaction/local-thread-store path recreated the durable rollout using only a compacted working window.
2. Earlier assistant records were discarded while selected user/developer inputs survived in replacement_history.
3. Paginated-history migration or projection then processed the already-rewritten rollout and left some threads unindexed.
4. Rebuilding the projection restored only the source records that remained.

This is an inference from local artifacts. Without pre-rewrite Windows files or server-side write logs, I cannot identify the exact writer.

What steps can reproduce the bug?

I do not have a safe deterministic reproduction. Conditions shared by the affected threads:

1. Use a long-running delegated/subagent task across many turns.
2. Allow multiple context compactions.
3. Update/restart Codex Desktop during the legacy-to-paginated history transition.
4. Reopen the task and observe that history stops at “Context automatically compacted.”
5. Inspect the rollout and observe session_meta followed immediately by a single compacted snapshot.

What is the expected behavior?

Context compaction should reduce model-visible context without deleting the durable user-visible transcript. An update or history migration should preserve every existing rollout and rebuild projections from the start. If recovery is impossible, the app should show an explicit error and retain a pre-rewrite backup.

Additional information

I can provide private thread/window IDs, sanitized diagnostics, file hashes, and the support case reference to an OpenAI maintainer. I am intentionally not publishing conversation text, task names, local paths, credentials, raw rollouts, or database files.

Start with the compaction/local-thread-store path and the paginated-history migration that write rollout JSONL and the SQLite state and history databases. Compare the affected rollout records with the retained examples and inspect how projections are rebuilt from source events. Done means durable transcripts remain intact across compaction and migration, missing history is indexed, and an unsafe rewrite preserves a recoverable backup.