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

Open 💬 2 comments Opened Aug 27, 2026 by SolidCircuit
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 15 hours ago

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

  • #41067

Powered by Codex Action

SolidCircuit · 14 hours ago

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:

  • #41067 reports ChatGPT/TPP-origin conversation records with UUID-like 6a… identifiers.
  • This report involves legacy Codex onboarding/suggested tasks with task_e_… identifiers.
  • These records are still successfully returned by the legacy /backend-api/wham/tasks/{task_e_id} and /turns endpoints (HTTP 200).
  • Current UUID-backed thread/read / archive management rejects the identifiers, while the ChatGPT conversation fallback returns Invalid conversation.
  • Selecting the legacy entry can create a brand-new projectless local UUID thread instead of merely failing to open/archive it.

The underlying fix may share reconciliation/sidebar code with #41067, but preserving this report should help cover the legacy task_e migration path and the unintended new-thread creation behavior.