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

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

• #25709
• #26157
• #26990
• #26502

Powered by Codex Action

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.

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.

Additional update after another crash:

After another Codex Desktop crash, all projects and all new chats that I created only yesterday disappeared from the UI.

This is not only about old archived sessions or old local history. These were fresh projects and fresh chats created yesterday in the current Codex Desktop app. I had around 8 projects visible in Codex, and after the crash they disappeared from the sidebar / project list together with their newly created chats.

Current behavior:

• I open Codex Desktop.
• The app crashes after 6 hours of work
• After reopening, the projects and chats created yesterday are no longer visible. (double check - status: log-ined, i can see usage)

• The sidebar shows no chats / missing projects.
• This happened after the latest Codex Desktop update.
• This happens even after previous cleanup attempts and with active sessions / archived sessions already emptied or moved out for recovery.

This makes Codex Desktop unsafe for production work because even newly created projects and chats can disappear after a crash. The app currently cannot be trusted as a working memory or project workspace.

This looks like a serious issue in:

• project list persistence,
• sidebar state,
• session indexing,
• crash recovery,
• local state rehydration,
• and/or Windows Desktop app state after crash.

Expected behavior:

• New projects and chats created yesterday should remain visible after a crash or restart.
• A crash should not make new projects disappear from the UI.
• If the app cannot load some state, it should show a recovery / rebuild index option instead of hiding projects and chats.
• The app should provide a safe way to restore project/sidebar state after a crash.

Impact:
This is now causing active work loss, not just inconvenience. I lost visibility of newly created projects and chats from yesterday after another crash. I need a recovery procedure, hotfix, or rollback path urgently.

<img width="2877" height="1677" alt="Image" src="https://github.com/user-attachments/assets/51721681-dac8-40ce-a396-75abbe68d6cf" />

Codex still shows three recent chats and projects when I right-click the app icon, but inside the Codex app itself it shows zero chats and zero projects.

Why is this happening to your users?

From a user perspective, it honestly feels like the product experience is pushing us away from Codex and forcing us to migrate to Claude.

<img width="2879" height="1704" alt="Image" src="https://github.com/user-attachments/assets/b9a718ba-3eb0-447e-a56e-6b3ac1f89f28" />

Codex Desktop often becomes unresponsive after a task has already completed. The freeze usually lasts 5-7 minutes, and sometimes up to 15 minutes. This does not look like model latency, because the task is already finished. It feels more like a post-run cleanup, state sync, history rendering, environment refresh, or UI thread blocking issue. During that period I cannot reliably type, switch threads, open menus, or continue working. This is happening on Windows with Codex Desktop and makes the app hard to use for production work.

Icon becomes unresponsive , you can not open the app and have to wait , currently is already longer than 5 min (20 tasks x 10 min = 200 min waiting only between tasks)

<img width="298" height="187" alt="Image" src="https://github.com/user-attachments/assets/047f240d-c44c-48de-877a-13ff6e4bde8f" />

Codex Desktop has a queueing control bug. When I click “Turn off queueing”, the UI changes correctly and the menu then shows “Turn on queueing”, so the app appears to know that queueing is disabled. However, the internal queue still continues to run. If I have many queued tasks and stop the current one, Codex immediately starts the next queued task instead of pausing the queue. This makes the session uncontrollable: I cannot stop the chain, the previous task may remain unfinished, and I have to manually delete queued messages one by one or restart the app. Expected behavior: “Turn off queueing” should immediately stop Codex from consuming queued follow-up messages, and stopping the current task should not automatically launch the next queued task.

upd: as i understood this button do not hold the que its just allow new messages comes with a priority . Please allow me to hold the que , espeicaly when i have big ques , some times i need to change processing logic and i can not do this until que done which can take a weeek., currently one small task can take 2-5 hours

Summary

I am repeatedly seeing Codex tasks disconnect during long-running project work with:

stream disconnected before completion: websocket closed by server before response.completed

The UI then shows reconnect attempts such as Reconnecting 3/5, and the task may continue partially, but the final state is often unclear.

This is especially painful for Codex projects that edit multiple files, because after the disconnect I cannot easily tell whether the task:

• completed fully,
• partially wrote files,
• failed before writing the final report,
• or continued on the backend while the UI stream was disconnected.

Environment

• OS: Windows 11
• Codex: Desktop/Web Codex inside ChatGPT
• Model: GPT-5.5 / Extra High
• Speed mode: Fast
• Network: please see notes below
• Project type: large local Codex project with many Markdown/JSON files and long-running tasks

Error observed

stream disconnected before completion: websocket closed by server before response.completed

Example UI state:

• Reconnecting /5
• stream disconnected before completion
• websocket closed by server before response.completed
• task sometimes remains in "Thinking"

What I was doing

I was installing / updating a small process-only project rule, not running a large rebuild.

Expected scope:

• create one policy file,
• create one lock JSON file,
• update one README pointer,
• write an install report,
• stop.

Actual behavior:

• task ran for 15–60 minutes,
• WebSocket disconnected before response.completed,
• after reconnect / context compaction, Codex re-read project files and sometimes continued from a partially reconstructed state,
• final project state required additional recovery/status prompts.

Expected behavior

Codex should either:

1. keep the stream alive until response.completed, or
2. automatically fall back to a more stable HTTPS/SSE transport when WebSocket fails, or
3. clearly mark the backend task state as:

• completed,
• failed,
• still running,
• partially applied,
• unknown.

For long-running file-editing tasks, Codex should always produce a durable final status artifact before the UI loses the stream.

Actual behavior

The UI stream disconnects before response.completed, and the task state becomes ambiguous.

In project workflows this is dangerous because files may be partially created or edited, but the UI does not always show a reliable final report.

Why this matters

For small one-file or chat-only tasks this is annoying.

For Codex project work it is much more serious:

• partial file writes are possible,
• recovery prompts are required,
• task time increases dramatically,
• user cannot trust whether the project state is clean,
• repeated reconnects consume usage while not always producing a clear result.

Suggested improvements

1. Add a user-facing network/transport setting:

• transport = websocket
• transport = https
• transport = auto

1. If WebSocket fails once in a session, cache that failure and use HTTPS/SSE fallback for the rest of the task/session.

1. Show a clear task-state indicator after reconnect:

• backend still running,
• backend completed,
• backend failed,
• UI stream only failed.

1. Provide a "write status report and stop" recovery button for file-editing tasks.

1. Avoid restarting broad project inspection after stream reconnect / context compaction if the task was already in the final reporting stage.

1. Add clearer diagnostics:

• WebSocket connection failed,
• server closed before response.completed,
• proxy/firewall likely,
• backend task still alive,
• backend task lost.

Network note

OpenAI documentation says Codex uses secure WebSocket traffic to:

wss://chatgpt.com/Codex

over TCP port 443, and that proxy/firewall/security filters must allow the standard Upgrade: websocket handshake.

However, even if the root cause is local network/proxy instability, Codex should fail more safely for long-running file-editing tasks.

Codex gets stuck in a pre-write context compaction loop on large projects, repeatedly re-reading instructions and never reaching file edits

Hi Codex team,

I want to share product feedback from a real long-running Codex project. This is not about model quality. The model often reasons correctly. The problem is task execution reliability and state management in large projects with many project instruction files.

Issue summary:
Codex can get stuck for hours before making any file changes. In my case, a simple single-game data processing task ran for 2–4+ hours, but no files were edited. The task repeatedly entered the same loop:

1. Read project hot files / rules.
2. Read lock / registry / state files.
3. Context automatically compacted.
4. Reconnect / stream interruption happens.
5. Codex resumes and re-reads the same files again.
6. It never reaches the actual write/action phase.

Example repeated pattern:

• “Continuing with one case…”
• “First I will check lock and current versions…”
• “Reading START_HERE / PROJECT_STATE / ACTIVE_TASK / CANONICAL_PATHS…”
• context compaction
• same sequence repeats again

Observed error:
stream disconnected before completion: websocket closed by server before response.completed

Why this matters:
For project/file-editing tasks, this is dangerous because the UI may show the task as working for hours, but the backend never reaches a durable write phase. The user cannot tell whether:

• the task is still valid,
• it is stuck in preflight,
• files were partially written,
• or the task should be stopped.

This becomes especially painful in projects with many instruction files, ledgers, registries, and safety rules. Codex appears to treat every reconnect/context compaction as a reason to re-run the full preflight, instead of resuming from a durable phase marker.

Expected behavior:
Codex should detect this loop and stop safely.

Suggested improvements:

1. Add automatic pre-write loop detection.

If Codex reads the same instruction/state files multiple times without file edits or new useful output, it should stop and write a short status report.

1. Add explicit task phase tracking.

For example:

• preflight_started
• preflight_done
• write_started
• validation_started
• final_report_started
• completed

After context compaction or reconnect, Codex should resume from the last durable phase instead of restarting preflight.

1. Add a “write status report and stop” recovery action.

This would be very useful when the UI stream disconnects but the project state is unclear.

1. Add a hard time/no-progress guard.

Example:
If no files were edited after 10–15 minutes in a file-editing task, Codex should ask whether to continue or stop with a report.

1. Improve WebSocket disconnect handling.

When websocket closed before response.completed happens, the UI should clearly show:

• backend still running,
• backend completed,
• backend failed,
• stream only failed,
• project state unknown.

1. Support lightweight fast-path modes.

For small repeatable workflows, users need a way to tell Codex:

• do not re-read all policies,
• read only these exact files,
• do not run broad search,
• stop if exact paths are missing.

Current workaround:
I had to redesign my workflow around lightweight “analysis packets” instead of asking Codex to fully integrate every data point, because full integration often triggers long preflight loops.

Impact:
This makes Codex much less reliable for large project workflows, even on higher reasoning / faster settings. The issue is not just speed. It is that the agent can spend hours preparing to work without reaching the actual work.

Thank you. I hope this helps improve Codex’s long-running project reliability.

Currently I'm suing Codex Desktop 26.608.12217 repeatedly stops loading project chat history
I’m using Codex Desktop on Windows, version 26.608.12217, released Jun 9, 2026.

This is the third time in the last five days in the 3 different Codex versions that chat history inside projects has disappeared or stopped loading. Sometimes the whole UI loses both projects and chats. Sometimes the projects are still visible, but the chat history inside them does not load. Today the histories were loading earlier, but then they suddenly stopped loading again; I waited more than 5 minutes and nothing appeared.

I did not delete, archive, or reset these chats manually.

Please add a safe re-index / recovery mechanism and make the app clearly show whether histories are loading, failed to load, or missing from the local database.

This is becoming a serious reliability issue because active work can become inaccessible without warning.

<img width="661" height="554" alt="Image" src="https://github.com/user-attachments/assets/a87f50ed-8907-4f1f-9186-f13a4931e390" />

New Update do not fix disappeared chats and sessions , unfortunately

Version 26.609.30741 • Released Jun 11, 2026

<img width="1747" height="945" alt="Image" src="https://github.com/user-attachments/assets/9485a9f4-6d29-4986-832c-2d9a4e71be54" />

Codex Desktop on Windows, version 26.608.12217, - fixed RAM consumption, 32gb was always 50-60%
New Version 26.609.30741 • Released Jun 11, 2026 - get back bug with ram and crashes that was before 26.608.12217, litteraly we get back to all old bugs and you did not fixed new one...

How to skip updates? or how to roll out to 26.608.12217 ?
<img width="291" height="158" alt="Image" src="https://github.com/user-attachments/assets/ec75ab1c-f076-492b-837a-4b14dcea36b6" />

Codex Desktop 26.609.30741 auto-installed today and caused severe performance regression on Windows.

After the update:

• UI became extremely laggy
• memory usage became very high
• the machine heats up
• everything feels slow even before doing heavy work
• previous version already had project history loading issues, and now the new build added severe performance/memory problems

This looks like a regression in local history indexing/rendering or background app-server work after update. Please investigate memory/CPU usage after startup and when opening project threads.

Title: Windows Codex Desktop: project chat histories disappear, local state still exists, then 26.609 causes severe performance/memory regression

Environment:

• Platform: Windows Codex Desktop
• Version where chats disappeared : 26.608.12217, released Jun 9, 2026 (and previous one)
• Auto-updated version installed today: 26.609.30741, released Jun 11, 2026
• CLI version installed separately: codex-cli 0.139.0
• Codex home checked: %USERPROFILE%.codex
• CODEX_HOME: not set
• CODEX_SQLITE_HOME: not set

Summary:
Over the last 5 days, this is the third time Codex Desktop has lost or stopped loading chat history inside projects. Sometimes both projects and chats disappear from the UI. Sometimes projects remain visible, but the history inside them does not load and shows as empty / “No chats”. I did not manually delete, reset, remove, or archive these chats.

After the automatic update to 26.609.30741, the situation became worse: the app became extremely slow, memory usage became very high, the UI started lagging, and the laptop started heating significantly. This looks like a combination of project history indexing failure and severe local state / log / transcript performance regression.

Observed behavior:

1. Project chat histories disappeared or stopped loading inside Codex Desktop.
2. This happened repeatedly: 3 times in the last 5 days.
3. In some cases, entire projects/chats disappeared from the UI.
4. In other cases, projects remained visible but the histories inside them did not load.
5. Waiting several minutes did not restore the histories.
6. After 26.609.30741 auto-installed, Codex became extremely laggy and memory-heavy.
7. The machine heats up while Codex is open.
8. The issue seems to happen even before doing heavy new work, suggesting startup/indexing/rendering/background app-server work may be involved.

Expected behavior:

• Existing project histories should remain visible after app restart or update.
• If local thread/index state is inconsistent, Codex should show a clear recovery state instead of showing empty projects.
• Codex should provide a safe “Repair / Re-index local histories” mechanism.
• Codex should not block the UI or consume excessive memory while indexing or loading local sessions.
• App updates should not make project histories disappear from the sidebar.

Local diagnostics:
I created a backup of %USERPROFILE%.codex before making changes.

Backup details:

• Backup size: 28.5 GB
• Files: 6,022
• Folders: 2,887

Key files found:

• %USERPROFILE%.codex\state_5.sqlite

• Size: 356,352 bytes
• LastWriteTime: Jun 11, 2026 7:56:06 PM
• %USERPROFILE%.codex\session_index.jsonl

• Exists: true
• Lines: 56
• Size: 7,612 bytes
• LastWriteTime: Jun 9, 2026 2:27:05 PM
• %USERPROFILE%.codex.codex-global-state.json

• Size: 43,614,122 bytes
• LastWriteTime: Jun 12, 2026 1:03:26 AM
• %USERPROFILE%.codex\logs_2.sqlite

• Size: 875,155,456 bytes
• LastWriteTime: Jun 12, 2026 12:58:54 AM

Session files:

• sessions jsonl: 3
• archived_sessions jsonl: 0
• total jsonl: 3
• ALL jsonl files under .codex: 6

The sessions folder is very large:

• %USERPROFILE%.codex\sessions

• Size: 26.54 GB
• Files: 3

Rollout files found:

• rollout-2026-06-08T23-29-25-019ea923-f0d4-7af0-bb96-2a041cff17e5.jsonl
• rollout-2026-06-08T23-37-07-019ea92a-fc7d-7483-9a5f-c2eedcfc65d8.jsonl
• rollout-2026-06-09T14-25-14-019eac58-151b-7102-94a4-c3a6f838b028.jsonl

Search test:
I searched for a known unique phrase from a missing project/history: “Runtime v11.9”.

The phrase was found in:

• multiple attachments/pasted-text.txt files
• all three rollout JSONL files
• session_index.jsonl

This suggests at least part of the missing project data still exists locally, but Codex Desktop is not surfacing it correctly in the UI.

Potential root-cause areas to investigate:

1. Project/sidebar history index drift:

• session_index.jsonl has 56 lines, but only 3 rollout JSONL session files are visible under sessions.
• The UI may be relying on stale/incomplete project-thread mapping.
• Please verify consistency between state_5.sqlite, session_index.jsonl, .codex-global-state.json, and sessions/*.jsonl.

1. Windows path normalization:

• Please check whether project/thread matching treats normal Windows paths and extended paths differently, for example:

• C:\Users...
• \?\C:\Users...
• A mismatch here could explain why project histories exist locally but show as empty in the sidebar.

1. Very large local session files:

• The sessions folder is 26.54 GB but contains only 3 files.
• Codex may be doing eager scanning, parsing, rendering, or indexing of very large rollout JSONL files.
• This may explain the severe UI lag, memory usage, and heating after 26.609.30741.

1. logs_2.sqlite performance:

• logs_2.sqlite is already 875 MB.
• Please check whether logging / SQLite writes / WAL checkpointing are blocking app-server or renderer responsiveness.

1. Crash-safe state writes:

• If Codex is restarted, updated, or force-closed while state is being written, it may leave session_index.jsonl or .codex-global-state.json stale while state_5.sqlite and rollout files still contain recoverable data.
• Please make these writes atomic and add validation/rebuild on startup.

Suggested product-side fixes:

1. Add a supported “Repair / Re-index local histories” button.
2. On startup, compare active/unarchived threads in state_5.sqlite with session_index.jsonl and sessions/*.jsonl.
3. If mismatch is detected, rebuild the index instead of showing “No chats”.
4. Normalize Windows project paths consistently before matching threads to projects.
5. Do not block the renderer while scanning large local histories.
6. Limit or rotate logs_2.sqlite / WAL growth.
7. Show a clear recovery warning if local history exists but cannot be indexed.
8. Provide a safe export/viewer for local rollout JSONL histories when the Desktop UI cannot load them.

Impact:
This is a serious reliability issue. Active project work becomes inaccessible without warning. The current app state also causes severe performance degradation, high memory usage, lag, and device heating after the 26.609.30741 update.

• PowerShell diagnostics showing session_index lines, JSONL counts, key file sizes, and folder size
• Backup folder properties

I don't know how is that possible that every next update is worse than previous , but

Name: OpenAI.Codex
Version: 26.609.4994.0
PackageFullName: OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
--------
app no longer open, i even can not open codex app