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:
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.
What version of the Codex App are you using?
Codex Desktop
26.609.41114on macOS.The app-server version reported after recovery was:
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:
This repeated for several startup attempts. After the local state was repaired from a known-good state backup, the next Desktop startup logged:
Local state evidence
Before repair, the new state DB at
~/.codex/sqlite/state_5.sqlitewas internally readable and passed SQLite integrity check, but appeared to be a half-built index:At the same time, the legacy/root state DB at
~/.codex/state_5.sqlitestill had complete thread metadata:After restoring the complete state index, the current state DB looked healthy again:
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:
backfill_state.status=runningfrom a previous failed app-server process and resume or reset the backfill lease safely;threads > 0butsum(has_user_event)=0/thread_dynamic_tools=0while the legacy/root DB has complete metadata;Actual behavior
The app-server repeatedly failed initialization with:
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:
The distinguishing detail here is that on macOS the new sqlite state DB passed
integrity_checkbut was stuck withbackfill_state.status=runningand had an obviously incomplete thread index, while the legacy/root state DB was still complete.