Windows App: Thread messages are displayed out of order after reopening, across all projects and newly created threads

Open 💬 5 comments Opened Jun 23, 2026 by DriffOcetor

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

26.519.81530

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

I am using the Codex Windows desktop app. After closing and reopening Codex, the conversation history inside threads is displayed out of order in the right-hand conversation pane.

This is not limited to one project or one thread. It affects all projects and all conversations I have checked. It also happens with newly created test threads: after I create a new thread, let Codex finish, close Codex, and reopen it, the same thread is displayed in a scrambled order.

I discovered the issue because my normal workflow uses strict numbered interactions, such as “Subtask 1”, “Subtask 2”, “Subtask 3”, etc. After reopening Codex, the visible order may become something like “Subtask 2”, then “Subtask 1”, then “Subtask 6”, which makes it clear that the global display order is incorrect.

Important observations:

1.Each individual user message still appears paired with its immediate Codex response. The local user-message / assistant-response pair is usually still correct.
2.However, the global order of these message pairs is wrong after reopening the app.
3.The visible timestamp shown on each message appears to be correct.
4.When I ask Codex inside the affected thread to summarize or reconstruct the conversation according to the actual context order, Codex produces the correct order. Codex also says it cannot read the UI timestamps, which suggests that the underlying context order provided to the model is correct.
5.Therefore, this appears to be a Windows App UI rendering / thread hydration / history display ordering issue, rather than the underlying conversation data being actually corrupted.

Scope:

Existing projects are affected.
Existing threads are affected.
Multiple unrelated projects are affected.
Newly created test threads are also affected.
Simple non-code tasks with no file modifications are also affected.

What steps can reproduce the bug?

1.Open the Codex Windows desktop app.
2.Create a new simple thread, preferably one that does not modify any files.
3.For example, “Recommend tourist attractions in G7 countries one by one in alphabetical order.” And ask Codex one by one in alphabet order till all 7 countries are finished.
4.Close Codex completely.
5.Reopen Codex.
6.Open the same newly created thread.
7.Observe that the right-hand conversation pane displays the message pairs in a scrambled or non-chronological order.

This also occurs in my existing project threads. In those threads, I number every interaction as “Subtask 1”, “Subtask 2”, “Subtask 3”, etc., and after reopening Codex the numbered message pairs are visibly out of order.

I have submitted an in-app /feedback report and received this feedback/session code:

019ed9a8-d411-7222-bc52-00a05b2b6e17

What is the expected behavior?

After reopening Codex, each thread should display messages in the same chronological order as when they were originally generated.

The right-hand conversation pane should preserve the correct global order of user-message / assistant-response pairs. For numbered workflows, “Subtask 1” should appear before “Subtask 2”, “Subtask 2” before “Subtask 3”, and so on.

Additional information

This seems to be a client-side display or hydration issue in the Windows App. The underlying conversation/context order appears to remain correct, because Codex can reconstruct the correct order when asked from inside the affected thread, even though the visible UI order is scrambled.

The visible timestamps on individual messages also appear correct, but the rendered order of message blocks is incorrect after reopening the app.

I can provide screenshots or a screen recording showing numbered subtasks displayed out of order after reopening Codex. I can also provide the /feedback session code if needed.

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗