Repository navigation
Windows desktop keeps already-deleted ChatGPT conversations in Recents after full restart #39989
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.818.2872.0 (Windows package OpenAI.Codex_26.818.2872.0_x64__2p2nqsd0c76g0; app-server client 26.818.22352)
What subscription do you have?
ChatGPT subscription (exact tier not exposed in the diagnostic surface)
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Two already-deleted ChatGPT cloud conversations remain indefinitely in the Windows desktop Recents sidebar. They do not appear in ChatGPT on the web. Selecting either row shows Could not load this ChatGPT conversation.
For privacy, the exact conversation IDs were sent in a private OpenAI Support report. Redacted forms:
6a87488f-...-b8ea6a874896-...-31ee
For both, GET /backend-api/conversation/{id} and the delete action return HTTP 404 with code: conversation_deleted and can_retry: false.
What steps can reproduce the bug?
- Have a ChatGPT cloud conversation deleted on the server while its row remains in the Windows desktop Recents sidebar.
- Confirm the conversation is absent from ChatGPT on the web.
- Select the stale Windows sidebar row.
- Observe
Could not load this ChatGPT conversation. - Sign out and back in, reload the renderer, then fully end every ChatGPT process and relaunch.
- Observe that the ghost row still remains.
Troubleshooting and diagnostics already performed:
- Backed up and quarantined only the Chromium HTTP cache, then allowed it to rebuild.
- Verified all relaunched processes had new start times.
- The decoded 100-item
/backend-api/conversationsresponse contains neither target ID nor the title. - The desktop unified task inventory contains neither target ID.
- Local Storage LevelDB, Session Storage, WebStorage, other cache partitions, and local Codex databases contain no target ID or title.
- No conversations, cookies, login state, local storage, app settings, or unrelated configuration were deleted or reset.
What is the expected behavior?
When the server reports conversation_deleted and the conversation is absent from the authoritative conversation list, Windows desktop sidebar reconciliation should remove the row and keep it removed after restart.
Additional information
This appears distinct from #39161: that issue covers local Codex thread/archive teardown, while these are already-deleted ChatGPT cloud conversations with no matching local Codex task.
It is closer to #25541's Windows frontend/sidebar reconciliation family, but affects deleted ChatGPT cloud conversations rather than archived local Codex tasks.
A full private diagnostic report with exact IDs was sent through OpenAI Support. No screenshot is attached here because it contains unrelated private sidebar titles.
Activity
github-actions commentedon Aug 21, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
hqzzlys commentedon Aug 24, 2026
Still reproducible on Windows package 26.818.5229.0 (
OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0).Observed behavior:
This appears to be the same stale-sidebar /
conversation_deletedreconciliation problem described in #39897, and it is still present in a newer Windows build than the one originally reported in this issue.Expected behavior: if the conversation is already deleted server-side, the desktop client should treat that state as an idempotent delete success and remove the stale sidebar row.
chqiye commentedon Aug 24, 2026
I’m seeing the same issue on the ChatGPT desktop app for macOS. Conversations that I deleted successfully are gone from chatgpt.com, but they continue to appear as stale entries in Recents in the desktop app. The conversation content can no longer be loaded from those entries.
I’ve tried fully quitting/restarting the app, signing out and back in, and completely reinstalling the desktop app, but the deleted entries still remain. So this appears to affect macOS as well, not just Windows.
NatLego commentedon Aug 25, 2026
Confirming the same symptom on Windows with a newer build.
26.818.8289.0(installed/updated 24 Aug 2026).local_thread_catalogcontains 7 ChatGPT rows. The difference is 4 stale rows corresponding to conversations already deleted on the web.initial_build_complete = 1; its observation sequence and incremental watermark advance, butlast_full_reconciled_atremains at 24 Aug 2026 12:43:22 BST. The missing cloud conversations are therefore not pruned by later incremental syncs.The evidence points to a missing tombstone/full-reconciliation path.
shizihan-1 commentedon Aug 26, 2026
I can reproduce the same issue on Windows with a newer Codex build.
Environment:
OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0In my case, a ChatGPT Work conversation that has already been deleted server-side still remains in the Codex desktop sidebar.
Additional observations:
GET /backend-api/conversation/<conversation_id>→ HTTP 404
→
code: conversation_deleted→
can_retry: falseconversation_deleted404.Cache,Code Cache,GPUCache,Local Storage,Session Storage, andWebStoragedirectories aside so that Codex recreated them from scratch. The stale row still came back.codex.chatgpt-pinned-conversationsvalue is empty.One potentially relevant implementation detail I observed in this build:
The renderer fetches ChatGPT Work history from
/conversationswithconversation_origin=tpp. When deleting an item from the sidebar, the local query/list eviction appears to happen only after the backend delete request succeeds.For an already-deleted conversation, the backend returns terminal HTTP 404
conversation_deleted, so that success path is never reached and the stale sidebar row is not evicted.This suggests two related reconciliation issues:
conversation_deleted/ HTTP 404 is not treated as an idempotent successful deletion for purposes of removing the stale row locally.It may therefore be worth treating
conversation_deletedas a successful cleanup outcome and evicting the sidebar entry even when the server-side object is already gone.I have local logs showing the failed detail request and can provide a sanitized excerpt if useful.
mmmd3d-source commentedon Aug 26, 2026
Additional independent Windows reproduction, observed on 2026-08-26:
HTTP 404responses withcode=conversation_deletedandcan_retry=false, while the same conversations are absent from ChatGPT on the web.state_5.sqlite/threads, zero exact-title rows, and no matching entries insession_index.jsonlor the Codex global-state JSON. Consequently, the affected entries have no local Codex thread, norollout_path, and no rollout JSONL.These results further support a stale Recents index or missing deletion-tombstone reconciliation path rather than retained local Codex thread data. A safe client-side behavior would be to treat terminal
conversation_deleted/can_retry=falseas an idempotent sidebar cleanup signal.A separate Windows user reported the same symptom this week: https://www.reddit.com/r/ChatGPTPro/comments/1vyaka0/deleted_chats_still_showing_in_the_chatgpt/
sethsaler commentedon Aug 27, 2026
I can reproduce this on macOS as well.
Environment:
A ChatGPT conversation deleted successfully on the web remains visible as a stale entry in the desktop Recents sidebar. It is absent from ChatGPT Web, but selecting it in the desktop app cannot load the conversation. Fully quitting and relaunching the app does not remove the entry.
This looks consistent with the missing tombstone/reconciliation behavior described here: a server-side deleted conversation should be treated as an idempotent cleanup result and evicted from the local Recents/sidebar index.
CipEna commentedon Aug 27, 2026
Also impacting my system : no-active-thread-01a042ec-7e77-7cf3-98cf-5217ec8f1a8e
lovely-xin commentedon Aug 29, 2026
Confirming this issue is still reproducible on a newer Windows build.
Environment
26.825.4187.0x640.150.0-alpha.12.226200.91682026-08-29Observed behavior
Three server-deleted ChatGPT conversations remained visible in the desktop Recents/sidebar. Trying to remove them appeared to fail.
Within approximately three minutes, the app made 12 requests for the three deleted conversations:
DELETEPATCHGETEvery request returned:
The server therefore confirmed that the conversations were already deleted. However, the desktop app logged the responses as
sa_server_request_failed, kept the stale sidebar entries, and allowed further requests for the same deleted conversations.Expected behavior
The client should treat
conversation_deletedwithcan_retry=falseas an idempotent cleanup success:This confirms that the issue remains present in Windows version
26.825.4187.0.Conversation IDs, titles, and account information are omitted. A sanitized diagnostic report was also submitted privately to OpenAI Support.
Dreamskyz commentedon Aug 29, 2026
I can reproduce this on a newer Windows desktop build.
Environment:
Observed behavior:
Additional local-state checks:
~/.codextext indexes and sessions for two affected conversation titles: no live matches in.codex-global-state.json,session_index.jsonl, orsessions/.~/.codex(state_5.sqlite,thread_history_1.sqlite,logs_2.sqlite,goals_1.sqlite,memories_1.sqlite,queue_1.sqlite, andsqlite/codex-dev.db): no active-row matches for the affected titles.rg -acould find one title only in raw bytes ofcodex-dev.db, but SQLite queries found no matching active row, consistent with deleted/free-page residue rather than a live thread entry.%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0and%LOCALAPPDATA%\OpenAI) in both text and binary modes: no matches for the affected titles.This strongly suggests the stale Recents rows are not being rebuilt from the obvious local Codex thread stores or package cache, and are instead coming from a stale desktop conversation-history/sidebar reconciliation path.
Expected behavior:
I can provide additional sanitized diagnostics if useful.
FicaBlag commentedon Sep 2, 2026
Confirmed a reproducible workaround on Windows that may help narrow this down.
Environment:
OpenAI.Codex_26.825.4187.0_x64__2p2nqsd0c76g0Local Storagedid not fix the stale Recents entries.What did fix it:
ChatGPT.exeprocesses remain.%USERPROFILE%\.codex\sqlite\codex-dev.db->codex-dev.db.BAKcodex-dev.db-wal->codex-dev.db-wal.BAK(if present)codex-dev.db-shm->codex-dev.db-shm.BAK(if present)The app recreated
codex-dev.db, rebuilt the local catalog, and the ghost ChatGPT conversations disappeared immediately. Normal cloud ChatGPT history repopulated correctly.This strongly suggests the stale Recents entries can persist in the desktop catalog DB (consistent with the
local_thread_catalogobservations already reported in this thread), rather than only in Chromium cache/Local Storage.Caution:
codex-dev.dbalso contains other desktop-local state, so renaming/backing it up is safer than deleting it. Users who rely on local Codex state should back up.codexfirst. In my case, all important work was cloud-backed, so rebuilding the DB caused no issue.A product-side fix could likely avoid requiring DB recreation by reconciling/pruning stale
local_thread_catalogChatGPT rows when the backend returns terminalconversation_deleted/ 404, or by providing a supported "rebuild Recents/local catalog" action.CipEna commentedon Sep 2, 2026
sethsaler commentedon Sep 2, 2026
Confirmed the same recovery works on macOS.
The macOS equivalent of
%USERPROFILE%\.codex\sqlite\is:What worked for me:
For example, after the app is fully quit:
In my case only
codex-dev.dbwas present; the-waland-shmfiles were absent. After relaunch, the app created a fresh, valid database, rebuilt the local catalog, and the stale ChatGPT sidebar conversations disappeared. Local Codex tasks repopulated as well.Important caution:
codex-dev.dbcontains other desktop-local state. Backing up/renaming the files is safer than deleting them, and anyone relying on local-only Codex state should back up~/.codexfirst. Also, do not move the database while the app is still running; an open process can keep using the moved file until it truly exits.This supports the theory that stale ChatGPT Recents rows can persist in the desktop
local_thread_catalog, and that a product-side reconciliation/pruning fix would be preferable to requiring users to rebuild the entire local catalog.mmmd3d-source commentedon Sep 3, 2026
Update from the same Windows system, observed on 2026-09-03:
OpenAI.Codex_26.901.1978.0_x64__2p2nqsd0c76g0.Therefore the issue remains reproducible on a substantially newer Windows build. The desktop Recents projection still does not reliably converge after the authoritative ChatGPT conversation has been deleted, including after a full restart.
CipEna commentedon Sep 3, 2026
maytayci commentedon Sep 4, 2026
Confirming this remains reproducible on a newer Windows build, with additional catalog evidence.
Environment
26200OpenAI.Codex 26.901.2854.0x64Reproduction
Sanitized app-log evidence for the affected row:
No conversation ID, title, account identifier, user identifier, local path, raw log, or screenshot is included here.
Additional local-catalog evidence
The stale item exists as one active
source_kind=chatgptrow inlocal_thread_catalog, withmissing_candidate=0.With the app fully stopped, I backed up the database and changed only that exact row to
missing_candidate=1; the update reported one changed row. After relaunch, the desktop sync changed the same row back tomissing_candidate=0, and the ghost entry reappeared.The ChatGPT catalog sync reports
initial_build_complete=1; the incremental observation sequence and watermark advance, while the full-reconciliation timestamp lags. Clearing Chromium Cache, Local Storage, Session Storage, Code Cache, and service-worker cache did not resolve the issue.This is consistent with a missing tombstone/full-reconciliation path: incremental sync reactivates an already server-deleted catalog entry. In addition to treating terminal
conversation_deletedas idempotent delete success, the catalog reconciler should avoid reactivating rows that are absent from the authoritative ChatGPT conversation list.CipEna commentedon Sep 4, 2026
holgerbuecking-ux commentedon Sep 4, 2026
Reproduced on Windows with desktop package 26.901.1978.0 (German UI) on 2026-09-04.
Observed behavior:
Chat konnte nicht geladen werden("Chat could not be loaded").Die Unterhaltung wurde gelöscht. Starte einen neuen Chat("The conversation was deleted. Start a new chat").Read-only diagnostics showed that the sidebar contained a mixture of local Work/Codex threads and ChatGPT cloud conversations. The local Work rollout files and their working directories were still present; representative JSONL files validated without malformed records. The supported thread reader could still return content, so this was not underlying data loss.
Using the supported Codex archive operation directly (bypassing the row menu), six local Work threads archived successfully. Three ChatGPT conversation rows could not be archived through that route and remain stuck; they are rejected as not being Codex threads. This further points to a unified-Recents reconciliation/routing problem rather than a mouse, account, or damaged-session problem.
Expected behavior: Recents should reconcile stale ChatGPT rows against the canonical conversation state, and a row whose backing conversation cannot be loaded should offer a supported "remove stale reference" action. Pinning must not display a deletion message.
No screenshot or full conversation IDs are attached publicly because the sidebar contains private titles, but they can be supplied through a private diagnostic channel if requested.
hqzzlys commentedon Sep 4, 2026
Additional observation that may help narrow down the root cause:
After updating the Codex desktop app once, all previously existing ghost/stale conversations disappeared from the Windows Recents sidebar. However, after continuing to use the app normally, new ghost conversations appeared again.
This suggests the update process may be triggering a full rebuild/reconciliation of the local Recents/thread catalog, which clears existing stale entries, while the normal incremental synchronization/invalidation path is still able to create new stale entries afterward.
So this does not look like only legacy corruption from an older version. The underlying deletion/reconciliation bug still appears to be active.
HUJH511 commentedon Sep 5, 2026
Also affected on Windows with OpenAI.Codex package 26.901.5280.0, bundled app-server 0.153.4, on September 5, 2026.
After deleting a chat in ChatGPT on the web, its entry remains in the desktop sidebar. Opening it fails, and deleting it again displays Failed to delete chat. Signing out/back in and reinstalling did not resolve it.
The inspected executable is
ChatGPT.exeinside the OpenAI.Codex Windows package.Additional diagnostic evidence
Read-only inspection of today's desktop logs found 9 responses across 2 distinct conversation IDs with HTTP
404andconversation_deleted: 7 open/init failures and 2 DELETE failures. Sanitized deletion events:Both DELETE responses include:
{ "detail": { "message": "Conversation has been deleted. Start a new chat.", "code": "conversation_deleted", "can_retry": false } }Read-only inspection of the packaged client found that the deletion handler awaits the DELETE request before notifying the thread catalog and cleaning up sidebar/query references. A rejected request skips those cleanup steps; the pending flag is reset in
finally, and the caller shows the generic deletion error. This is consistent with an already-deleted conversation remaining impossible to remove through the UI.The source of the lingering entries—local persisted state versus a server-side list/index—has not been established by this inspection.
Please investigate handling the specific
conversation_deletedresponse as completed deletion for client cleanup, and reconciling the source list so these entries stay removed after refresh/restart/login. A generic 404 should not automatically be treated as confirmed deletion.Conversation titles, full IDs, account information, local paths, and unrelated log contents are omitted from this public report.
P4th0g33n commentedon Sep 8, 2026
I can confirm that this issue is still affecting me on Windows 11.
My case matches the reports here: a conversation deleted successfully from ChatGPT Web or iOS disappears there, but remains in the Windows desktop app as a stale/ghost entry that can no longer be opened, archived, or deleted.
I reported this to OpenAI Support and was told that the issue had been escalated internally. However, I still have not received a substantive follow-up, while the number of matching public reports has continued to grow.
Given the detailed evidence already collected in this thread around conversation_deleted, the desktop Recents/catalog state, and reconciliation behavior, could an OpenAI maintainer please confirm whether there is now a canonical internal engineering issue tracking this?
It would be especially helpful to know whether:
I am happy to provide a fresh reproduction with the current Windows app version, exact UTC timestamps, and a Feedback ID if that would help correlate the issue with internal telemetry.
Thank you.
deicide666 commentedon Sep 8, 2026
Additional Windows reproduction (2026-09-08):
Reset-AppxPackage.Expected behavior: when opening a Recent entry returns the terminal deleted/nonexistent state, the desktop client should remove that orphaned row from Recents, or provide an idempotent “Remove from Recents” action even when delete/archive returns 404.
No account identifiers, conversation contents, IDs, or local paths are included here.