Skip to content

Regression: forced remote compaction removes local fallback and compaction visibility #10986

Closed as not planned
Closed as not planned
Regression: forced remote compaction removes local fallback and compaction visibility#10986
Labels
contextIssues related to context management (including compaction)enhancementNew feature or requestsessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@ignatremizov
ignatremizov
opened on Feb 7, 2026

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:

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.

Activity

  1. etraut-openai commented on Feb 7, 2026

    @etraut-openai
    etraut-openai
    on Feb 7, 2026
    Contributor

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

  2. etraut-openai
    added
    enhancementNew feature or request
    contextIssues related to context management (including compaction)
    agentIssues related to the core agent loop
    on Feb 7, 2026

  3. ignatremizov commented on Feb 7, 2026

    @ignatremizov
    ignatremizov
    on Feb 7, 2026
    Author

    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 Auto compaction causes GPT-5-Codex to lose the plot. It forgets it is mid-task, forgets it has edited files and stops. #5957 (comment)), 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 (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.

  4. ignatremizov commented on Feb 7, 2026

    @ignatremizov
    ignatremizov
    on Feb 7, 2026
    Author

    Example:
    Image

    Image

    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

  5. ignatremizov commented on Feb 9, 2026

    @ignatremizov
    ignatremizov
    on Feb 9, 2026
    Author

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

  6. etraut-openai commented on Mar 20, 2026

    @etraut-openai
    etraut-openai
    on Mar 20, 2026
    Contributor

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

  7. etraut-openai
    closed this as not plannedon Mar 20, 2026

  8. ignatremizov commented on Mar 21, 2026

    @ignatremizov
    ignatremizov
    on Mar 21, 2026
    Author

    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

  9. etraut-openai
    added
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    and removed
    agentIssues related to the core agent loop
    on Apr 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    contextIssues related to context management (including compaction)enhancementNew feature or requestsessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions