MacOS desktop app keeps undeletable "ghost" conversations in the sidebar after deletion

Environment

App: ChatGPT macOS desktop app (Codex-based), version 26.825.51511 (latest)
OS: macOS (Apple Silicon)
Account: fengw2002@gmail.com (Plus)

Description
After deleting several conversations, their titles remain stuck in the desktop app's sidebar "Recent" list. These ghost entries:

Show "Unable to load this ChatGPT conversation" when clicked;
Fail with "Chat could not be deleted" when using right-click → Delete chat;
Fail with "Conversation could not be archived" when using Archive;
Redirect to the chatgpt.com homepage when opened via "Open on chatgpt.com" — the conversation no longer exists server-side (e.g. conversation ID: 6a915541-a670-83ea-a3a1-baea4345992d);
Do NOT appear in the web sidebar, so the issue is specific to the desktop app's conversation list index.

Troubleshooting already attempted (none worked)

Fully quitting and relaunching the app;
Deleting local app data and caches (~/Library/Application Support/com.openai.codex, ~/Library/Caches/com.openai.codex) — the list was restored identically after relaunch;
Signing out and signing back in — ghost entries persist and delete/archive still fail;
Confirmed the app is on the latest version.

Conclusion
The conversation objects were deleted server-side, but the desktop app's conversation list index retains stale references. Delete/archive requests fail because the target no longer exists, so the list cannot self-heal. The state is account-bound (server-side), independent of device or local data.

Request
Please purge the stale entries from my account's desktop conversation list, or fix the sync bug where deleting a non-existent conversation leaves a permanent sidebar entry.

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

[macOS][Desktop] Deleted ChatGPT conversations remain in sidebar after full local profile reset #41399
Windows desktop app: deleted chats remain as stale entries in Recents and can’t be removed #41880
[Windows][Desktop 26.825.6671.0] Deleted conversations persist in Recents after reset, re-login, and canonical-list removal #41693
Deleted conversations remain as stale titles in Windows app Recents #41602
Can't delete conversation in desktop app #40981

Powered by Codex Action

I can reproduce this exact issue on macOS 26.6.2 (Apple Silicon) with ChatGPT/Codex desktop app 26.825.51511.

Additional diagnostics from my case:

Three deleted cloud conversations remain visible as undeletable sidebar entries.
Two are associated with a ChatGPT project; one is projectless.
The authoritative live and archived task inventories omit all three.
Fetching each entry returns HTTP 404 with conversation_deleted and can_retry: false.
Attempting Delete again returns the same HTTP 404 because the underlying conversation is already gone.
Fully quitting and restarting the app does not remove them.
Moving the desktop web cache aside, allowing it to rebuild, and restarting again does not remove them.

This supports the conclusion that the stale references are account-bound sidebar/project-index records rather than recoverable local cache entries. Conversation IDs, titles, contents, and raw logs are intentionally omitted here, but sanitized logs are available if an OpenAI maintainer requests them through a private channel.

I can reproduce this exact issue in the ChatGPT macOS desktop app with a ChatGPT Business workspace.

The cloud Work conversation “Teste em nuvem” was deleted successfully and no longer appears on chatgpt.com.

However, it remains permanently visible under Recents in the macOS desktop app. When selected, the app shows:

“Não foi possível carregar esta conversa do ChatGPT”
(Unable to load this ChatGPT conversation)

Already tried:

Fully quitting and reopening the desktop app
Signing out and signing back in
Confirming the conversation is gone from the web version

I also submitted diagnostic feedback from the desktop app.

Feedback ID:
no-active-thread-01a0696b-c253-7f91-8b0f-99eed7df5407

Environment:

ChatGPT Business workspace
macOS
Desktop app

I can reproduce the same issue in the ChatGPT macOS desktop app, build 26.831.21537.

Two ordinary ChatGPT conversations remain as undeletable sidebar entries:

Conversation ID 6a9864b1-7cbc-83e8-a8f0-5613633c0293
Conversation ID 6a9a1de0-75cc-83e9-a1c6-5559519df56d

Observed behavior:

Clicking either entry shows that the conversation cannot be loaded.
The desktop logs return HTTP 404 with conversation_deleted for both IDs.
One ID also briefly returned conversation_inaccessible before subsequent requests returned conversation_deleted.
A delete request also returns 404 because the server already considers the conversation deleted.
The entries are normal ChatGPT conversations (source_kind=chatgpt), not Codex threads, so the Codex archive operation cannot remove them.
Mobile and web clients display the expected cloud state.
Fully quitting/relaunching and signing out/in did not remove the stale desktop entries.

No conversation contents or local filesystem paths are included here. This appears to be the same stale desktop conversation-index behavior described in this issue.

I’m seeing the same issue on macOS, specifically with chats deleted from the ChatGPT iPhone app.
The deletion succeeds on iPhone, but the deleted conversation remains visible in the Mac app sidebar. Clicking the orphaned entry produces:
“Could not load this ChatGPT conversation”
Troubleshooting already performed:

Completely removed and reinstalled the ChatGPT Mac app. This temporarily cleared the orphaned entries, but the problem returned after deleting additional chats on iPhone.
Used “Log out of all sessions” and terminated 16 active sessions, then signed back in. The problem still persists.
This appears consistent with the conversation being deleted successfully on the server while the macOS conversation-list/Recents state is not being invalidated or synchronized correctly.
Related in-product feedback IDs:
no-active-thread-01a0716c-7169-71e3-ac8c-edf993ee177b
no-active-thread-01a07178-f17f-7af3-9533-687dd37ac2a5
I also have screenshots showing the stale sidebar entry and the “Could not load this ChatGPT conversation” error.

Independent reproduction on the current macOS desktop build.

Environment

ChatGPT Desktop: 26.901.20858 (build 7658)
macOS: 26.6.2 (build 25G83)
Apple Silicon, arm64

Observed behavior

One server-deleted, projectless ChatGPT conversation remains visible in the macOS Desktop sidebar as a ghost entry.
Selecting it triggers GET /conversation/<id> and returns HTTP 404, errorCode=conversation_deleted, can_retry=false.
Trying Delete triggers DELETE /conversation/id/<id> and returns the same terminal 404 conversation_deleted; Desktop shows the generic “Failed to delete chat” toast.
The matching GET and DELETE events were captured at 2026-09-05 21:53 KST.
Fully quitting and reopening the app, then signing out and signing back in, did not remove the entry.

Read-only local confirmation

A read-only inspection found exactly one matching row in:

database: ~/.codex/sqlite/codex-dev.db
table: local_thread_catalog
source_kind = chatgpt
missing_candidate = 0
project state: projectless

PRAGMA integrity_check returned ok. The target is absent from the current authoritative thread inventory and is not a local Codex rollout/thread. No database or local file was modified during diagnosis.

The conversation identifier is intentionally redacted here as 6a97ba3b-…-9d43; the full identifier and sanitized log lines can be provided to an OpenAI maintainer through a private channel if needed.

Expected behavior

When GET or DELETE returns terminal conversation_deleted with can_retry=false, Desktop should treat the operation as an idempotent local removal signal and evict the matching local_thread_catalog entry instead of preserving an undeletable sidebar item.

Reproduced on a newer macOS desktop build:

ChatGPT Desktop: 26.901.51231 (build 8109)
Bundled Codex CLI: 0.153.4
macOS 26.5.2 (25F84), Apple Silicon / arm64

Two server-deleted, projectless ChatGPT conversations remained visible as undeletable entries in Recents.

GET /conversation/<id> returned HTTP 404 with errorCode=conversation_deleted and can_retry=false.
Retrying Delete called DELETE /conversation/id/<id> and returned the same terminal 404, while Desktop displayed “Failed to delete chat.”
Both stale references remained in ~/.codex/sqlite/codex-dev.db, table local_thread_catalog, with source_kind=chatgpt and missing_candidate=0.
The authoritative thread reads could not find either conversation.
Resetting the derived ChatGPT thread catalog removed the stale local references; cloud conversations, projects, and local Codex threads were left untouched.

This confirms the bug still exists in build 8109. Desktop should treat terminal conversation_deleted responses as an idempotent local-removal signal and evict the corresponding catalog entry instead of preserving an undeletable Recents item.

Is any workaround for this issue?

My current workaround is to not delete any messages from my iPhone, and only delete from my Mac desktop installation Sent from my iPhoneOn Sep 7, 2026, at 8:21 AM, Christos Chatzaras ***@***.***> wrote:CyberCr33p left a comment (openai/codex#41987) Is any workaround for this issue? —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

I hit this on macOS with ChatGPT Desktop 26.901.51231 (build 8109) and can confirm that targeted local catalogue cleanup fixed it for me.

This affected an ordinary ChatGPT conversation under Recents. I had already deleted it, but its title remained in the desktop sidebar and both Delete and Archive failed. Signing out/in, fully quitting the app, and stopping the ChatGPT/Codex processes did not clear it.

The recovery described in this comment on #39897 matches what worked in my case. The stuck entry was a single row in:

~/.codex/sqlite/codex-dev.db
table: local_thread_catalog
source_kind: chatgpt
missing_candidate: 0

The app's task-list tool did not return this entry, even though it was still visible in the sidebar and present in that catalogue.

After making a SQLite-consistent backup, I removed only the exact matching (host_id, thread_id) catalogue row in a transaction. The repair followed the installed client's applyAuthoritativeRemoval bookkeeping: advancing that host's observation sequence and incrementing local_thread_catalog_metadata.catalog_revision. There was no active scan checkpoint for the affected host; its sync watermark was left unchanged.

Validation:

Exactly 1 stale catalogue row removed; 0 matching rows remaining.
All 92 other catalogue rows compared unchanged.
PRAGMA integrity_check returned ok.
After quitting and reopening ChatGPT, the stuck entry disappeared. I confirmed the sidebar was fixed.

This is a successful recovery of the existing orphan, not evidence that future deletions are fixed. It supports routing already-deleted conversations through the client's local-removal/reconciliation path. Sharing the scoped recovery result here for anyone investigating the bug; I would not clear the entire app database to address this.

I solved the mystery today. Anyone likes to know how to kill the ghost chats reply and I will explain how to get rid of all of them without any side effects on your other chats or information

Not sure why you keep posting the same "I was able to reproduce the issue..." ok so what? Who gives a damn? Fix it

Reporting another macOS desktop case with matching symptoms:

Multiple entries remain in the desktop Recent list, while the user reports that the same entries are absent from ChatGPT Web using the same account.
Opening an affected entry displays exactly: “无法加载此 ChatGPT 对话” (“Unable to load this ChatGPT conversation”), verified from a user-provided screenshot.
The user reinstalled the ChatGPT desktop app; the entries still remain.
Separately, 12 genuine local Codex tasks were successfully archived via the supported app management tool. They disappeared from the user's sidebar screenshot. The remaining affected ChatGPT entries were not returned by list_threads, and their titles were not found among the local Codex task database records. The current Codex task was preserved.

These observations suggest a mismatch between the desktop Recent list and accessible conversation records, but do not establish whether the remaining conversations were deleted, whether this is account/workspace related, or whether stale references are stored locally or remotely.

Please provide a supported way to remove/reconcile inaccessible Recent entries without deleting valid chats or projects, and ensure that app task-management inventory either includes these entries or clearly reports its coverage limitations. A blanket archive/delete-all operation would exceed the desired scope.

No private conversation titles, content, screenshots, account identifiers, or logs are attached.

Additional evidence from another affected macOS user:

The conversation is absent from the ChatGPT web client but remains in the macOS desktop sidebar.
Opening it shows Could not load this ChatGPT conversation.
Archive/Delete fail.
Signing out/in does not clear it.
Quick Chat does not clear it either.

I inspected the desktop app's local SQLite catalog at ~/.codex/sqlite/codex-dev.db. The stale conversation still has a row in local_thread_catalog even though the server-side conversation is gone. Relevant fields for one affected entry:

source_kind        chatgpt
missing_candidate  0
conversation_origin NULL
project_id          NULL

I am omitting the actual thread ID and title here.

This confirms the ghost entry is persisted in the desktop thread catalog rather than being only a UI rendering artifact. The missing_candidate = 0 value may also be useful when tracing why reconciliation does not remove the stale row.

A possible fix is for reconciliation to evict the local catalog entry when the server reports that the conversation no longer exists.

Follow-up to my earlier report, with observations from September 22, 2026.

Environment

ChatGPT/Codex desktop for macOS: 26.915.31945, build 9922
macOS 27.0, Apple Silicon / arm64

Current user-observed behavior

I archived several chats from the desktop app this morning, and later found them back in Recent. This affects multiple ordinary chats, including unpinned chats; it is not limited to a pinned conversation. Repeated archiving has not reliably kept them out of the sidebar. The exact return trigger and delay are not yet known.

This makes routine sidebar cleanup unreliable: conversations deliberately removed from the active list return and need attention again.

Read-only evidence and limits

The app inventory currently includes ordinary ChatGPT conversations in Recent and a pinned ChatGPT conversation that I report repeatedly archiving.
Four separate local Codex archive operations this morning returned without an archive error. Those four task IDs are currently present in the archived inventory and absent from the active inventory. This does not prove that archive persistence works for the returning cloud chats.
Separately, today's desktop logs show GET /conversation/<redacted> and PATCH /conversation/<redacted> returning HTTP 404, conversation_deleted, can_retry=false, for another cloud conversation. That is consistent with the deleted-conversation symptom in this issue, but it does not establish that the archive recurrence has the same cause.
The returning chats have not yet been compared against ChatGPT Web's archived list, and no controlled archive/restart reproduction was performed during this investigation. We cannot yet distinguish an archive mutation that did not persist from a stale desktop sidebar entry.

Expected behavior

After a successful archive, a chat should stay out of Recent and Pinned across refreshes, reconnections, and restarts. Failed archive requests should show a clear error. The app should reconcile terminal conversation_deleted responses without retaining unusable sidebar entries.

Please investigate the ordinary ChatGPT archive path as well as deleted-chat cleanup, and provide a supported way to repair stale entries without deleting valid conversations or resetting the entire app database.

Related archive/restart report: #41214. Similar symptoms do not establish a shared root cause.

No private conversation titles, contents, IDs, account details, filesystem paths, screenshots, or raw logs are attached.

Navigation Menu

Repository navigation

MacOS desktop app keeps undeletable "ghost" conversations in the sidebar after deletion #41987

Environment

Observed behavior

Read-only local confirmation

Expected behavior

Environment

Current user-observed behavior

Read-only evidence and limits

Expected behavior

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

MacOS desktop app keeps undeletable "ghost" conversations in the sidebar after deletion #41987

Description

Activity

github-actions commented on Sep 1, 2026

ck-os-vaults commented on Sep 1, 2026

guimachala commented on Sep 3, 2026

tuipsam commented on Sep 4, 2026

se1961 commented on Sep 5, 2026

dev-kdy commented on Sep 5, 2026

Environment

Observed behavior

Read-only local confirmation

Expected behavior

t1anhe commented on Sep 7, 2026

CyberCr33p commented on Sep 7, 2026

se1961 commented on Sep 7, 2026

0xsiddharthks commented on Sep 7, 2026

mvahedi2020 commented on Sep 8, 2026

gohitbear commented on Sep 12, 2026

jiyeqian commented on Sep 13, 2026

ck-os-vaults commented on Sep 22, 2026

Environment

Current user-observed behavior

Read-only evidence and limits

Expected behavior

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions