Repository navigation
Codex task history corrupted after Windows app crash #41333
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.820.71523
What subscription do you have?
Pro
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
A very important, long-running Codex Work task became corrupted after the ChatGPT Windows app/computer crashed. The computer locked up and had to be powered off and restarted.
The task repeatedly resets to the same pre-crash checkpoint. Closing and reopening the task and restarting the Windows app do not resolve it.
Diagnostics observed inside Codex:
- The affected turn remains permanently marked
inProgress. - The thread itself remains marked
active. - A same-directory fork failed with a history-projection error: expected ordinal 6442, got 6441.
- New messages and completed work after the crash disappear from the visible transcript when the task is reopened.
I created a separate recovered task so I can continue working, but I need the original task and its history preserved. Please repair or close the stuck turn and restore the complete transcript, or provide a server-side fork/export of the task.
Exact task and turn identifiers have been provided privately to OpenAI support and can be supplied to maintainers through a secure channel. Application logs are also available privately; they contain sensitive local information and will not be posted publicly.
What steps can reproduce the bug?
- Open an existing, long-running Codex task in the ChatGPT Windows app.
- Start a turn that performs multiple tool calls and takes several minutes.
- While that turn is still running, allow the computer or Windows app to crash unexpectedly.
- Restart the ChatGPT Windows app and reopen the same task.
- Continue the conversation and complete additional turns.
- Close and reopen the task, navigate away and back, or restart the app again.
What is the expected behavior?
After restarting the app, the interrupted turn should either:
- resume normally;
- be marked failed/cancelled; or
- allow the user to continue from the last durable message.
Subsequent completed messages should remain visible, and the task should remain forkable/exportable.
Additional information
Actual result
The conversation repeatedly resets to the turn that was running when the crash occurred. Messages and completed work after that checkpoint may appear temporarily, but disappear from the visible transcript after the task is reopened.
The interrupted turn remains permanently marked inProgress, and the thread remains active. Restarting the app does not clear the state.
Attempting to create a same-directory fork also fails with:
failed to prepare paginated fork: thread-store internal error:
thread history projection for <redacted thread identifier>
expected ordinal 6442, got 6441
Diagnostic identifiers
Exact session/thread and stuck-turn identifiers have been provided privately to OpenAI support.
Stuck turn status: inProgress
Thread status: active
Token/context information
Exact token-limit usage and context-window percentages were not displayed in the Windows app, so I cannot provide reliable numbers. The conversation was long and had undergone at least one automatic context compaction before the crash.
Code snippet
No application-code snippet is applicable because this is a Windows app/thread-store persistence issue triggered by an unexpected crash during an active Codex turn.
Activity
github-actions commentedon Aug 28, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
yi-chen123 commentedon Aug 28, 2026
Additional recurrence evidence from the same Windows incident (sanitized; no local paths, task IDs, or conversation contents):
Codex CLI process exited classifiedAsExpected=falsewith decimal exit code3221225786(0xC000013A), followed by automatic recovery.expected ordinal 8869, got 8868expected ordinal 5368, got 5367This reproduced across multiple tasks in the same app session/day.
MuscleLabsDev commentedon Aug 29, 2026
I have an independent Windows desktop reproduction of the same paginated-history failure class, with additional persistence-level evidence.
Environment:
26.825.4187.026.825.32147history_mode=paginatedMeasured state:
25656, including a later surviving checkpoint at ordinal25642.next_ordinal=25202.158669268, but the complete rollout record at that offset is ordinal25201.expected ordinal 25202, got 25201371 times across two app-server processes.This supports a derived projection/cursor recovery bug rather than canonical conversation loss. A browser-process crash is time-correlated with the specimen, but it is not a proven trigger; four ultimately omitted turns completed before the crash.
The public
thread_history_materialization.rspath currently rejects an ordinal behindnext_ordinal. A safe recovery direction would be to invalidate/rebuild only the derived per-thread projection from the intact rollout, never rewrite the rollout itself.Related reports with the same projection family: #38792 and #41079.
I have a private local review-draft patch and focused regression-test plan if maintainers want more detail. I have not repaired or modified the preserved specimen, and I am not posting prompts, conversation text, task identifiers, local paths, databases, or raw logs publicly.
wunsir commentedon Aug 29, 2026
Additional Windows reproduction on Codex Desktop 26.825.5331.0.
Two local paginated threads were affected after interruptions and app restarts. Their durable rollout JSONL files still contain later user messages, tool activity, and completed assistant responses, but after restart the desktop UI reconstructs only an early subset of each thread.
thread/fork and side chat fail with code -32603:
The desktop log also records [Composer] side chat failed with the same failed to prepare paginated fork error.
Restarting the app did not rebuild the projection. The app-server exposes only 9 turns for one affected thread and only the initial interrupted turn for the other, while their durable rollout files contain substantially more history.
This appears to be a history projection/index failure rather than deletion of the durable transcript.
No transcript, absolute paths, local thread IDs, or raw logs are included publicly. Full diagnostics were submitted privately through Codex feedback.
Codex feedback ID: 01a04d88-e06d-7103-97eb-4bdec4a6f2cc
Jetonii commentedon Sep 6, 2026
Exactly the same problem is happening to me several times, its become so annoying and really hard to use codex this way.