Windows desktop keeps already-deleted ChatGPT conversations in Recents after full restart

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

• #39897

Powered by Codex Action

Still reproducible on Windows package 26.818.5229.0 (OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0).

Observed behavior:

• A regular ChatGPT cloud conversation was deleted successfully on the web and no longer appears there.
• The same conversation remains in the Windows desktop Recents/sidebar.
• Opening the stale entry shows "Could not load this ChatGPT conversation".
• Trying to delete it from the desktop app fails (UI reports that the chat could not be deleted).
• Windows App Repair and Reset do not remove the stale entry.
• This is a normal ChatGPT conversation, not a local Codex/Work thread.

This appears to be the same stale-sidebar / conversation_deleted reconciliation 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.

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.

Confirming the same symptom on Windows with a newer build.

• Codex Windows package: 26.818.8289.0 (installed/updated 24 Aug 2026).
• The live/unified task inventory currently returns 3 ChatGPT conversations, while the desktop local_thread_catalog contains 7 ChatGPT rows. The difference is 4 stale rows corresponding to conversations already deleted on the web.
• Fully restarting the app does not remove those stale entries.
• The ChatGPT catalogue sync state has initial_build_complete = 1; its observation sequence and incremental watermark advance, but last_full_reconciled_at remains at 24 Aug 2026 12:43:22 BST. The missing cloud conversations are therefore not pruned by later incremental syncs.
• Local Codex tasks and session files are unaffected.

The evidence points to a missing tombstone/full-reconciliation path.

I can reproduce the same issue on Windows with a newer Codex build.

Environment:

• Windows
• Codex package: OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0
• Observed on: 2026-08-26

In my case, a ChatGPT Work conversation that has already been deleted server-side still remains in the Codex desktop sidebar.

Additional observations:

• The conversation is no longer present in ChatGPT Web Recent.
• ChatGPT global search returns no result for the conversation title.
• Clicking the stale sidebar row causes:

GET /backend-api/conversation/<conversation_id>
→ HTTP 404
→ code: conversation_deleted
→ can_retry: false

• Trying to delete the stale row again also returns the same conversation_deleted 404.
• Restarting Codex and signing out/in does not remove the row.
• I fully stopped all Codex/ChatGPT processes and moved the renderer's Cache, Code Cache, GPUCache, Local Storage, Session Storage, and WebStorage directories aside so that Codex recreated them from scratch. The stale row still came back.
• The recreated codex.chatgpt-pinned-conversations value is empty.
• The deleted conversation ID/title is not present in the live local sidebar/storage data I inspected.
• The current Codex thread catalog also does not contain this conversation.

One potentially relevant implementation detail I observed in this build:

The renderer fetches ChatGPT Work history from /conversations with conversation_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:

1. A sidebar/history source is still supplying or retaining a summary row for a conversation that is already tombstoned/deleted.
2. 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_deleted as 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.

Additional independent Windows reproduction, observed on 2026-08-26:

• The issue is still reproducible on OpenAI.Codex 26.820.7780.0, which is newer than the 26.818.2872.0 build in the original report.
• Eight server-deleted entries remain visible in Recents. The affected set includes both ordinary ChatGPT chats and chats that were originally inside ChatGPT Projects.
• At least three sampled entries return terminal HTTP 404 responses with code=conversation_deleted and can_retry=false, while the same conversations are absent from ChatGPT on the web.
• A read-only local preflight found zero matching rows in state_5.sqlite/threads, zero exact-title rows, and no matching entries in session_index.jsonl or the Codex global-state JSON. Consequently, the affected entries have no local Codex thread, no rollout_path, and no rollout JSONL.
• This also rules out the separate local archive-path failure mode discussed around #39161: its required preconditions are absent here.
• Full process restart, sign-out/sign-in, and rebuilding only the Chromium HTTP cache did not resolve the stale entries.

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=false as 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/

I can reproduce this on macOS as well.

Environment:

• macOS 27.0 (build 26A5421a), Apple silicon (arm64)
• ChatGPT desktop app: 26.820.60940
• Observed: 2026-08-26
• Feedback ID: no-active-thread-01a0408f-ebdf-7050-bfbc-68fb6d3bc08a

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.

Also impacting my system : no-active-thread-01a042ec-7e77-7cf3-98cf-5217ec8f1a8e