[Windows Desktop 26.715] Completed large thread is fully replayed every few seconds, causing system-wide input stutter

What version of Codex is running?

• Codex Desktop package: 26.715.2305.0
• Desktop client version in app-server traces: 26.715.21425
• Bundled WSL Codex runtime: 0.145.0-alpha.18

What operating system are you using?

Windows 10 Pro x64, version 10.0.19045 (24 logical processors, 128 GB RAM), with the Codex app-server running through WSL2.

What is the issue?

A large thread that has already emitted task_complete and is no longer active continues to be polled by Codex Desktop with thread/turns/list.

Each request reconstructs the entire rollout (about 167 MB / 94,706 items). This repeats indefinitely while the Desktop app is open and causes:

• delayed typing in the composer;
• mouse-pointer and general Windows UI stutter every 1–2 seconds;
• lag even while viewing a different project/thread;
• occasional loss of responsiveness around session navigation.

Task switching is not required. The stutter continues while the app is simply left open.

Sanitized trace pattern:

app_server.client_name="Codex Desktop"
app_server.client_version="26.715.21425"
rpc.method="thread/turns/list"
Resuming rollout from "<redacted>.jsonl"
Resumed rollout with 94706 items

The latest turn had already ended with task_complete, but the same Desktop connection continued issuing these requests.

Steps to reproduce

1. Have a large local thread (in this case about 167 MB and 94.7k reconstructed items).
2. Let its current turn finish and emit task_complete.
3. Switch to another thread/project, or leave Codex Desktop idle.
4. Keep Codex Desktop open and move the mouse or type in Codex/another Windows app.
5. Observe periodic whole-system input/UI stutter.
6. Fully quit Codex Desktop: the stutter stops immediately.
7. Use Codex CLI with Desktop closed: the system remains smooth.
8. Reopen Desktop: the periodic stutter returns.

Measurements

Over one five-minute sample after the thread had completed:

• 34 complete whole-rollout replays;
• mean gap between replay completions: about 7.16 seconds;
• cache-warmed replay duration: about 3.65–4.52 seconds each;
• app-server sustained about 1.02 CPU cores, with about 1.87 cores observed during an earlier replay/startup sample;
• app-server RSS: about 409 MB;
• the settled Windows frontend used only about 0.06 CPU core in a comparison sample.

This is not memory exhaustion; the machine has 128 GB RAM.

The rollout was also copied, with matching hash, from the Windows-mounted filesystem to WSL ext4:

• before: each full replay took about 33.7–45.5 seconds and was largely I/O-bound;
• after: the initial resume took 6.87 seconds and later replays took 3.65–4.52 seconds;
• however, the polling/replay loop continued, became CPU-bound, and the system-wide stutter remained.

The state database passed quick_check, the JSONL is valid, and there were no repeated rollout parse errors. Moving storage therefore improves each scan but does not fix the repeated full-history hydration.

Expected behavior

• A completed, inactive thread should not be continuously polled.
• thread/turns/list should use indexed/cached metadata and true pagination instead of reconstructing the complete JSONL for every request.
• Background status/session refresh should not hydrate an entire transcript.
• Desktop should not affect mouse or system-wide input responsiveness while idle.
• Any unavoidable history indexing should be coalesced, cancellable, and run at low priority.

A/B isolation

• Codex Desktop open: periodic system-wide stutter.
• Codex Desktop fully closed: stutter disappears immediately.
• Codex CLI alone: smooth.
• Faster WSL-local storage: individual scans are faster, but the loop and stutter remain.

Related issues

• #33382 — system-wide stutter during task switching; this report does not require switching and identifies repeated full-rollout hydration.
• #22411 — app-server loads session files on thread/list.
• #32198 — full replay during thread/turns/list; that report includes legacy parse errors, while this rollout has no parse errors.
• #25215 — large-rollout resume/list limits.
• #33774 — separate history/project-mapping regression observed around the same Desktop upgrade.

I have intentionally omitted the rollout, databases, thread IDs, titles, local paths, prompts, and raw trace files because they contain private project data. I can provide additional sanitized counters or a synthetic large-rollout reproducer if maintainers specify the preferred format.