Repository navigation
Deleted conversations remain in sidebar and cannot be removed or archived – HTTP 404 conversation_deleted #44343
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.903.61454 (build 8378)
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Darwin 24.6.0 arm64 arm
What issue are you seeing?
Some ChatGPT conversations remain visible in the sidebar even though the server considers them already deleted. They cannot be deleted again or archived.
Steps to reproduce:
- Open the ChatGPT desktop app on macOS.
- Open the three-dot menu next to one of the affected conversations.
- Select Delete or Archive.
- The application reports that the conversation cannot be deleted, and the entry remains in the sidebar.
Actual result:
The delete request returns HTTP 404 with the error code conversation_deleted. The server response states that the conversation has already been deleted, but its entry remains visible in the desktop application's sidebar. Archiving the same conversation also fails.
Expected result:
A conversation that has already been deleted on the server should disappear from the sidebar. I should also be able to manually delete or archive other conversations normally.
Additional information:
- Only some conversations can be deleted.
- The affected conversations are not visible in the ChatGPT web version.
- The affected conversations are not actually running, although some may appear to be working in the desktop interface.
- Reinstalling the application did not resolve the issue.
- Completely resetting the local application profile and caches did not resolve the issue.
- The problem persists after restarting the application.
- The issue appears to be caused by a stale or inconsistent conversation index associated with my account.
Relevant log result:
HTTP status: 404
Error code: conversation_deleted
Request method: DELETE
Route: /conversation/id/{conversation_id}
Previous diagnostic session ID:
01a0624e-c8fc-79c3-9278-25cabf70ab64
What steps can reproduce the bug?
- Open the ChatGPT desktop app on macOS.
- Locate one of the affected conversations in the sidebar.
- Click the three-dot menu next to the conversation.
- Select Delete and confirm the deletion.
- The application displays an error and the conversation remains visible.
- Try to archive the same conversation. Archiving also fails.
- Restart the application. The conversation is still present.
- Repeat the procedure after reinstalling the application and resetting the local application profile and caches. The problem remains.
The DELETE request returns HTTP 404 with the error code conversation_deleted.
Diagnostic session ID:
01a0624e-c8fc-79c3-9278-25cabf70ab64
What is the expected behavior?
After I confirm deletion, the conversation should be permanently removed from the sidebar. If the server already considers the conversation deleted, the desktop application should remove its stale sidebar entry automatically.
Archiving should move an existing conversation to Archived Chats without displaying an error. The conversation list should remain consistent after restarting the application and across the desktop and web versions.
Additional information
Environment:
- ChatGPT desktop app version: 26.903.61454 (build 8378)
- Subscription: ChatGPT Plus
- Operating system: macOS 15.8 (build 24H22)
- Platform: Apple Silicon / arm64
- Kernel information: Darwin 24.6.0 arm64 arm
Scope of the problem:
- Only some conversations are affected.
- The affected conversations are visible in the macOS desktop app but are not visible in the ChatGPT web version.
- The affected conversations are not actually running, although the desktop interface may display a stale working state.
- Other conversations can still be deleted normally.
Troubleshooting already completed:
- Restarted the application.
- Reinstalled the application.
- Reset the local application profile.
- Cleared the application caches.
- The issue persists after all of these steps.
Sanitized log information:
- Request method: DELETE
- Route: /conversation/id/{conversation_id}
- HTTP status: 404
- Error code: conversation_deleted
- The server reports that the conversation has already been deleted, but the desktop application continues to display it.
This appears to be an account-level conversation index or synchronization inconsistency rather than an active-task or local-cache problem.
Previous diagnostic session ID:
01a0624e-c8fc-79c3-9278-25cabf70ab64
Activity
github-actions commentedon Sep 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
zeta667 commentedon Sep 11, 2026
Windows reproduction and local catalog evidence
Environment
Observed behavior
%USERPROFILE%\.codex\sqlite\codex-dev.db, tablelocal_thread_catalog, withsource_kind='chatgpt'andmissing_candidate=0.source_kind='vscode'and were unrelated.chatgptrows asmissing_candidate=1and incrementinglocal_thread_catalog_metadata.catalog_revisionremoved the stale entries after restart.Expected behavior
No personal conversation titles, account identifiers, conversation IDs, or database files are included. Sanitized screenshots or logs can be provided privately if required.
rm6m6jf5k9-source commentedon Sep 11, 2026
Adding the diagnostic findings from my duplicate report #44898, reproduced in ChatGPT desktop 26.903.71938 on macOS.
errorCode=conversation_deleted; Archive also failed.Suggested fix: treat the specific
404 / conversation_deletedresponse as authoritative local removal, use the normal catalog-removal path (including the catalog revision and any in-progress scan removal marker), and invalidate the relevant sidebar caches. Apply equivalent cleanup when opening or archiving a chat returns the same explicit deletion status. Timeouts, authentication failures, and ambiguous not-found errors should not trigger removal.Validation should cover normal deletion, deletion from another client, repeated deletion, sidebar refresh after restart, and errors that do not confirm deletion.
Please address this in a desktop app update so manual local repairs are no longer needed. No conversation contents, chat titles, account identifiers, or raw logs are included.
xibian-YQ commentedon Sep 12, 2026
Additional macOS recurrence with a captured event sequence (a second distinct ghost conversation after an earlier targeted cleanup).
Environment:
Observed sequence (Asia/Shanghai):
refetchandasync-statusconversation updates, but logged each aschatgpt_conversation_update_ignoredwithreason=conversation_not_loaded.POST /conversation/initandGET /conversation/{conversation_id}. Both returned HTTP 404,errorCode=conversation_deleted,can_retry=false.DELETE /conversation/id/{conversation_id}and returned the same terminal 404.source_kind=chatgpt,project_id=NULL, andmissing_candidate=0.initial_build_complete=1.Inference:
The desktop indexes a conversation before loading it, ignores later invalidation/refetch events while it is not loaded, and then fails to evict the catalog row when open/delete returns authoritative
conversation_deleted. The sidebar therefore continues rendering the stale local row after restart.Suggested behavior:
conversation_deletedwithcan_retry=falseas an idempotent local-removal signal.This is a recurrence involving a different conversation after an earlier targeted catalog cleanup. Conversation titles, full IDs, account identifiers, and raw logs are intentionally omitted.
jenya-martynenko commentedon Sep 12, 2026
Reproducing this on macOS / Apple Silicon with Codex Desktop 26.908.40834.
Observed behavior:
Could not load this ChatGPT conversation.This also happens in the inverse workflow where a chat is first surfaced in Codex, later deleted elsewhere, but Codex continues to keep the sidebar reference.
Expected behavior:
If the server reports that a conversation is deleted/missing (
conversation_deleted), Codex should treat that as an authoritative/idempotent local-removal signal and evict the stale entry from the local thread catalog/sidebar automatically.The visible symptom in my case is exactly the blank conversation view with the message:
Could not load this ChatGPT conversation.This looks like the same stale local catalog / cross-client deletion reconciliation issue described above.
jenya-martynenko commentedon Sep 12, 2026
Reproducing this on macOS / Apple Silicon with Codex Desktop 26.908.40834.
Observed behavior:
Could not load this ChatGPT conversation.This also happens in the inverse workflow where a chat is first surfaced in Codex, later deleted elsewhere, but Codex continues to keep the sidebar reference.
Expected behavior:
If the server reports that a conversation is deleted/missing (
conversation_deleted), Codex should treat that as an authoritative/idempotent local-removal signal and evict the stale entry from the local thread catalog/sidebar automatically.The visible symptom in my case is exactly the blank conversation view with the message:
Could not load this ChatGPT conversation.This looks like the same stale local catalog / cross-client deletion reconciliation issue described above.
d22fomina commentedon Sep 16, 2026
I’m experiencing the same issue with the new ChatGPT macOS desktop app.
App version: 26.908.70816
Deleted conversations remain visible as ghost entries in the macOS sidebar, while they are no longer visible on the web or mobile app. Clicking them shows “Unable to load this conversation.”
I reproduced the issue and checked the app logs. At approximately 02:43:25 UTC on September 16, 2026, the server returned:
errorCode=conversation_deletedHTTP 404/conversation/init/conversation/<conversation_id>The server response indicates that the conversation has already been deleted, while the macOS app continues to display it in the sidebar.
Cmd+K search partially refreshes the sidebar and removes some of the ghost entries, but some remain. The issue has been recurring for about 1–2 months.
Diagnostic session ID from in-app feedback:
no-active-thread-01a0a803-29f8-79e2-a168-341d9b5629eeplay12345 commentedon Sep 25, 2026
Additional macOS reproduction of deleted conversations remaining in the sidebar.
Environment: ChatGPT desktop 26.901.51231 (build 8109), macOS 26.6.2 (25G83).
Deleted conversations remain visible in the sidebar. Opening them reports that the conversation is deleted or cannot be loaded. Retrying Delete or Archive displays a failure and leaves the entry visible. Fully restarting the application and signing out/back in have already been tried without resolving the problem.
Read-only inspection of September 24–25, 2026 desktop logs confirmed HTTP 404 responses with
errorCode=conversation_deletedandcan_retry=falsefor eight distinct conversations. This is a count from the inspected logs, not a claim that every sidebar entry is deleted. GET, DELETE and PATCH requests were affected. Earlier attempts also encounterednet::ERR_NETWORK_CHANGED; this does not establish the cause of the stale entries.Expected: reconcile sidebar entries when the service explicitly reports that the conversation has been deleted, and provide a supported repair for existing stale entries. Generic network, authentication or not-found errors should not be treated as deletion confirmation.
No internal database or cache edits were performed. Conversation titles, contents, identifiers, account information, screenshots, local paths and raw logs are omitted.
Reguai0469 commentedon Oct 19, 2026
Additional macOS report: persistent ghost conversations
I am a long-time Codex Desktop user on macOS. Multiple conversation entries remain in my sidebar despite attempts to remove them through the normal Delete action. These are persistent entries, rather than a single temporary glitch, and they interfere with everyday history management. I cannot reliably clean up my own conversation list.
Current installed environment, checked on October 19, 2026:
The failed deletion attempts and persistence are my reported experience; no additional conversations were deleted to prepare this comment. I have not verified HTTP 404, conversation_deleted, the backend deletion state, a cross-device trigger, or the technical cause in my case. I am adding this here because the visible symptom matches, without assuming the same underlying mechanism. Related sidebar reports include #46349 and #44047.
Please provide a reliable product fix and a supported way to clear existing stale entries while preserving valid chats, local tasks, and settings. Choosing Delete should consistently remove the intended conversation from the list, and the client should maintain a correct conversation state afterward. Users should not have to edit a database or application files to manage their history.
Could the team confirm whether this failure is tracked, whether a released build addresses it, and how affected users can safely recover existing stuck entries? No private chat content, identifiers, screenshots, or logs are attached.