Codex Desktop becomes unresponsive when opening previous conversations; thread history loading appears too eager

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #29187
• #28867
• #29376
• #29321

Powered by Codex Action

Thanks for writing this up. I am seeing a related Windows Codex Desktop performance regression in #28855: since June 12, opening/using Codex Desktop can cause severe intermittent mouse/typing/system input lag, and it still persists for me on OpenAI.Codex 26.616.10790.0.

I linked your report in a broader Discussion collecting recent Windows Desktop performance reports here: https://github.com/openai/codex/discussions/29949#discussioncomment-17428007

No action needed from you unless you want to add more detail there, but I wanted to connect the reports because the recent Windows issues look related enough that they may need a canonical tracker.

I can reproduce this issue with a newer Codex Desktop version.

Environment:

• Codex Desktop: 26.707.9981.0
• codex-cli: 0.144.2
• Microsoft Windows NT 10.0.26200.0 x64
• Approximately 180 local threads, 278.8 MB in total

Additional findings:

• Switching to an existing thread makes the thread visible, but the input box remains unresponsive for approximately 3–4 seconds.
• All inspected rollout JSONL files were valid. No duplicate thread IDs or JSON corruption were found.
• Some compacted histories contain repeated inline base64 input_image data.
• One full thread/resume response contained 143 turns and was approximately 586 KB.
• A local experiment using:

excludeTurns: true
initialTurnsPage: { limit: 16, sortDirection: "desc", itemsView: "full" }
reduced the initial response to approximately 52 KB and improved overall responsiveness.

• Reducing the initial page to 8 turns reduced the payload further, but did not materially reduce the remaining 3–4 second input delay.
• After one desktop restart, an orphaned older app-server process caused repeated HTTP 409 "Remote app server already online" errors and model refresh timeouts. Terminating only the orphaned process stopped those errors.

Suggested improvements:

1. Use paged thread/resume loading by default.
2. Enable the input box before older turns finish loading.
3. Avoid duplicating inline base64 image data in compacted replacement history.
4. Lazy-load older images and turns.
5. Terminate stale app-server processes when Codex Desktop restarts.

The problem originally reproduced on the stock Codex Desktop app. The paging behavior above was only a local diagnostic workaround added afterward.

Additional Windows reproduction with a bounded read-only capture.

Environment:

• Codex Desktop App: OpenAI.Codex 26.727.6591.0 (Windows AppX)
• Windows 11 x64
• default CODEX_HOME (~/.codex)

Symptom:
The largest stall was observed while opening the current existing task after a Desktop restart, before sending a new prompt. The UI was much less responsive during task/history opening than during ordinary idle use.

Capture window: 2026-08-01 21:56:40-22:06:36 local time.

Observed on the main codex.exe process:

• 22:00:23: CPU 174% (multi-core process counter), working set 225 MB, total process I/O ~27.3 MB/s, read ~23.0 MB/s, write ~4.3 MB/s, page faults ~7.7k/s.
• 22:00:29: CPU 114%, working set 236 MB, total process I/O ~54.9 MB/s, read ~54.5 MB/s, write ~0.38 MB/s, page faults ~16.7k/s.

Local state activity during the same capture:

• state_5.sqlite-wal grew from about 1.02 MB to 2.99 MB.
• logs_2.sqlite-wal had 78 distinct metadata-update timestamps during the capture window, while its size stayed approximately constant in this sample.
• A codex-code-mode-host process appeared after the main I/O/CPU spike; its peak was substantially lower, so it does not look like the primary source of the opening stall in this run.
• The profile contains a largest archived rollout of about 518 MB. We sampled metadata only and did not read its contents, so this capture does not prove that the archived JSONL was fully scanned.

Interpretation:
This is consistent with a heavy synchronous or foreground phase while reconstructing an existing thread/state and persisting local state. It is not a model-generation delay: the main spike occurred while opening the task, before a new prompt was submitted. File-level attribution is still needed to distinguish transcript hydration from SQLite/state reconstruction, logging, or app-server resume work.

Requested follow-up:
Please add phase-specific timings for opening/resuming a thread and expose whether the work is history parsing, state-db reconstruction, logging, plugin/network initialization, or renderer hydration. Opening a thread should load bounded metadata plus a recent tail, with older transcript/tool/image data loaded lazily; persistence/logging should not block the UI.

Related reports: #29177, #29674, and #29799.

Copy-ready comment for openai/codex#29590

I have additional single-host Windows evidence that supports the “history loading is
too eager” hypothesis and points to an app-server path that already exists.

Environment for this run:

• Codex Desktop 26.727.6591.0 (Microsoft Store/MSIX)
• Codex CLI/app-server 0.145.0
• Windows x64
• no task text, task identifiers, or raw logs are included below

Controlled Desktop observations:

• A 101.56 MB legacy task took about 3,050 ms to resume, then the Desktop loaded

ten additional history pages over about 17,524 ms after the task was already
visible.

• A 53.14 MB task took about 1,316 ms to resume, then loaded four additional pages

over about 5,380 ms.

• During the post-open history hydration, the renderer reached roughly 3.7 logical

core equivalents. This coincided with visible input/UI contention.

I then built a read-only lab client against a separate local Codex app-server. It did
not parse or modify rollout JSONL. It requested exactly five turns with
thread/turns/list, sortDirection: "desc", and itemsView: "summary", and requested
one older page only after an explicit action.

| Stored task size | Cold five-turn tail | Warm memory tail | One older page |
|---:|---:|---:|---:|
| 101.56 MB | 1,215–1,379 ms | 0.1 ms | 1,187–1,194 ms |
| 94.57 MB | 982 ms | 0.1 ms | 973 ms |
| 53.14 MB | 733 ms | 0.1 ms | 620 ms |
| active 13.55 MB task | 246 ms | 0.1 ms | 238 ms |

In the lab UI, selecting an active task rendered five turns in 199.2 ms; switching
away and back was served from memory in 0.0 ms; loading once changed the rendered
count from exactly five to ten. Typing or switching tasks cancelled the pending read,
and a stale response could not replace the latest selection. A restart hit a bounded,
revision-checked DPAPI tail snapshot in 42.8 ms.

This does not prove that a sidecar fixes Desktop, and I am not proposing a sidecar
as the product solution. It shows that a bounded tail-first client path avoids the
continued all-history DOM work seen in the Desktop baseline.

The app-server already exposes the relevant experimental resume path:

{
  "method": "thread/resume",
  "params": {
    "threadId": "<redacted>",
    "excludeTurns": true,
    "initialTurnsPage": {
      "limit": 5,
      "sortDirection": "desc",
      "itemsView": "summary"
    }
  }
}

Suggested Desktop behavior:

1. Resume with no full thread.turns payload and render only the initial 3–5 turn

page.

1. Request exactly one older page when the user scrolls near the top; never drain all

cursors in the background.

1. Give each task selection/history request a generation. On task switch, composer

input, tool execution, or route teardown, cancel the old request and reject any late
stale result even if transport cancellation loses the race.

1. Preserve the scroll anchor when prepending a page.
2. Keep any idle prefetch to at most one cancellable data page and do not mutate the

message DOM until the user asks for it.

Suggested acceptance criteria:

• initial task render contains no more than five turns;
• no older-history request occurs before upward scrolling;
• one threshold crossing produces at most one page request;
• task switching and typing remain responsive while a large stored task is selected;
• no background history hydration consumes renderer CPU after the tail is interactive;
• full model continuity and the original rollout remain unchanged.

Related: #34663 documents the same excludeTurns + initialTurnsPage direction for the
CLI/TUI resume surface.