›_ Codex Issues
Codex Issues / #38466

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

Open 💬 4 comments Opened Aug 14, 2026 by AiurArtanis
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

4 Comments

AiurArtanis · 14 days ago

Additional redacted quota-consumption evidence

  • Plan/model context: pro20x.
  • Workload: the same long-running conversation was repeatedly continued overnight.
  • Weekly quota shown before the repeated run: approximately 79% remaining.
  • Weekly quota shown afterward: approximately 15% remaining.
  • Observed change: approximately 64 percentage points consumed overnight.

This is a UI-observed aggregate measurement; no account identifier, billing identifier, prompt content, or raw usage log is included. The evidence is consistent with repeated continuation/compaction work causing unexpectedly high usage, but it does not by itself establish the exact token accounting or whether retries/tool calls were charged separately.

github-actions[bot] contributor · 14 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #38431
  • #38349

Powered by Codex Action

AiurArtanis · 14 days ago

Additional redacted UI/session-recovery evidence

  • From the start of last night's work, the content of the first work turn appeared to repeat an extremely large number of times after the session was restarted this morning.
  • Possible trigger: at the beginning of the work session, opening the subagent sidebar appeared to roll the conversation view back to a conversation from more than a month earlier, while the session still displayed as running.
  • After the session was closed this morning and then restarted, the first-turn content from last night was visible repeatedly rather than once.

This is an observed UI/session-history symptom and a possible trigger sequence, not a confirmed root cause. No screenshots, account identifiers, project content, or raw session data are attached.

shleder · 14 days ago

This is a useful real-world stress case for Codex Rescue because the rollout is large, heavily compacted, and the latest turn is interrupted. I want to be clear that broad real-world compaction recovery is still experimental — I’m specifically trying to validate where the current diagnostic/salvage boundary is.

If you still have the affected session, would you be willing to try:

pipx install codex-rescue==0.1.0a3
codex-rescue sessions
codex-rescue doctor --latest

If it identifies the right rollout, sanitized doctor / salvage --fork / verify output would help a lot. Rescue leaves the original rollout untouched and fails closed when it cannot prove a safe continuation.

Please don’t share the raw 273 MB rollout, prompts, source, SQLite DBs, credentials, or private paths.

https://github.com/shleder/codex-rescue