openai / openai/codex

[Windows Desktop] Legacy onboarding task_e entries cannot be opened, archived, or deleted

Open
#41,198 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

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

Description

What version of the Codex App are you using?

Current unified ChatGPT/Codex Desktop build on 2026-08-27. The bundled Codex runtime reports 0.150.0-alpha.8.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Two legacy Codex cloud tasks that originated from the initial suggested/onboarding chat tasks remain permanently visible under Codex → Recently used with cloud icons.

They are not normal ChatGPT conversations and do not appear anywhere in ChatGPT Web, including Work, chat history, projects, or archived chats. They also cannot be opened, archived, reassigned, or deleted in the current Desktop app.

Affected legacy task IDs:

  • task_e_68403986fd048333a3deb190d7512fdb
  • task_e_68403986e0fc8333b9d065b0cb643170

The two sidebar titles are:

  • Codebasis durchgehen und Probleme finden
  • Fehler in ausgewähltem Code beheben

Read-only diagnostics show that the legacy task service still returns HTTP 200 for:

  • GET /backend-api/wham/tasks/{task_e_id}
  • GET /backend-api/wham/tasks/{task_e_id}/turns

However, the current thread APIs expect UUID-style local thread IDs:

  • thread/read rejects the value with an invalid-thread-ID error because task_e_... is not a UUID.
  • The fallback GET /backend-api/conversation/{task_e_id} returns HTTP 400 with Invalid conversation.
  • The supported archive action reports No Codex thread found.

Selecting one of these sidebar entries does not open the existing task. Instead, the app creates a brand-new projectless local UUID thread. For example, entering a short confirmation while trying to open the legacy item created an unrelated local thread titled Öffnen.

The affected entries are absent from Settings → Archived chats, so the documented archive-first deletion workflow cannot be used.

What steps can reproduce the bug?
  1. Use an account that has old Codex tasks created from the initial suggested/onboarding chat tasks.
  2. Upgrade to or open the current unified ChatGPT/Codex Desktop app.
  3. Open the Codex sidebar.
  4. Observe the legacy tasks under Recently used, marked with cloud icons.
  5. Select either legacy task.
  6. Observe that the existing task is not resumed; the next input creates a new local projectless thread.
  7. Try to archive the legacy entry.
  8. Observe that the current thread service cannot resolve the task_e_... identifier.
  9. Open ChatGPT Web and Settings → Archived chats.
  10. Observe that these entries are absent and therefore cannot be deleted there either.
What is the expected behavior?

The migration should handle legacy task_e_... Codex onboarding/suggested tasks in one of these ways:

  1. migrate them to current UUID-backed threads while preserving history and management actions; or
  2. keep a compatibility path that can open, archive, and permanently delete them through the legacy task service; or
  3. if they are stale/non-user-manageable onboarding artifacts, remove them from the sidebar automatically.

At minimum, users need a supported permanent-delete action for these legacy records. Selecting a legacy task must not silently create a new unrelated local thread.

Additional information
  • The affected task records are server-backed, not entries that can be fixed by editing a local projectId.
  • Local project reassignment is not applicable: the tasks use the legacy cloud task_e format and are returned by the old wham/tasks service.
  • Clearing or editing local sidebar state would not be a durable workaround because the cloud task service still returns the records.
  • This appears related to, but more specific than, general delete/archive requests such as #39540 and orphaned-thread reports such as #38724. The distinguishing factor is the migration boundary between legacy task_e onboarding tasks and current UUID-backed threads.
  • No authentication tokens, account IDs, local usernames, absolute paths, conversation contents, or raw logs are included.

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 issue with the two task_e_ identifiers and compare the legacy /backend-api/wham/tasks/{id} endpoints with thread/read and the archive action. Trace the Windows Desktop sidebar selection and migration path. Done means legacy entries can be opened and managed or are removed, without creating an unrelated UUID thread.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design, 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.