[Windows Desktop] Legacy onboarding task_e entries cannot be opened, archived, or deleted
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_68403986fd048333a3deb190d7512fdbtask_e_68403986e0fc8333b9d065b0cb643170
The two sidebar titles are:
Codebasis durchgehen und Probleme findenFehler 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/readrejects the value with an invalid-thread-ID error becausetask_e_...is not a UUID.- The fallback
GET /backend-api/conversation/{task_e_id}returns HTTP 400 withInvalid 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?
- Use an account that has old Codex tasks created from the initial suggested/onboarding chat tasks.
- Upgrade to or open the current unified ChatGPT/Codex Desktop app.
- Open the Codex sidebar.
- Observe the legacy tasks under Recently used, marked with cloud icons.
- Select either legacy task.
- Observe that the existing task is not resumed; the next input creates a new local projectless thread.
- Try to archive the legacy entry.
- Observe that the current thread service cannot resolve the
task_e_...identifier. - Open ChatGPT Web and Settings → Archived chats.
- 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:
- migrate them to current UUID-backed threads while preserving history and management actions; or
- keep a compatibility path that can open, archive, and permanently delete them through the legacy task service; or
- 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_eformat and are returned by the oldwham/tasksservice. - 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_eonboarding tasks and current UUID-backed threads. - No authentication tokens, account IDs, local usernames, absolute paths, conversation contents, or raw logs are included.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I reviewed #41067. The user-visible symptoms overlap, but this report appears to cover a different legacy record type and migration boundary, so I am leaving it open for maintainer triage.
Key differences from #41067:
6a…identifiers.task_e_…identifiers./backend-api/wham/tasks/{task_e_id}and/turnsendpoints (HTTP 200).thread/read/ archive management rejects the identifiers, while the ChatGPT conversation fallback returnsInvalid conversation.The underlying fix may share reconciliation/sidebar code with #41067, but preserving this report should help cover the legacy
task_emigration path and the unintended new-thread creation behavior.