[Windows] Delete All archived chats leaves a hidden archived fork that may block its source

Environment: Windows; Codex desktop package 26.901.5280.0; running backend codex-cli 0.153.4.

Observed: September 5, 2026.

What happened

I had an archived task named “Cleanup plan” and a fork named “Cleanup plan (2).” Both were visible when I clicked Delete all in Archived chats. The operation displayed “Failed to delete archived chats.” Afterward, only “Cleanup plan” appeared in the archive list, and further deletion attempts failed.

Expected: Both selected archived tasks should be deleted, with fork dependencies handled correctly. If deletion cannot complete, the app should identify the blocking task and preserve a way to manage it.

Findings verified before repair

• Both tasks still had archived database records and transcript files. Both were readable through the app's task-reading API.
• The fork's transcript metadata contained history_base.thread_id referencing the original task.
• The original's stored preview was 543 characters; the fork's preview was empty.
• A live thread/list request using {"archived":true,"limit":200,"useStateDbOnly":true} returned only the original, with nextCursor: null. The existing fork was omitted.
• The installed backend contains the list predicate AND threads.preview <> ''.
• The installed desktop's global Delete All implementation uses that database-only archived listing, calls thread/delete sequentially in returned order, and stops at the first unrecovered error. It does not explicitly order tasks by fork dependencies.
• The installed backend contains the rejection template cannot delete thread <id>: forked history still references it. This was found in executable strings; it was not captured as the response to the original failed click.

Repair and verification

With explicit permission, an assistant used the same running backend version's standard thread/delete API to delete the fork first, then the original. Both requests returned success (result: {}).

The two task records, their transcript files, and the original's seven spawned subagent histories were verified removed. Their indexed history/catalog records were absent, the archived list was empty, and no unrelated pre-existing task records were removed. No direct database edits were used.

Suspected cause and limits

The strongest explanation is that an archived fork with an empty preview is omitted from the list used for bulk deletion, while its retained history reference still blocks deletion of the original. The successful fork-first repair supports this explanation.

The original response error and exact original batch contents were not retained, so the complete failure sequence is not proven. It is also unknown why the fork's preview was empty. This should not be described as confirmed evidence that the app simply sorted the parent ahead of the fork: documented default listing order is newest-created first, which would normally place the newer fork first if included.

Please investigate the mismatch between archived tasks eligible for deletion and tasks included in the bulk-deletion list, plus handling and reporting of fork dependencies during partial failures.

Related report

Related: #40365 reports Delete All aborting when an active fork references an archived source. In this case, the dependent fork was also archived, remained readable, and was omitted from the database-only archived list because its preview was empty. The added issue is that an intended archived deletion target can become undiscoverable while retaining the dependency.

References

• Official thread-list behavior
• Official thread deletion
• Official reporting instructions

Conversation contents, local account paths, actual task identifiers, and raw diagnostic files are omitted.

Trace the desktop global Delete All flow and the backend thread/list and thread/delete entry points, starting with the archived-list predicate and sequential deletion behavior described here. Done means eligible archived forks are discoverable, fork dependencies are handled during deletion, and any blocking task is reported without removing unrelated records.