›_ Codex Issues
Codex Issues / #10986

Regression: forced remote compaction removes local fallback and compaction visibility

Resolved 💬 6 comments Opened Feb 7, 2026 by ignatremizov Closed Mar 20, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

#10840 removed the remote_compaction feature flag and now forces remote compaction for OpenAI providers with no local fallback path.

This is a regression for workflows that depend on local compaction behavior:

  • cannot run local/plaintext compaction with OpenAI provider anymore
  • cannot reliably prepend/append deterministic context for compaction in local path
  • user-visible compaction text is often unavailable as remote output is encrypted

Relevant commits:

  • dd80e332c removed remote_compaction and made OpenAI always use remote (should_use_remote_compact_task(provider) -> provider.is_openai()).
  • ba8b5d901 made compaction failures terminal for the turn path, with no local fallback.
  • 143daadb3 further centered replacement-history processing around remote compaction output.

Code points:

This also intersects with:

  • #10336 (exposing compaction summary/prompt to users)
  • #9800 (remote compact failures)
  • #5957 (compaction-induced context loss)

What steps can reproduce the bug?

  1. Use openai provider on current main (after dd80e332).
  2. Attempt to disable remote compaction in config (features.remote_compaction) - option no longer exists.
  3. Trigger /compact or auto-compaction.
  4. Observe that compaction is forced through remote path; local compaction prompt customization path cannot be used for OpenAI provider.
  5. If remote compaction output is encrypted-only, there is no reliable plaintext compacted prompt/summary for downstream UIs and tools.

What is the expected behavior?

At least one of these should be supported:

  1. Restore a supported opt-out for remote compaction (e.g. remote_compaction=false) so OpenAI provider can use local compaction path when needed.
  2. Keep remote compaction default, but add fallback-to-local when remote compact fails.
  3. If remote-only is required, provide plaintext compaction summary/message fields through supported events/items whenever available, so users can inspect post-compaction context.

Additional information

This is distinct from pure feature requests about richer UI. It is a behavior regression in configurability and debuggability introduced by forcing remote compaction with no local escape hatch.

If the long-term direction is remote-only, please document the migration path and provide equivalent observability APIs before removing local behavior.

View original on GitHub ↗

6 Comments

etraut-openai contributor · 5 months ago

You mentioned "observability APIs". Can you say more about your use case?

ignatremizov · 5 months ago

Thank you for the reply. By "observability APIs" I mean exposing the actual post-compaction context artifact in a machine-readable way, so clients can show/debug what changed after /compact or auto-compact (ref: #5957, #10336).

My concrete use case is:

  • when a session starts forgetting state after compaction, I need to inspect what summary/prompt was actually kept
  • I also customize the compaction behavior via experimental_compact_prompt_file (for example the prompt from https://github.com/openai/codex/issues/5957#issuecomment-3831297422), and I need to verify that the resulting compacted output matches that prompt’s intent
  • in TUI/CLI wrappers, I want to display the compacted output to the user and persist it with thread_id/turn_id
  • in app-server consumers, I need the same data over RPC notifications/items (not only internal logs), so behavior is reproducible and debuggable

I prototyped this in [my fork](github.com/ignatremizov/codex) (branch feat/compact-summary-output, current commit e919d5500, codex sessions 019bbd09-72c6-76a1-abbd-d61ee9005f7b, 019c1a76-b2d5-7b90-9280-85e71bd11b07):

  • ContextCompacted carries optional summary and message
  • app-server v2 thread/compacted notification includes those fields
  • TUI shows compacted prompt/summary after compaction
  • codex exec --json emits ContextCompacted with the same payload

The main concern is: if remote compaction is forced and output is encrypted-only, downstream clients lose this observability unless there is an official plaintext field path when available.

ignatremizov · 5 months ago

Example:
<img width="695" height="780" alt="Image" src="https://github.com/user-attachments/assets/7e8e6eed-5edf-4d74-9b41-eaa5fedd09d8" />

<img width="704" height="718" alt="Image" src="https://github.com/user-attachments/assets/e790cd08-1d84-48e7-ad2f-15654760032f" />

Here after this compaction, I can know exactly what is the state. Certain variables are no longer in context. Certain discussion points are missing. Whole-summary state from beginning of thread is missing. But, it is now focused on the ongoing rebase conflict resolution work. If I just had "Context compacted." - I would have no way of knowing for sure what the model now knows/doesn't know

ignatremizov · 5 months ago

@etraut-openai having the compaction summary visible would help alleviate issues like #5957 #9734 #9743 #9800 #11174

etraut-openai contributor · 4 months ago

This feature request hasn't received enough upvotes, so closing.

ignatremizov · 4 months ago

But this would resolve many issues with compaction observability and debugging long-running sessions - you can see dozens of issues opened about this, and I proposed a concrete fix? I'll try to get more eyes on this then