Repository navigation
Deleted conversations remain as stale titles in Windows app Recents #41602
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Powered by Codex & OWL, version 26.825.51511
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Windows 11 x64
What issue are you seeing?
Deleted conversations still remain as stale titles in the Windows desktop app's Recents/sidebar.
I deleted all conversations from ChatGPT Web. The conversations themselves appear to be deleted successfully.
However, the old conversation titles are still visible in the Windows desktop app.
When I click one of these stale titles, the app indicates that the conversation/thread has already been deleted or no longer exists, but the title remains in the Recents list.
I have already tried resetting the Windows app, signing out and signing back in, and restarting the app, but the stale titles remain.
This appears to be a Recents/sidebar metadata or synchronization issue rather than the conversations themselves failing to delete.
What steps can reproduce the bug?
Feedback ID: no-active-thread-01a050a8-2e29-7fd1-8006-efde2bf38fa5
What is the expected behavior?
After a conversation is deleted, its title should also be removed from the Recents/sidebar list.
If all conversations are deleted from the account, the Windows desktop app should synchronize with the server and remove all deleted conversation titles.
Deleted or nonexistent threads should not remain visible as stale entries in Recents.
Additional information
The conversations were deleted from ChatGPT Web using the delete-all-conversations option.
On the web version, the deleted conversations no longer appear.
The issue is limited to the Windows desktop application's Recents/sidebar, where the old titles remain visible even though the underlying conversations no longer exist.
I have already tried:
- Restarting the app
- Signing out and signing back in
- Windows app Reset
The issue still persists.
The stale titles appear to reference deleted/nonexistent threads.
Activity
github-actions commentedon Aug 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
AmirRajaian commentedon Sep 1, 2026
I can reproduce this issue on the Windows desktop app, and I found a local-database workaround that may help identify the root cause.
Environment
Windows desktop app
Package: OpenAI.Codex
Version: 26.825.6671.0
Package family: OpenAI.Codex_2p2nqsd0c76g0
Observed behavior
Conversations were deleted from ChatGPT Web.
The deleted conversations continued to appear in Recents in the Windows desktop app.
The stale entries could not be opened or deleted.
Resetting the Windows app did not fix the issue.
Uninstalling/reinstalling the app and clearing its data also did not fix it.
Local database finding
I inspected:
C:\Users<username>.codex\sqlite\codex-dev.db
The stale ChatGPT conversations were still present in the SQLite table:
local_thread_catalog
The affected rows had:
source_kind = chatgpt
host_id beginning with chatgpt:
missing_candidate = 0
So, importantly, the stale/deleted conversations were not being marked as missing candidates.
Workaround that successfully fixed the issue
With the ChatGPT/Codex desktop app completely closed, I backed up the database and removed only the stale conversation rows from local_thread_catalog.
After reopening the desktop app, the ghost/stale conversations immediately disappeared from Recents.
I first tested this with a single stale conversation, and it worked. I then removed the remaining stale ChatGPT rows, while preserving the active conversation, and Recents was cleaned successfully.
This suggests that the Windows desktop app's local local_thread_catalog is not being properly reconciled/cleaned after a cloud ChatGPT conversation is deleted.
It may also be relevant that missing_candidate remained 0 for these orphaned entries.
Hopefully this helps narrow down the issue. A future fix may need to invalidate/remove the
ar3-danilo commentedon Sep 2, 2026
Additional reproducibility information
I can consistently reproduce this issue on the Windows desktop app.
The important detail in my case is that this does not appear to be caused only by stale data left from a previous installation.
What I observed
I delete a conversation.
The conversation is correctly removed from the web version of ChatGPT.
However, the deleted conversation remains visible in the Windows desktop app's chat/Recents list.
Trying to delete or archive that stale entry from the desktop app fails, since the conversation has already been deleted on the server.
Logging out, restarting the app, or simply uninstalling and reinstalling the Windows app does not resolve the issue.
Full local cleanup test
I found that the only way to completely restore synchronization is:
Uninstall the ChatGPT desktop app.
Manually remove all remaining local files/directories related to ChatGPT, OpenAI, and Codex.
Reinstall the app.
After doing this, the desktop app and the web version become perfectly synchronized again, and all previously deleted conversations disappear from the desktop Recents list.
However, the issue is immediately reproducible again:
Start from this completely clean and synchronized state.
Delete a new conversation.
The conversation disappears correctly from the web version.
The same conversation remains in the Windows desktop app.
The stale entry cannot then be successfully deleted from the desktop app.
So the cleanup fixes the existing stale state, but the next normal conversation deletion creates the problem again.
This suggests that the local Recents/thread catalog can be rebuilt correctly from the server, but the desktop client is failing to invalidate/remove the local entry when a conversation is deleted.
In other words, this appears to be an active synchronization/reconciliation bug in the deletion flow, rather than only corruption from an older installation.
guojiansuo commentedon Sep 9, 2026
Additional reproduction on Windows with desktop release
26.903.61454(from app logs), observed 2026-09-09.Eight stale ChatGPT conversation entries remain visible in the desktop Recents/sidebar. The user reports that clicking all eight produces the localized error
无法加载此chatgpt对话(unable to load this ChatGPT conversation), and the entries cannot be removed through desktop archive/delete actions.Sequence and evidence:
Conversation has been deleted. Start a new chat.for a deleted URL.list_threadsrequest usinglimit: 50does not include those four known IDs, and itschats/Tasks section returnsitemKeys: [], while the visible sidebar reportedly retains the stale entries. This is a discrepancy between the tool's returned inventory and the user-visible list, not proof of the underlying cache implementation.errorCode=conversation_inaccessibleandcan_retry=falseonPOST /conversation/init.Expected: reconcile Recents with deleted/inaccessible conversation state, and provide a way to remove orphaned entries even when the conversation itself can no longer load.
No raw logs, conversation bodies, private titles, account identifiers, or conversation IDs are included in this public comment. The precise cause (local persisted metadata versus remote Recents synchronization) has not been established.
guojiansuo commentedon Sep 9, 2026
Follow-up to my previous reproduction comment: the affected user moved the eight stale entries into a custom sidebar section named
？, making the orphaned references directly observable through the desktop app tool.Fresh verification on 2026-09-09:
list_threads({limit:50})response contains that custom section with exactly 8 distinctchatgpt:conversation:<id>itemKeys.read_threadindividually for all eight IDs returnsNo Codex thread found ... Hosts without a readable match: local. This error is a tool lookup/fallback result, not independent proof that all eight cloud conversations are deleted.无法加载此chatgpt对话.This confirms that sidebar section membership retains references to at least four known-deleted conversations, and that those stale entries can still be moved into a custom section. Moving them groups the problem but does not repair the underlying conversation access.
Suggested investigation: reconcile sidebar section membership / Recents references with conversation deletion and inaccessible-conversation handling, including custom sections. Please provide a supported way to remove orphaned sidebar references without resetting unrelated local projects or task history.
Private conversation IDs, titles, contents, account information, and raw logs remain omitted.
jonesjl commentedon Sep 10, 2026
This is also happening in the Linux version as well. See Feedback no-active-thread-01a08b4d-c05a-7110-83a0-514f9db0036d. Linux desktop app retains chats in Recents after they are deleted through the web interface. Opening those entries reports that the conversation couldn’t be retrieved. Fully quitting/reopening and signing out/in do not remove the entries.
zs2932634802-blip commentedon Sep 11, 2026
I can reproduce this on Windows with current desktop packages:
Behavior:
This looks like the desktop Recents/sidebar index retaining references that no longer resolve to manageable conversation objects.
A full Windows app Reset is not an acceptable workaround for this case because the user needs to preserve other local Codex conversations and local app state. Please add a safe self-healing path or a per-entry "remove stale reference" action that does not require loading the underlying conversation or clearing all local state.
No conversation titles, conversation IDs, screenshots, or account information are included for privacy.
OKJOIZJ commentedon Sep 15, 2026
Additional Windows evidence from ChatGPT desktop / OpenAI.Codex MSIX
26.908.9136.0x64:This is not limited to the “Delete all chats” operation. The same stale-entry behavior occurs whenever a conversation is deleted on ChatGPT Web—including an ordinary deletion of a single conversation—but the Windows desktop app has already indexed it. The account-wide deletion merely made the failure visible at large scale.
For the large-scale reproduction, I used Delete all chats on ChatGPT Web for a long-lived account with a large history. A fresh web session showed no old conversations, while the Windows desktop sidebar still showed hundreds of old titles. Delete and Archive both failed for those entries. A full desktop restart and Chromium HTTP-cache refresh did not change the list.
The single-conversation reproduction is:
Local catalog evidence
The stale sidebar metadata was present in:
Before repair:
925rows belonged to a host withhost_kind='chatgpt'and hadsource_kind='chatgpt'.14unrelated local Codex rows were present.initial_build_complete=1.PRAGMA integrity_checkreturnedok.After making a complete SQLite backup, I performed a narrowly scoped local recovery: recorded the 925 known stale
(host_id, thread_id)pairs, deleted only those ChatGPT catalog rows, and incrementedcatalog_revision. The stale sidebar list cleared after relaunch. The 14 local rows were preserved and the post-relaunch integrity check remainedok.As a diagnostic, blocking reinsertion of only those same 925 IDs kept the deleted entries from returning, while newly created ChatGPT conversation IDs were still inserted normally. This is evidence that the persistent unified catalog, rather than the Chromium HTTP cache, was driving the ghost list. Manual SQLite repair is not a suitable product-level solution and should not be required of users.
Likely failure mode
The desktop
local_thread_catalogappears not to consume or reconcile ordinary per-conversation deletions performed on the web. The same flaw also affects an account-wide delete operation. An incremental catalog can remain marked complete while retaining rows whose source conversations are gone. Please also check whether the desktop history request usinghide_snorlax=falsecan surface legacy/deleted records.Confirmed reconciliation mechanism in this build
Inspection of the packaged main-process bundle shows that the catalog coordinator considers a cold full reconciliation due only when the initial build is incomplete or
lastFullReconciliationAtis null. Once a full scan completes, the coordinator records a non-null full-reconciliation timestamp and clears its in-memoryfullReconciliationDueflag. Subsequent ordinary and notification-triggered runs select incremental mode whileinitial_build_complete=1.The store's absence handling (
missing_candidate) is performed during full scans. Therefore, if a web deletion notification is missed, an already-complete desktop catalog can remain in incremental mode indefinitely and never revisit the deleted ID. This matches the observed persistence across relaunches. The ChatGPT source also appears configured with a 720-hour history horizon, so periodic recent-history sweeps alone may not cover deletions of older conversations; authoritative deletion tombstones are still necessary.As a local diagnostic only, setting the ChatGPT host's
initial_build_completeto0, clearinglast_full_reconciled_at, and removing only interrupted-scan checkpoints makes the next app start select a full reconciliation without deleting any catalog rows directly. A copy-of-database test preserved all ChatGPT rows and all unrelated local Codex rows and passedPRAGMA quick_check. This is a workable recovery signal but not a substitute for automatic tombstone delivery and periodic authoritative reconciliation in the product.I did not capture the HTTP response from the failing Delete/Archive action in this reproduction, so a
404/410response is a hypothesis here rather than a confirmed observation. Related reports such as #39989 and #44343 contain directconversation_deletedevidence.Suggested product fix
local_thread_catalogperiodically, on startup, account/login changes, and manual refresh; prune rows that are absent or tombstoned.Not Found/Goneduring Delete or Archive as idempotent success and remove the local catalog row.This is major for affected long-lived accounts because hundreds of stale entries can become permanently visible and individually undeletable.
rockakuworks commentedon Sep 20, 2026
I’m seeing the same issue on a newer Windows app version.
Environment:
The stale deleted-chat titles appear immediately when I launch the Windows app.
The corresponding chats are already absent from the web version, including Search and Archived chats.
When I click one of the stale titles, the conversation does not load.
I have already tried:
The issue still persists.
Feedback session ID:
no-active-thread-01a0bf98-bfe8-7d50-b38f-f1d051020fd9
I’m a Japanese user.