openclaw - 💡(How to fix) Fix [Feature]: surface promote-then-rotate suggestion when session context overflow trips repeatedly [1 comments, 2 participants]

Summary

When session-level context overflow trips repeatedly on the same session ([context-overflow-diag] compactionAttempts), surface a one-time promote-then-rotate suggestion to the operator with a pre-computed dry-run of memory promote candidates, plus a one-click confirm to (a) promote the candidates and (b) archive + rotate the session.

Problem to solve

Today, when a long-running agent session bloats past safe context bounds, OpenClaw fires auto-compaction (in-place trim during the active tool loop). This works for small overflows but is fragile mid-tool-call and silently degrades long sessions.

The cleaner workflow — extract the durable bits to long-term memory, archive the transcript, spawn fresh — is supported (openclaw memory promote --apply then archive transcript + remove from sessions.json) but operators don't know to invoke it until they notice symptoms like degraded responses, repeated overflow events, or visible session bloat.

The result: sessions accumulate hundreds of messages of state, compaction fights an unwinnable battle, and the durable bits the operator would have wanted to preserve in MEMORY.md quietly age out via compaction instead.

This is the gap we hit running RentalClaw on habitat: a 397-message agent:main:main session, compactionAttempts=0 log line firing for the first time at the moment of overflow, and no proactive nudge from the system to consider the cleaner promote-then-rotate path. By the time we noticed and decided to rotate, compaction had already trimmed the very messages we would have wanted promoted.

Proposed solution

Detection signal. Trip a lifecycle suggestion when any of:

• A session's compactionAttempts exceeds threshold within a window (default: 3 attempts in 24h).
• Session context utilization stays above threshold for N consecutive tool turns post-compaction (default: >50% for >20 turns).

Pre-compute candidates. When the signal trips, run memory promote (or rem-harness) in dry-run mode against the session and assemble the candidate list once.

Surface. Emit a structured [lifecycle-suggestion] log line carrying the candidate count and a stable correlation id. If a UI / notification surface exists, fire a notification with three actions: Promote + rotate / Promote only / Dismiss. The CLI shows the suggestion next time the operator runs openclaw sessions or openclaw memory status.

Stay opt-in for auto-execution. Surfacing the suggestion is the default. Auto-firing the rotate without operator confirmation requires explicit config:

{
  "agents": {
    "defaults": {
      "lifecycle": {
        "suggestPromoteRotateOnOverflow": true,
        "autoPromoteRotateOnOverflow": false
      }
    }
  }
}

The judgment call about which messages to memorize stays under operator control because the cost of getting it wrong silently is high (under-promote → lose context; over-promote → memory pollution per #67363, #66287, #72887).

Alternatives considered

1. Just rely on compaction. Current default. Loses durable context indiscriminately during tool loops; the operator has no nudge to switch to the cleaner path until symptoms become visible.
2. Auto-fire promote-then-rotate on overflow without confirmation. Risky — promotes the wrong messages or strips context the operator was relying on. Same reasons #72887 wants a review queue before auto-writes to MEMORY.md.
3. Manual operator vigilance via openclaw memory status checks. Works for disciplined operators; doesn't scale and loses to "I'll get to it later." The gap this issue is filing against.

Impact

• Affected: Operators running long-lived default / main agent sessions (every personal-assistant deployment with >1 day of active use).
• Severity: Medium. Compaction does prevent hard failures but degrades long-session quality and silently discards content the operator would have wanted to preserve.
• Frequency: Every long-running session eventually trips overflow; currently always falls into the fragile compaction path.
• Consequence: Loss of durable context, harder post-hoc memory recovery from archived transcripts, and a manual operational task ("remember to rotate session N before it bloats") that's easy to forget.

Evidence/examples

Concrete instance from our RentalClaw deployment on habitat (gateway image ghcr.io/openclaw/openclaw:2026.4.25):

[2026-04-28T23:51:24] [agent/embedded] [context-overflow-diag]
  sessionKey=agent:main:main
  provider=openai-codex/gpt-5.4
  source=assistantError
  messages=397
  sessionFile=/home/node/.openclaw/agents/main/sessions/87e3158a-...jsonl
  compactionAttempts=0
  observedTokens=unknown
  error=Context overflow: estimated context size exceeds safe threshold during tool loop.
[2026-04-28T23:51:24] [agent/embedded] context overflow detected (attempt 1/3); attempting auto-compaction

agent:main:main session was at 146k/272k tokens (54%) after compaction — still bloated, with 397 raw messages of accumulated state, and no signal to the operator that promote-then-rotate would have been the better path. By the time we noticed and ran openclaw memory promote, compaction had already trimmed whatever it deemed expendable.

Related issues

• #66287 — single-occurrence important events bypassed by promotion scoring (would benefit from review-queue surface before auto-write).
• #67363 — raw verbatim daily-log snippets promoted without distillation (related quality-of-promotion concern).
• #72887 — review queue before writing deep-promoted candidates to MEMORY.md (adjacent: gates the output of dreaming auto-promotion; this issue gates the invocation of promotion based on session-overflow signals).

Additional information

• The detection signal already exists — [context-overflow-diag] is emitted with the relevant fields.
• The memory promote CLI (when working — see #72882 and the chokidar fix in 2026.4.26) already supports dry-run via the absence of --apply.
• The rotation step (archive transcript + remove from sessions.json) is already a documented operator workflow.
• This issue is about wiring the existing pieces together at the lifecycle-suggestion layer, not building new memory machinery.