[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.