›_ Codex Issues
Codex Issues / #35674

Large long-lived local session history blocks Codex Desktop startup during state DB backfill

Open 💬 1 comment Opened Jul 27, 2026 by SanSan-

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

Codex Desktop: 26.721.4979.0, App server: 0.146.0-alpha.3.1

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows 11 x64 (Microsoft Windows NT 10.0.26200.0 x64)

What issue are you seeing?

Codex Desktop startup appears to depend on the total size and composition of the user's long-lived local session history. With my full existing Codex profile restored, containing approximately 34.25 GiB of session history, the application does not open and reports:

Codex app-server initialize handshake timed out

The Desktop log shows:

state db backfill is running at /mnt/c/Users/user/.codex; waiting up to 30s before retrying startup initialization

I first noticed this after an app update installed on Saturday, July 25, 2026. I cannot confirm whether that update introduced the regression or whether the behavior already existed and only became visible after the update/restart.

This is a serious long-term usability and data-retention problem. A user who keeps using Codex and retains session history can eventually reach a state where the application cannot start. Recovery currently requires manually moving internal session and SQLite state files, then restoring history in measured batches. Normal accumulated user history should not become a startup dependency that can make the application unusable.

The problem is specifically related to the session/state layer:

  • With the full historical sessions, archived_sessions, and matching state DB restored, Desktop initialization times out.
  • When those items are isolated from the active profile, Desktop starts.
  • When history is restored incrementally while the state DB remains in a completed backfill state, Desktop starts again.
  • In one verified staged state, approximately 0.9 GiB of restored history and 121 indexed DB entries produced a 275 ms Desktop handshake, a visible main window in 603 ms, and mounted routes in about 2.05 s, with no backfill wait.

This points to startup being synchronously coupled to a potentially large or repeated state DB backfill under a fixed initialization timeout. Large individual rollout files may also contribute.

What steps can reproduce the bug?

  1. Use a long-lived Codex Desktop profile with many retained sessions, including some large session rollout files. My complete history is approximately 34.25 GiB.
  2. Place the session history and its matching state_5.sqlite state under the normal %USERPROFILE%\.codex profile.
  3. Start Codex Desktop.
  4. Observe that the app-server initialization handshake times out while the state DB backfill is still running or waiting.
  5. Exit Codex completely.
  6. Move sessions, archived_sessions, and state_5.sqlite* out of the active profile, then start Codex again.
  7. Observe that the application starts.
  8. Restore smaller subsets of the same history incrementally and rebuild/index them to completion.
  9. Observe that startup works again below the problematic history/backfill state.

The exact size threshold may depend on session count, individual rollout size, DB state, storage performance, and the WSL-backed filesystem path. The key reproducible boundary is that the same application installation starts with the history/state layer isolated and fails with the full long-lived history/state layer present.

What is the expected behavior?

Codex Desktop should remain launchable regardless of how much valid session history has accumulated during normal long-term use.

In particular:

  • Historical state migration/backfill should be incremental, resumable, and preferably performed in the background.
  • Startup should not require the entire historical corpus to finish processing within a fixed app-server handshake deadline.
  • If migration is required, the UI should open and display progress or a recovery option instead of failing the whole application startup.
  • A completed backfill should not be needlessly repeated.
  • Large histories should be indexed, segmented, or compacted in a way that keeps startup time bounded.
  • Failure diagnostics should identify the exact database/path, current progress, and a safe recovery action that does not require deleting user history.

Additional information

This appears related in theme to reports of unbounded local Codex state growth, but it is distinct from issue #27741: that issue concerns logs_2.sqlite, while this report concerns retained session history, state_5.sqlite, state DB backfill, and the Desktop initialization handshake.

I can provide sanitized timing data, file-count/size summaries, and the relevant Desktop log excerpt. I cannot safely publish raw session JSONL files, the complete SQLite database, or the full .codex archive because they contain conversation content, commands, local repository paths, and potentially sensitive data.

View original on GitHub ↗

1 Comment

null0526 · 27 days ago

Additional reproduction: an empty completed backfill is not invalidated after rollout files are restored

I reproduced the same fixed 30-second initialization failure described in this issue on a substantially smaller Windows profile, and the recovery process exposed a second deterministic state/indexing problem.

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

History at the time of failure:

  • 127 active rollout files, approximately 497 MB
  • 209 archived rollout files, approximately 860 MB
  • 336 rollout files, approximately 1.36 GB total

logs_2.sqlite was approximately 464 MB, but moving it aside did not change the state-backfill failure.

Startup failure

With the full rollout history present and the WSL state DB requiring backfill, Desktop consistently terminated initialization after approximately 30 seconds:

state db backfill is running at /mnt/c/Users/<windows-user>/.codex;
waiting up to 30s before retrying startup initialization

initialize_handshake_result
durationMs=30001
errorMessage="Codex app-server initialize handshake timed out"

failed to initialize sqlite state runtime:
timed out waiting for state db backfill after 30s
(status: running)

The failure was deterministic while backfill_state.status remained running.

Deterministic stale-complete reproduction

The following recovery sequence exposed a separate issue:

  1. Fully stop Codex Desktop and its app-server processes.
  1. Temporarily move sessions and archived_sessions outside the active Codex home.
  1. Start Desktop with no rollout files present.
  1. Desktop starts successfully and records:

``text
threads=0
backfill_state.status=complete
``

  1. Fully stop Desktop.
  1. Restore all rollout files to their original directories.
  1. Start Desktop again.

Desktop now starts, but the restored history remains absent. The rollout files are not rescanned after the prior empty backfill has been marked complete.

Unsupported re-arm experiment

After backing up the database, changing the backfill state so that the importer ran again caused the existing rollout files to be indexed. Observed progress across separate launches included:

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

This demonstrates that the restored rollout files were readable and importable. However, each launch still encountered the same 30-second fatal startup boundary while backfill remained active.

Completion was reached only after temporarily excluding four of the largest remaining rollout files:

12.9 MB
19.8 MB
24.2 MB
64.1 MB

All four files passed line-by-line JSONL parsing. One contains an individual JSONL record of approximately 10 MB. That record is a candidate performance factor, but I have not established that it is the blocking record or the root cause.

Restoring even one excluded file and re-arming the backfill returns Desktop to the startup-timeout path.

Current workaround

Desktop is currently usable with:

  • 332 indexed threads;
  • the four unindexed rollout files kept outside the active session directories; and
  • the backfill state marked complete.

No rollout files were deleted, but those four sessions are unavailable through Desktop history.

This workaround requires direct manipulation of internal state and is not suitable as a supported recovery procedure.

Additional behavior requested

This reproduction suggests that recovery needs all of the following:

  1. Backfill or migration work must not be a fatal prerequisite for the Desktop initialization handshake.
  2. A completed backfill must detect rollout files added or restored afterward, or expose a supported way to re-arm reconciliation.
  3. One slow or unprocessable rollout should be reported and isolated without preventing the remaining history from being indexed.
  4. Codex should provide a supported, idempotent local-history verify/reindex operation.

This also overlaps with #31433 and #28068, which cover valid rollout files missing from the state DB and the lack of a supported historical rescan/reindex path. The additional evidence here is the deterministic empty-backfill-to-stale-complete transition and the observed incremental importer progress under the same Windows/WSL runtime.