openclaw - 💡(How to fix) Fix `/status` can report stale pre-compaction totals for already-compacted sessions [1 participants]

Summary

For already-compacted sessions, /status can still report stale pre-compaction context totals (for example 151k/128k) even after the live prompt has already been reduced.

This appears to happen when status rendering prefers an older store snapshot or a whole-transcript estimate that still reflects the pre-compaction history.

User-visible symptoms

In our repro on a Telegram thread session:

• compaction had already succeeded
• the agent itself could report a much smaller live context after compaction
• but /status still showed a large pre-compaction number like 149k/128k, then 151k/128k

So operators saw a status card that looked like the session was still over budget, even though the prompt had already been reduced.

Repro shape

1. Drive a session past compaction threshold.
2. Let compaction succeed.
3. Keep an older larger session total or a whole-transcript estimate available.
4. Call /status.

Observed:

• /status can prefer the stale larger total
• the reported context usage can jump back to pre-compaction values

Expected:

• once a session has compacted, /status should prefer:
  • a trustworthy post-compaction snapshot, or
  • unknown
• it should not present a stale pre-compaction total as current truth for the active session

Why this matters

This is operationally misleading:

• it makes it look like compaction did not work
• it makes ordinary chat look unsafe even when the reduced prompt is actually fine
• it makes it much harder to debug real compaction problems because stale display and real runtime state diverge

Related issue

This is adjacent to #45268, which covers misleading status output when totalTokensFresh=false.

This issue is narrower and later in the lifecycle:

• the session has already compacted
• the problem is that /status can still prefer a stale pre-compaction total or transcript-wide estimate instead of post-compaction truth