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

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 #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