›_ Codex Issues
Codex Issues / #38835

Remote compaction v2 retains raw media and can trigger repeated auto-compaction

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

Summary

In a long-running Codex Desktop session with image inputs, repeated remote compaction retained raw media payloads in replacement history. The session then kept auto-compacting and the rollout grew continuously.

Observed behavior

  • A successful compaction did not remove earlier inline image payloads from the retained history.
  • Subsequent compaction requests carried those payloads forward again.
  • The retained payload volume created a high context floor and repeated automatic compaction.

Root-cause hypothesis

The v2 retained-history path in codex-rs/core/src/compact_remote_v2.rs assigns zero text-token cost to InputImage and InputAudio, while preserving the raw items during truncation. Therefore a byte-heavy media item can survive the text-only budget indefinitely across compactions.

Expected behavior

After successful compaction, retained history must not contain raw image or audio payloads from previous turns, and all retained context should remain bounded by the retention budget.

Proposed fix

Before retained-history budget truncation, replace InputImage and InputAudio with bounded text markers. This preserves conversation structure without resending or persisting raw media. Add regression coverage that asserts compacted retained history contains no data:image or audio payload and that markers are charged by the existing budget.

Related discussion

This is a current reproduction and source-level analysis related to #33493.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 12 days ago

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

  • #38753

Powered by Codex Action

LeonSGP43 · 12 days ago

Sanitized reproduction data

The following is a structural-only scan of one affected local rollout. No transcript text, prompts, file paths, screenshots, tool output, account identifiers, or raw media is included.

Environment and capture window

| Field | Value |
| --- | --- |
| Client version recorded at session start | 0.144.6 |
| History mode | legacy |
| Session start | 2026-07-25 08:28:28 UTC |
| Last recorded event at scan time | 2026-08-16 04:13:14 UTC |
| Writer state | rollout file was still open by the running Codex process |

Measured rollout shape

| Metric | Value |
| --- | ---: |
| Rollout size | 10,057,075,750 bytes, 9.4 GiB as reported by du |
| JSONL records | 64,983 |
| context_compacted records | 494 |
| Literal input_image occurrences | 30,202 |

Compaction concentration

The event timestamps show a pronounced late-session acceleration. Counts below are UTC and are structural event counts only.

| Date | context_compacted records |
| --- | ---: |
| 2026-08-13 | 19 |
| 2026-08-14 | 32 |
| 2026-08-15 | 269 |
| 2026-08-16 through 04:13 UTC | 35 |

The 269 compactions on 2026-08-15 correspond to an average interval of about 5.4 minutes across that UTC day. The problem persisted after compactions rather than resolving the history pressure.

Source-level correlation

In codex-rs/core/src/compact_remote_v2.rs:

  1. message_text_token_count assigns zero text-token cost to InputImage and InputAudio.
  2. truncate_message_text_to_token_budget preserves those media items unchanged.
  3. The retained items are installed into the compaction replacement history and can be sent again on later compaction cycles.

This makes a media-heavy retained history effectively unbounded with respect to the text-only retention budget, matching the measured growth and recurring compaction pattern.

Acceptance criteria for a fix

  1. A successful remote v2 compaction leaves no raw data:image or audio payload in retained replacement history.
  2. Retained media is represented by bounded text only and participates in the existing retention budget.
  3. Repeated compactions do not reintroduce prior raw media into the next request or persisted rollout history.
  4. The regression test uses synthetic media only and asserts complete response-item structure, without recording user data.
Rina48 · 11 days ago

Additional Windows reproduction on a current Desktop build

Corroborating this on Windows 11 x64 with Codex Desktop
26.810.7004.0, embedded CLI 0.148.0-alpha.9, gpt-5.6-sol,
and remote_compaction_v2 enabled during the incident.

A structural-only scan of one image-heavy thread showed:

  • rollout size of approximately 400 MiB;
  • dozens of persisted compaction records;
  • hundreds of repeated input_image / data:image occurrences across

replacement histories; these were not unique images;

  • 13 compaction attempts during the final approximately 30-minute window;
  • every compact HTTP request returned 200 OK, but token usage remained above

the automatic-compaction threshold, causing another compaction roughly every
2–3 minutes.

This distinction may be useful: the failure was not only a transport error.
Compaction succeeded at the HTTP layer but did not re-establish enough context
headroom to converge, leaving the Desktop session unusable.

No transcript text, prompts, paths, task or thread identifiers, screenshots,
raw logs, media, account information, or repository content is included.

shleder · 11 days ago

Your retained-media/compaction case is a strong stress test for codex-rescue because the failure is persisted in session history rather than being only a transient UI symptom. I’m field-testing the tool on real broken/oversized Codex sessions. It is experimental, local-first, and keeps the source rollout read-only; it does not claim to fix remote compaction itself.

Could you run the narrow diagnostic path on an affected local session?

pipx install codex-rescue
codex-rescue sessions
codex-rescue doctor --latest

For a multi-GB/image-heavy rollout, please stop there first rather than immediately salvaging it. I’m interested in whether discovery/diagnosis stays bounded and reports the state without mutating the original file.

Sanitized output + versions/exit codes would be useful; please don’t post raw JSONL/SQLite, image payloads, prompts, credentials, or private paths. Repo: https://github.com/shleder/codex-rescue