openai / openai/codex

[macOS] Permanently delete is hidden for the same local task in ChatGPT view but available in Codex view

Open
#45,442 1 comment 0 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

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

ChatGPT desktop app 26.908.40834, build 8881 (verified from the installed app's Info.plist).
Bundled Codex CLI: 0.154.0-alpha.6.2.

What subscription do you have?

Not specified in this report.

What platform is your computer?

macOS 26.6.2.

What issue are you seeing?

The same existing local Codex task has a Permanently delete action in its sidebar context menu when the app's top-left view selector is set to Codex, but that action disappears when the selector is set to ChatGPT. In the ChatGPT view, the task is displayed with a Work badge.

The task and its contents remain the same across the switch. Archive is available in both menus. The Swedish UI label Ta bort permanent appears only in the Codex view.

This makes deletion appear unavailable when a user is managing the task from the ChatGPT view, even though switching views exposes the action for that very same task. There is no explanation or link in the ChatGPT menu directing the user to the other view.

What steps can reproduce the bug?
  1. Open the unified ChatGPT desktop app on macOS with an existing local Codex task that is visible in both sidebar views.
  2. Select ChatGPT using the top-left view selector.
  3. Open that task's sidebar context menu. It has a Work badge in this view. Observe that Archive is available, but Permanently delete is absent.
  4. Switch the top-left selector to Codex, keeping the same task.
  5. Open the same task's sidebar context menu. Permanently delete now appears directly below Archive.
  6. Switch back to ChatGPT and inspect the same task again: the deletion action is absent.

The user supplied side-by-side evidence of the two menus for the same task. Screenshots are omitted here because they contain unrelated private information. No deletion needs to be confirmed to reproduce this menu inconsistency; this report does not claim that the final deletion operation was tested successfully.

What is the expected behavior?

For a task that supports permanent deletion, expose the same deletion action and confirmation dialog in both sidebar views. The selected view should not make an existing task-management capability disappear. If this distinction is intentional, provide a clear explanation and a direct route to the supported deletion flow.

Additional information

A read-only inspection of the installed app bundle found the sidebar action explicitly gated on the selected mode being codex:

o === `sidebar` && e.get(Qr) === `codex` && M.push({ id: `delete-thread`, ... })

The accompanying action description is: "Task context menu action in Codex mode that opens confirmation before permanently deleting the task". This supports the observed difference, but does not establish whether the restriction is intentional product behavior or an implementation oversight.

Related reports reviewed:

  • #33589 reports missing deletion controls in the macOS app generally; it does not document this same-task comparison between the ChatGPT and Codex views.
  • #13018 requests permanent deletion for Codex tasks generally.
  • #37791 describes broader fragmentation across ChatGPT/Work/Codex views, without this specific deletion-menu reproduction.

This report concerns action visibility before deletion, not stale sidebar entries after successful deletion.

Follow-up: ChatGPT view incorrectly presents the task as archived and cannot restore it

The user reports a further problem in the ChatGPT view: the task is unexpectedly presented as archived. A new screenshot supplied on September 14, 2026 shows the ChatGPT view selected and the task content replaced by an archive placeholder with these exact Swedish messages:

  • “Den här uppgiften är arkiverad” — “This task is archived.”
  • “Återställ den här uppgiften från arkivet för att öppna den” — “Restore this task from the archive to open it.”
  • Button: “Återställ från arkiv och öppna” — “Restore from archive and open.”

At the same time, a red error notification reads:

Det gick inte att återställa den här uppgiften från arkivet

Translation: “Could not restore this task from the archive.”

The visible result is that the ChatGPT view does not show the task content, presents restoration as necessary to open it, and reports that restoration failed. The user describes the archived state as incorrect. The screenshot confirms the archive placeholder and restoration error; it does not independently establish the task's underlying archive status or the precise sequence that triggered this state. Whether this shares a root cause with the view-dependent deletion-menu inconsistency above is not yet established.

Expected behavior: The ChatGPT and Codex views should reflect the same actual archive state for the same local task. An active task should open without an archive placeholder. If the task is genuinely archived, the restore-and-open action should restore it and display its content, or provide an actionable explanation of the failure.

The screenshot is not attached because it also contains unrelated private sidebar and browser information. The relevant UI text is transcribed above.

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 same local task's context menus in the ChatGPT and Codex views, then inspect the installed app bundle's reported sidebar action gate for delete-thread. Compare the archive placeholder and restore failure in ChatGPT with the task state in Codex; done means both views consistently expose supported actions and reflect the same archive state.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, macos, rust
Domain
desktop, frontend
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.