Codex App archives two independent tasks when only one is selected

What version of Codex CLI is running?

Not applicable. This issue occurred in Codex Desktop App 26.901.31953 (build 7868), not in Codex CLI.

What subscription do you have?

ChatGPT Pro

Which model were you using?

Unknown; the issue concerns task management rather than model execution.

What platform is your computer?

Darwin 25.5.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Not applicable. No terminal or CLI operation was involved.

Codex doctor report

not available

What issue are you seeing?

Archiving one task in the Codex Desktop App unexpectedly archived a second, independently created root task in the same project.

Only one task was selected when the Archive action was performed, but both tasks disappeared from the active project list and were shown as archived.

I later deleted the archived entries. After deletion, neither task could be recovered. The primary defect is that a single archive action affected two independent tasks; the permanent data loss was a downstream consequence.

Affected task IDs:

• 019fad1b-ce2c-7c93-8a41-71c17508d276
• 019fc61a-48d8-7d31-be2f-f7faaebc74d5

The two tasks were separate root entries. They were not forks and did not have a parent-child relationship.

Approximate occurrence: September 4, 2026, 17:34 CST (Asia/Shanghai).

What steps can reproduce the bug?

Uploaded diagnostic thread: 01a06bc6-8fd8-7311-8bd5-7820932a76f8

1. Open a project containing two independently created root tasks.
2. Open the overflow menu for one task.
3. Select Archive.
4. Return to the project task list.
5. Observe that both independent tasks have disappeared from the active list and are shown as archived.

I have not attempted to reproduce this again because doing so could cause further task loss.

What is the expected behavior?

Only the explicitly selected task should be archived. Other independent tasks in the same project must remain unchanged.

Archive and delete confirmation dialogs should clearly identify the affected task and should not apply to multiple root tasks unless they were explicitly selected.

Additional information

A post-incident read-only check found stale sidebar references to both task IDs. After the archived entries were manually deleted, neither root task remained in the local thread database or active/archived rollout storage.

The post-deletion storage state does not prove the cause of the archive behavior, but it confirms that the tasks are no longer locally recoverable.

No complete database, global-state file, or raw logs have been attached because they may contain sensitive information. Narrowly scoped and redacted diagnostics can be provided if requested.

Start by reviewing the uploaded diagnostic thread and the affected task IDs, then inspect the sidebar references, local thread database, and active/archived rollout storage mentioned in the report. Verify that archiving one selected root task leaves the other independent root task unchanged, and that confirmation dialogs identify only the affected task.