Codex Desktop can get stuck on sqlite state backfill with partial new index while legacy state is complete

What version of the Codex App are you using?

Codex Desktop 26.609.41114 on macOS.

The app-server version reported after recovery was:

currentVersion=0.140.0-alpha.2

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

macOS 15.6.1 (darwin), Apple Silicon.

What issue are you seeing?

Codex Desktop can get stuck during startup when the new SQLite state DB is left in a partial backfill state.

The user-facing symptom was that the app stayed around "Rebuilding conversation history" / failed to initialize, and the app-server repeatedly failed the initialization handshake. This looked similar to a local-history loss incident, but the original session files and the legacy/root state DB were still present.

The relevant Desktop log repeatedly showed:

failed to initialize sqlite state runtime under ~/.codex/sqlite:
timed out waiting for state db backfill at ~/.codex after 30s (status: running)
initialize_handshake_result outcome=failure

This repeated for several startup attempts. After the local state was repaired from a known-good state backup, the next Desktop startup logged:

Current reported app-server version: currentVersion=0.140.0-alpha.2
initialize_handshake_result durationMs=163 outcome=success transportKind=stdio

Local state evidence

Before repair, the new state DB at ~/.codex/sqlite/state_5.sqlite was internally readable and passed SQLite integrity check, but appeared to be a half-built index:

integrity=ok
backfill_state.status=running
threads=394
sum(has_user_event)=0
archived=206
thread_dynamic_tools=0

At the same time, the legacy/root state DB at ~/.codex/state_5.sqlite still had complete thread metadata:

integrity=ok
backfill_state.status=complete
threads=410
sum(has_user_event)=306
archived=206
thread_dynamic_tools=869

After restoring the complete state index, the current state DB looked healthy again:

integrity=ok
backfill_state.status=complete
threads=410+
sum(has_user_event)=306
thread_dynamic_tools=869

Expected behavior

Codex Desktop should detect and recover from this stale or failed backfill state instead of repeatedly failing startup after 30 seconds.

Possible safe behaviors:

• detect backfill_state.status=running from a previous failed app-server process and resume or reset the backfill lease safely;
• detect that the new sqlite index has threads > 0 but sum(has_user_event)=0 / thread_dynamic_tools=0 while the legacy/root DB has complete metadata;
• fall back to a safe rebuild path, or show a clear local-state recovery prompt that does not risk wiping thread metadata;
• avoid presenting a partial new sqlite index as valid sidebar/project history.

Actual behavior

The app-server repeatedly failed initialization with:

timed out waiting for state db backfill at ~/.codex after 30s (status: running)

This made the Desktop app unusable until the local state index was repaired manually from backup.

Related issues

This seems related to, but more specific than:

• #23787, which reports a Windows startup crash involving SQLx checksum drift and backfill timeout.
• #23979, which reports local project conversation history missing after update while threads still exist.

The distinguishing detail here is that on macOS the new sqlite state DB passed integrity_check but was stuck with backfill_state.status=running and had an obviously incomplete thread index, while the legacy/root state DB was still complete.