Repository navigation
[Windows][Codex][ChatGPT][Desktop][26.928.21956] Severe UI freeze, rendering corruption, and high CPU/GPU usage when opening older Codex chats after update #49591
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Version: 26.928.21956 Release date: 2026/09/30 Distribution: Microsoft Store desktop version
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Windows 11 Pro 25H2 OS Build: 26200.9445 CPU: AMD Ryzen 7 5800X RAM: 64 GB GPU: NVIDIA GeForce RTX 5060 Ti 16 GB NVIDIA Driver: 617.14 x64
What issue are you seeing?
After updating the Microsoft Store version of the ChatGPT/Codex desktop application to version 26.928.21956, released on September 30, 2026, the application has become extremely unstable.
The most serious problem occurs when opening existing/older Codex conversations, especially conversations associated with previous projects.
When I open one of these chats:
- The Codex UI may become visually corrupted or partially fail to render.
- The entire application becomes unresponsive.
- Mouse clicks and keyboard input stop responding inside the app.
- CPU and/or GPU usage increases significantly while the application is frozen.
- The freeze can persist long enough that I have to terminate or restart the application.
- Some older project conversations are effectively impossible to open or continue working on.
This appears to be a regression introduced by the 26.928.21956 update.
These same conversations/projects were usable before the update.
The problem is particularly serious because I have ongoing development work stored in previous Codex project conversations, and I currently cannot reliably access or continue those projects.
This is not simply slow model response or network latency. The local desktop UI itself freezes and becomes unresponsive, while local CPU/GPU usage rises.
I have also previously encountered an application error mentioning:
Application Error: routeId checkout
What steps can reproduce the bug?
- Launch ChatGPT/Codex desktop version
26.928.21956on Windows. - Open Codex.
- Open the conversation/history list.
- Select an older Codex conversation, particularly one containing a long-running development project or substantial conversation history.
- Wait for the conversation to load.
- The UI may begin rendering incorrectly and then become unresponsive.
- CPU and/or GPU usage increases significantly.
- In severe cases, the app must be forcibly closed and restarted.
- Reopening the same historical conversation can reproduce the issue.
The issue appears much more frequently when opening existing/older conversations than when starting a new empty conversation.
What is the expected behavior?
Existing Codex conversations should open normally without freezing the desktop application.
Loading a long conversation or project history should not:
- block or freeze the entire UI,
- cause rendering corruption,
- cause sustained abnormal CPU/GPU usage,
- make the application stop responding,
- or prevent users from accessing existing projects.
Historical Codex project conversations are important working data and should remain accessible after a desktop application update.
Impact
This is currently blocking access to some of my previous Codex development projects.
Because the affected conversations contain ongoing project context and development history, creating a new conversation is not an adequate workaround.
The issue therefore significantly disrupts normal use of Codex for ongoing development work.
A[dditional information]
The problem became apparent after updating to:
- Version:
26.928.21956 - Release date:
2026/09/30
Feedback / Report ID:
no-active-thread-01a0f1fe-a703-7da1-b0fe-522a06bb23fe
The symptoms appear related to Windows desktop conversation-history rendering/loading and resource usage.
Please investigate this as a regression in version 26.928.21956, particularly the handling of older or large Codex conversation histories.
Access to existing project conversations is currently unreliable, and in some cases the application freezes before the project can be used at all.
What steps can reproduce the bug?
Feedback ID: no-active-thread-01a0f1fe-a703-7da1-b0fe-522a06bb23fe
What is the expected behavior?
No response
Activity
github-actions commentedon Sep 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
hisui007 commentedon Sep 30, 2026
Thanks for identifying the potentially related issues.
This may be related to #48665 and #48938, but I am currently reproducing the problem on the newer
26.928.21956build released on September 30, 2026.In my case, the issue is especially reproducible when opening older Codex conversations / existing project threads. Some previous project conversations become effectively inaccessible because opening them causes the UI to freeze and CPU/GPU usage to increase.
So I am keeping this issue open for now because it may indicate that the regression reported in the earlier
26.924.2738.0build is still present in26.928.21956, with older/session-heavy conversations being a particularly strong trigger.[-][Windows][Desktop][26.928.21956] Severe UI freeze, rendering corruption, and high CPU/GPU usage when opening older Codex chats after update[/-][+][Windows][Codex][ChatGPT][Desktop][26.928.21956] Severe UI freeze, rendering corruption, and high CPU/GPU usage when opening older Codex chats after update[/+]hisui007 commentedon Sep 30, 2026
Additional information:
Restarting the ChatGPT/Codex desktop application does not resolve the issue.
After completely closing and reopening the app, opening the affected older Codex conversations still causes the same behavior:
So this does not appear to be a temporary renderer state that is cleared by restarting the application.
The issue is consistently reproducible on version
26.928.21956.hisui007 commentedon Sep 30, 2026
Additional potentially related symptom:
I also checked Codex in the browser, and my Codex conversation history is missing there as well.
However, the conversations are still visible from the regular ChatGPT interface.
So the conversation data itself does not appear to be completely lost. This may instead be an issue with Codex-specific session/history indexing, synchronization, or thread projection.
Current behavior:
This makes me concerned that the Codex session index or synchronization layer may have become inconsistent after the
26.928.21956update, rather than this being only a renderer/performance issue.hisui007 commentedon Sep 30, 2026
Additional read-only forensic findings:
I backed up
%USERPROFILE%\.codexand inspected the local Codex databases without modifying them.All SQLite databases pass
PRAGMA integrity_check:goals_1.sqlite: OKlogs_2.sqlite: OKmemories_1.sqlite: OKqueue_1.sqlite: OKstate_5.sqlite: OKthread_history_1.sqlite: OKLocal session/history data is still present:
rollout-*.jsonlfiles: 149state_5.sqlite -> threads: 149thread_history_projection_state: 149thread_items: 3283thread_turns: 322However, the project registry in
state_5.sqliteis empty:projects: 0project_roots: 0project_idempotency_keys: 0This suggests that the underlying conversation/session data has not been deleted, but the Codex project registry and/or project-to-thread assignment state may have been lost or failed to migrate after the update.
This also matches the user-visible behavior:
At this point this looks more like a project/session indexing or migration regression than SQLite database corruption.
hisui007 commentedon Sep 30, 2026
I found additional evidence that this may be a stuck/incomplete project-to-thread migration rather than database corruption.
All SQLite databases still pass
PRAGMA integrity_check, and all 149 local rollout/session files and 149 thread records are still present.However,
.codex-global-state.jsoncurrently reports:projectsMigrated: truebut:
threadAssignmentsMigrated: falseThere are also exactly 33
pendingThreadAssignmentIds.At the same time:
projectless-thread-ids: 33 entriesthread-workspace-root-hints: 33 entriesthread-projectless-output-directories: 33 entrieslocal-projects: 0 entriesIn
state_5.sqlite, all 149 thread rows currently haveproject_id = NULL.There is also a Windows path representation mismatch:
The workspace-root hints use:
C:\Users\xxxx\Documents\Codexwhile the affected
threads.cwdrecords use the extended Windows path form:\\?\C:\Users\xxxx\Documents\Codex\...The directories themselves exist and
Test-Pathsucceeds.This looks consistent with an incomplete thread-assignment migration and/or Windows path canonicalization issue. The conversation/session data itself still appears intact, but Codex is not successfully rebuilding or assigning the existing threads to their projects.
The migration state remaining at
threadAssignmentsMigrated: falsewith 33 pending thread IDs after restarting the app may also explain why older threads trigger UI freezes and high CPU/GPU usage when opened.hisui007 commentedon Sep 30, 2026
Further investigation found an internal inconsistency in the migration state.
The same exact 33 thread IDs appear in all four migration-related sets:
pendingThreadAssignmentIds: 33projectless-thread-ids: 33thread-workspace-root-hints: 33thread-projectless-output-directories: 33All four sets are exactly equal.
However, only 28 of those 33 thread IDs exist in
state_5.sqlite -> threads.The 28 matching rows all currently have
project_id = NULL.So there are currently 5 thread IDs still marked as pending for project/thread assignment that do not have corresponding rows in the current
threadstable.At the same time:
projectsMigrated = truethreadAssignmentsMigrated = falseThis looks like the thread-assignment migration state may be stuck or internally inconsistent.
I am now checking whether the remaining 5 pending thread IDs still have their corresponding session JSONL files.
hisui007 commentedon Sep 30, 2026
Additional diagnostic result:
I removed only the 5 stale migration thread references that existed in pendingThreadAssignmentIds but had no corresponding threads database row and no session JSONL file.
This reduced the migration-related sets from 33 to 28, while leaving all actual thread/session data untouched.
The problem still reproduces.
When opening an affected older Codex conversation, the conversation initially becomes visible, but the desktop UI renders incorrectly: only part of the maximized window is painted while a large portion of the right and bottom area remains blank/unrendered. The application then becomes unresponsive.
Therefore, the 5 stale migration references do not appear to be the primary cause.
The screenshot shows the renderer/UI corruption immediately before/while the application is frozen.
hisui007 commentedon Sep 30, 2026
Additional diagnostics:
The issue still reproduces with the same UI corruption and freeze.
I also tested removing/rebuilding the local plugin cache, but this did not change the behavior.
During the freeze, the local Codex logs show bursts of repeated
thread/attachment/listrequests with different request IDs, repeatedthread/listrequests, and repeated plugin manifest/config loading warnings within only a few seconds.In the captured 5-minute window:
I also performed a controlled test where I removed only 5 stale thread IDs that were present in the migration state but had no corresponding
threadsdatabase row and no session JSONL file.That reduced the migration-related sets from 33 to 28, while leaving all actual conversation/session data untouched.
However, the same UI rendering corruption and freeze still reproduced, so those 5 stale migration references do not appear to be the primary cause.
The affected app process remains alive while the UI stops rendering/responding. I did not observe an obvious crash entry during the captured period.
The repeated attachment-list / thread-list activity and repeated plugin/config loading may be related to the freeze, but I cannot confirm causality yet.
I have a screenshot showing the partially rendered maximized window during the freeze and can provide the extracted Codex log for the affected time window if useful.
hisui007 commentedon Oct 1, 2026
Update after installing the latest Microsoft Store build:
OpenAI.Codex 26.928.3736.0
After updating from 26.928.21956 and restarting Windows, the failure mode changed.
Previously, the app launched, but opening older Codex conversations caused severe UI rendering corruption, high resource usage, and freezing.
With 26.928.3736.0, the app now fails earlier during startup with:
“Unable to load organization settings”
The dialog says the app is paused until organization settings can be loaded safely, and offers Retry / Sign out / Exit.
This appeared immediately after the update and reboot.
So the original issue is not resolved in this build; instead, the desktop app is now blocked during organization-settings initialization.
hisui007 commentedon Oct 1, 2026
Tested again after updating to OpenAI.Codex 26.928.3736.0.
The original issue is still reproducible.
Older Codex conversations still cause the same UI rendering corruption and application freeze as in 26.928.21956.
So this build does not resolve the issue reported here.
I also briefly encountered an “Unable to load organization settings” startup dialog after the update/reboot, but after getting past that, the original freeze/rendering issue still remains.
hisui007 commentedon Oct 1, 2026
I am still experiencing this issue as of October 1, 2026.
Environment:
When I create a new Codex chat and send the first message, it immediately fails with:
Unable to determine project root for task
Refreshing the page and trying again does not resolve the issue.
I am also currently affected by a separate Codex Desktop issue where opening older conversations causes UI corruption and freezing, so at the moment both Codex Desktop and Codex Web are effectively unusable for me.
I can provide the screenshot if needed.
hisui007 commentedon Oct 2, 2026
Update: The issue is still reproducible on Codex Desktop 26.930.21537, released 2026-10-02.
I also tried Windows App Repair, but the behavior is unchanged.
Opening older Codex conversations still causes the same rendering corruption and UI freeze.
Therefore, the issue persists across: