Feature request: Open long threads at latest message and lazy-load older history

Feature request

Please add a per-thread history-loading mode so a long-running Codex task can open at only the latest message or a recent window (for example, the last day), while older history is loaded only on demand.

Problem

Opening a long-lived thread can force Codex Desktop to restore or process substantial history even when the user only needs the latest task state.

In one observed Windows case, merely opening a large thread increased the Codex main process private memory from approximately 8.19 GB to 12.79 GB. Total system RAM reached approximately 97.2%, heavy paging began, and the UI froze. Switching away from the thread did not release the memory; a full app restart was required. After restart, Codex returned to approximately 0.56 GB and total RAM usage returned to approximately 60%.

This is especially disruptive on 16 GB systems. Creating a replacement thread is not an adequate workaround because users rely on long-running task history for continuity.

Requested behavior

• Open a task at the latest message by default.
• Lazy-load older messages only when the user scrolls upward or explicitly requests them.
• Add a per-thread option such as:
  • Latest message only
  • Recent day / recent window
  • Full history
• Immediately cancel history restoration/loading when the user navigates away.
• Keep the original thread identity and full history intact; do not require archive, deletion, or handoff to a new task.
• Warn before restoring an exceptionally large history.
• Keep sending/steering usable without reconstructing the entire retained history.

Expected result

Accidentally opening a very large thread should not make the whole computer or Codex app unresponsive. The user should be able to continue from the newest context and retrieve older content only when needed.

Environment

• Codex Desktop on Windows 11
• 16 GB RAM
• Long-running task with a large retained conversation history

Related reports

• #22991 — very large rollout/history files can freeze Codex
• #18693 — desktop performance collapses with very large histories
• #38787 — expensive full history reconstruction blocks resume/steering
• #37291 — saved chats should reopen at the latest message

This request focuses on the missing user-facing control and bounded/lazy history-loading behavior. No private thread IDs, conversation content, or local file paths are included.

No files, tests, or entry points are named. Start by locating the Codex Desktop thread restoration and history-loading paths, then trace navigation cancellation and message-window selection. Done means a thread can open at the latest or a recent window, load older history on demand, preserve full history, and remain usable without reconstructing everything.