Skip to content

BUG: Control UI loses visible pre-compaction chat history after refresh #76415

@kAIborg24

Description

@kAIborg24

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

After an automatic compaction in a long Control UI/webchat session, the visible chat history no longer shows the earlier turn-by-turn conversation. The data is still present in checkpoint/reset transcript files, but the active chat view reloads from the compacted successor transcript and makes prior messages appear to have disappeared without an obvious user-facing explanation or recovery path.

Steps to reproduce

  1. Use a long Control UI/webchat session until automatic compaction occurs.
  2. Let the session continue after compaction.
  3. Disconnect/reconnect the Control UI or trigger a chat history refresh.
  4. Observe the visible chat transcript before and after the refresh.

Expected behavior

The Control UI should not make prior visible messages look silently lost. It should either preserve/reconstruct the visible history across compaction, show an explicit compaction boundary with enough context, or provide a clear way to view/restore the pre-compaction checkpoint from the chat view.

Actual behavior

After compaction, chat.history/Control UI displays the compacted successor transcript rather than the earlier full turn-by-turn transcript. The older transcript is retained in checkpoint/reset files and referenced by compaction checkpoint metadata, but the normal chat view makes previous assistant/user messages appear to disappear.

OpenClaw version

2026.5.2 (8b2a6e5)

Operating system

Ubuntu 26.04 LTS

Install method

Global npm/pnpm package install

Model

GPT-5.5

Provider / routing chain

OpenAI Codex Responses provider

Additional provider/model setup details

Default Control UI/webchat session using embedded agent runtime; no channel delivery needed to reproduce.

Logs, screenshots, and evidence

Observed evidence from one affected session:
- Active session metadata recorded `compactionCount: 9`.
- Latest compaction checkpoint reason was `overflow-retry`, with `tokensBefore: 157947` and `tokensAfter: 23010`.
- The checkpoint metadata references both a pre-compaction checkpoint transcript and a post-compaction active transcript.
- The active transcript starts with the post-reset/post-compaction successor session and contains a persisted `compaction` entry plus only the later tail of the conversation.
- The old full transcript was still present in checkpoint/reset JSONL files, so this is not confirmed data loss. It is a visible-history/UX/history-projection problem.
- Gateway logs around the observed event showed successful `chat.history` responses and no crash/error.

Impact and severity

Medium. In long-running sessions, users can believe assistant/user messages were deleted or lost after compaction even though checkpoint files still exist. This is especially confusing during debugging or operational work where the visible chat history is treated as the audit trail.

Additional information

This may be expected internally because compaction rotates to a compacted successor transcript, but the current Control UI behavior is surprising: the chat view does not clearly explain that older turn-by-turn messages moved behind a compaction checkpoint. A maintainer-friendly fix could be either a history projection change or a clear compaction checkpoint affordance in the chat UI.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingbug:behaviorIncorrect behavior without a crash

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions