CLI can get stuck in repeated pre-sampling compact failure loop with large tool-output history #24732

What version of Codex CLI is running?

codex-cli 0.133.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.5, reasoning effort xhigh

What platform is your computer?

Darwin 25.5.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Ghostty initially. The replacement session was later moved to tmux after recovery. The failing session was an interactive Codex CLI session, not codex exec.

Codex doctor report

not available

What issue are you seeing?

A long-running Codex CLI goal session entered a repeated Failed to run pre-sampling compact loop. The process stayed alive and the session JSONL kept updating, but the TUI stopped accepting useful steering: sending /compact, continue, or other text did not create a new usable turn. The only practical recovery was to recover the objective from the session file and start a fresh Codex session.

The important part is that auto-compact appears to have triggered, but the compact request itself could not complete. From the outside this looked like a permanent retry loop before the next normal model turn.

Observed local log line repeated many times:

codex_core::session::turn: Failed to run pre-sampling compact

Sanitized session metrics at the time:

last_input_tokens: 224,320
last_total_tokens: 224,505
model_context_window: 258,400
session_jsonl_size: ~43.5 MB
function_call events: 4,350
function_call_output events: 4,350
token_count events: 2,782
thread_goal_updated events: 2,345
task_started events: 61
function outputs with original token count > 5,000: 651
large outputs near the failure: roughly 20k-21k tokens each

The loop continued for more than two hours in the logs. A sanitized count from the log tail found 115 occurrences, with the first around 2026-05-27T02:43:00Z and the last around 2026-05-27T04:48:25Z.

This was not a normal provider capacity message or a dead process:

• The Codex wrapper and native process remained alive.
• The TUI/session file kept recording token_count / goal update state.
• No new meaningful task_started appeared from manual steering after it entered the loop.
• The visible nominal context window still had apparent headroom, but compaction itself appeared unable to fit/complete.

My interpretation is that the pre-sampling compact request has its own effective request budget: compact prompt, retained history, tool schemas/metadata, hidden overhead, and output reserve must all fit. With enough high-volume tool output in history, the compact request itself can fail even though auto-compact exists and even though the visible nominal window suggests some headroom.

What steps can reproduce the bug?

I do not have a small deterministic repo reproduction, but the observed pattern was:

1. Start an interactive Codex CLI goal session using gpt-5.5 xhigh.
2. Let the session run for many hours with many tool calls and large tool outputs.
3. Accumulate many function_call_output records, including hundreds above 5k original tokens and several around 20k tokens.
4. Continue until Codex tries pre-sampling compaction before the next normal turn.
5. Observe repeated Failed to run pre-sampling compact in the Codex TUI log.
6. Try to recover from the TUI with Esc, /compact, continue, or a short steering message.
7. Observe that the text does not become a normal new turn and the session remains in the compact retry loop.

The session contents were project-specific, so I cannot attach the raw JSONL, but the metrics above are from the local session file and logs with private details removed.

What is the expected behavior?

When auto-compact itself fails, Codex should not remain indefinitely in a pre-sampling compact retry loop. Expected recovery behavior could include one or more of:

• Fall back to a more aggressive emergency compaction strategy that retains only a bounded tail plus last successful user/assistant summaries.
• Drop or summarize large historical tool outputs before building the compact request.
• Surface an actionable TUI state explaining that compaction failed and offer a safe /compact --aggressive or /recover path.
• Allow manual /compact or user steering to land as a new recovery turn instead of being swallowed by the retry loop.
• Emit clearer telemetry in the log: failing compaction request size, estimated tokens/bytes, retained history count, largest tool outputs, and whether the failure is size, timeout, remote error, or provider error.

Additional information

Related issues that appear similar but not identical:

• Remote CLI auto-compact times out on gpt-5.5 long sessions #24538: remote CLI auto-compact times out on gpt-5.5 long sessions
• Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact) #18450 / Codex Desktop: context compaction fails with remote compact stream disconnected #22107: remote compact stream disconnected / desktop compact failures
• Auto-compaction never triggers #16033: auto-compaction never triggers in headless exec mode
• Codex doesnt auto compact its context with gpt 5.5 xhigh #22467: app context compaction appears to hang with gpt-5.5 xhigh

This report is specifically about an interactive CLI session where pre-sampling compact did trigger, then repeatedly failed before a normal turn could proceed. The requested product behavior is a bounded fallback/recovery path so a long-running session can degrade gracefully instead of becoming unrecoverable.