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

[TforThomas]

What version of the Codex App are you using (From “About Codex” dialog)?

26.616.71553

What subscription do you have?

business

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Problem

When opening previous conversations in Codex Desktop, the app often becomes very slow or temporarily unresponsive while loading conversation history.

logs showed slow thread operations:

• thread/list: up to about 29.9s
• thread/resume: up to about 18.3s
• thread/start: up to about 23.7s

This happens even with a relatively small number of saved sessions.

Local Findings

Raw file I/O does not appear to be the main bottleneck:

• Reading the largest 11.14 MB transcript from disk: about 38ms
• Parsing that transcript as JSONL: about 176ms
• Parsing all 25 session files, about 48 MB: about 962ms

Isolated app-server tests using a temporary CODEX_HOME with only one copied session showed:

• thread/list default scan: 77ms
• thread/list with useStateDbOnly=true: 10ms
• thread/read includeTurns=false: 40-87ms
• thread/read includeTurns=true: 479ms
• thread/turns/list summary 20: 357ms
• thread/resume default: about 2.1s

So the long Desktop stalls are likely not caused by JSONL file size alone. They seem to come from higher-level Desktop/app-server behavior around session listing, resume semantics, plugin/network initialization, UI state, or foreground metadata repair.

During isolated app-server tests, thread/resume also attempted plugin/network-related work, including featured/curated plugin fetches and websocket connection attempts. That suggests thread/resume may be too heavy for simply opening/viewing an old conversation.

Expected Behavior

Opening the conversation list or clicking an old thread should remain responsive. The app should show lightweight metadata quickly and load detailed history progressively.

What steps can reproduce the bug?

The bug happens when opening/resuming previous conversations in Codex Desktop on Windows. The app can become very slow or temporarily unresponsive while loading local conversation history.

Observed affected session:

• Session ID: 019ed607-cdbe-7f52-b24e-ff56a519e8fd
• Token/context window usage: not applicable / not captured. The slowdown occurs before sending a new prompt or starting a model turn. No new token generation is required to reproduce the loading issue.

Steps to reproduce:

1. On Windows, use Codex Desktop with several saved local conversations under ~/.codex/sessions.
2. Ensure at least one previous conversation has a relatively large transcript. In my case:
   019ed607-cdbe-7f52-b24e-ff56a519e8fd, about 11.14 MB.
3. Open Codex Desktop.
4. Open the previous conversation list / history.
5. Click the old conversation above.
6. Observe that Codex Desktop may become very slow or temporarily unresponsive while loading/resuming the conversation.

What is the expected behavior?

Opening a previous conversation should be responsive and fast.

Additional information

No response

[github-actions]

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

• Codex Desktop thread switching is consistently slow on Windows #29187
• Desktop thread/resume can lock regular active threads after recent update #28867
• Desktop: remote MCP startup timeout blocks creating new conversation #29376
• MCP startup should not block tool listing or thread startup #29321

Powered by Codex Action

[Yassycodes]

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: #29949 (comment)

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.

[nico883991-ui]

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.

[TeaShaman-cyber]

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.