Codex App archived chats bulk delete shows success but does not remove archived threads

Summary

In Codex App, deleting all archived chats from the archived chats page shows a success toast, but the archived chats are not actually removed. Refreshing/reopening the archived chats page still shows the same archived threads.

Environment

• Codex App: 26.609.41114 (CFBundleVersion=3888, bundle id com.openai.codex)
• Codex CLI: codex-cli 0.140.0-alpha.2
• macOS: 15.7.3 (24G419)
• Local app/server logs show app_server.api_version="v2"

Steps to reproduce

1. Open Codex App.
2. Navigate to Archived Chats.
3. Click the bulk delete action for archived chats.
4. Observe the success toast, for example: Deleted 25 archived chats.
5. Refresh/reopen the archived chats page.

Actual behavior

The archived chats still appear after the success toast.

Local state inspection immediately after the toast showed:

select archived, count(*) from threads group by archived;

Result:

archived  count
0         71
1         25

All 25 archived thread rows still existed in the local Codex state database, and their rollout_path values still pointed at redacted paths under:

~/.codex/archived_sessions/*.jsonl

The archived session files also still existed.

The currently exposed thread-management tools in this environment include archive/unarchive operations but no delete-thread operation, which is consistent with the delete UI not changing the underlying state.

Expected behavior

After a successful bulk delete toast:

• archived thread rows should be removed from the local thread state, or otherwise marked so they no longer appear in Archived Chats;
• archived session files should be deleted or detached according to the intended product semantics;
• the success toast should only be shown after the underlying state mutation succeeds and is verified, or it should report a failure/partial failure.

Additional observations

The local log database had codex_rollout::state_db warnings around thread listing/read-repair, for example stale rollout path/read-repair messages. I did not find an explicit delete failure log. This looks like a UI/app-server state consistency issue rather than a user workflow issue.

No private thread titles or screenshots are included here; the evidence above is intentionally aggregated/redacted.