Windows Desktop: many threads in one project make sending and responses very slow even on fast model

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

26.519.5221.0

What subscription do you have?

Not included in this public report.

What platform is your computer?

Windows NT 10.0.19045.0 x64

What issue are you seeing?

Codex Desktop becomes very slow when a project accumulates many chat threads. Sending a new message and waiting for the answer/stream to begin can become extremely slow, even when using a fast model/reasoning setting.

This feels like a Desktop/app-server/session-management performance issue rather than only model latency: the slowdown correlates with having many conversations under the same project/workspace.

Local redacted diagnostics from the affected Windows profile:

• state_5.sqlite total threads: 90
• unarchived threads: 89
• largest single project/workspace thread count: 31 unarchived threads
• second largest project/workspace thread count: 14 unarchived threads
• largest local rollout file: about 49.83 MiB
• next largest rollout files include about 18.36 MiB, 11.80 MiB, 11.31 MiB, 10.45 MiB, and several more in the 5-10 MiB range
• logs_2.sqlite has about 120,097 log rows and is roughly hundreds of MB on disk

The active symptom is user-facing latency: composing/sending prompts and receiving answers becomes very slow after many conversations are added to the same project, even with fast settings.

What steps can reproduce the bug?

1. Use Codex Desktop on Windows.
2. Work repeatedly in the same local project/workspace.
3. Create many separate chat threads in that project. In this affected profile, the largest project has 31 unarchived threads.
4. Continue using Codex in that project.
5. Send a prompt in an existing or new thread using a fast model/reasoning setting.
6. Observe that sending and response/stream startup can become very slow.

What is the expected behavior?

The number of historical conversations under the same project should not materially slow down prompt sending, UI input, or response streaming in the active thread.

Desktop should lazily page/hydrate history and avoid blocking the active send path on sidebar history enumeration, session resume, workspace-root scanning, rollout parsing, or log/session indexing.

Additional information

This may overlap with existing performance reports, but this is a Windows-specific profile where the strongest user-visible correlation is “many conversations in the same project/workspace,” not just one huge active thread.

Related issues:

• #18693: Desktop performance collapses in profiles with a few very large local conversation histories
• #21527: Codex is really too slow
• #21076: Desktop history/sidebar can hide local conversations even though they exist in state_5.sqlite

Possible areas to inspect:

• Project/workspace-scoped thread listing and sorting
• Sidebar history hydration/pagination
• App-server thread/list behavior under many workspace threads
• Session resume/read/index behavior for many or large rollout files
• Whether local log/session indexing is happening on the active message-send path

I am omitting exact workspace paths and conversation contents for privacy, but can provide additional redacted diagnostics if useful.