[Windows Desktop] Renderer hydrates only a recent subset of valid paginated thread history (autogen selfreport from codex)

Summary

Codex Desktop can display only a small recent subset of a long paginated task even though the durable rollout, history projection, and app-server pagination are complete.

This was reproduced in a mixed local/remote Desktop session. It is a renderer hydration defect, not transcript deletion.

Environment

• Windows 11 ARM64
• Microsoft Store package: 26.818.8289.0
• Desktop release reported by the active client: 26.818.61809
• History mode: paginated
• Correlation task ID: 019f3421-934e-7471-8c1b-95c95f668565

Read-only audit

The seven most recent Windows tasks and seven most recent Linux-backed tasks were checked.

Storage and backend results:

• all 14 tasks had exactly one canonical rollout;
• all rollout JSONL records parsed successfully;
• all paginated projections reached end-of-file;
• no token_count conversion failure, ordinal gap, duplicate rollout candidate, or missing rollout was found;
• direct app-server reads could page to the end and reconstruct the complete logical history.

Representative complete histories returned by the Linux app-server contained:

• 658 logical turns in task A;
• 231 logical turns in task B;
• 101 logical turns in task C;
• 50, 32, 32, and 8 logical turns in the remaining sampled tasks.

Renderer state from the same active Desktop session, after approximately 14.9 hours, contained only:

• 3 loaded conversations;
• 33 loaded turns in total;
• at most 22 loaded turns for any one conversation.

The user-facing conversation pane therefore exposed only a recent subset while the backend could still return the complete history.

Reproduction pattern

1. Open several local and remote-backed paginated tasks in Codex Desktop.
2. Keep the Desktop session active for several hours and continue long tasks.
3. Switch among the tasks or reopen a long task.
4. Observe that only a recent subset of its conversation is visible.
5. Read the same task through app-server pagination.
6. Observe that all older turns remain available and pagination reaches end-of-file.

The failure is intermittent, but it has recurred across multiple long tasks.

Expected behavior

• The renderer must continue requesting older pages when the visible task has more history.
• A renderer remount or task switch must reconcile its in-memory conversation state with the paginated backend.
• Lazy loading must expose a reliable way to load all older turns.
• The UI must not present a partially hydrated task as complete.
• If hydration fails, show an actionable error and preserve a retry path.

Distinction from related issues

• #40342 concerns a projection that stops at a rejected token_count record. No projection error or ordinal gap exists here.
• #34175 concerns legacy-mode history reconstruction. The affected tasks here use paginated history.
• #24263 concerns renderer reload and unknown-conversation/item-state errors. This case does not require those errors; the backend remains readable while the renderer silently retains only a subset.

Privacy

No conversation text, prompts, local paths, account data, hostnames, repository names, IP addresses, or raw logs are included. The correlation task ID is included for internal diagnosis.

No source files or tests are named. Start by tracing the Desktop renderer's paginated hydration path, including task switching and renderer remount reconciliation, and compare it with app-server pagination that reaches end-of-file. Done means older turns load reliably, incomplete hydration is not presented as complete, and failures retain an actionable retry path.