Lost part of thread history and all subagent thread history after Codex App restart.

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

Version 26.325.31654 (1272)

What subscription do you have?

Pro

What platform is your computer?

MacOS 26.3 (25D125)

What issue are you seeing?

I restarted the app after being prompted for system recording permissions to take a screenshot. I went back to the thread and told it I was about to restart it, so then it finished its message, so it wasn't during an ongoing thread. But once it finished its message, I restarted the app and reopened it, and the thread had reverted back to a couple messages previously and had lost all of its sub-agent threads as well (across other sessions too).

thread ID 019d4f15-8541-7c83-85d0-4fc9abb8139b

What steps can reproduce the bug?

I continue to reopen the app to the missing threads and thread message history

What is the expected behavior?

Preserve app state after restart

Additional information

thread ID 019d4f15-8541-7c83-85d0-4fc9abb8139b

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Powered by Codex Action

Root Cause Analysis — async persistence not flushed on shutdown

After digging through the codex-rollout and codex-state crates, I believe the data loss stems from three unsynchronized async persistence layers that can all have in-flight writes when the process is terminated.

The persistence pipeline:

App → RolloutRecorder (async mpsc, 256-item buffer) → background writer → JSONL
    → StateRuntime (SQLite in WAL mode) → state.db
    → session_index (append-only file)

All three writes proceed concurrently and none are guaranteed to flush before process exit.

1. `RolloutRecorder` drops buffered items on shutdown

File: codex-rs/rollout/src/recorder.rs

Items are queued into a bounded 256-item tokio::sync::mpsc channel and consumed by a background writer task. If the process is killed (SIGTERM, system restart, OS interruption during a permission prompt) before that task drains the channel, the queued items are dropped. There is no sync_all() / fsync() and no mechanism to await the task's completion before exit.

2. SQLite WAL not checkpointed on process exit

File: codex-rs/state/src/ (STATE_DB_VERSION = 5)

The state database runs in WAL mode. Writes accumulate in the -wal file and are only checkpointed into the main database on a clean close or explicit PRAGMA wal_checkpoint. An abrupt exit leaves the WAL uncheckpointed, so on next startup thread metadata (timestamps, titles, status) reverts to the last successful checkpoint — which can lag behind the actual rollout by many transactions.

3. Incomplete session_index write breaks sub-agent thread discovery

File: codex-rs/rollout/src/session_index.rs

The session index is append-only and backward-scanned at startup by find_thread_path_by_id_str(). Sub-agent thread IDs are only discoverable if their index entry was fully written and flushed. A mid-write process exit produces a truncated or absent entry, making sub-agent threads completely invisible on restart — even though their JSONL rollout files still exist on disk. This explains why sub-agent histories disappear entirely while the main thread partially recovers.

Proposed Fix

On graceful shutdown, in order:

Drop the sender half of the RolloutRecorder channel and await the writer task to fully drain before returning
Call PRAGMA wal_checkpoint(TRUNCATE) on the SQLite connection before closing the pool
Ensure session_index appends call sync_all() after each write, or are sequenced behind the recorder flush

For non-graceful exits, a startup recovery pass that reconciles a partial JSONL rollout via reconcile_rollout() against the WAL could recover data that's on disk but not yet indexed.

What a disaster. How do you allow this crucial data to disappear? I've literally lost all of my planning sessions, which I needed because 5.4 is retarded. The only thing that consistently works about this trash app is the spinner eating GPU for no reason. It's wild--the session disappears from the Threads list (leaving an empty folder, lovely), AND the recovery file is clipped!

Do you expect users to trust your software and ecosystem when the app can't even preserve CHAT SESSIONS reliably? Maybe OpenAI should build some kind of chat product, maybe call it ChatLLM or something less generic. A robust chat product would require session data to persist reliably, so once you build that you could leverage it in Codex. It's too bad an OpenAI chat product doesn't yet exist.

codex: surface shutdown durability failures (#16599)

codex: distinguish shutdown durability failures (#16599)

codex: checkpoint WAL after rollout shutdown errors (#16599)

codex: emit shutdown complete after durability errors (#16599)