Regression: Desktop 26.707 replays legacy thread history and emits 1,282 parse errors per page, freezing the Windows UI #32198

Summary

Codex Desktop 26.707 on Windows becomes work-blocking after opening a large thread created by an earlier Desktop version.

The affected rollout contains legacy response_item/tool_search_output records with this shape:

{
  "type": "tool_search_output",
  "call_id": "<redacted>",
  "status": "completed",
  "execution": "<redacted>",
  "tools_summary": {"omitted_tool_count": 1}
}

The current parser requires a tools field. Every history reconstruction emits one parse error for each legacy record. At the same time, each thread/turns/list request reconstructs the complete rollout instead of only the requested page. Background hydration therefore repeatedly parses the entire file, floods the trace database, raises app-server/renderer memory, and eventually makes the whole Desktop window nearly unresponsive.

This is a high-severity, work-blocking regression. Smaller control threads in the same profile remain responsive, and system RAM is not exhausted.

Environment

• Codex Desktop package: 26.707.3748.0
• Desktop client version in app-server traces: 26.707.31428
• Bundled Codex CLI: 0.144.0-alpha.4
• Windows 11 x64, build 22631
• Local Codex Home
• Thread was created and used across earlier Codex Desktop versions

Reproduction

1. Use Codex Desktop 26.707 on Windows.
2. Open a long thread created by an earlier version whose JSONL contains legacy tool_search_output.tools_summary records without tools.
3. The recent tail appears first and the UI is initially responsive.
4. Leave the thread open or scroll into older history.
5. Desktop requests older pages through thread/turns/list.
6. Observe that each page request reconstructs the complete rollout.
7. During each reconstruction, app-server repeatedly logs failed to parse rollout line: missing field \tools``.
8. After hydration continues, scrolling, clicking, switching threads, and the entire Desktop window become extremely sluggish or unresponsive.

Sanitized measurements from one affected thread

• Rollout size: 228,385,027 bytes (about 217.8 MiB)
• JSONL records: 362,562
• Reconstructed rollout items: 361,280
• Legacy tool_search_output records using tools_summary: 1,281
• Legacy thread_name_updated event rejected as an unknown variant: 1
• Parse errors per complete reconstruction: 1,282
• Additional trace rows observed during a 10-second replay sample: about 1,960
• app-server working set observed: about 0.55-0.92 GiB
• primary renderer working set observed: about 0.51-0.55 GiB
• logs_2.sqlite: about 2.11 GiB
• WAL: about 71.5 MiB
• System still had more than 8 GiB free RAM, so this was not whole-system memory exhaustion

The same Codex Home was fully audited without loading all rollouts into memory: 302/302 registered thread files parsed as valid JSONL. Across those files, 1,348 legacy tools_summary records and 50 thread_name_updated events were found, which indicates this is a persisted-history compatibility issue rather than corruption of one file.

Sanitized trace pattern

app_server.client_version="26.707.31428"
rpc.method="thread/turns/list"
failed to parse rollout line: missing field `tools`

apply_rollout_reconstruction{
  thread_id=<redacted>,
  rollout_item_count=361280
}

Expected behavior

1. Rollout parsing remains backward-compatible with legacy tool_search_output.tools_summary records.
2. Unknown historical event variants do not generate one error on every replay.
3. thread/turns/list reads or caches only the requested page instead of reconstructing the complete rollout for every page.
4. Hydration and rendering stay bounded for large threads.
5. Repeated per-record parse errors are aggregated/rate-limited instead of expanding the trace DB indefinitely.

Related issues

• Long threads are unrecoverable when rollout JSONL grow beyond resume/list limits #25215: paginated thread/turns/list still replays the complete rollout
• Windows/WSL2: Desktop retains one eager MCP stack per opened chat and replays history during navigation #32154: 26.707 Windows thread switching repeatedly reads history and stalls the UI
• Codex Desktop becomes extremely sluggish when opening very large local thread on Windows #25390: severe sluggishness opening large local threads on Windows
• Codex Desktop becomes unusable on long active threads due to app-server/renderer memory and TRACE log churn #21134: long threads increase app-server/renderer memory and log churn
• [Desktop] Long conversations show only recent turns after update although full rollout history remains local #31995: 26.707 history tail/pagination behavior

I did not attach the rollout, state database, trace database, or screenshots because they contain private prompts, local paths, and credentials. I can provide a synthetic legacy JSONL reproducer if maintainers specify the preferred format.