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

[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?

Create a regular ChatGPT conversation.
Delete that conversation on the ChatGPT side.
Open ChatGPT Desktop on macOS and inspect the ChatGPT-mode sidebar.
Observe that the deleted conversation remains in the sidebar.
Open the stale conversation.
Observe that GET /conversation/{conversation_id} returns 404 conversation_deleted and the conversation cannot be displayed.
Try to delete the same entry from the sidebar.
Observe that DELETE /conversation/id/{conversation_id} also returns 404 conversation_deleted, while the sidebar entry remains.
Fully quit and relaunch ChatGPT Desktop.
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.

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):

A ChatGPT conversation is deleted from ChatGPT on another device (web/phone).
That conversation had previously been synced into the Codex conversation list (the entry is a remote chatgpt-source thread, not a local Codex task).
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.

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.

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.

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.

Having same issue, please fix, its very annoying, I have about 5 chats same situation on Desktop app Mac and Windows too, no issue on the web. Thanks.!

Powered by Codex & OWL
Version 26.825.32147

Released 28 Aug 2026

no-active-thread-01a048a1-adb0-7e80-94fe-420ef218816d

Additional independent confirmation on macOS. This appears to be the same local catalog reconciliation failure described above.

Symptoms

A regular ChatGPT cloud conversation was deleted from the mobile app.
The conversation was no longer present in the authoritative conversation list.
It nevertheless remained visible under Recents in ChatGPT Desktop.
The normal sidebar removal controls could not remove it because the backing cloud conversation no longer existed.
The stale item was not a normal local Codex task.

Environment

ChatGPT Desktop: 26.818.61809 (build 7019)
macOS: 27.0 (build 26A5421a)
Architecture: Apple Silicon, arm64

What did not work

Removing the stale entry through the normal Desktop sidebar controls.
Refreshing or reloading the sidebar and forcing a fresh conversation listing.
Using the normal Codex thread-management path; no readable Codex thread existed for the stale item.
Checking the legacy com.openai.chat application state was not applicable on this installation because the legacy state locations were not present.

Local diagnosis

The authoritative cloud conversation had already been deleted, and neither the normal Codex thread stores nor the unified thread listing contained the affected item.

However, one stale remote-ChatGPT entry remained in the Desktop catalog with the following relevant state:

table: local_thread_catalog
source_kind = 'chatgpt'
missing_candidate = 0

This appears to leave the Desktop sidebar treating the deleted cloud conversation as present even though the normal conversation and thread APIs can no longer operate on it.

Successful recovery

Backed up the Desktop catalog database.
Verified that exactly one catalog row corresponded to the stale conversation.
Removed only that confirmed stale row from local_thread_catalog.
Incremented local_thread_catalog_metadata.catalog_revision.
Refreshed the Desktop sidebar.
Confirmed that the stale-row count was 0.
Ran a database integrity check and confirmed that it returned ok.

The ghost entry disappeared.

No cookies, authentication state, unrelated conversations, local Codex sessions, or general application data were removed.

Restart and sign-in status

No sign-out/sign-in was performed.
A full application restart was not required after the targeted repair.
Refreshing the sidebar was sufficient.

Recurrence

The stale entry has not reappeared so far, although the observation period is still short.

This database modification should be treated as diagnostic evidence rather than a supported general-purpose workaround, since the internal database schema may change between releases.

At the product level, the expected fix would be for Desktop to remove or mark the corresponding local catalog entry as missing when the authoritative cloud conversation disappears or returns conversation_deleted.

For privacy, this report intentionally omits the conversation title, conversation/thread identifiers, account and user identifiers, local filesystem paths, tokens, cookies, and logs.

Another independent confirmation on macOS, still reproducible on a newer Desktop build.

Environment

ChatGPT Desktop: 26.825.41651 (build 73452)
Bundled app-server: 0.151.0-alpha.7.1
macOS: 27.0 (build 26A5421a)
Architecture: Apple Silicon, arm64

Observed behavior

One already-deleted regular ChatGPT cloud conversation remains visible in the Desktop sidebar.
Opening it returns 404 conversation_deleted with can_retry: false.
Deleting it again also returns 404 conversation_deleted.
Sign-out/sign-in and a complete quit and relaunch do not remove it.

The conversation ID is intentionally redacted: 6a91a50a-…-aac0.

Read-only local confirmation

The stale conversation exists exactly once in:

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

This confirms the same local catalog reconciliation failure described in this issue: the authoritative cloud conversation is already deleted, while the Desktop catalog still treats it as present.

The expected behavior is for conversation_deleted to be treated as an idempotent removal signal and for the corresponding catalog/sidebar entry to be invalidated automatically.

The complete conversation ID, title, account identifiers, and full logs are intentionally omitted from this public comment.

@bc-openai

Still reproducible on version 26.831.21537 as of September 2, 2026; same GET/DELETE → 404 conversation_deleted behavior on Mac and Windows.

@bc-openai , @willwang-openai - sorry for the direct ping. Would you guys mind taking a look or routing this to the appropriate team?

The issue happens if the chat is deleted using the ChatGPT mobile app, or the web app. The deleted conversation still remains permanently visible in the Desktop sidebar, while opening or deleting the stale entry returns 404 conversation_deleted.

At this point it has become very annoying and is cluttering the sidebar with conversations that should no longer exist.

I’ve reported this through Support and Codex feedback as well, but haven’t been able to get it triaged yet. As a paying customer, I’d really appreciate getting this in front of the right team.

Thanks!

Another Android-to-macOS occurrence of the same user-visible stale-Recents issue.

Environment

Codex desktop app 26.825.41651 (build 7345, com.openai.codex)
macOS 26.6.2, Apple silicon
ChatGPT Android app 1.2026.237 on a Samsung Galaxy S24
Same account and workspace on both devices

Observed behaviour

I used Delete on three chats in the ChatGPT Android app.
All three continued to appear in desktop Recents.
Fully quitting and reopening the desktop app did not remove them.

A later limited check did not find the affected entries in the first 50 accessible Recents rows, so their current state is unconfirmed. I did not independently confirm a server-side conversation_deleted response or inspect the local catalog. This confirms the same user-visible issue pattern, but not the documented local root cause.

Chat titles, contents, identifiers, screenshots and logs are intentionally omitted.

Independent confirmation on the current macOS build, with additional catalog-reconciliation evidence.

Environment

ChatGPT/Codex desktop: 26.831.21537 (build 7579)
Bundled Codex CLI: 0.152.1
macOS 26.7 (build 25G224)

Reproduction and observed behavior

Ten ordinary ChatGPT conversations that had already been deleted server-side remained in the unified desktop sidebar.
Opening an affected row returned terminal HTTP 404 with conversation_deleted.
Retrying Delete returned the same 404 conversation_deleted.
Retrying Archive also returned 404 conversation_deleted.
The affected items were absent from the website, so this was not a failed cloud deletion.

Additional local-state evidence

All ten affected IDs remained in:

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

For the ChatGPT catalog source, initial_build_complete was 1, while last_full_reconciled_at was still NULL. The source had continued to advance its observation sequence, but no completed full reconciliation had been recorded.

The desktop delete/archive flow appears to remove the local catalog row only after the remote mutation succeeds. Because the remote object is already deleted, the terminal 404 prevents that local cleanup, and the stale row remains visible. Loading a row and receiving conversation_deleted also did not invalidate it.

Targeted recovery result

After making a verified database backup, deleting only the ten server-confirmed stale chatgpt rows and incrementing local_thread_catalog_metadata.catalog_revision removed them from the running app's thread inventory.

ChatGPT catalog rows: 47 before, 37 after
Local Codex (vscode) rows: 27 before and after
Confirmed stale rows remaining: 0
PRAGMA integrity_check: ok

No ChatGPT content, local Codex threads, authentication state, or general application data was deleted. Conversation IDs, titles, account identifiers, local paths, and raw logs are intentionally omitted from this public comment.

Suggested product behavior

Treat conversation_deleted as an idempotent success for sidebar cleanup and apply the client's authoritative local-removal path. A completed full reconciliation should also prune server-absent rows so the catalog can self-heal even when deletion occurs on another client.

@raniendu

@raniendu , @yszhengys , @chongyangdu2008-cyrus - Would you be willing to provide a step-by-step guide that someone who has no background in software development can follow to resolve this issue on macOS?

Thank you in advance!

Follow-up from the same environment: the issue recurred later the same day on ChatGPT/Codex desktop 26.831.21537 (build 7579).

The ten catalog rows removed in the earlier targeted recovery did not return.
Three different, user-confirmed server-deleted ChatGPT conversations remained as new stale local_thread_catalog rows.
All three still had source_kind = 'chatgpt' and missing_candidate = 0.
The ChatGPT source now had a non-NULL last_full_reconciled_at, so a recorded full reconciliation had occurred, but it did not prevent later deletions from becoming stuck in the local catalog.
A fresh backup and exact-row cleanup removed those three entries; unrelated ChatGPT rows and all local Codex rows were preserved, and PRAGMA integrity_check returned ok.

This recurrence strengthens the case for handling terminal conversation_deleted responses as authoritative local-removal signals rather than relying on a later catalog reconciliation. No conversation titles, IDs, account identifiers, personal paths, or raw logs are included here.

This has been resolved for me as of the latest update on macOS (Version 26.901.22334) 👍

it still exist, i'm on 26.901.22334 MacOs and i have more than 20 orphan conversation, please fix, Thanks!

@vcbrewers

@vcbrewers @mustafa-ramax — I published a small macOS-only Codex skill for this exact ghost-entry case:

https://github.com/chongyangdu2008-cyrus/chatgpt-macos-ghost-entry-repair-skill

If the latest Desktop update has already removed the ghost entries for you, no workaround is needed. If they are still present on macOS, I would not recommend manually copying the SQL snippets from this thread.

The skill is deliberately conservative: it diagnoses the catalog read-only first, refuses to proceed unless it finds exactly one eligible remote ChatGPT row with no local timeline and a healthy database, creates a SQLite-consistent backup, and asks for explicit confirmation immediately before deleting only that confirmed row and incrementing the catalog revision.

For someone without a software background, the simplest route is to use a local Codex/ChatGPT coding-agent session that has shell access:

Ask the agent to install the repository as a Codex skill so that SKILL.md is at ~/.codex/skills/chatgpt-macos-ghost-entry-repair/SKILL.md.
Then tell it something like:

Use $chatgpt-macos-ghost-entry-repair for my undeletable ghost ChatGPT conversation. Inspect only first. Do not modify anything until you show me the sanitized findings and ask for confirmation.
Follow the agent's confirmation step only if all of the skill's safety checks pass.

The repository README contains the installation details. Please keep the real conversation title/IDs and diagnostic output local rather than posting them publicly.

Important scope note: this skill is for macOS + an already-deleted cloud ChatGPT conversation that remains only in Desktop Recents. It should not be used for Windows, local Codex tasks, or conversations that still exist in the cloud.

@chongyangdu2008-cyrus

Thanks mate @chongyangdu2008-cyrus , I appreciate your efforts finding a solution, but I wont spent my tokens and time on a bug belongs to ChatGPT, I'm paying money to OpenAI not to spend on OpenAI! hoping they focus on fixing bugs as much as they're focusing on shipping! Cheers.

Note: I inspected your script (catalog_repair.py), It modifies Codex’s internal database it could work safely, but also it could delete a valid entry or leave inconsistent records as it doesn’t check every related table. So is not worth the risk at least for me :)
So for others I'd say (Use at your own risk) Fully close Codex and make a separate backup first.

I am also affected on macOS, desktop app 26.901.51231 (build 8109), in ChatGPT mode → Recents.

Reproduction

Delete existing ChatGPT conversations on the web.
Observe that the deleted conversations remain in desktop Recents.
Try deleting one of those entries in the desktop app.
The entry temporarily disappears, the app displays “Failed to delete chat”, and the entry reappears.

Sanitized diagnostic findings

Failed delete requests return HTTP 404, error code conversation_deleted, and can_retry: false. The server message is “Conversation has been deleted. Start a new chat.”
A read-only local investigation found three entries with this confirmed server response still marked visible in the desktop SQLite local_thread_catalog table (source_kind = chatgpt, missing_candidate = 0).
Inspection of the installed app's delete handler found that it temporarily hides the entry, awaits the server deletion, and performs catalog/cache cleanup only after that request succeeds. When the already-deleted response throws, cleanup is skipped and the temporary hidden state is cleared. This explains the failed-delete/reappearing-entry loop.

Expected behavior
A structured conversation_deleted response should remove the stale local reference, just like a successful deletion. Genuine authentication/network failures should retain their normal error handling. Deletions made on the web should also be reconciled into desktop Recents.

The initial reason the history became stale remains unconfirmed. No chat contents or titles, conversation/account/session IDs, personal paths, screenshots, or raw logs are included or attached.

Additional confirmed occurrence on Windows, with a localized persistence finding and a user-confirmed workaround.

Environment

Codex desktop app on Windows (platform=win32)
Desktop log release: 26.901.51231
Observed: 2026-09-08
Affected item: an ordinary ChatGPT conversation displayed in Recents, not a local Codex task.

Observed behavior

The conversation was absent from ChatGPT Web but remained in the desktop sidebar. Delete displayed Failed to delete chat; archive displayed Failed to archive conversation. Fully quitting/restarting the app and signing out/back in did not remove the entry. The original event that caused the stale entry was not captured, so this is a diagnosed occurrence rather than a deterministic fresh-account reproduction.

Sanitized desktop logs show both operations returning the same terminal server state:

2026-09-08T00:45:57.877Z DELETE /conversation/id/<redacted> -> 404 conversation_deleted
2026-09-08T00:48:27.109Z DELETE /conversation/id/<redacted> -> 404 conversation_deleted
2026-09-08T00:50:27.669Z PATCH /conversation/<redacted> -> 404 conversation_deleted

{"detail":{"message":"Conversation has been deleted. Start a new chat.","code":"conversation_deleted","can_retry":false}}

Concrete local persistence finding

The affected ID and matching title were still present in:

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

A read-only query by the affected thread_id returned exactly one matching catalog row. local_thread_catalog_scan_entries had no matching row. The app's list_threads tool did not return the affected conversation even while the sidebar continued to show it.

Verified remediation in this occurrence

After backing up the single matching catalog record, we removed only that row (constrained by both host_id and thread_id) in a SQLite transaction and incremented local_thread_catalog_metadata.catalog_revision. Verification showed exactly one row removed, zero remaining matches, and PRAGMA quick_check returned ok. Other catalog rows were preserved. The user then confirmed the problem was resolved.

This is diagnostic evidence, not a recommendation for general users to edit app databases. It demonstrates that a stale local catalog record was sufficient to sustain this occurrence; it does not establish why initial synchronization failed or exclude an upstream index issue.

Expected handling / investigation suggestions

Reconcile the local catalog and sidebar when the server returns terminal conversation_deleted with can_retry:false.
Treat an already-deleted response to Delete as successful local cleanup rather than leave an unremovable entry.
Ensure catalog reconciliation on restart/sign-in converges with server deletion state.
Add regression coverage for ChatGPT-source catalog entries whose delete/archive requests encounter this terminal response.

Conversation title/content, complete conversation ID, account/user identifiers, personal filesystem paths, and unrelated logs have been omitted from this public report.

Additional Windows confirmation, with a located persistence source and a successful targeted local recovery.

Environment and symptoms

Observed on 2026-09-09.
Windows packaged desktop app; inspected package/log version: 26.901.6511.0.
Five ordinary ChatGPT conversations remained visible in the desktop sidebar but were absent from ChatGPT Web.
Opening and deleting sampled affected conversations returned HTTP 404 with code=conversation_deleted and can_retry=false.
Moving the entries into a custom sidebar section worked. Trying to pin an affected entry reported that the conversation had been deleted.
Sign-out/sign-in, rebooting Windows, and renaming the ordinary Chromium Cache directory did not resolve the problem.

Sanitized request evidence:

GET /conversation/<redacted> -> 404 conversation_deleted
DELETE /conversation/id/<redacted> -> 404 conversation_deleted

Persistence source found on this installation

All five affected IDs and their titles were present in:

$CODEX_HOME/sqlite/codex-dev.db
table: local_thread_catalog
source_kind: chatgpt
host_id: chatgpt:<account>:<user>

After the entries were moved into a custom section, five corresponding chatgpt:conversation:<id> references were also present in:

$CODEX_HOME/.codex-global-state.json
electron-persisted-atom-state -> sidebar-custom-sections-v3

This is separate from state_5.sqlite and ordinary session rollout files. Finding an ID in HTTP cache was only evidence of a cached request URL, not proof that the cache held the stale sidebar catalog.

Client-code observation

Read-only inspection of the installed bundle showed the deletion path awaiting the remote delete before performing local catalog/sidebar removal and query invalidation. In that path, a rejected delete skips cleanup; the sidebar catch displays “Failed to delete chat.” The inspected deletion function did not specially handle conversation_deleted.

The bundle also contains an authoritative missing-entry removal path that deletes a catalog entry, updates its revision/observation state, and accounts for scan tombstones. This suggests that explicit server deletion responses could be routed through that existing cleanup mechanism.

Targeted recovery and outcome

With the desktop app fully exited, a backed-up, ID/account/type/title-validated cleanup removed exactly five catalog rows and five custom-section references, updating catalog bookkeeping. Copy-based tests verified 31 -> 26 catalog rows, preservation of unrelated rows/settings, idempotency, and rollback on a simulated write failure. The actual cleanup recorded five rows and five references removed. After reopening the app, the user confirmed that the stale entries were gone.

This was a local recovery, not a client patch or a general recommendation to edit databases. It does not establish why the stale entries were originally retained, whether remote list reconciliation also contributed, or whether future synchronization could recreate them.

Suggested fix

Treat the explicit terminal conversation_deleted response as successful local removal for an already-deleted conversation; reconcile the catalog, custom-section references, and query state. Do not treat arbitrary 404/403 or network failures as deletion success. Add coverage for this case and for persistence across restart/full catalog scans.

Conversation titles, full IDs, account identifiers, usernames, and raw logs are intentionally omitted.

Additional confirmation on macOS with ChatGPT/Codex Desktop 26.903.61454 (build 8378), observed on September 10, 2026.

A regular ChatGPT conversation deleted on the website remained in the desktop conversation list. Opening it and attempting to delete it again both failed.

Read-only diagnostics confirmed:

GET /conversation/{id} and DELETE /conversation/id/{id} both returned HTTP 404 with code: conversation_deleted and can_retry: false.
The same conversation ID and matching title remained in ~/.codex/sqlite/codex-dev.db, table local_thread_catalog, with source_kind = 'chatgpt' and missing_candidate = 0.
The desktop list_threads tool did not return the affected conversation, despite the residual catalog row.
Inspection of the installed client bundle showed that the delete handler awaits the remote delete before removing the local catalog entry and query/cache state. A rejected already-deleted response skips those cleanup steps.

Expected: Treat an explicit terminal conversation_deleted response as an authoritative signal to remove the stale local entry, while preserving normal error handling for unrelated 404, authentication, or network errors. Deletions made on another client should also be reconciled into the desktop catalog.

No local conversation database modifications were made. Conversation titles, complete IDs, account identifiers, and raw logs are omitted.

Additional Windows observation, recorded on 2026-08-22. This is historical evidence, not a claim of a fresh reproduction on today's build.

Environment: Store package 26.818.5229.0, app-server 0.149.0-alpha.4.1, Windows 11 Pro 25H2, build 26200.8037.

A regular cloud ChatGPT conversation remained visible in the Desktop sidebar. Opening it and trying to delete the stale entry both returned HTTP 404, conversation_deleted, with can_retry=false. It was not a local Codex session. A separate healthy conversation remained readable, and the diagnosis found no general network/authentication failure.

A later native conversation listing stopped returning the affected entry. We did not establish when the visible sidebar converged, and did not modify the internal database or conversation state to repair it.

Expected: an explicit terminal conversation_deleted response should reconcile the stale local entry; an already-deleted response to Delete should not leave the user in a repeated error loop. This should not be generalized to arbitrary 404 or authentication/network failures.

The reason the cloud object was deleted is unknown. An update preceded the observation, but update causality is not established. Conversation title/content, identifiers, personal paths, screenshots and raw logs are omitted.

You can close this issue, it fixed on MacOS and Windows build Version 26.908.40834 Released Sep 12, 2026, Thanks team!

If anyone still facing this issue, make sure to restart your device, update to last build, and delete any orphan chat, wait a bit it will go forever. Cheers!

Additional reproduction on ChatGPT desktop for macOS 26.903.71938 (build 8576), bundle ID com.openai.codex, macOS 27.0, observed on 13 September 2026.

Deleted cloud-marked conversations remain in the desktop Recents sidebar. Attempting to delete them displays “Failed to delete chat.” Archiving also fails according to the user. They are absent from the phone and browser; browser inspection confirmed an empty chat sidebar and “You have no archived conversations.” Local Codex/Work tasks remain accessible.

Restarting the app and signing out/in did not resolve this. No app cache or task database was modified during this investigation.

Sanitized diagnostics from the desktop logs:

2026-09-13 08:36:28.718 UTC — DELETE /conversation/id/{redacted} → HTTP 404
2026-09-13 08:37:08.499 UTC — GET /conversation/{redacted} → HTTP 404
2026-09-13 08:37:13.140 UTC — DELETE /conversation/id/{redacted} → HTTP 404
errorCode: conversation_deleted
message: Conversation has been deleted. Start a new chat.
can_retry: false

Earlier deletion attempts at 08:14–08:15 UTC also recorded net::ERR_NETWORK_CHANGED, but later requests explicitly returned conversation_deleted for at least two affected conversations.

Expected: the desktop sidebar should reconcile already-deleted conversations and remove those entries. If a supported recovery is available, it should preserve local tasks, projects, and settings.

This report intentionally excludes conversation titles, contents, IDs, screenshots, and raw logs.

@HissingAngryCat

@HissingAngryCat , Solved on MacOS and Windows build Version 26.908.40834 Released Sep 12, 2026.

If you still facing this issue, make sure to restart your device, update to last build, and if you see any orphan chat just click on delete, wait a bit it will go forever. Cheers!

Additional user report (2026-10-19): On ChatGPT Desktop for macOS, conversations deleted long ago still appear in the desktop sidebar. Opening these entries shows an empty conversation, while the same deleted conversations are correctly absent from chatgpt.com in a browser. Fully quitting/relaunching and reinstalling the desktop app have not resolved this. The suggested “Open in Quick Chat” workaround also failed. Please ensure the desktop history/sidebar reconciles server-side deletions and can remove an orphaned entry when the conversation no longer exists remotely. No private conversation titles or IDs are included in this report; exact app/macOS version was not provided.

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

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

Septuagint0201 commented on Aug 21, 2026

xihangzou commented on Aug 24, 2026

Environment

Observed behavior

Local diagnosis

Expected reconciliation

yangqoor commented on Aug 25, 2026

Observed behavior

Local diagnosis

Targeted recovery

Suggested product behavior

vcbrewers commented on Aug 27, 2026

mustafa-ramax commented on Aug 28, 2026

chongyangdu2008-cyrus commented on Aug 28, 2026

Symptoms

Environment

What did not work

Local diagnosis

Successful recovery

Restart and sign-in status

Recurrence

yszhengys commented on Aug 29, 2026

Environment

Observed behavior

Read-only local confirmation

mustafa-ramax commented on Sep 2, 2026

matthewlowdon commented on Sep 2, 2026

Environment

Observed behaviour

raniendu commented on Sep 2, 2026

Environment

Reproduction and observed behavior

Additional local-state evidence

Targeted recovery result

Suggested product behavior

vcbrewers commented on Sep 2, 2026

raniendu commented on Sep 2, 2026

vcbrewers commented on Sep 3, 2026

mustafa-ramax commented on Sep 3, 2026

chongyangdu2008-cyrus commented on Sep 4, 2026

mustafa-ramax commented on Sep 4, 2026

d0gx commented on Sep 7, 2026

Feynman2021 commented on Sep 8, 2026

Environment

Observed behavior

Concrete local persistence finding

Verified remediation in this occurrence

Expected handling / investigation suggestions

jasonma888 commented on Sep 9, 2026

Environment and symptoms

Persistence source found on this installation

Client-code observation

Targeted recovery and outcome

Suggested fix

linq0016 commented on Sep 10, 2026

aidawilliam41-ops commented on Sep 10, 2026

mustafa-ramax commented on Sep 13, 2026

HissingAngryCat commented on Sep 13, 2026

mustafa-ramax commented on Sep 16, 2026

adamklatovsky commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions