Summary

Control UI can keep showing Compacting context... even when no compaction is actually running.

This appears to be a frontend stale-state bug, not necessarily a backend compaction bug.

Evidence

In the observed case:

• the UI kept showing Compacting context...
• the reply had already fully rendered
• sessions.json showed compactionCount = 0
• the corresponding transcript had 0 compaction records

So the UI state and backend/session state had diverged.

Likely root cause

The Control UI state machine appears to do this:

• on phase: "start" → set compactionStatus.active = true
• on phase: "end" → clear it

But:

• there is no stale timeout for an active compaction state
• several transition paths clear other run/stream state but do not clear compactionStatus / fallbackStatus

So if the end event is missed, or the UI switches state mid-run (session switch, reconnect, reset, send failure, etc.), the compaction badge can remain stuck indefinitely.

Expected behavior

Compacting context... should only be shown while the current session/run is actually compacting.

Actual behavior

The banner can stay stuck until refresh or manual recovery, even when no compaction is in progress.

Proposed fix

1. Add a stale timeout for active compaction state
2. Clear compactionStatus / fallbackStatus on:
   • session switch
   • clearChatState
   • reconnect / disconnect
   • agent/label switch
   • send-failure cleanup
3. Optionally bind compaction state more tightly to the active session/run identity

Environment / scope

Runtime evidence comes from a local OpenClaw 2026.3.24 install on openclaw-control-ui. Source-path reasoning is only meant to identify the likely seam, not to claim a byte-for-byte repro on latest main.

Related issues

• #39908 has a similar symptom report, but without this root-cause diagnosis
• this ticket is specifically about stale compaction status in the Control UI state machine