openclaw - ✅(Solved) Fix [Feature]: Add a recent/top-of-mind continuity layer for recovery-first memory [1 pull requests, 2 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#60742Fetched 2026-04-08 02:47:43
View on GitHub
Comments
2
Participants
1
Timeline
3
Reactions
0
Author
Participants
Timeline (top)
commented ×2cross-referenced ×1

Add a recent/top-of-mind continuity layer so OpenClaw can recover the current in-flight work state more reliably across /new, /reset, and compaction boundaries.

Problem to solve

OpenClaw already has transcripts, session memory, retrieval, QMD, and long-term workspace memory. Those pieces preserve history, but they do not always preserve the clearest current working state.

In long-running workflows, the failure mode is often not “no memory,” but:

  • the agent has too much undifferentiated history
  • the active task/blocker/next step is not prominent enough
  • /new or /reset preserves archives but still makes the next turn feel detached
  • compaction preserves content in aggregate, but not always in the most recovery-friendly form

This feels different from:

  • sessionMemory graduation (#51386), which is about indexing transcript history across sessions/channels
  • long-term memory lifecycle proposals like ranking/consolidation/forgetting (#51385)
  • cross-session shared daily logs (#57543)

This request is narrower:

it is about preserving and reading the current active state first.

Proposed solution

Add an additive “recent continuity” layer, for example:

  • memory/recent/latest.md
  • memory/recent/snapshots/*.md

This layer would store a small structured snapshot of the current in-flight work state:

  • current primary task
  • current phase
  • latest explicit user ask
  • active blocker
  • next step
  • touched files/systems when useful

Suggested behavior:

  1. On /new and /reset

    • keep existing archive behavior
    • also write a recent continuity snapshot
  2. On session:compact:before

    • write/update the recent continuity snapshot
    • do not require a full archive note for this path
  3. On recovery/post-compaction context refresh

    • read the recent continuity snapshot before broader long-term history
  4. Keep this additive

    • do not replace QMD
    • do not replace transcripts
    • do not replace vector memory

Proposed recovery direction:

  1. recent continuity
  2. active topics / project anchor
  3. broader memory recall

Alternatives considered

  1. Rely only on transcript/session indexing

    • good for recall, weak for current-state prioritization
  2. Rely only on manual MEMORY.md / project anchors

    • works, but is too manual and inconsistent for high-frequency state changes
  3. Jump directly to a full memory lifecycle system

    • too large a first step and harder to review safely

Impact

Affected:

  • long-running engineering workflows
  • users who rely on compaction and /new//reset
  • users who expect the assistant to resume active work, not just retrieve old facts

Severity:

  • medium to high for heavy users

Frequency:

  • frequent in long-running sessions and project work

Consequence:

  • partial “amnesia” feeling
  • repeated restating of active task/blocker/next step
  • loss of trust in continuity across resets/compaction

Evidence/examples

Related upstream issues:

  • #51386 — sessionMemory graduation (cross-session transcript recall)
  • #51385 — frequency-aware ranking / consolidation / forgetting
  • #57543 — cross-session shared daily memory log

Local prototype work already exists for this narrower slice:

  • recent continuity file protocol
  • snapshot generation on reset/new/compaction
  • post-compaction context integration
  • focused tests and type-check pass locally

If useful, I can open the implementation as a small focused PR rather than a broad memory rewrite.

Additional information

GitHub Discussions appear to be disabled on this repository right now, so I’m filing this as a feature request issue rather than a Discussion thread.

My intent is not to propose a full memory rewrite.

The intended upstream shape is incremental:

  • first: recent/top-of-mind continuity layer
  • later: scoped retrieval/freshness
  • later: rollback-friendly promotion
  • later: experimental background cleanup

Root Cause

Add a recent/top-of-mind continuity layer so OpenClaw can recover the current in-flight work state more reliably across /new, /reset, and compaction boundaries.

Problem to solve

OpenClaw already has transcripts, session memory, retrieval, QMD, and long-term workspace memory. Those pieces preserve history, but they do not always preserve the clearest current working state.

In long-running workflows, the failure mode is often not “no memory,” but:

  • the agent has too much undifferentiated history
  • the active task/blocker/next step is not prominent enough
  • /new or /reset preserves archives but still makes the next turn feel detached
  • compaction preserves content in aggregate, but not always in the most recovery-friendly form

This feels different from:

  • sessionMemory graduation (#51386), which is about indexing transcript history across sessions/channels
  • long-term memory lifecycle proposals like ranking/consolidation/forgetting (#51385)
  • cross-session shared daily logs (#57543)

This request is narrower:

it is about preserving and reading the current active state first.

Proposed solution

Add an additive “recent continuity” layer, for example:

  • memory/recent/latest.md
  • memory/recent/snapshots/*.md

This layer would store a small structured snapshot of the current in-flight work state:

  • current primary task
  • current phase
  • latest explicit user ask
  • active blocker
  • next step
  • touched files/systems when useful

Suggested behavior:

  1. On /new and /reset

    • keep existing archive behavior
    • also write a recent continuity snapshot
  2. On session:compact:before

    • write/update the recent continuity snapshot
    • do not require a full archive note for this path
  3. On recovery/post-compaction context refresh

    • read the recent continuity snapshot before broader long-term history
  4. Keep this additive

    • do not replace QMD
    • do not replace transcripts
    • do not replace vector memory

Proposed recovery direction:

  1. recent continuity
  2. active topics / project anchor
  3. broader memory recall

Alternatives considered

  1. Rely only on transcript/session indexing

    • good for recall, weak for current-state prioritization
  2. Rely only on manual MEMORY.md / project anchors

    • works, but is too manual and inconsistent for high-frequency state changes
  3. Jump directly to a full memory lifecycle system

    • too large a first step and harder to review safely

Impact

Affected:

  • long-running engineering workflows
  • users who rely on compaction and /new//reset
  • users who expect the assistant to resume active work, not just retrieve old facts

Severity:

  • medium to high for heavy users

Frequency:

  • frequent in long-running sessions and project work

Consequence:

  • partial “amnesia” feeling
  • repeated restating of active task/blocker/next step
  • loss of trust in continuity across resets/compaction

Evidence/examples

Related upstream issues:

  • #51386 — sessionMemory graduation (cross-session transcript recall)
  • #51385 — frequency-aware ranking / consolidation / forgetting
  • #57543 — cross-session shared daily memory log

Local prototype work already exists for this narrower slice:

  • recent continuity file protocol
  • snapshot generation on reset/new/compaction
  • post-compaction context integration
  • focused tests and type-check pass locally

If useful, I can open the implementation as a small focused PR rather than a broad memory rewrite.

Additional information

GitHub Discussions appear to be disabled on this repository right now, so I’m filing this as a feature request issue rather than a Discussion thread.

My intent is not to propose a full memory rewrite.

The intended upstream shape is incremental:

  • first: recent/top-of-mind continuity layer
  • later: scoped retrieval/freshness
  • later: rollback-friendly promotion
  • later: experimental background cleanup

Fix Action

Fixed

PR fix notes

PR #60743: memory: add recent continuity snapshots

Description (problem / solution / changelog)

Summary

Describe the problem and fix in 2–5 bullets:

  • Problem: long-running sessions can keep transcripts and memory archives but still lose the clearest current in-flight state across /new, /reset, and compaction.
  • Why it matters: the next turn can feel detached even when history exists, which shows up as partial continuity loss rather than missing storage.
  • What changed: add an additive memory/recent continuity layer with latest.md plus timestamped snapshots, wire it into reset/new, compact-before, and post-compaction recovery, and place the continuity helpers under the current packages/memory-host-sdk layout used by upstream main.
  • What did NOT change (scope boundary): no retrieval ranking changes, no rollback journal/promotion, no dream/background scheduler, and no replacement of QMD/vector memory/transcripts.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #
  • Related #60742
  • This PR fixes a bug or regression

Root Cause (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

  • Root cause: N/A
  • Missing detection / guardrail: N/A
  • Contributing context (if known): N/A

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should catch this. Otherwise write N/A.

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: N/A
  • Scenario the test should lock in: N/A
  • Why this is the smallest reliable guardrail: N/A
  • Existing test that already covers this (if any): N/A
  • If no new test is added, why not: feature slice, not a regression fix

User-visible / Behavior Changes

  • /new and /reset still write archive notes, and now also write a recent continuity snapshot.
  • session:compact:before writes a recent continuity snapshot without requiring a full archive note.
  • Post-compaction recovery can read the recent continuity layer before broader history.

Diagram (if applicable)

Before:
[active work] -> [reset/compact] -> [broad history survives] -> [current task state is less obvious]

After:
[active work] -> [recent continuity snapshot] -> [reset/compact] -> [recent state restored first]

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) Yes
  • If any Yes, explain risk + mitigation:
    • The runtime now writes an additional recent continuity file in the existing workspace memory area.
    • Mitigation: additive only, same workspace boundary, no new external transport, and no broader retrieval/promotion behavior in this slice.

Repro + Verification

Environment

  • OS: macOS
  • Runtime/container: local development checkout
  • Model/provider: N/A for core file-writing/recovery wiring; continuity extraction helper covered in local test flow
  • Integration/channel (if any): none
  • Relevant config (redacted): default local workspace memory flow

Steps

  1. Trigger /new or /reset on a session with active work state.
  2. Trigger session:compact:before and inspect the resulting workspace memory files.
  3. Run post-compaction recovery context generation.

Expected

  • memory/recent/latest.md and snapshots reflect the current in-flight task state.
  • Recovery helpers surface recent continuity before broader history.

Actual

  • Local tests pass for continuity parsing/rendering, archive/reset wiring, compaction safeguard context, and post-compaction refresh.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Focused validation run locally:

  • packages/memory-host-sdk/src/host/continuity.test.ts
  • src/hooks/bundled/session-memory/handler.test.ts
  • src/auto-reply/reply/post-compaction-context.test.ts
  • src/agents/pi-hooks/compaction-safeguard.test.ts
  • Result: 4 files, 132 tests passed
  • tsc -p tsconfig.json --noEmit passed

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios:
    • recent continuity documents render and parse round-trip
    • material-change detection avoids noisy snapshot rewrites
    • reset/new paths continue archive writes and add continuity writes
    • post-compaction helpers and safeguard summaries include recent continuity
  • Edge cases checked:
    • timestamp-only changes do not force rewrites
    • compact-before path can write continuity without full archive note
  • What you did not verify:
    • live rollout against an actively running production workspace

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps:

Risks and Mitigations

  • Risk:
    • Recent continuity snapshots could add noise if written too often.
    • Mitigation:
      • material-change detection avoids rewriting on trivial timestamp-only changes.
  • Risk:
    • Review scope could sprawl into broader memory architecture discussion.
    • Mitigation:
      • this slice is intentionally limited to recent continuity only, with follow-up work kept out of this PR.

Changed files

  • packages/memory-host-sdk/src/host/continuity.test.ts (added, +180/-0)
  • packages/memory-host-sdk/src/host/continuity.ts (added, +637/-0)
  • src/agents/pi-hooks/compaction-safeguard.test.ts (modified, +35/-0)
  • src/agents/pi-hooks/compaction-safeguard.ts (modified, +34/-7)
  • src/auto-reply/reply/post-compaction-context.test.ts (modified, +73/-0)
  • src/auto-reply/reply/post-compaction-context.ts (modified, +55/-21)
  • src/hooks/bundled/session-memory/handler.test.ts (modified, +154/-17)
  • src/hooks/bundled/session-memory/handler.ts (modified, +200/-59)
  • src/hooks/llm-session-memory.ts (added, +192/-0)
RAW_BUFFERClick to expand / collapse

Summary

Add a recent/top-of-mind continuity layer so OpenClaw can recover the current in-flight work state more reliably across /new, /reset, and compaction boundaries.

Problem to solve

OpenClaw already has transcripts, session memory, retrieval, QMD, and long-term workspace memory. Those pieces preserve history, but they do not always preserve the clearest current working state.

In long-running workflows, the failure mode is often not “no memory,” but:

  • the agent has too much undifferentiated history
  • the active task/blocker/next step is not prominent enough
  • /new or /reset preserves archives but still makes the next turn feel detached
  • compaction preserves content in aggregate, but not always in the most recovery-friendly form

This feels different from:

  • sessionMemory graduation (#51386), which is about indexing transcript history across sessions/channels
  • long-term memory lifecycle proposals like ranking/consolidation/forgetting (#51385)
  • cross-session shared daily logs (#57543)

This request is narrower:

it is about preserving and reading the current active state first.

Proposed solution

Add an additive “recent continuity” layer, for example:

  • memory/recent/latest.md
  • memory/recent/snapshots/*.md

This layer would store a small structured snapshot of the current in-flight work state:

  • current primary task
  • current phase
  • latest explicit user ask
  • active blocker
  • next step
  • touched files/systems when useful

Suggested behavior:

  1. On /new and /reset

    • keep existing archive behavior
    • also write a recent continuity snapshot
  2. On session:compact:before

    • write/update the recent continuity snapshot
    • do not require a full archive note for this path
  3. On recovery/post-compaction context refresh

    • read the recent continuity snapshot before broader long-term history
  4. Keep this additive

    • do not replace QMD
    • do not replace transcripts
    • do not replace vector memory

Proposed recovery direction:

  1. recent continuity
  2. active topics / project anchor
  3. broader memory recall

Alternatives considered

  1. Rely only on transcript/session indexing

    • good for recall, weak for current-state prioritization
  2. Rely only on manual MEMORY.md / project anchors

    • works, but is too manual and inconsistent for high-frequency state changes
  3. Jump directly to a full memory lifecycle system

    • too large a first step and harder to review safely

Impact

Affected:

  • long-running engineering workflows
  • users who rely on compaction and /new//reset
  • users who expect the assistant to resume active work, not just retrieve old facts

Severity:

  • medium to high for heavy users

Frequency:

  • frequent in long-running sessions and project work

Consequence:

  • partial “amnesia” feeling
  • repeated restating of active task/blocker/next step
  • loss of trust in continuity across resets/compaction

Evidence/examples

Related upstream issues:

  • #51386 — sessionMemory graduation (cross-session transcript recall)
  • #51385 — frequency-aware ranking / consolidation / forgetting
  • #57543 — cross-session shared daily memory log

Local prototype work already exists for this narrower slice:

  • recent continuity file protocol
  • snapshot generation on reset/new/compaction
  • post-compaction context integration
  • focused tests and type-check pass locally

If useful, I can open the implementation as a small focused PR rather than a broad memory rewrite.

Additional information

GitHub Discussions appear to be disabled on this repository right now, so I’m filing this as a feature request issue rather than a Discussion thread.

My intent is not to propose a full memory rewrite.

The intended upstream shape is incremental:

  • first: recent/top-of-mind continuity layer
  • later: scoped retrieval/freshness
  • later: rollback-friendly promotion
  • later: experimental background cleanup

extent analysis

TL;DR

Implementing a "recent continuity" layer to store a small structured snapshot of the current in-flight work state can help OpenClaw recover the current working state more reliably across /new, /reset, and compaction boundaries.

Guidance

  • Consider adding a memory/recent/latest.md file and memory/recent/snapshots/*.md directory to store recent continuity snapshots, containing information such as the current primary task, phase, and next step.
  • Update the behavior of /new and /reset to write a recent continuity snapshot, and update the session:compact:before behavior to write/update the recent continuity snapshot without requiring a full archive note.
  • Prioritize reading the recent continuity snapshot before broader long-term history during recovery/post-compaction context refresh.
  • Ensure the recent continuity layer is additive and does not replace existing memory mechanisms such as QMD, transcripts, or vector memory.

Example

No explicit code example is provided, but the proposed solution suggests using Markdown files to store recent continuity snapshots, such as memory/recent/latest.md and memory/recent/snapshots/*.md.

Notes

The implementation of the recent continuity layer should be incremental, with a focus on preserving the current active state first, and later expanding to include scoped retrieval, freshness, and rollback-friendly promotion.

Recommendation

Apply the proposed workaround by implementing the recent continuity layer, as it provides a targeted solution to the problem of preserving the current working state across /new, /reset, and compaction boundaries, without requiring a full memory rewrite.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING