[state DB] Restored rollout files are not rescanned after an empty backfill is marked complete

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

26.727.40816

What subscription do you have?

20x pro

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

Summary

Codex treats a completed state DB backfill as terminal even when that backfill ran while sessions and archived_sessions were temporarily empty.

If rollout files are restored afterward, subsequent launches do not rescan them. Desktop starts normally, but local history remains empty because the restored files are never added to the threads table.

There is no supported command to invalidate, rebuild, or reconcile the completed index.

This is related to #31433 and #28068. The distinguishing evidence here is a deterministic state transition from an empty completed backfill to restored, valid but permanently unindexed rollout files.

Environment
Codex Desktop package: OpenAI.Codex_26.727.4816.0_x64
Bundled WSL app-server: 0.146.0-alpha.9.2
Windows 10 Pro, build 19045, x64
Windows Codex home: C:\Users\<windows-user>\.codex
WSL state DB: /home/<wsl-user>/.codex/sqlite/state_5.sqlite

Restored history:

127 active rollout files
209 archived rollout files
336 files, approximately 1.36 GB total

What steps can reproduce the bug?

Steps to reproduce

Start with valid rollout files under:

%USERPROFILE%\.codex\sessions
%USERPROFILE%\.codex\archived_sessions
Fully stop Codex Desktop and all app-server processes.
Temporarily move both rollout directories outside the Codex home.
Remove or recreate the WSL state_5.sqlite.
Start Codex Desktop.

Confirm that it starts and records:

threads=0
backfill_state.status=complete
Fully stop Desktop.
Restore all rollout files to their original directories.
Start Desktop again.
Actual behavior

Desktop starts, but history remains empty.

The restored rollout files are not added to the threads table because the previous empty backfill is already marked complete.

Repeated restarts do not cause another scan.

Evidence that the rollouts are importable

After backing up the database, manually re-arming the backfill caused the existing files to populate the threads table.

Observed progress included:

threads=195 backfill=running
threads=292 backfill=running
threads=332 backfill=complete

This was an unsupported diagnostic experiment, not a proposed user workaround.

What is the expected behavior?

Expected behavior

At least one of the following should be supported:

Detect rollout files added or restored after the previous backfill completed.
Invalidate the completed state when the rollout inventory differs from the indexed inventory.
Provide a supported, idempotent reindex or reconcile local history command.
Report and isolate individual files that cannot be indexed rather than abandoning the complete reconciliation operation.
Related issues
#31433 covers valid rollout files missing from the state DB and the absence of a supported bulk reindex operation.
#28068 covers historical rollout files remaining undiscoverable after state-index regeneration.
#35674 covers the separate 30-second Desktop startup failure encountered while the backfill is actively running.

This report is intentionally scoped to invalidation of an already completed empty backfill, rather than the Desktop initialization timeout itself.

Additional information

_No response_