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
- Use Codex Desktop 26.707 on Windows.
- Open a long thread created by an earlier version whose JSONL contains legacy
tool_search_output.tools_summary records without tools.
- The recent tail appears first and the UI is initially responsive.
- Leave the thread open or scroll into older history.
- Desktop requests older pages through
thread/turns/list.
- Observe that each page request reconstructs the complete rollout.
- During each reconstruction, app-server repeatedly logs
failed to parse rollout line: missing field \tools``.
- 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
- Rollout parsing remains backward-compatible with legacy
tool_search_output.tools_summary records.
- Unknown historical event variants do not generate one error on every replay.
thread/turns/list reads or caches only the requested page instead of reconstructing the complete rollout for every page.- Hydration and rendering stay bounded for large threads.
- Repeated per-record parse errors are aggregated/rate-limited instead of expanding the trace DB indefinitely.
Related issues
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.
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_outputrecords 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
toolsfield. Every history reconstruction emits one parse error for each legacy record. At the same time, eachthread/turns/listrequest 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
26.707.3748.026.707.314280.144.0-alpha.422631Reproduction
tool_search_output.tools_summaryrecords withouttools.thread/turns/list.failed to parse rollout line: missing field \tools``.Sanitized measurements from one affected thread
228,385,027 bytes(about217.8 MiB)362,562361,280tool_search_outputrecords usingtools_summary:1,281thread_name_updatedevent rejected as an unknown variant:11,2821,9600.55-0.92 GiB0.51-0.55 GiBlogs_2.sqlite: about2.11 GiB71.5 MiBThe 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_summaryrecords and 50thread_name_updatedevents were found, which indicates this is a persisted-history compatibility issue rather than corruption of one file.Sanitized trace pattern
Expected behavior
tool_search_output.tools_summaryrecords.thread/turns/listreads or caches only the requested page instead of reconstructing the complete rollout for every page.Related issues
thread/turns/liststill replays the complete rolloutI 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.