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
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.
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
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
Related reports
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.