Bulk project archive only processes loaded tasks; stale entries fail with rollout_not_found

What version of the Codex App are you using (From “About Codex” dialog)?

ChatGPT/Codex Desktop 26.825.41651 (build 7345)

What subscription do you have?

ChatGPT Pro ($200/month)

What platform is your computer?

Darwin 25.6.0 arm64 arm (macOS 26.6.2, build 25G83)

What issue are you seeing?

In a local project with more than 50 user-visible tasks, the project-level Archive all / Archive chats action operated on an incomplete, currently loaded inventory.

Initially the project list showed only 6 tasks. After using the bulk archive action, those 6 disappeared, but the same 6 later returned in the sidebar. The project still contained many more tasks behind Show more.

The behavior was captured during a performance trace:

• The bulk action again showed only the initial subset and the UI displayed “Archived 6 tasks.”
• I then clicked Show more five times.
• The next confirmation displayed “Archive 51 chats?”
• After confirming, the project displayed “No chats.”

Local diagnostic logs for this incident show that bulk archive fans out individual thread/archive requests:

• 98 archive responses total
• 92 successful responses
• 6 failed responses
• before trace recording: 41/41 successful
• during the trace window: 51 successful plus 6 failures
• each failure returned JSON-RPC -32600 with no rollout found for thread id / rollout_not_found

The six failed IDs were not present in the local thread state database. This suggests two related integrity problems, although the exact internal cause is not proved:

1. bulk archive appears to use the currently loaded/sidebar inventory instead of enumerating all eligible project tasks; and
2. stale sidebar entries can be included even though their backing rollout/thread record no longer exists.

The UI did not clearly report a partial result or the six failures.

Verified in-product Feedback ID: 01a04ff9-44be-7e13-86c1-d9caba7d9601

Verified performance trace ID: no-active-thread-01a04ff7-d3bb-7e83-9bf5-590803dc4491

What steps can reproduce the bug?

1. Use ChatGPT/Codex Desktop with a local project containing more than 50 user-visible tasks.
2. Open the project while only the initial subset is loaded in the sidebar. In this incident, 6 tasks were visible.
3. Use the project menu’s Archive all / Archive chats action and confirm.
4. Observe that only the visible/loaded subset is archived and that archived rows may reappear.
5. Click Show more repeatedly until the full project inventory is loaded.
6. Run the bulk archive action again.
7. Observe that the confirmation count is much larger (51 in this incident) and that individual archive requests may fail for stale entries with rollout_not_found.

The final state was reached only after explicitly loading more pages and archiving again. A clean deterministic reproduction after that state was not attempted to avoid disturbing additional task history.

What is the expected behavior?

• A project-level bulk archive action should enumerate all eligible tasks for that project, independent of how many sidebar pages are currently loaded.
• The confirmation count should represent the complete eligible project inventory.
• Successfully archived tasks should not reappear in the active sidebar.
• Stale/orphaned entries should either be removed automatically or handled by a working cleanup path.
• If any archive request fails, the UI should report an exact partial-result summary, including succeeded, failed, and skipped counts, rather than displaying an unconditional success message.
• Bulk archive should be idempotent and leave the active and archived views consistent.

Additional information

This is related to, but not an exact duplicate of:

• #41249 — global task inventory stops at 50
• #41214 — archived tasks resurrect after restart in a multi-host setup
• #14162 — stale/orphaned entries fail with no rollout found for thread id
• #20419 — older local conversations are hidden outside the recent window

The distinguishing behavior here is a single local project where bulk archive immediately used the loaded subset (6), a later fully loaded confirmation showed 51, and the same operation included six stale entries that failed with rollout_not_found.

No raw logs, screenshots, local paths, project names, account identifiers, or private task contents are attached. The performance trace and in-product feedback were uploaded through OpenAI’s supported diagnostic channels.

Start by reproducing the project-level Archive all flow with more than 50 tasks, first using the initially loaded sidebar inventory, then loading pages with Show more. Inspect how the action enumerates tasks and fans out thread/archive requests, including rollout_not_found failures. Done means all eligible tasks are included regardless of pagination, stale entries are handled, and the UI reports accurate succeeded, failed, and skipped counts.