openai / openai/codex

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

Open
#39,897 24 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app bug session
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the stale entry and tracing the ChatGPT conversation-history/sidebar index, conversation-list query or cache, and client-side invalidation path for the documented 404 responses. The listed Codex stores and chatgpt-sidebar-state-v1 contain no matching entry, so use the GET and DELETE logs as the entry points. Done means a conversation_deleted response removes the stale sidebar item and relaunching does not restore it.

Written by the indexing model from the issue text.

Assessment

Tech stack
macos, rust
Domain
desktop
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.