exec: avoid loading the full legacy rollout when recovering completed turn items

[MikeeI]

What variant of Codex are you using?

CLI (codex exec)

What feature would you like to see?

I found a potential performance concern in current source rather than a confirmed user-visible bug. After a non-ephemeral codex exec turn completes, in-process delivery may have dropped non-terminal item notifications under backpressure. To recover final items, exec sends thread/read with include_turns: true and then selects only the matching completed turn. For legacy threads, this path loads every rollout item and constructs all turns before returning that one turn's items.

Please consider a completion-recovery read that returns only the matched turn's completed items without loading the full legacy rollout or materializing all legacy turns. It should preserve the active exec thread/turn filter, the non-ephemeral and TurnItemsView eligibility gates, paginated-thread behavior, the current backpressure fallback, best-effort warning behavior, final output, item order, and completion ordering. I am not assuming that a targeted legacy index already exists; the implementation could add one or another history-store-supported targeted read.

Additional information

Evidence

• maybe_backfill_turn_completed_items sends thread/read with include_turns: true for a qualifying completion, then turn_items_for_thread selects one matching turn and clones its items.
• The app-server thread/read path passes include_turns into read_thread_view. For an unloaded legacy thread, load_persisted_thread_for_read requests history and builds every legacy turn; for a loaded thread, apply_thread_read_store_fields loads history and builds every legacy turn.
• The local store's load_history and read_thread paths both reach attach_history_if_requested, which calls load_history_items. RolloutRecorder::load_rollout_items reads rollout lines to EOF and retains every parsed item.
• Related prior art: #16781 and #16795 concern invalid includeTurns recovery for ephemeral threads; the merged fix intentionally retains recovery for non-ephemeral threads. #34226 removed backfill for unrelated child completions but retained the active primary-turn recovery request. #21211 documents costly full thread/read(includeTurns=true) hydration for a different Desktop thread-open path, and #22411 concerns thread/list plus the separate exec resume lookup discussed there. None targets a one-turn completion-recovery read for exec.

Impact

Not measured. No latency, allocation, or I/O-volume measurement was taken. The fallback performs work proportional to the complete legacy rollout before selecting one completed turn. User-visible cost, occurrence, and frequency remain unknown.

Question

Would maintainers like completion recovery to avoid materializing the full legacy rollout while preserving the current backpressure fallback semantics?

I checked all relevant issues, comments, pull requests, discussions, and release notes; this report is not a duplicate.

I am reporting this finding only and am not proposing a pull request unless a maintainer invites one.

Disclosure

Investigated thoroughly with GPT-5.6 (high reasoning effort), using Oh My Pi as the agent framework.

This report is not generic or unreviewed AI-generated output. Its claims were checked against the cited evidence, and it includes the relevant detail intended to help maintainers resolve the issue.

If reports like this are not useful to the project, please let me know and I will refrain from submitting similar ones. My intent is to help without wasting maintainer time or energy or discouraging their work.

Thank you for your work.