[Windows][Codex Desktop] Archived Delete all aborts when one thread is referenced by an active fork

[berkyuo2-cpu]

Summary

On Windows, Settings > Archived chats > Delete all aborts the whole operation when one archived paginated thread is still referenced as history_base by an active fork. The UI only shows a generic failure toast and leaves every archived thread in place.

Environment

• Windows 10.0.19045 x64
• Codex Desktop package: 26.818.5229.0
• Bundled app-server / CLI runtime: 0.149.0-alpha.4.1
• Local archived Codex threads visible in the UI: 121

Reproduction and evidence

1. Keep an active fork whose session metadata has history_base.thread_id pointing to an archived paginated parent.
2. Open Settings > Archived chats. The referenced parent is the first listed archived item.
3. Choose Delete all and confirm.
4. The UI shows the generic localized equivalent of Archived chats could not be deleted. No visible archived thread is removed.

Sending thread/delete for that first parent directly to the bundled app-server returns JSON-RPC code -32600 with:

cannot delete thread <parent>: forked history still references it

Using the same bundled supported CLI path, codex delete --force , successfully deleted the other 120 visible archived threads. The referenced parent correctly remained protected. This isolates the bulk failure to one protected item rather than general filesystem corruption or permissions.

Expected behavior

Delete all should process items independently or preflight the full set. It should:

• delete every deletable archived thread;
• skip the fork-referenced parent;
• report the exact protected-thread reason and the number deleted/skipped;
• avoid reducing an intentional referential-integrity guard to a generic all-or-nothing error.

Related

• Archived chats show a Delete button, but deletion does not work #28095 covered the older single-delete failure and is closed as fixed.
• Session delete removes the archive payload but leaves a stale database row, then errors on every subsequent delete #36558 concerns payload/database residue; this report is specifically the bulk UI abort caused by an active fork reference.

I am omitting the screenshot and real thread IDs because they contain private task titles. The exact error, versions, counts, and before/after behavior above were captured from the live Windows installation.