Codex Desktop Windows 26.602.71036 crashes / becomes inaccessible after update even with empty sessions

[SocialK]

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

26.602.71036, Released Jun 8, 2026

What subscription do you have?

ChatGPT Pro, $200/month

What platform is your computer?

Windows 11 x64, Version 10.0.26200.8524 Device: ASUS Zenbook 14 OLED UX3405MA CPU: Intel Core Ultra 9 185H (32gb ram)

What issue are you seeing?

Title: Codex Desktop Windows 26.602.71036 crashes, loses queued tasks, and becomes inaccessible after update

I am reporting a production-blocking regression in Codex Desktop for Windows.

Environment:

• OS: Windows 11
• Device: ASUS Zenbook 14 OLED UX3405MA , intel arc (latest available drivers)
• CPU: Intel Core Ultra 9 185H (32gb ram)
• Codex Desktop version: 26.602.71036
• Codex CLI version: 0.138.0
• Subscription: ChatGPT Pro, $200/month

Summary:
After the latest Codex Desktop update, the Windows desktop app became significantly worse and is no longer usable for production work.

Before the update, Codex Desktop could freeze or become unresponsive, but after closing and reopening it, my chats, project history, and queued work were still recoverable.

After the update, Codex Desktop crashes, closes, hangs, or becomes inaccessible. In some cases I cannot even enter the app. If I open Codex, switch to another window, and then return to Codex, I can no longer access the app. The app either hangs, becomes unusable, or crashes.

Critical data-loss issue:
Because the Desktop app refused to work, I had to clear / move active session folders to recover the app state. As a result, more than 50 queued tasks were lost. This is a serious workflow failure: queued work should not be stored only inside fragile session state that users may need to clear during recovery.

Important reproduction detail:
The crash / inaccessible state happens even when:

• .codex\sessions is empty
• .codex\archived_sessions is empty

Therefore, this does not look like only a large local session-history issue. The issue appears to be in the Windows Desktop app, app state, Microsoft Store build, sidebar state, crash recovery, queue handling, or Windows sandbox / process layer.

What changed:

• Before the latest update: Codex could hang, but chats, project history, and queued tasks were recoverable after closing/reopening.
• After the latest update: Codex crashes / becomes inaccessible, project chats disappear from the UI, and queued tasks can be lost.
• The app behavior became worse after the update, not better.

Observed behavior:

• Codex Desktop crashes or closes.
• Codex Desktop becomes inaccessible after switching to another app/window and returning.
• Project chats disappear from the sidebar / UI.
• Queued tasks are not safely preserved when sessions must be cleared or moved.
• The issue persists even when active .codex\sessions and .codex\archived_sessions are empty.
• Codex CLI 0.138.0 is installed and works, but Codex Desktop remains broken.
• Codex itself reported a Windows sandbox process issue during work: “First parallel search partially failed due to a Windows sandbox process issue…”
• Codex then attempted to continue using small sequential commands instead of parallel inventory, which suggests the Windows sandbox / process layer is unstable.

Queue-specific problem:
When the Desktop app crashes and restarts repeatedly, queued tasks should not continue to auto-start. Right now, the user can end up in a broken state where dozens of queued tasks keep stacking up, remain incomplete, and new failed tasks continue to pile on top of old failed tasks.

Requested queue behavior:

1. Queued tasks should be stored in a separate durable queue store, not only inside session files.
2. Clearing or moving .codex\sessions should not delete queued tasks.
3. Queued tasks should survive Desktop crashes, app resets, and session recovery operations.
4. If Codex Desktop crashes, the queue should be automatically paused.
5. After a crash, queued tasks should only continue after explicit manual user approval.
6. The app should detect crash loops and disable auto-resume / auto-run of queued tasks until the user manually confirms.
7. The queue should deduplicate tasks by stable task IDs so repeated restarts do not create duplicate queued work.
8. The UI should show a clear queue manager with Pending / Running / Failed / Paused / Cancelled states.
9. Users should be able to export, import, pause, resume, and clear queued tasks independently from chat/session history.
10. Failed queued tasks should not silently restart forever after a crash.

Expected behavior:

• Codex Desktop should open normally.
• Empty .codex\sessions and .codex\archived_sessions should never cause a crash.
• Switching away from Codex and back should not make the app inaccessible.
• Project chats should not disappear after an update or crash.
• Queued tasks should not be lost when session folders are cleared for recovery.
• A crash should automatically pause the queue.
• Queued tasks should resume only after manual user approval following a crash.
• The app should provide a safe recovery path for local app state, sidebar state, queue state, and session index.

Actual behavior:

• Codex Desktop crashes or becomes inaccessible.
• Project chats disappear from the UI.
• More than 50 queued tasks were lost after I had to clear / move sessions to recover from the broken Desktop state.
• Queue state appears too tightly coupled to fragile session state.
• Repeated crashes can cause unfinished queued tasks to remain stuck while new failed tasks continue stacking on top.
• The issue persists even after clearing active sessions and archived sessions.
• The latest update made the problem worse, not better.

Troubleshooting already attempted:

• Cleared / moved active .codex\sessions.
• Cleared / moved .codex\archived_sessions.
• Verified that active sessions are empty.
• Verified that archived sessions are empty.
• Rebooted Windows.
• Installed / verified Codex CLI 0.138.0.
• The Desktop app still crashes / hangs / becomes inaccessible.

Evidence from Codex output:
During the recovery/inventory process, Codex itself displayed the following diagnostic message:

“First parallel search partially failed due to a Windows sandbox process issue, but three key files were read successfully. I am repeating the inventory with small sequential commands to avoid creating another hanging layer.”

This message was shown inside Codex during execution, not invented by me. It suggests that the issue is not only related to project files or local sessions, but may also involve the Windows sandbox / process execution layer.

Impact:
I am paying for ChatGPT Pro / Codex access, but I currently cannot use Codex Desktop for production work. This has blocked my workflow for multiple days and caused loss of more than 50 queued tasks.

This looks like a Windows Desktop regression affecting:

• launch stability
• app state
• sidebar state
• crash recovery
• Windows sandbox / process execution
• session index handling
• queue durability
• queue crash safety
• queue auto-resume behavior

Please escalate this issue. I need:

1. a hotfix,
2. a safe recovery procedure,
3. instructions for resetting only broken app state without losing chats or queued tasks,
4. a durable queue design that is independent from session files,
5. automatic queue pause after crash,
6. manual approval before queue continuation after crash,
7. and fix big files sessions issue I had to delete 50gb of session files expecting it will solve the issue but it doesn't :( and I lost it

What steps can reproduce the bug?

its hard to say, you open the app and it becomes unresponsive instantly , or you working and it become unresponsive - its hard to guess what goes wrong

What is the expected behavior?

No response

Additional information

No response

[github-actions]

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

• Windows Desktop App - Extremely sluggish and unusable as of last update - Windows firewall related? #25709
• Codex Desktop update lost project/sidebar conversation history mapping although local sessions still exist #26157
• Windows Desktop local state is not crash-safe after power loss: pins/projects reset, config regresses, future timestamps #26990
• [Feature request] Add a “hold queued tasks” control for human-in-the-loop review #26502

Powered by Codex Action

[SocialK]

Additional observation / reproduction clue:

I do not know how to explain this, but after rebooting my computer many times, I noticed a strange pattern.

If I launch Codex Desktop and immediately start working, switching windows, opening chats, or interacting with the app, Codex often crashes, freezes, or becomes inaccessible.

However, if I reboot Windows, open Codex Desktop, and then do absolutely nothing for about 10 minutes, Codex sometimes starts working better and becomes usable for a while.

This is very hard to explain from a user perspective. It feels like Codex Desktop needs time after launch to finish some background initialization, sandbox setup, indexing, state recovery, cache hydration, or process startup work. If I interact with the app too early, it appears to crash or enter a broken state. If I wait long enough without touching it, the app sometimes stabilizes.

Possible related areas:

• delayed Desktop app initialization
• Windows sandbox process startup
• sidebar / project state hydration
• session index recovery
• background queue restoration
• app cache / local state loading
• race condition after app launch
• race condition after Windows reboot
• unsafe auto-resume or queued-task startup during initialization

Expected behavior:
Codex Desktop should either be ready to use immediately after launch, or it should clearly show a “loading / initializing / restoring state” screen and block user actions until initialization is complete.

Actual behavior:
The UI appears available, but if I start using it immediately, the app can crash, freeze, or become inaccessible. Waiting around 10 minutes after launch sometimes makes it work better.

This makes the issue very difficult to work around, because the app looks open but may not actually be ready.

[SocialK]

Feedback for Codex Windows App

One of the most frustrating issues I’m experiencing in the Codex Windows app is input lag while Codex is running a task.

For example, when Codex is already working on something and I start typing a new instruction or preparing the next message, the text appears with a 2–3 second delay. The letters do not show up immediately, and the whole typing experience feels slow and unresponsive.

I understand this may sound like a minor issue compared to crashes or failed tasks, but in daily use it is extremely unpleasant. It makes the app feel heavy, laggy, and uncomfortable to work with.

At the moment, this is probably one of the most harmless bugs, but it still seriously damages the overall user experience. If you knew how annoying this feels during real daily work, I think you would treat it as an important usability issue.