codex.exe exits with code 0 mid-session; thread-store then fails "expected ordinal N, got N-1"

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

OpenAI.Codex 26.818.8289.0; codex-core 0.149.0-alpha.4.3

What subscription do you have?

ChatGPT Pro ($200/month)

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64 (Windows 10 build 19045)

What issue are you seeing?

Environment: OpenAI Codex desktop app (Microsoft Store), package OpenAI.Codex 26.818.8289.0, engine codex-core 0.149.0-alpha.4.3, Windows 10 build 19045.

During an active session, the codex.exe engine process periodically terminates with exit code 0x00000000. This is a clean exit: there is no Application Error or Windows Error Reporting event and Windows does not create a crash dump. The exit code was confirmed by attaching ProcDump to codex.exe.

After each exit, the thread whose rollout was being written becomes permanently broken. Every subsequent durable write fails:

codex_thread_store::local::live_writer ... failed to project durable rollout for <tid>:
thread-store internal error: thread history projection for <tid> expected ordinal N, got N-1

Subsequent turns then fail with:

Custom tool call output is missing for call id ...

The affected thread remains unusable. Archiving only stops additional errors because the archived thread is no longer written.

Observed scope from a read-only snapshot of logs_2.sqlite taken at 2026-08-25 15:50:27 UTC:

• 6 distinct affected threads
• 2,713 rows containing expected ordinal
• First event: 2026-08-23 21:13:23 UTC
• Most recent event: 2026-08-25 15:49:56 UTC

One exact logged failure:

handle_tool_call_with_source:dispatch_tool_call_with_code_mode_result{otel.name=apply_patch tool_name=apply_patch call_id="exec-f4c539e3-e06f-44a6-9ce4-b24617e7e213" aborted=false}:dispatch_tool_call_with_terminal_outcome:persist_rollout_items{item_count=1}:append_items{item_count=1}:append_items{item_count=1}: failed to project durable rollout for 01a02da6-8925-7412-a4b6-3bf9c0af6a98: thread-store internal error: thread history projection for 01a02da6-8925-7412-a4b6-3bf9c0af6a98 expected ordinal 6732, got 6731

This does not appear to be a network or authentication issue: backend requests return 200 OK and authentication remains valid. It also does not appear to be an OS-level crash.

A full user-mode dump captured at the exact exit moment is available on request. It may contain session data and is therefore not attached publicly.

This may be related to #40231, but the termination signature is different: that report shows 0xC000013A / STATUS_CONTROL_C_EXIT, while this report was externally observed as 0x00000000.

What steps can reproduce the bug?

1. Use Codex Desktop normally in an active session.
2. Continue a turn that performs local work while the rollout is being written.
3. When the periodic codex.exe exit occurs mid-write, Codex Desktop restarts the engine.
4. Resume or continue the affected thread.
5. Durable writes repeatedly fail with the thread-history ordinal mismatch, followed by missing custom tool-call output errors.

The exit is intermittent, but every observed thread active at the exit becomes unusable afterward.

What is the expected behavior?

codex.exe should remain running during an active turn. If the process exits or is restarted, the durable thread history should recover atomically without an ordinal mismatch or a missing tool-call output, and the thread should remain usable.

Additional information

The SQLite log database was inspected through a read-only URI with query-only mode enabled. No Codex database was modified.

No public memory dump is attached. A full user-mode dump captured at the exit moment can be provided through a secure channel on request.

Start by tracing the codex.exe restart path and the codex_thread_store::local::live_writer durable projection, using the logged append_items and persist_rollout_items failures as entry points. Reproduce or inspect the ordinal mismatch after a mid-turn process exit; done means the thread history recovers atomically and subsequent tool-call output and durable writes remain usable.