[Feature]: Show compaction state and result instead of a generic "Working" #7652

What

When a provider compacts a thread, the timeline shows Working for N, exactly like any other work. Nothing says compaction is running, how long it has been running, or whether it succeeded. On a long compaction the only honest read of the UI is "something is happening".

Proposal

Give compaction its own timeline state, and a result line when it lands:

Deliberately no percentage or progress bar. No provider emits real compaction progress — the Claude Code CLI's own compaction bar is a pure function of elapsed time (1 − e^(−elapsed/90s), capped at 95%; it snaps to done when the operation finishes). Replicating a synthetic bar is possible but it would be a lying spinner, so this proposal sticks to what is true: the state, the elapsed time, and the result.

What each provider gives us

So three of five providers can feed a shared "compacting" thread state, and per AGENTS.md the ACP pair get an explicit "not supported here".

Where the code stands

• Claude: ClaudeAdapter.ts:3119 reads status:"compacting" but flattens it into the generic waiting session state — that is why the UI says Working. The compact_boundary already becomes a context-compaction activity (ProviderRuntimeIngestion.ts:744, summary "Context compacted") with the raw compact_metadata in its payload, so the result line is mostly a client-rendering task. compact_result/compact_error appear nowhere in the repo — a failed compaction is indistinguishable from a successful one.
• Codex: CodexAdapter.ts maps compaction items to the canonical context_compaction type, but ingestion filters item lifecycle events to tool types (ProviderRuntimeIngestion.ts:847), so both the start and completion of a Codex compaction are dropped. Codex compaction visibility currently rests entirely on the deprecated thread/compacted notification; wiring the item fixes that.
• OpenCode: OpenCodeAdapter.ts handles none of the compaction signals.
• Nothing in apps/web references context compaction at all — every compact hit in the web client is layout density.

Suggested shape

1. A compacting state on the shared thread/session contract that any adapter can raise and clear, rendered as the "Compacting context" row with a client-side elapsed timer.
2. The completion row rendered from the existing context-compaction activity, with token delta and duration where the provider supplies them (Claude), plain "Context compacted" where it does not.
3. A failure variant fed by Claude's compact_result:"failed"/compact_error.

Stacked per-adapter PRs on top of the contract change would fit how this decomposes.

Related

#7589 — a heartbeat with no turn stranded a thread on Working forever after /compact. The fix stops the stranding, but compaction that outlives its turn surfaces nothing at all, which makes this gap more visible rather than less.

Screenshots are the real timeline row with the proposed states patched in.