›_ Codex Issues
Codex Issues / #39897

[ChatGPT Desktop][macOS] Deleted ChatGPT conversation remains in sidebar and cannot be removed

Open 💬 4 comments Opened Aug 21, 2026 by tndd

[Codex]

What version of the Codex App are you using (From “About Codex” dialog)?

ChatGPT Desktop 26.818.31338 (build 6892)

Bundled Codex CLI: 0.149.0-alpha.4

What subscription do you have?

ChatGPT Plus

What platform is your computer?

macOS 15.7.9 (build 24G830)

Darwin 24.6.0 arm64 arm

What issue are you seeing?

A regular ChatGPT conversation that has already been deleted on the ChatGPT side remains permanently visible in the unified ChatGPT Desktop sidebar.

This is a normal ChatGPT cloud conversation, not a local Codex task or thread.

Opening the stale sidebar entry causes the ChatGPT backend to return:

{
  "detail": {
    "message": "The conversation has been deleted. Please start a new conversation.",
    "code": "conversation_deleted",
    "can_retry": false,
    "conversation_id": "6a87292c-…-5de1"
  }
}

The observed request is:

GET /conversation/{conversation_id}
status: 404
code: conversation_deleted

Trying to delete the entry again from the desktop sidebar sends another request that returns the same error:

DELETE /conversation/id/{conversation_id}
status: 404
code: conversation_deleted

The conversation itself is therefore already deleted, but the sidebar entry remains visible and can neither be opened nor removed.

Fully quitting and relaunching ChatGPT Desktop does not clear the entry.

What steps can reproduce the bug?

  1. Create a regular ChatGPT conversation.
  2. Delete that conversation on the ChatGPT side.
  3. Open ChatGPT Desktop on macOS and inspect the ChatGPT-mode sidebar.
  4. Observe that the deleted conversation remains in the sidebar.
  5. Open the stale conversation.
  6. Observe that GET /conversation/{conversation_id} returns 404 conversation_deleted and the conversation cannot be displayed.
  7. Try to delete the same entry from the sidebar.
  8. Observe that DELETE /conversation/id/{conversation_id} also returns 404 conversation_deleted, while the sidebar entry remains.
  9. Fully quit and relaunch ChatGPT Desktop.
  10. Observe that the deleted conversation is still present in the sidebar.

In this reproduction, the app launched as a new process at:

2026-08-21 18:07:27 JST

The delete attempt after relaunch still failed:

2026-08-21 18:07:45 JST
DELETE /conversation/id/{conversation_id}
404 conversation_deleted

Later attempts to open the entry returned the same result:

2026-08-21 18:12:03 JST
GET /conversation/{conversation_id}
404 conversation_deleted

2026-08-21 18:14:30 JST
GET /conversation/{conversation_id}
404 conversation_deleted

What is the expected behavior?

Deleting a ChatGPT conversation should also remove it from the ChatGPT Desktop sidebar.

If loading a sidebar entry returns conversation_deleted, the client should invalidate the stale conversation-list entry and remove it from the sidebar.

A DELETE request that returns conversation_deleted because the conversation is already gone should also be treated as an idempotent success for the UI, allowing the stale sidebar entry to be removed.

Additional information

I inspected the local state read-only. The affected ChatGPT conversation ID does not exist in any of these Codex local-thread stores:

~/.codex/state_5.sqlite
~/.codex/session_index.jsonl
~/.codex/.codex-global-state.json

The threads table in state_5.sqlite contains zero rows matching the affected ID.

The ChatGPT sidebar persisted atom, chatgpt-sidebar-state-v1, also contains no entry for this conversation.

This therefore does not appear to be a stale local Codex thread. The stale reference is more likely retained in one of these places:

  • the ChatGPT conversation-history/sidebar index;
  • the ChatGPT Desktop conversation-list query/cache; or
  • the client-side invalidation path for conversation_deleted responses.

The public report intentionally omits the conversation title and the complete conversation ID. The complete ID and a sanitized relevant log excerpt can be provided privately if needed.

I checked related reports before filing. Issue #28095 concerns deletion of archived local Codex threads, and Issue #38965 concerns a Realtime Voice-created Codex orphan thread with missing rollout state. This report concerns a regular ChatGPT cloud conversation and a different persistence path.

View original on GitHub ↗

4 Comments

Septuagint0201 · 7 days ago

Same root cause here, with one more variant: the stale entry also shows up in the Codex conversation list as a ChatGPT-synced conversation, not only in the regular ChatGPT sidebar.

Reproduction (ChatGPT Desktop 26.818.21641 build 6849, macOS 26.6.2):

  1. A ChatGPT conversation is deleted from ChatGPT on another device (web/phone).
  2. That conversation had previously been synced into the Codex conversation list (the entry is a remote chatgpt-source thread, not a local Codex task).
  3. The stale entry remains in the list permanently. Opening it fails with 404 conversation_deleted; deleting it from the list also fails with 404 conversation_deleted. Quitting and relaunching the app does not clear it.

Local state (macOS): the ghost entry is cached in the Codex local thread catalog used for the conversation list — ~/.codex/sqlite/codex-dev.db, table local_thread_catalog (source_kind = 'chatgpt', host_id = 'chatgpt:<account-id>:<user-id>'). The server-side deletion is never propagated to this table, and since the remote conversation is already gone, the app's own removal path for the entry cannot succeed either, so the UI can never dismiss it.

Workaround (until fixed): quit the app, back up the DB, then remove the stale row and advance the host's sync watermark so the next incremental sync does not re-import it:

DELETE FROM local_thread_catalog
 WHERE host_id = 'chatgpt:<account-id>:<user-id>'
   AND thread_id = '<stale thread id>';

UPDATE local_thread_catalog_sync_state
   SET watermark_updated_at = strftime('%s','now')
 WHERE host_id = 'chatgpt:<account-id>:<user-id>';

Suggested fix: propagate server-side conversation deletions to the local thread catalog (and the sidebar), and allow dismissing stale synced entries even when the remote conversation already returns 404.

xihangzou · 3 days ago

Confirmed on macOS with a newer ChatGPT Desktop build, with a more specific local persistence source and a successful targeted recovery.

Environment

  • ChatGPT Desktop: 26.818.61809 (build 7019)
  • macOS: 26.5.2 (build 25F84)
  • Affected items: two regular ChatGPT cloud conversations

Observed behavior

  • Both conversations had already been deleted server-side.
  • Neither appeared in ChatGPT on the web.
  • Both remained in the desktop Recents sidebar.
  • Selecting either stale row failed because the conversation no longer existed.
  • Full app restart, sign-out/sign-in, and rebuilding the normal app cache did not remove them.

The full conversation IDs and titles are intentionally omitted from this public comment.

Local diagnosis

The affected IDs had no normal Codex backing thread:

  • no matching row in ~/.codex/state_5.sqlite (threads)
  • the desktop thread reader returned No Codex thread found
  • the unified thread listing did not return either item

However, both stale entries were present in:

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

So these were orphaned ChatGPT catalog rows: the authoritative conversation was gone, but the local unified-sidebar catalog still treated each row as present.

Removing only the two affected rows from local_thread_catalog, incrementing local_thread_catalog_metadata.catalog_revision, and refreshing the renderer removed both ghost entries. The result persisted after refresh. No cookies, login state, unrelated chats, or general application data were cleared. A database backup was made first.

Removing the IDs from the sidebar-order atom alone did not fix the issue. This suggests the stale source is the local thread catalog reconciliation path rather than the normal HTTP cache or sidebar ordering state.

Expected reconciliation

When a ChatGPT conversation disappears from the authoritative conversation list, or loading it returns conversation_deleted, its local_thread_catalog row should be marked missing and removed. An already-deleted response should be treated as an idempotent success for sidebar cleanup.

This comment documents the database change as diagnostic evidence, not as a recommended end-user workaround.

yangqoor · 3 days ago

Windows reproduction, sanitized.

I can confirm the same stale ChatGPT conversation behavior on Windows 11 x64 in ChatGPT/Codex Desktop.

Observed behavior

  • A regular ChatGPT cloud conversation had already been deleted / was no longer returned by ChatGPT on the web.
  • The same item remained visible in the Desktop unified sidebar / conversation list.
  • The stale item could no longer be opened or meaningfully acted on from Desktop.
  • Restarting the Desktop app did not remove the stale entry.

Local diagnosis

The affected item was not a normal local Codex task. The stale record was present in the Desktop catalog database:

%USERPROFILE%\.codex\sqlite\codex-dev.db

Relevant table/state:

local_thread_catalog
source_kind = chatgpt
host_id = chatgpt:<redacted>
missing_candidate = 0

This is separate from the local Codex rollout/thread store (state_5.sqlite). In this case, the stale sidebar item was tied to the Desktop catalog rather than a missing or corrupt local rollout.

Targeted recovery

After fully quitting ChatGPT/Codex Desktop and backing up codex-dev.db, removing only the confirmed stale chatgpt catalog row(s) cleared the ghost entry from the sidebar. No local Codex rollout JSONL files were moved or deleted, and state_5.sqlite was not modified.

This strongly matches the catalog-reconciliation failure described above: the authoritative ChatGPT conversation is already gone, but the local Desktop catalog still treats the item as present.

Suggested product behavior

When a ChatGPT conversation disappears from the authoritative list, or opening/deleting it returns conversation_deleted, Desktop should treat that as an idempotent removal signal and invalidate the corresponding local_thread_catalog entry instead of leaving an undeletable ghost row.

I have intentionally omitted conversation titles, thread/conversation IDs, account/user identifiers, local project paths, logs, tokens, cookies, and other private data.

vcbrewers · 13 hours ago

Environment:

  • macOS 27 Dev Beta running on M1 Pro
  • ChatGPT Version 26.820.80927

Issue

  • 4 Stale/Orphaned Entries in Recents Records on macOS desktop app.
  • Each conversation was deleted via iOS or the web client and is no longer showing on any other platform.
  • Updating, restarting, and signing out/in did not clear them.