RemoteCompactionV2 repeat-compaction loop and state loss in ephemeral side conversations

Open 💬 5 comments Opened Jul 27, 2026 by bardsleym

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Codex Desktop 26.721.41059 (build 5848, embedded codex-cli 0.146.0-alpha.3.1), an ephemeral side conversation repeatedly auto-compacts while investigating compaction itself. The compacted conversation resumes with an unusually large context, quickly compacts again, and can lose decision-critical state.

A diagnostic upload was submitted through feedback/upload with logs enabled and the desktop log attached. The API associated it with parent thread 019fa51f-b15d-7fb2-82ad-7bac48ccbca6 rather than returning a separate feedback ID.

Thread IDs

Persistent parent: 019fa51f-b15d-7fb2-82ad-7bac48ccbca6
Ephemeral side conversation: 019fa548-b7d2-7b43-ab59-c8f3b7d05b4e

Reproduction evidence

The side conversation was forked from the parent at 2026-07-27T20:33:54.313Z and received its boundary injection at 20:33:54.379Z, while parent tool item exec-2506c50c-b54b-4e5d-aac6-8071a391fbc5 was still active.

Immediately around that fork, the desktop log emitted hundreds of messages of this form:

Item not found in turn state itemId=exec-2506c50c-b54b-4e5d-aac6-8071a391fbc5
Received turn/started for unknown conversation conversationId=019fa548-b7d2-7b43-ab59-c8f3b7d05b4e
Received item/started for unknown conversation conversationId=019fa548-b7d2-7b43-ab59-c8f3b7d05b4e
Rebinding placeholder latest turn to incoming event ...

The side conversation is deliberately ephemeral and pathless. It has no rollout JSONL and no row in state_5.sqlite, so its compaction replacement and turn history cannot be audited through the normal persisted artifacts.

After a fresh compaction in that side conversation, app-server token telemetry resumed at approximately 138,163 tokens and rose past 159,499 within roughly one minute. Every record showed:

auto_compact_scope_limit=244800
full_context_window_limit=258400
RemoteCompactionV2

This leaves little useful headroom after compaction and produces another compaction during ordinary tool-heavy investigation.

Separately, an earlier compaction in the persistent July 14 lineage lost an architectural constraint and caused the assistant to reach the wrong conclusion. Re-reading the pre-compaction JSONL reversed that conclusion. This was decision-critical semantic loss, not only inefficient token retention.

Failure layers

The evidence appears to show three related but distinct problems:

Retention/headroom: RemoteCompactionV2 retains enough raw message and startup/tool context that this side conversation resumes around 138k tokens and quickly compacts again.
Active-turn semantic state: decision-critical constraints can disappear or older state can be restored as current, overlapping the behavior reported in #8648.
Side-fork lifecycle and observability: forking while a parent tool item is active produces unknown-item/unknown-conversation/rebinding errors, while the ephemeral fork has no persisted rollout for diagnosis.

Expected behavior

A side fork should have a coherent turn/item lifecycle even when the parent has an active tool call.
Compaction should leave enough headroom for meaningful continued work rather than immediately triggering another compaction.
The current active goal, user correction, and architectural constraints should survive compaction.
Ephemeral side-conversation failures should have enough persisted diagnostic state to reconstruct the compaction and event sequence.

Related issues

#8648: replies or resumes from the wrong conversational state after compaction
#21269: retained startup/context packets in compacted replacement history, closed after the June 29 local-compaction rollout

This reproduces on the current local-v2 desktop build after #21269 was closed.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

#35032
#35226
#34862

Powered by Codex Action

betaucourt · 1 month ago

I can reproduce the repeat-compaction loop in a normal persistent local desktop task, so the affected scope appears broader than ephemeral side conversations.

Environment

ChatGPT/Codex desktop for macOS: 26.715.52143 (build 5591)
Embedded CLI: codex-cli 0.145.0-alpha.18
macOS 26.4 (build 25E246)
Persistent local task ID: 019fa463-f80c-7143-acef-24491dc181e7

Evidence

The affected work was a bounded documentation/validation handoff: list the few owner-only provider values still required to close an infrastructure Phase 0, record their sources, validate the repository artifacts, and finish the conversation.

From thread/read for turn 019fa5bf-3e7b-7bc2-9a5e-3c53cca25e94:

Status: interrupted
Duration: 9,476,685 ms (~2 h 37 min 57 s)
248 visible items
111 contextCompaction items
87 reasoning items
36 agent messages
7 file-change items
4 MCP tool calls
3 user messages (the original request plus two user interventions asking the agent to finish)

The agent repeatedly returned from compaction saying it was about to inspect, verify, or patch the same small handoff. It did make some changes, but repeatedly lost operational continuity and expanded/reprocessed the task instead of completing it.

The subsequent explicit closure turn 019fa652-0c90-7bb0-9226-ed2bc0a5425b was also interrupted after 517,490 ms (~8 min 37 s). It contained 6 more contextCompaction items, three short reasoning items, and two status messages, but no tool call, file change, or final answer.

The complete local rollout currently contains 157 context_compacted events across 129 user-message events. I am not attaching the raw rollout because the task contains private infrastructure identifiers; the task ID is included for internal diagnostics.

Expected behavior

One compaction should produce a usable continuation with the active request and completed work preserved.
A compacted turn should not immediately enter another compaction loop while repeatedly re-planning the same bounded action.
If compaction cannot recover enough headroom or state, the turn should fail visibly with a diagnostic instead of consuming hours/usage and emitting repeated progress messages.
User steering that says to stop expanding scope and finish should remain the highest-priority active instruction after compaction.

This reproduction seems related to all three layers described in the issue: insufficient post-compaction headroom, loss of active-turn semantic state, and weak observability/recovery. Unlike the original report, however, it occurred in an ordinary persisted desktop task with a rollout JSONL and a stable task ID.

betaucourt · 1 month ago

Follow-up: I also submitted this through Codex's internal /feedback flow with logs and diagnostics enabled.

Uploaded feedback/session ID: 019fa677-950c-7a92-823c-1d7916e4618e
Affected persistent task: 019fa463-f80c-7143-acef-24491dc181e7
Affected archived rollout size: 5.7 GB

Two direct feedback/upload app-server attempts against the affected task remained pending indefinitely (first with logs, then with includeLogs=false and only a 2 MB desktop log). I therefore used a fresh TUI /feedback session and included the affected task/turn IDs plus this issue comment URL in the report text. The 5.7 GB rollout was not attached through that fresh upload, but its path/size and the original task ID are recorded in the feedback.

jskoiz · 28 days ago

I reproduced a stronger form of this in a persistent Codex Desktop task and inspected the rollout JSONL.

Environment: Desktop 26.727.40816 (build 6067), embedded codex-cli 0.146.0-alpha.9.2, GPT-5.6 Sol, 258,400-token context, remote_compaction_v2=true.

The task crossed three automatic compaction boundaries at approximately 225k–231k total tokens. Every resulting type="compacted" record had:

payload.message == ""
payload.replacement_history.length == 4

Those four messages contained only startup/context material: app/memory/skill instructions, multi-agent instructions and the AGENTS.md/environment wrapper. The active user request, progress, tool results, conclusions and next action were all absent.

Immediately after the three compactions, the model responded with variants of:

What would you like me to work on in this workspace?

This appears model-generated from the surviving startup instructions, not a hardcoded reset message.

The first request used 32,124 input tokens, including 191 advertised skills and a broad memory/AGENTS.md packet. That large baseline makes compaction occur sooner, but it is not sufficient to explain total task loss: it is only ~12.4% of the context window.

The causal boundary supported by the artifacts is:

large fixed baseline → earlier compaction → V2 produces/assembles a replacement with no task summary → client installs it without validating continuity → model sees instructions but no task

The local records cannot distinguish whether the service returned an empty summary or client-side V2 assembly discarded it. They do prove the malformed replacement was persisted and installed silently.

Suggested guard: reject or fall back whenever payload.message is empty and replacement_history contains only startup/context packets with no actual user task or progress summary. Disabling remote_compaction_v2 is an effective bypass; reducing startup size only postpones the failure.

boombx403-byte · 9 days ago

Hi @bardsleym, regarding the missing tool output / unfinished call state in the transcript, Codex Rescue Alpha5 has bounded tool-correlation diagnostics to detect persisted correlation anomalies and incomplete turn boundaries without assuming non-execution.

To inspect the rollout locally and safely in read-only mode:

pip install codex-rescue==0.1.0a5
codex-rescue doctor <path-to-rollout.jsonl>

No private files need to be uploaded; please sanitize any repository details before sharing diagnostic output.