[macOS][Chat] Server-deleted conversations repopulate in Recents and cannot be removed

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

ChatGPT unified desktop app 26.818.41705 (build 6971).

What subscription do you have?

Paid individual ChatGPT plan.

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

Product / surface

Unified ChatGPT desktop app for macOS
Chat tab / ordinary ChatGPT conversations
Not Work mode
Not Codex mode

Dozens of conversations that have already been deleted server-side remain or repopulate as stale entries in the macOS Recents sidebar. The same account is clean on chatgpt.com and mobile: the deleted conversations are absent there.

The stale macOS entries cannot be opened, deleted, or archived:

Open: GET /conversation/<redacted-id> returns HTTP 404.
Delete: DELETE /conversation/id/<redacted-id> returns HTTP 404 and the UI shows Failed to delete chat.
Archive/unarchive: PATCH /conversation/<redacted-id> returns HTTP 404 and the UI shows Failed to archive conversation.

Every sampled response is terminal and consistent:

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

Four distinct affected conversation entries were captured in the desktop logs; all four returned conversation_deleted. The sidebar contains dozens of affected entries in total.

Controlled comparison

Client / surface	Result
`chatgpt.com` web, same account	Deleted conversations are absent
Mobile app, same account	Deleted conversations are absent
macOS unified desktop app → Chat → Recents	Dozens of deleted titles remain/repopulate

This does not look like ordinary local cache residue. After Cache, Local Storage, Session Storage, and cookies were removed and the app was fully restarted, the clean client subscribed to the remote conversations and alder-conversations topics. The deleted titles then repopulated in Recents and continued returning the same terminal 404 responses.

The evidence suggests a stale remote Recents/conversation-index entry or a missing tombstone-reconciliation path in the macOS client. This is an inference from the comparison and logs, not a confirmed root cause.

What steps can reproduce the bug?

Delete ordinary ChatGPT conversations so that they are no longer present on the server-facing web and mobile clients.
Confirm that the conversations are absent on chatgpt.com and mobile using the same account.
Open the unified ChatGPT desktop app on macOS and select Chat.
Observe that deleted conversation titles remain or repopulate under Recents.
Select an affected entry. It does not open; the request returns 404 conversation_deleted.
Try Delete. The app shows Failed to delete chat, and the DELETE request returns the same terminal 404.
Try Archive. The app shows Failed to archive conversation, and the PATCH request returns the same terminal 404.
Fully quit the app, remove its Cache, Local Storage, Session Storage, and cookies, then restart it.
Observe that the clean app subscribes to the remote conversation topics and the same deleted titles repopulate.

Reproduction rate for the four sampled entries: 4/4. The issue has persisted through sign-out/sign-in, full app restarts, and local web-storage/cache removal.

What is the expected behavior?

Server-deleted conversations should not remain in or repopulate the macOS Recents list.

If a stale Recents entry resolves to the terminal conversation_deleted response, the client/index reconciliation path should remove that entry. Delete or archive requests that encounter this tombstone could be treated as an idempotent cleanup success for the sidebar instead of leaving an undeletable entry and displaying a retryable-looking failure toast.

The Recents index should converge with the authoritative conversation state used by web and mobile.

Additional information

Sanitized diagnostic excerpt

2026-08-23T07:14:11.162Z
method=DELETE
route=/conversation/id/<conversation-A>
status=404
response={"message":"Conversation has been deleted. Start a new chat.","code":"conversation_deleted","can_retry":false}

2026-08-23T07:14:23.279Z
method=GET
route=/conversation/<conversation-A>
status=404
response={"message":"Conversation has been deleted. Start a new chat.","code":"conversation_deleted","can_retry":false,"conversation_id":"<redacted>"}

2026-08-23T07:14:31.367Z
method=GET
route=/conversation/<conversation-B>
status=404
response={"message":"Conversation has been deleted. Start a new chat.","code":"conversation_deleted","can_retry":false,"conversation_id":"<redacted>"}

2026-08-23T07:14:34.224Z
method=GET
route=/conversation/<conversation-C>
status=404
response={"message":"Conversation has been deleted. Start a new chat.","code":"conversation_deleted","can_retry":false,"conversation_id":"<redacted>"}

2026-08-23T07:15:40.460Z and 2026-08-23T07:15:43.057Z
method=PATCH (archive/unarchive attempts)
route=/conversation/<conversation-A>
status=404
response={"message":"Conversation has been deleted. Start a new chat.","code":"conversation_deleted","can_retry":false}

2026-08-23T07:54:37.619Z
method=DELETE
route=/conversation/id/<conversation-D>
status=404
response={"message":"Conversation has been deleted. Start a new chat.","code":"conversation_deleted","can_retry":false}

2026-08-23T07:56:16.479Z
event=chatgpt_pubsub_topic_subscribed
topicId=conversations
catchupCount=0
hadPreviousOffset=false
recovered=false

2026-08-23T07:56:16.479Z
event=chatgpt_pubsub_topic_subscribed
topicId=alder-conversations
catchupCount=0
hadPreviousOffset=false
recovered=false

Troubleshooting already completed

Verified the same single account is used on macOS, web, and mobile.
Verified web and mobile do not show the affected conversations.
Signed out and back in.
Fully quit and restarted the desktop app.
Removed desktop Cache, Local Storage, Session Storage, and cookies, then performed a clean restart.
Retested open, delete, and archive against multiple distinct entries.
Did not modify or delete local Codex projects or ~/.codex session data; the affected items are ordinary Chat conversations.

Public-report privacy

Conversation IDs, titles, contents, account identifiers, email addresses, local paths, log filenames, cookies, tokens, and unrelated events are intentionally omitted. Exact affected IDs and a fuller sanitized diagnostic excerpt have been supplied privately to OpenAI Support. A support case is open and its number can be provided privately.

Related but not duplicate

[macOS][Chat] Existing conversations can get stuck loading in desktop app while the same chat loads normally on web #37580 reports ordinary Chat conversations stuck loading on macOS while they remain valid on web. Here the conversations are already deleted server-side, web/mobile are clean, and the macOS Recents index continues surfacing tombstoned entries.
Failed to archive conversation + seeing threads that do not have any reason for existing? #28276 reports a generic archive failure involving unexpected Codex/Desktop threads. Here the affected items are ordinary Chat conversations and all operations fail with the specific server response conversation_deleted.

Useful fixes would include:

reconciling Recents against conversation-deletion tombstones;
removing a stale entry when open/delete/archive receives terminal conversation_deleted with can_retry:false; and
exposing an explicit Recents refresh/rebuild path if automatic reconciliation cannot converge.

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

[ChatGPT Desktop][macOS] Deleted ChatGPT conversation remains in sidebar and cannot be removed #39897
Windows desktop keeps already-deleted ChatGPT conversations in Recents after full restart #39989

Powered by Codex Action

I have the same problem after the update.

I’m seeing the same issue on macOS. A normal ChatGPT web conversation was deleted successfully and is gone from chatgpt.com and search, but it remains as an orphaned entry in the desktop app’s Recents list.

I’ve already tried sign-out/sign-in, reinstalling the app, and removing Cache, HTTP storage, Local Storage, and Session Storage. The orphan entry remains/reappears.

This appears consistent with the stale remote Recents/index behavior described in this issue.

Sure — I’m seeing the exact same behavior here. The deleted conversation is gone from the web app and search, but it still remains in the macOS desktop Recents list even after reinstalling and clearing local storage/cache.

So this also looks like a stale remote Recents/index sync issue rather than a local cache problem. I suspect we’ll probably have to wait for a desktop app update to fix it.

I also haven’t tried switching back to the Classic version yet, so I can’t confirm whether the issue appears there as well.

Quick update: I’ve now tested ChatGPT Classic on the same Mac/account.

The orphaned deleted conversations do not appear there — the Recents list looks normal in Classic. So at least in my case, the issue seems specific to the new macOS desktop app / its Recents implementation, rather than the account’s normal chat history itself.

same issue, only on unified desktop, not on classic.

Update: confirmed local catalog persistence and repeatable workaround

I have now reproduced and repaired this several times on the same Mac/account. The issue is still present on ChatGPT Desktop 26.820.60940 (build 7119).

Confirmed finding

The affected ChatGPT entries are present in the unified app's local conversation catalog:

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

The exact IDs that returned 404 conversation_deleted were found as source_kind='chatgpt' rows in this table. This explains why clearing Electron Cache, Local Storage, Session Storage, HTTP storage, and cookies did not help: those operations do not clear this catalog.

The issue has recurred across multiple cleanup/restart cycles, with different batches of locally cataloged ChatGPT rows (including batches of 19, 4, 9, 8, and 24). The local cleanup succeeds, but startup/full or incremental sync can repopulate entries. Rows for conversations that still legitimately exist on the server are expected to return; the bug is that terminally deleted conversations can return or remain as undeletable ghost entries too.

Workaround that cleared the UI

This is an unsupported local workaround, not a product fix. Fully quit the unified ChatGPT app before modifying the database, and back up the database first if the local catalog matters to you.

For one confirmed-deleted conversation, the narrow form is:

BEGIN IMMEDIATE;

DELETE FROM local_thread_catalog
 WHERE source_kind = 'chatgpt'
   AND host_id LIKE 'chatgpt:%'
   AND thread_id = '<confirmed-deleted-conversation-id>';

UPDATE local_thread_catalog_sync_state
   SET watermark_updated_at = CAST(strftime('%s','now') AS REAL),
       last_full_reconciled_at = CAST(strftime('%s','now') AS INTEGER) * 1000,
       initial_build_complete = 1
 WHERE host_id LIKE 'chatgpt:%';

COMMIT;

In this account the intended Chat Recents list was empty, so the bulk variant used was:

BEGIN IMMEDIATE;

DELETE FROM local_thread_catalog
 WHERE source_kind = 'chatgpt'
   AND host_id LIKE 'chatgpt:%';

UPDATE local_thread_catalog_sync_state
   SET watermark_updated_at = CAST(strftime('%s','now') AS REAL),
       last_full_reconciled_at = CAST(strftime('%s','now') AS INTEGER) * 1000,
       initial_build_complete = 1
 WHERE host_id LIKE 'chatgpt:%';

COMMIT;

Important behavior observed during verification:

The app must actually be fully stopped; deleting while its process remains active is not sufficient for a reliable cleanup.
After one restart, the initial sync repopulated a smaller subset. Waiting for that sync to finish and removing the remaining source_kind='chatgpt' rows produced a stable count of zero during the verification window.
PRAGMA integrity_check returned ok after each repair.
Rows from other sources remained unchanged; local Codex/VS Code tasks and rollout/session files were not deleted.
This only removes local catalog entries. A valid conversation that still exists server-side can be imported again. The workaround is most useful for entries already confirmed as terminally deleted by conversation_deleted, can_retry:false.

Likely missing product behavior

The desktop synchronization/reconciliation path should propagate conversation-deletion tombstones into local_thread_catalog. In addition:

GET, DELETE, or PATCH returning 404 conversation_deleted with can_retry:false should invalidate and dismiss the corresponding local row;
the delete action should be idempotent from the UI's perspective when the remote object is already gone; and
full/incremental sync should not resurrect a tombstoned conversation.

This finding is consistent with #39897, but the repeated cleanup cycles here also demonstrate the interaction between the local catalog, sync watermarks, restart-time repopulation, and the need for a second reconciliation pass in some cases.

No conversation IDs, titles, account/user IDs, email addresses, tokens, cookies, or personal paths are included in this update.

Same issue here.

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.

Update: confirmed local catalog persistence and repeatable workaround

I have now reproduced and repaired this several times on the same Mac/account. The issue is still present on ChatGPT Desktop 26.820.60940 (build 7119).

Confirmed finding

The affected ChatGPT entries are present in the unified app's local conversation catalog:
~/.codex/sqlite/codex-dev.db
table: local_thread_catalog
source_kind: chatgpt
host_id: chatgpt:<redacted-account>:<redacted-user>
The exact IDs that returned 404 conversation_deleted were found as source_kind='chatgpt' rows in this table. This explains why clearing Electron Cache, Local Storage, Session Storage, HTTP storage, and cookies did not help: those operations do not clear this catalog.

The issue has recurred across multiple cleanup/restart cycles, with different batches of locally cataloged ChatGPT rows (including batches of 19, 4, 9, 8, and 24). The local cleanup succeeds, but startup/full or incremental sync can repopulate entries. Rows for conversations that still legitimately exist on the server are expected to return; the bug is that terminally deleted conversations can return or remain as undeletable ghost entries too.

Workaround that cleared the UI

This is an unsupported local workaround, not a product fix. Fully quit the unified ChatGPT app before modifying the database, and back up the database first if the local catalog matters to you.

For one confirmed-deleted conversation, the narrow form is:

BEGIN IMMEDIATE;

DELETE FROM local_thread_catalog
WHERE source_kind = 'chatgpt'
AND host_id LIKE 'chatgpt:%'
AND thread_id = '';

UPDATE local_thread_catalog_sync_state
SET watermark_updated_at = CAST(strftime('%s','now') AS REAL),
last_full_reconciled_at = CAST(strftime('%s','now') AS INTEGER) * 1000,
initial_build_complete = 1
WHERE host_id LIKE 'chatgpt:%';

COMMIT;

In this account the intended Chat Recents list was empty, so the bulk variant used was:

BEGIN IMMEDIATE;

DELETE FROM local_thread_catalog
WHERE source_kind = 'chatgpt'
AND host_id LIKE 'chatgpt:%';

UPDATE local_thread_catalog_sync_state
SET watermark_updated_at = CAST(strftime('%s','now') AS REAL),
last_full_reconciled_at = CAST(strftime('%s','now') AS INTEGER) * 1000,
initial_build_complete = 1
WHERE host_id LIKE 'chatgpt:%';

COMMIT;

Important behavior observed during verification:
1. The app must actually be fully stopped; deleting while its process remains active is not sufficient for a reliable cleanup.

2. After one restart, the initial sync repopulated a smaller subset. Waiting for that sync to finish and removing the remaining `source_kind='chatgpt'` rows produced a stable count of zero during the verification window.

3. `PRAGMA integrity_check` returned `ok` after each repair.

4. Rows from other sources remained unchanged; local Codex/VS Code tasks and rollout/session files were not deleted.

5. This only removes local catalog entries. A valid conversation that still exists server-side can be imported again. The workaround is most useful for entries already confirmed as terminally deleted by `conversation_deleted`, `can_retry:false`.
Likely missing product behavior

The desktop synchronization/reconciliation path should propagate conversation-deletion tombstones into local_thread_catalog. In addition:
* `GET`, `DELETE`, or `PATCH` returning `404 conversation_deleted` with `can_retry:false` should invalidate and dismiss the corresponding local row;

* the delete action should be idempotent from the UI's perspective when the remote object is already gone; and

* full/incremental sync should not resurrect a tombstoned conversation.
This finding is consistent with #39897, but the repeated cleanup cycles here also demonstrate the interaction between the local catalog, sync watermarks, restart-time repopulation, and the need for a second reconciliation pass in some cases.

No conversation IDs, titles, account/user IDs, email addresses, tokens, cookies, or personal paths are included in this update.

I am proud to say that this workaround worked PERFECTLY on two different MacOS installations that had this bug, thank you.

I can confirm that this remains reproducible on:

ChatGPT unified desktop app 26.825.41651, build 7345
macOS 26.6.2 (25G83)
Apple Silicon

At least five conversations that were already absent from the server-facing web history remained as undeletable entries in the macOS Recents catalog. Opening or deleting them failed because the conversations no longer existed remotely.

One additional diagnostic detail: three affected rows in local_thread_catalog had missing_candidate = 1, while two other confirmed server-missing conversations incorrectly had missing_candidate = 0. The latter entries were therefore still treated as valid by the local catalog.

After backing up the database and removing only the exact confirmed-deleted rows, the ghost entries disappeared. A subsequent conversation sync did not recreate them during the verification period, and PRAGMA integrity_check returned ok.

No conversation titles, IDs, contents, account identifiers, or personal paths are included here.

I can reproduce this issue on Windows as well.

Environment:

Windows x64
ChatGPT/Codex Desktop 26.825.6671
Affected items are ordinary ChatGPT conversations, not local Codex tasks

Observed behavior:

The conversations were deleted successfully and no longer appear on chatgpt.com using the same account.
The deleted conversations remain visible under Recents in the Windows desktop app.
Opening an affected entry or attempting to send a message returns Request failed with error 404.
Attempting to delete it displays Failed to delete chat.
Attempting to archive it also fails.
Multiple deleted conversations are affected.
Updating and fully restarting the desktop app did not remove the stale entries.

This confirms that the issue is not limited to macOS. The web conversation state is correct, while the Windows desktop Recents list retains stale references to server-deleted conversations.

A feedback session ID is available privately if the OpenAI team needs it.

Additional independent reproduction from macOS:

ChatGPT unified desktop app release: 26.825.51511
Five already-deleted ordinary ChatGPT conversations remain visible under Chat → Recents.
The same conversations are absent from ChatGPT Web for the same account.
Sampled entries return terminal 404 conversation_deleted with can_retry: false when opened.
Delete and archive attempts also return conversation_deleted.
I fully quit the app, backed up and rebuilt the Desktop Local Storage LevelDB, then relaunched. The five stale titles repopulated in Recents, so rebuilding that local cache did not resolve the issue.
The local Codex state_5.sqlite integrity check is ok, and these are not local Codex threads.
Complete conversation IDs, titles, account identifiers, and local paths are intentionally omitted from this public comment.

This is consistent with the report's stale remote Recents index / missing tombstone-reconciliation hypothesis. It would help if the client removed a Recents row after any terminal conversation_deleted response, treating delete/archive against an already-deleted conversation as an idempotent sidebar cleanup success.

Independent reproduction on a newer build:

ChatGPT/Codex unified desktop app for macOS: 26.831.21537 (build 7579)
Two ordinary ChatGPT conversations were deleted from mobile and are absent from both ChatGPT Web and mobile.
Both remained in macOS Recents on two separate Macs using the same account.
Opening them showed Could not load this ChatGPT conversation; deleting showed Failed to delete chat.

Read-only inspection on one Mac found both stale entries in:

~/.codex/sqlite/codex-dev.db
table: local_thread_catalog

Both rows had:

source_kind = 'chatgpt'
missing_candidate = 0

After backing up the database and deleting only the two exact confirmed-deleted rows, then incrementing local_thread_catalog_metadata.catalog_revision, the local catalog no longer contained the stale entries. PRAGMA quick_check returned ok, and unrelated catalog rows were unchanged.

This confirms the issue still reproduces on build 7579 and that terminally deleted ChatGPT conversations can remain marked as valid (missing_candidate = 0) in the local catalog. The product fix should reconcile remote deletion tombstones into local_thread_catalog, and treat an already-deleted remote object as an idempotent sidebar cleanup success.

Conversation titles/IDs and account identifiers are intentionally omitted.

Windows reproduction confirming this is cross-platform.

Environment

Codex desktop app: OpenAI.Codex 26.831.2377.0 (Microsoft Store package)
OS: Windows 11, Microsoft Windows NT 10.0.26200.0, x64
Surface: ordinary ChatGPT conversations under Recents, not Codex project threads
Reproduced: 2026-09-03

Observed behavior

Conversations deleted earlier from the mobile client intermittently reappeared in the Windows desktop Recents list. Attempting to delete them in the desktop UI displayed a deletion failure. The entries sometimes disappeared and later returned.

Six affected entries were confirmed. The current account-backed conversation listing no longer returned those conversations, but the Windows desktop catalog still contained rows for them in:

%USERPROFILE%\.codex\sqlite\codex-dev.db
local_thread_catalog
source_kind = chatgpt

For the stale rows, missing_candidate was still 0, so they were treated as normal catalog entries despite being absent from the current account-backed list. One valid conversation returned by the account listing was also present in the same table, providing a useful control.

Workaround and result

After making a SQLite online backup, deleting only the six exact stale source_kind = chatgpt catalog rows removed the ghost entries. The valid control conversation remained present. A subsequent desktop list and database query both showed the six stale IDs absent.

Conversation titles, IDs, account identifiers, and database files are intentionally omitted from this public comment. I can provide sanitized IDs privately if an OpenAI maintainer requests them.

Expected behavior

The Windows desktop Recents catalog should reconcile against server deletion tombstones. A terminal response indicating that a conversation is already deleted should be treated as idempotent cleanup success: remove the local catalog entry instead of showing a deletion failure and allowing it to reappear.

Confirmed on macOS as well.

Environment:

ChatGPT/Codex Desktop on macOS
Surface: ordinary ChatGPT conversations under Recents
Reproduced: 2026-09-02

I had four conversations that had already been deleted from ChatGPT, but they remained visible in the Desktop Recents list.

I checked:

~/.codex/sqlite/codex-dev.db
local_thread_catalog

All four stale entries were still present with:

source_kind = chatgpt
missing_candidate = 0

I first created a SQLite backup, then deleted only those four exact stale rows from local_thread_catalog using their thread_id values.

Result:

all four ghost conversations disappeared from Recents immediately;
valid conversations remained untouched;
after reopening the Desktop app, the stale entries did not return.

So I can confirm that the workaround described above also works on macOS.

This appears to further confirm that the issue is in reconciliation between the account-backed conversation state and the local Desktop local_thread_catalog, rather than in the conversation deletion itself.

Thanks for documenting the workaround.

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

I was able to work with OpenAI desktop sync team engineers (Case Number: 13957766) to get this issue properly resolved with the latest ChatGPT update (Version 26.901.22334)

I just installed 26.901.22334 and I still have a full list of recent chats that were deleted via the browser days ago.

EDIT: Never mind. It took a few minutes, but it did update.

@daveyjones

I can confirm that the bug is still there (26.901.22334), started a chat on desktop, deleted it on web app, quit the desktop app, restart desktop app, phantom undeletable chat still there. Even after a few minutes (how long did you wait @daveyjones ?)
Workaround still works too..

Additional reproduction on macOS (2026-09-04):

The affected conversations have been deleted successfully on chatgpt.com and no longer appear on the web.
The same deleted conversations continue to remain visible in the ChatGPT macOS app sidebar/Recents.
Opening the stale entries fails / the conversation cannot be displayed.
Attempting to delete those stale entries from the macOS app also fails.
This is ordinary ChatGPT Chat history, not a Codex local task/thread.

So the web-side conversation state is already clean, while the macOS client continues to surface undeletable stale conversation entries. This matches the behavior described in this issue and provides another independent affected-user reproduction.

I'm having the same problem!
OS: Ubuntu 26.04.1
Desktop App Version: 26.901.31953
Feedback ID: no-active-thread-01a06c75-d100-7270-90cd-6f041da2fa3b

issue occurs on both macOS and Windows

I have now confirmed that this issue is not specific to my Mac. The same deleted conversations continue to appear in the ChatGPT desktop application's Recents sidebar on both my Mac and Windows PC.

Key observations:

The affected conversations were deleted several days ago.
They do not appear on ChatGPT.com.
They do not appear when searching for them.
They nevertheless remain visible in Recents in the ChatGPT desktop app.
The issue occurs on two separate computers running different operating systems: macOS and Windows.
On macOS I have already:
Signed out and back in.
Completely uninstalled and reinstalled ChatGPT.
Reset the application's local data.
Removed/recreated ~/Library/Application Support/Codex.
Tested with a completely fresh local Codex/ChatGPT application-data profile.
Even after creating a fresh local application-data profile, the exact same deleted conversations repopulated in Recents.
The same ghost entries subsequently appeared on my Windows installation.

This strongly suggests that the stale Recents records are being synchronized or supplied by an account-side/Desktop Unified Recents service, rather than being caused by a local cache on either computer.

Navigation Menu

Repository navigation

[macOS][Chat] Server-deleted conversations repopulate in Recents and cannot be removed #40219

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?

Product / surface

Controlled comparison

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Sanitized diagnostic excerpt

Troubleshooting already completed

Public-report privacy

Related but not duplicate

Update: confirmed local catalog persistence and repeatable workaround

Confirmed finding

Workaround that cleared the UI

Likely missing product behavior

Update: confirmed local catalog persistence and repeatable workaround

Confirmed finding

Workaround that cleared the UI

Likely missing product behavior

Environment

Observed behavior

Workaround and result

Expected behavior

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[macOS][Chat] Server-deleted conversations repopulate in Recents and cannot be removed #40219

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?

Product / surface

Controlled comparison

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Sanitized diagnostic excerpt

Troubleshooting already completed

Public-report privacy

Related but not duplicate

Activity

github-actions commented on Aug 23, 2026

dmurotov commented on Aug 25, 2026

tracedef commented on Aug 25, 2026

dmurotov commented on Aug 25, 2026

dmurotov commented on Aug 25, 2026

dongiedong commented on Aug 25, 2026

ShalevZorany commented on Aug 26, 2026

Update: confirmed local catalog persistence and repeatable workaround

Confirmed finding

Workaround that cleared the UI

Likely missing product behavior

vcbrewers commented on Aug 27, 2026

bytePatrol commented on Aug 28, 2026

Update: confirmed local catalog persistence and repeatable workaround

Confirmed finding

Workaround that cleared the UI

Likely missing product behavior

Magneand commented on Aug 29, 2026

sjh8153 commented on Aug 31, 2026

wangzhefeng commented on Aug 31, 2026

dilashchuk commented on Sep 2, 2026

julianshi0122-dot commented on Sep 2, 2026

Environment

Observed behavior

Workaround and result

Expected behavior

dmurotov commented on Sep 3, 2026

vcbrewers commented on Sep 3, 2026

bytePatrol commented on Sep 3, 2026

daveyjones commented on Sep 3, 2026

dongiedong commented on Sep 4, 2026

Paayamok commented on Sep 4, 2026

AndysTMC commented on Sep 4, 2026

tanmaynk commented on Sep 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions