Expose compaction summary/prompt to users (keep thread/compacted or add fields to contextCompaction)

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

Variant: CLI (TUI + app-server v2)

What feature would you like to see?

Expose the compacted summary/prompt to users. Please keep thread/compacted (legacy) or add summary?: string / message?: string to contextCompaction so clients can show what’s actually in context after compaction.

Additional information

When a thread auto-compacts (or when the user runs /compact), users lose visibility into what the model now actually has in-context. This makes it very hard to understand or debug behavior changes after compaction, and it erodes trust when the agent forgets/denies earlier work.

A concrete example is openai/codex#5957, where auto-compaction caused the agent to forget it had edited files and it confidently denied having made those edits.

Current state

Recent work introduced contextCompaction as a v2 ThreadItem / item lifecycle marker (see the recent compaction work, e.g. #10034 and the item notification tests in #10123). However, contextCompaction currently only carries { id }.

At the same time, the existing thread/compacted notification (ContextCompactedNotification) can carry summary and the full compacted message (prompt), but it is now marked Deprecated: Use ContextCompaction item type instead.

Potential regression risk

If thread/compacted is removed before there is an equivalent replacement, this is a user-visible regression for downstream clients that already surface compaction summaries/prompts. It would remove the only way to debug what the model actually kept after compaction.

Request

Please don't remove/deprecate the only user-visible carrier of compaction text until there's an equivalent replacement.

Two viable options:
1) Keep thread/compacted (ContextCompactedNotification) as a supported event (even if marked legacy), because it's extremely useful for users/UIs to show the compacted summary and/or compacted prompt.
2) Alternatively, extend the contextCompaction item to include summary?: string and message?: string (optional) so new clients can rely purely on the item stream. Then thread/compacted can be deprecated later with a clear timeline.

Why this matters

Showing the compacted text lets the user immediately see why the agent forgot or misunderstood something after compaction. It also helps debugging support requests, since a repro often hinges on whether compaction dropped key state.

Implementation note

For providers/paths where plaintext isn't available (e.g. remote compaction that can return encrypted content), summary/message can simply be omitted; but when available, exposing them to the UI is very valuable.

Ref

"compaction" #10034

View original on GitHub ↗

5 Comments

ignatremizov · 6 months ago

@aibrahim-oai

ignatremizov · 6 months ago

I implemented the TUI display for the compacted summary/prompt in [my fork](github.com/ignatremizov/codex): commit e85f124e8 on branch feat/compact-summary-output. It shows the compacted text after compaction so users can see what the model retained.

This currently relies on the thread/compacted (ContextCompactedNotification) payload to get summary/message. If compacted is removed without an equivalent summary/message on contextCompaction, the TUI won’t be able to show compaction summaries at all.

ignatremizov · 6 months ago

FYI: PR #10445 (“Add thread/compact v2”) is now merged. It adds thread/compact/start as a trigger-only v2 RPC that returns {} immediately and emits only item/started/item/completed with ThreadItem::ContextCompaction { id }. No summary/message fields were added to the item stream.

So the visibility gap remains: v2 compaction still has no carrier for compacted summary/prompt. This issue is still the only place tracking that need. Extending ContextCompaction with optional summary / message (or keeping thread/compacted around) still seems necessary.

@aibrahim-oai

etraut-openai contributor · 5 months ago

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

ignatremizov · 5 months ago

Just because it's not popular, doesn't mean it's not a critical improvement to everyone's workflows and can resolve issues like #5957

I'll try to get more eyes on this then. I wasn't aware you have the policy to close issues with not enough visibility.