Long-running Desktop session becomes huge and difficult to inspect after repeated compaction; thread read output is truncated

Summary

A long-running Codex Desktop conversation can accumulate a very large rollout history after repeated context compaction. The affected thread becomes difficult to inspect or resume: reading the thread returns a very large payload that is truncated by the client, while the latest interrupted turn does not expose a concise failure summary or a bounded diagnostic view.

This report is based on a single redacted local session. No raw rollout file, project source, user names, credentials, or private prompt content is attached.

Environment

• Product: Codex Desktop
• Platform: Windows 11 x64
• Codex CLI reported in the session metadata: 0.145.0-alpha.27
• Thread source: Desktop / local
• Affected thread ID: 019f84df-9cf2-7803-9587-c186c0212c8a

Observed behavior

• The thread contains a long sequence of repeated investigation/tool turns across multiple days.
• The latest turn is marked interrupted, while the thread itself is idle.
• A bounded read of the latest 10 turns produced a response of roughly 220k output tokens and was truncated by the client.
• A one-turn read still produced roughly 79k output tokens and was truncated.
• The rollout file for the affected thread is approximately 273.48 MiB with 66,875 lines.
• Redacted type counts from that file:
  • agent_message: 3,398
  • custom_tool_call: 7,072
  • function_call: 4,901
  • context_compacted: 135
  • patch_apply_end: 818
• The thread history includes many repeated status/planning messages after compaction; the latest interrupted turn does not provide a compact root-cause/error summary.

Reproduction pattern

1. Keep one Codex Desktop thread active for a long development workflow.
2. Let the thread undergo repeated context compaction (especially when it includes many tool calls and delegated work).
3. Continue the workflow across many turns.
4. Open/read the thread or request a recent-turn summary.
5. Observe that the response becomes very large and is truncated, making the thread difficult to inspect or recover after an interruption.

Expected behavior

• Thread history should remain bounded or deduplicated after compaction.
• Thread inspection should return a predictable bounded summary with explicit pagination and no huge implicit expansion.
• An interrupted turn should expose a concise diagnostic (reason, last completed tool, and safe resume point).
• Large histories should remain usable without requiring raw rollout-file inspection.

Privacy / security

The evidence above is intentionally redacted and aggregate-only. It omits local paths, project names, file contents, credentials, usernames, and raw session data. The session ID is included so OpenAI staff can locate the relevant uploaded thread if available.

Please let me know if a private diagnostic bundle or more targeted metadata is needed.

No source file or test is identified in the report. Start by reproducing the repeated-compaction pattern and inspecting the bounded thread-read response and rollout metadata; done means thread inspection stays predictably bounded and an interrupted turn exposes a concise diagnostic and safe resume point.