[Feature]: Pre-reset agentic memory flush — /new and daily reset should get the same memory flush as compaction

[kamikariat]

Summary

Run a silent agentic memory flush before /new, /reset, and the daily reset destroy the session, using the same mechanism that already runs before compaction.

Problem to solve

When a session nears compaction, OpenClaw runs a silent agentic turn (runMemoryFlushIfNeeded) where the agent writes curated notes to memory/YYYY-MM-DD.md before context is compressed. This works well.

When a user sends /new or /reset — or when the daily reset fires automatically — the session is destroyed with no agentic flush. The only safety net is the session-memory hook, which mechanically dumps the last 15 raw messages into a file. The agent never gets a chance to curate what matters, update MEMORY.md, or write structured notes.

(There's also a separate bug where the hook's output uses slugged filenames that the boot sequence doesn't read — #45607.)

The asymmetry:

• Compaction → agentic flush (agent decides what to save) ✅
• /new and /reset → mechanical dump (raw messages, no curation) ❌
• Daily reset → same mechanical dump, triggered silently every morning ❌

The daily reset is the big one. The default reset mode is daily with atHour: 4 (src/config/sessions/reset.ts:22-23). Every user hits it at least once per day without any manual action. Any context from the previous day that wasn't written to disk is gone.

Proposed solution

Before destroying the session on /new or /reset, run a silent agentic turn (same pattern as runMemoryFlushIfNeeded) that gives the agent a chance to write durable memories to disk.

Behavior:

1. User sends /new (or /reset)
2. Gateway detects reset trigger (existing code in initSessionState)
3. New step: Before minting the new sessionId, run a silent pre-reset memory flush turn against the current session
4. The agent writes any durable notes to memory/YYYY-MM-DD.md (or MEMORY.md), then replies NO_REPLY
5. Session is destroyed, new session starts (existing behavior)
6. session-memory hook fires as before (raw dump is still useful as backup / audit trail)

Most of the infrastructure already exists:

• runMemoryFlushIfNeeded in src/auto-reply/reply/agent-runner-memory.ts:253
• before_reset plugin hook in src/plugins/types.ts:541
• NO_REPLY suppression for silent turns
• Daily memory checkpoint (shouldRunDailyMemoryCheckpoint in src/auto-reply/reply/memory-flush.ts:196) already extends the flush beyond compaction

The main work is wiring runMemoryFlushIfNeeded (or a variant) into the reset path before the session is destroyed.

Guards:

• Skip for empty sessions (no turns = no flush)
• Skip for CLI and read-only workspaces (same as existing compaction flush)
• Timeout cap (~30s) so /new doesn't feel stuck
• One flush per reset (track in session entry)

Alternatives considered

1. Status quo (session-memory hook only): Dumps raw messages, no curation. Agent can't decide what matters. Output uses slugged filenames the boot sequence can't read ([Bug]: session-memory hook writes files the boot sequence never reads #45607).
2. Make session-memory hook agentic: Run an LLM call inside the hook. Viable but the hook is fire-and-forget with no access to the agent's tools or workspace context. The existing pre-compaction flush already has the right infrastructure.
3. Add a /save command: Explicit user-triggered flush. Works but puts the burden on the user and doesn't help when they forget (or for the daily reset).
4. Background flush after reset: Destroy session immediately, flush archived transcript in background. Preserves instant /new feel but requires reconstructing agent context from archived JSONL.

Impact

• Affected: Every OpenClaw user (daily reset is default behavior)
• Severity: Medium — silent memory loss every day
• Frequency: At least once per day per user (daily reset), plus every manual /new or /reset
• Consequence: Agent loses learned context between sessions; users with memory-heavy workloads (personal assistants) are most impacted

Evidence/examples

I wrote a detailed proposal with source code references, full design history, and recent commit analysis at docs/proposals/pre-reset-memory-flush.md in my fork. Key findings:

• The pre-compaction memory flush was designed for compaction (Jan 12 2026, 7dbb21be8) and never extended to resets
• When /new was first added (Dec 4 2025, 34eb75f63), there was no workspace memory system
• The daily memory checkpoint (1146b3664 by @PotatoParser, Mar 5 2026) was the first acknowledgment that compaction-only wasn't sufficient — but it only covers active sessions, not sessions that ended before the boundary
• The session-memory hook and before_reset plugin hook (Feb 14 2026, ab71fdf82) provide mechanical preservation but no agentic curation
• The post-reset boot sequence has been carefully built up, but the pre-reset teardown path has no agentic save step

Additional information

Open questions:

1. Blocking vs background: Should /new block until the flush completes, or start the new session immediately and flush in the background?
2. Config location: compaction.memoryFlush.onReset (extends existing) vs session.reset.memoryFlush (cleaner separation)?
3. Daily reset: Should it also get a flush? Options: background flush on next message, proactive "bedtime flush" via heartbeat before atHour, or accept daily checkpoint is good enough for that case.
4. Interaction with session-memory hook: Keep both? The hook provides raw audit trail; the agentic flush provides curated memory. They serve different purposes and can coexist.

Related: #45607 (session-memory naming mismatch bug)

[kamikariat]

Proposal: Pre-Reset Agentic Memory Flush

Summary

Run a silent agentic memory flush before /new and /reset destroy the
session, using the same mechanism that already runs before compaction.

Additionally: the existing session-memory hook writes files that the
boot sequence never reads — a naming mismatch that makes the current
safety net effectively invisible.

Bug: session-memory hook output is invisible to boot

The session-memory hook and the boot sequence were built independently
with no contract between them. The hook writes files the agent never reads
on startup.

What the hook writes (on /new or /reset):

memory/YYYY-MM-DD-slug.md — e.g. memory/2026-03-13-memory-search.md

(src/hooks/bundled/session-memory/handler.ts:315 — const filename = \${dateStr}-${slug}.md``)

What the boot sequence reads (on session start):

memory/YYYY-MM-DD.md — e.g. memory/2026-03-13.md

(AGENTS.md:15 — "Read memory/YYYY-MM-DD.md (today + yesterday)")

These are different files. The agent on boot looks for
memory/2026-03-13.md, which doesn't exist. The actual content from the
previous session is sitting in memory/2026-03-13-memory-search.md,
never read.

The pre-compaction flush gets this right. It explicitly bans the slug
pattern to ensure output goes to the canonical file:

"Do NOT create timestamped variant files (e.g., YYYY-MM-DD-HHMM.md);
always use the canonical YYYY-MM-DD.md filename."

(src/auto-reply/reply/memory-flush.ts:21 — DEFAULT_MEMORY_FLUSH_PROMPT)

The only path that picks up slugged files is memory_search — which
indexes all memory/*.md files regardless of naming. But if
memory_search is unavailable (e.g. QMD not installed, embeddings not
configured), the hook's output is completely lost.

System	Writes to	Reads from
Pre-compaction flush	memory/YYYY-MM-DD.md (canonical)	—
session-memory hook	memory/YYYY-MM-DD-slug.md (slugged)	—
Boot sequence (AGENTS.md)	—	memory/YYYY-MM-DD.md (canonical)
Post-compaction injection	—	memory/YYYY-MM-DD.md (via AGENTS.md)
memory_search	—	All memory/*.md (indexed)

Fix options:

1. Change the session-memory hook to append to
   memory/YYYY-MM-DD.md (the canonical file) instead of creating
   slugged variants. Simplest fix, aligns with the pre-compaction flush.
2. Change the boot sequence to glob memory/YYYY-MM-DD*.md instead of
   looking for an exact filename. More permissive but noisier.
3. Both: append to canonical for boot visibility, keep slugged file as
   a separate audit artifact.

---

Problem to solve

When a user sends /new or /reset, the session is destroyed immediately.
Any context the agent learned during the session that was not explicitly
written to disk is permanently lost.

The existing session-memory hook partially addresses this by mechanically
dumping the last 15 raw messages into memory/YYYY-MM-DD-slug.md
(src/hooks/bundled/session-memory/handler.ts:55 — default messageCount = 15).
But this is a raw transcript dump, not a curated distillation. The agent
never gets a chance to decide what matters, extract decisions, update
MEMORY.md, or write structured notes — all things the pre-compaction
memory flush already does well.

Worse, as documented above, the hook's output is written to a slugged
filename that the boot sequence doesn't read — so even the raw dump is
invisible to the agent unless memory_search is working.

Why it matters

• Silent memory loss: Users hit /new to change topics, not to
  discard everything. The expectation is that important context survives.
• Asymmetric behavior: Compaction gets a memory flush
  (src/auto-reply/reply/agent-runner-memory.ts:253 — runMemoryFlushIfNeeded),
  where the agent writes curated notes before context is compressed.
  Reset only gets the raw transcript dump via the session-memory hook
  (src/hooks/bundled/session-memory/handler.ts:199 — saveSessionToMemory).
  The agentic path is better and already proven.
• Workaround burden: Users who know about this gap must manually ask
  the agent to "write this down" before every /new. Most users don't
  know.

Who is affected

Every user who uses /new or /reset in sessions where the agent learned
something worth remembering. Most common with personal assistant / memory-
heavy workloads.

The daily reset is even worse

The daily (nightly) reset has the same gap but is harder to work around.

The daily reset is not a cron job — nothing happens at 4 AM. The gateway
evaluates freshness lazily when the next message arrives
(src/auto-reply/reply/session.ts:356 — evaluateSessionFreshness).
If the session's updatedAt is older than the most recent atHour
boundary (default 4 AM —
src/config/sessions/reset.ts:23 — DEFAULT_RESET_AT_HOUR = 4),
the session is stale and a new one starts
(src/config/sessions/reset.ts:76 — resolveDailyResetAtMs).

This means:

1. User's last message is at 11 PM
2. Nothing happens overnight — no flush, no checkpoint, no compaction
3. Next morning, user sends a message at 8 AM
4. evaluateSessionFreshness() sees updatedAt (11 PM) < boundary
   (4 AM) → session is stale
   (src/config/sessions/reset.ts:141)
5. New sessionId minted
   (src/auto-reply/reply/session.ts:380),
   old transcript archived
   (src/auto-reply/reply/session.ts:572 — archiveSessionTranscripts)
6. session-memory hook fires (raw dump)
7. New session boots

The daily memory checkpoint
(src/auto-reply/reply/memory-flush.ts:196 — shouldRunDailyMemoryCheckpoint)
partially covers this — if the session is still active when the date
boundary crosses, it triggers a flush during the next turn. But if the
user stopped talking before the boundary and doesn't resume until after
it, that checkpoint never fires because there is no turn to evaluate it
on.

With manual /new, the user at least chose to end the session and could
have asked the agent to save things first. The daily reset happens
silently, automatically, with zero warning to either the user or the
agent. Any context from the previous day that was not written to disk is
gone.

Frequency

Every /new and /reset (multiple times per day for active users), plus
every daily reset (once per day per session, silently).

Proposed solution

Before destroying the session on /new or /reset, run a silent agentic
turn (same pattern as runMemoryFlushIfNeeded) that gives the agent a
chance to write durable memories to disk.

Behavior

1. User sends /new (or /reset)
   — triggers matched in
   src/auto-reply/reply/session.ts:284-317
   against DEFAULT_RESET_TRIGGERS
   (src/config/sessions/types.ts:378)
2. Gateway detects reset trigger (existing code in initSessionState)
3. New step: Before minting the new sessionId, run a silent
   pre-reset memory flush turn against the current session
4. The agent writes any durable notes to memory/YYYY-MM-DD.md (or
   MEMORY.md), then replies NO_REPLY
5. Session is destroyed — new sessionId minted, counters zeroed
   (src/auto-reply/reply/session.ts:533-546),
   user overrides carried over on manual reset
   (src/auto-reply/reply/session.ts:384-395)
6. session-memory hook fires as before (raw dump is still useful as
   backup / audit trail)
   — src/auto-reply/reply/commands-core.ts:94

Prompt

Reuse the existing memory flush prompt structure with a reset-specific
variant:

Pre-reset memory flush. The user is about to start a new session (/new).
Store durable memories now (use memory/YYYY-MM-DD.md; create memory/ if
needed). Focus on decisions, preferences, facts, and action items from this
session. If nothing worth storing, reply with NO_REPLY.

Config

Extend the existing compaction.memoryFlush config or add a sibling:

{
  agents: {
    defaults: {
      compaction: {
        memoryFlush: {
          enabled: true,               // existing
          softThresholdTokens: 4000,   // existing
          // New: also flush before session resets
          onReset: true,               // default: true
          resetPrompt: "...",          // optional override
        },
      },
    },
  },
}

Alternatively, a top-level session.reset.memoryFlush may be cleaner
since this is a session lifecycle concern, not a compaction concern:

{
  session: {
    reset: {
      memoryFlush: {
        enabled: true,
        prompt: "...",
      },
    },
  },
}

Guards

• Skip for empty sessions: If the session has zero or very few turns
  (e.g. the user sent /new immediately after a previous /new), skip
  the flush to avoid wasted LLM calls.
• Skip for CLI: Same as existing compaction flush.
• Skip for read-only workspaces: Same as existing.
• Timeout: Cap the flush at a reasonable timeout (e.g. 30s) so /new
  doesn't feel stuck. The user should see the new session greeting within
  a few seconds. Consider running the flush in the background and letting
  the new session start immediately.
• One flush per reset: Track in session entry to prevent double-flush
  if the gateway retries.

Alternatives considered

1. Rely on the existing session-memory hook (status quo)

The hook dumps raw messages but doesn't curate them. The agent never gets
to decide what matters. For memory-heavy workloads, raw dumps are noisy
and don't update MEMORY.md or structured memory files.

2. Make the session-memory hook agentic

Run an LLM call inside the hook to summarize/extract memories instead of
dumping raw messages. This is viable but puts agentic behavior in a
fire-and-forget hook with no access to the agent's tools or workspace
context. The existing pre-compaction flush already has the right
infrastructure (full agent turn with tool access).

3. Add a "save" command (/save)

Let users explicitly trigger a memory flush before /new. This works but
puts the burden on the user and doesn't help when they forget.

4. Background flush after reset

Destroy the session immediately, then run a memory flush against the
archived transcript in the background. This preserves the instant /new
feel but requires reconstructing agent context from the archived JSONL,
which is more complex.

Existing infrastructure

The codebase already has most of the pieces:

• Pre-compaction memory flush
  (src/auto-reply/reply/agent-runner-memory.ts:253 — runMemoryFlushIfNeeded):
  Full implementation of silent agentic flush with token gating, prompt
  injection, and NO_REPLY suppression.

• Memory flush trigger logic
  (src/auto-reply/reply/memory-flush.ts:131 — shouldRunMemoryFlush):
  Token-threshold gating. The default prompt instructs the agent to write
  to memory/YYYY-MM-DD.md and append only
  (src/auto-reply/reply/memory-flush.ts:17 — DEFAULT_MEMORY_FLUSH_PROMPT).

• before_reset plugin hook
  (src/plugins/types.ts:541 — type definition,
  src/plugins/hooks.ts:372 — runner,
  src/auto-reply/reply/commands-core.ts:94 — fire site):
  Fires on /new//reset with the old session's messages. Currently
  only used by the session-memory hook. Runs fire-and-forget.

• session_end plugin hook
  (src/plugins/hooks.ts:617 — runner,
  src/auto-reply/reply/session.ts:603 — fire site):
  Fires when a session is replaced by a new one.

• session-memory bundled hook
  (src/hooks/bundled/session-memory/handler.ts:199 — saveSessionToMemory):
  Mechanical dump of last N messages (default 15) into
  memory/YYYY-MM-DD-slug.md with LLM-generated slug. Handles
  transcript rotation after /new
  (src/hooks/bundled/session-memory/handler.ts:101 — reset fallback).

• Daily memory checkpoint
  (src/auto-reply/reply/memory-flush.ts:196 — shouldRunDailyMemoryCheckpoint):
  Already extends the flush beyond pure compaction triggers by checking
  date boundaries.

• Session freshness evaluation
  (src/config/sessions/reset.ts:141 — evaluateSessionFreshness):
  Determines whether a session is stale based on daily/idle/manual mode.

• Session reset prompt
  (src/auto-reply/reply/session-reset-prompt.ts:4 — BARE_SESSION_RESET_PROMPT_BASE):
  Injected on bare /new to trigger the agent's startup sequence.

The main work is wiring runMemoryFlushIfNeeded (or a variant) into the
reset path in initSessionState or the command handler, before the
session is destroyed.

Design history: /new, /reset, and session resets

Understanding how the reset system evolved explains why the agentic flush
gap exists — it was never deliberately omitted, the feature just grew
incrementally and this case wasn't covered.

Phase 1: Idle-only sessions (Nov–Dec 2025)

The project started with idle-based session expiry only. Sessions had a
configurable idleMinutes — if no message arrived within that window,
the next message started a fresh session. There was no daily reset and no
/new command. Peter Steinberger built this in the initial auto-reply
module (2025-11-25).

Phase 2: /new added as manual reset (Dec 4, 2025)

Peter added /new as a single hardcoded reset trigger
(34eb75f63 —
"auto-reply: honor /new after timestamp prefixes"). The motivation was
simple: give users a way to explicitly start a fresh session without
waiting for idle expiry. Two weeks later
(c2c5b28c7 —
Dec 20), he added the bare /new greeting: "If sent alone, the agent
replies with a short hello to confirm the reset."

At this point, sessions were short-lived (idle expiry) and memory
persistence wasn't a concern — there was no workspace memory system yet.

Phase 3: /reset added as alias (Dec 22, 2025)

Peter added /reset alongside /new in the resetTriggers config
(f10c8f2b4 —
"feat: add group activation command"). /reset was never intended to
behave differently from /new — it is purely a discoverability alias.
Both triggers run through identical code paths in initSessionState().

Phase 4: Daily reset replaces idle as default (Jan 18, 2026)

Peter added the daily reset policy
(367826f6e —
"feat(session): add daily reset policy", co-authored with Austin Mudd).
This introduced mode: "daily" with atHour: 4 as the new default,
replacing idle-only. The daily reset creates a new session exactly like
/new does, just triggered automatically by the freshness check.

Phase 5: Pre-compaction memory flush added (Jan 12, 2026)

Peter added the pre-compaction memory flush
(7dbb21be8 —
"feat: add pre-compaction memory flush"). This was the first agentic
memory preservation mechanism — a silent turn before compaction where the
agent writes durable notes to disk. It was designed specifically for the
compaction path; the reset path was not considered.

Phase 6: Reset hardening (Jan–Mar 2026)

Over the following weeks, a stream of community fixes established that
/new and /reset should behave identically:

• b3b6d421c (Jan 16) — Reset compactionCount on both /new and /reset
• 13e2dd97a (Jan 19) — Preserve model overrides on /new
• 15e5bb345 (Jan 20) — /new <model> accepts model hints
• 585c9a726 (Feb 12) — Preserve verbose/thinking/TTS overrides across both (thanks @mcaxtr)
• 93b450349 — Clear stale token metrics on both
• 31537c669 — Archive old transcripts on both
• d583399c9 — Extend session-memory hook to fire on /reset too (was /new only)

Phase 7: session-memory hook and before_reset (Feb 14, 2026)

The plugin hook system was extended to include before_reset
(ab71fdf82 —
"Plugin API: compaction/reset hooks, bootstrap file globs, memory plugin
status", by @solstead). The session-memory bundled hook was wired to
this, providing the mechanical transcript dump on reset. Multiple fixes
followed to handle transcript rotation after /new.

Phase 8: Post-reset boot sequence (Feb–Mar 2026)

The post-reset boot path was refined in three stages:

1. 616658d4b (Feb 14) — Created session-reset-prompt.ts with a
   basic greeting prompt: "A new session was started via /new or /reset.
   Greet the user..."
2. cd6bbe8ce (Feb 20) — Added "Execute your Session Startup
   sequence now — read the required files before responding." This was
   the key change that made /new actually trigger the agent's boot
   sequence (read SOUL.md, USER.md, daily files, MEMORY.md).
   Before this, the agent just said hi without re-reading its context.
3. 53727c72f (Mar 3) — Substituted YYYY-MM-DD with the real
   date in both the reset prompt and post-compaction context, so the
   agent reads the correct daily files.

Phase 9: Post-compaction boot (Feb–Mar 2026)

A parallel evolution happened for the post-compaction path — what the
agent sees after context is compressed:

1. 35a3e1b78 (Feb 16) — First post-compaction context injection.
   After compaction, the gateway re-reads AGENTS.md and injects the
   "Every Session" and "Safety" sections as a system event.
2. d0b33f23e (Feb 16) — Improved section extraction (case-
   insensitive, H3 support, code block awareness).
3. c4f829411 (Feb 16) — Also appended workspace critical rules
   directly into the compaction summary itself.
4. 96021a2b1 (Mar 5) — Aligned default AGENTS.md template section
   names ("Session Startup" + "Red Lines") with what the extraction
   code expects.
5. 03b9abab8 (Mar 7) — Made post-compaction sections configurable
   via compaction.postCompactionSections.

Phase 10: Pre-reset teardown (Feb–Mar 2026)

The pre-reset path got hooks but not an agentic flush:

1. ab71fdf82 (Feb 14) — Added before_reset plugin hook, fired
   on /new//reset with the old session's messages. Fire-and-forget.
   By @solstead.
2. d583399c9 (Feb 20) — Extended session-memory hook to fire on
   /reset too (was /new only).
3. aec41a588 (Feb 24) — Backfilled reset hooks for native slash
   commands (Telegram/Discord).
4. 19ae7a4e1, d6acd7157, 3fff266d5 (Feb 16-17) —
   Three attempts to fix the session-memory hook reading empty
   transcripts after /new rotates the file. Ended with
   getRecentSessionContentWithResetFallback.
5. 2655041f6 (Feb 13) — Wired 9 previously unwired plugin hooks,
   including session_start/session_end in session.ts.

What /new and /reset are today

There is no functional difference between /new and /reset. Both
are entries in DEFAULT_RESET_TRIGGERS = ["/new", "/reset"]
(src/config/sessions/types.ts:378)
and run through the same code path. /reset is purely an alias for
discoverability.

The daily reset is the same mechanism triggered automatically by the
freshness check. All three paths produce the same outcome: new UUID,
archived transcript, zeroed counters, agent re-boots from startup files.

Critically, the daily reset means every user hits this code path at
least once per day without any manual action. The default reset mode
is daily with atHour: 4
(src/config/sessions/reset.ts:22-23).
The first message each morning triggers a session reset with the same
lack of agentic flush as a manual /new. This isn't an edge case — it's
the default behavior for every OpenClaw user, every day.

Pre-reset vs post-reset: the asymmetry

The post-reset boot sequence has been carefully built up — the agent is
told to re-read all its context files, gets the current date, and follows
its startup procedure. After compaction, the agent additionally gets
critical AGENTS.md sections re-injected.

The pre-reset teardown, by contrast, only has:

• The before_reset plugin hook (fire-and-forget, no agentic turn)
• The session-memory hook (mechanical dump, no curation)
• The session_end plugin hook (fire-and-forget, informational only)

There is no agentic "save your work" step before the session dies.

Why the gap exists

The pre-compaction memory flush was designed for compaction (phase 5) and
never extended to resets (phase 6-10). When /new was first added
(phase 2), there was no workspace memory system. By the time memory
persistence became important, /new already had a mechanical safety net
(the session-memory hook) — good enough that nobody noticed the lack of
an agentic flush. The daily checkpoint (described below in "Recent
changes") was the first acknowledgment that compaction-only wasn't
sufficient.

Recent changes (past month)

Active development on both the memory flush and reset paths in the past
month shows this area is under active iteration. Key changes, in
chronological order:

Memory flush hardening

• ffbcb3734 — Inject runtime date-time into memory flush prompt so
  agents write to the correct YYYY-MM-DD.md file instead of guessing.
• 503d39578 — Guard transcript-size forced flush against repeated
  runs (fix(memoryFlush): guard transcript-size forced flush against repeated runs #32358). The forceFlushTranscriptBytes path was firing on every
  message once the transcript exceeded 2 MB. Extracted
  hasAlreadyFlushedForCurrentCompaction() to gate both trigger paths.
• fbd832d64 — Shared byte-size parsing for memory flush config.
• d729ab215 — Hardened usage accounting and memory flush recovery.
• fcb685978 — Corrected context token accounting for flush gating
  (fix(memoryFlush): correct context token accounting for flush gating #5343).
• 94fdee2ea — Banned timestamped variant files in the default flush
  prompt (fix(memory-flush): ban timestamped variant files in default flush prompt #34951). The prompt now explicitly says "Do NOT create
  timestamped variant files (e.g., YYYY-MM-DD-HHMM.md); always use the
  canonical YYYY-MM-DD.md filename." This was a direct fix for agents
  creating proliferating daily files.

Session reset path fixes

• 616658d4b — Route bare /new and /reset through
  sessions.reset so reset behavior is consistent.
• cd6bbe8ce — Enforce startup sequence on bare reset greeting. The
  reset prompt was updated to tell the agent to execute its Session
  Startup sequence on /new.
• d583399c9 — Persist session memory on /reset. Extended the
  session-memory hook to fire on both /new and /reset (previously
  only /new).
• aec41a588 — Backfill reset command hooks for native /new path.
  Native slash commands (Telegram/Discord) weren't firing the
  before_reset hook.
• 19ae7a4e1 — Fallback to rotated transcript after /new. The
  session-memory hook was reading an empty active transcript because
  /new had already rotated it.
• d6acd7157 — Same area: find previous session file after /new.
• 709dc671e — Archive old transcript on daily/scheduled reset to
  prevent orphaned files (fix(session): archive old transcript on daily/scheduled reset to prevent orphaned files #35493). Daily resets were leaving old
  transcripts as orphan files on disk.

Daily memory checkpoint (March 2026)

A daily memory checkpoint was added that extends the memory flush
beyond compaction triggers:

• 1146b3664 — Added shouldRunDailyMemoryCheckpoint() to trigger a
  memory flush when a date boundary is crossed within an active session.
  Also added manual reset mode (sessions never auto-reset). This is
  the closest existing work to the pre-reset flush proposed here — it
  recognized that compaction alone isn't sufficient and added a date-
  boundary trigger.
• bd1809a77 — Fixed /new triggering a spurious daily memory
  checkpoint. After /new, memoryCheckpointAt was undefined,
  causing the daily checkpoint to fire immediately on the first turn of
  the new session. Fixed by setting memoryCheckpointAt = Date.now() so
  the checkpoint sees the new session as current.
• Follow-up commits added XML tags (<openclaw:daily-checkpoint> vs
  <openclaw:pre-compaction>) to distinguish the two flush paths, then
  deduplicated shared prompt logic.

What this tells us

1. The memory flush is being actively hardened — repeated fixes for
   token accounting, repeated-run guards, prompt improvements, and
   transcript-size triggers.
2. The reset path is being actively improved — hooks were missing for
   native commands, transcripts were being orphaned, the session-memory
   hook had multiple bugs with reading rotated files.
3. The daily checkpoint was added specifically to cover the gap where
   compaction alone wasn't sufficient — but it only works when the session
   is still active. It does not cover the case where the session ended
   before the boundary.
4. Nobody has yet wired the agentic flush into the reset path. The
   infrastructure is there (and getting more robust), but the reset path
   still only gets the mechanical session-memory dump.

Impact

• Latency: /new will take 2-10 seconds longer (one LLM turn). This
  can be mitigated by running the flush in the background and starting the
  new session immediately.
• Cost: One additional LLM call per /new//reset. Skipping empty
  sessions avoids waste.
• Backward compatible: Yes. The flush is additive. Existing behavior
  is preserved. Users who disable memoryFlush.enabled or set
  onReset: false opt out.

Open questions

1. Blocking vs background: Should /new block until the flush
   completes, or start the new session immediately and flush in the
   background? Blocking is simpler and guarantees the flush finishes.
   Background is faster UX but risks the flush being interrupted.
2. Config location: compaction.memoryFlush.onReset (extends
   existing) vs session.reset.memoryFlush (cleaner separation)?
3. Daily reset: Should the daily (nightly) reset also get a flush?
   The daily reset is lazy (evaluated on next message), so the flush
   would have to run at the start of the next conversation against the
   old session before booting the new one. This is awkward — the user
   sent a message and is now waiting while the agent flushes a stale
   session they may not even remember. Options:
   • Run the daily flush in the background (don't block the new session)
   • Run a proactive flush via heartbeat or cron before the atHour
     boundary (e.g. a "bedtime flush" at 3:50 AM if atHour is 4)
   • Accept that the daily checkpoint + session-memory hook are
     "good enough" for the daily case and only add agentic flush for
     manual /new//reset
4. Interaction with session-memory hook: Keep both? The hook
   provides raw audit trail; the agentic flush provides curated memory.
   They serve different purposes and can coexist.

[dsantoreis]

Strong proposal, and the asymmetry is clearly a gap.

The daily reset at atHour: 4 is the biggest impact — every user loses uncurated context silently every morning. /new and /reset are at least intentional, but the daily reset fires without any user action.

The implementation path is clean: runMemoryFlushIfNeeded already exists and works well before compaction. Calling it before session teardown in /new, /reset, and the daily reset timer adds maybe 5-10 seconds of latency (the agentic turn) but saves potentially hours of context.

One consideration: the flush should be timeboxed (say 15s max) so a hung flush doesn't block session teardown indefinitely. The compaction flush already has this pattern.

This pairs naturally with #45607 — fixing the hook's filename convention means both the agentic flush AND the mechanical fallback feed into the same canonical file the boot sequence reads.

[lidafu759]

Real-world case: compaction summary discarded on daily reset

We hit this exact gap in production. Sharing a concrete case that highlights an additional angle not yet discussed.

What happened

A WeChat DM session (69bbc02d, 267 lines) accumulated significant domain knowledge over multiple conversations on March 12 — including detailed information about a traditional Chinese medicine reference (本经注蔬) scraped from an external website. The session had already been compacted, producing a ~13KB compaction summary preserving all key context (goals, constraints, exact identifiers, prior decisions).

At 2026-03-13T00:24, the daily reset (evaluateSessionFreshness, atHour: 4 boundary) triggered:

1. Old session JSONL archived to .reset.2026-03-13T00-24-12.987Z
2. New session 39980e38 created with crypto.randomUUID() — completely empty
3. The existing compaction summary was NOT carried forward

When the user asked the bot the same question on March 14, the bot had zero context and gave a wrong answer (even "correcting" the user's terminology).

The additional gap

The current discussion in this issue focuses on triggering a new agentic memory flush before reset. But there's a simpler, complementary fix for sessions that already have a compaction summary:

On reset, inject the most recent compaction entry from the old session into the new session JSONL.

This is a much smaller change than the full pre-reset flush proposal — it's essentially a one-liner in the reset path at src/auto-reply/reply/session.ts:378-379. The compaction entry already exists in a well-defined format; it just needs to be copied to the new file after the session header.

Workaround

We manually extracted the compaction entry from the archived .reset.* file and injected it into the new session JSONL. The bot immediately recovered all prior context and answered correctly.

Suggested approach

1. Quick win (this issue): On daily/idle reset, if the old session contains a compaction entry, copy its last compaction into the new session. Zero LLM cost, preserves existing summarized knowledge.
2. Full solution (Daily reset doesn't trigger session-memory hook flush #43524): Additionally fire session-memory hook on daily/idle reset (not just command:new/command:reset) so the agentic flush can produce a fresh summary when no compaction exists yet.

These two changes are complementary — (1) handles the common case where compaction already happened, (2) handles sessions that were reset before reaching compaction threshold.

[dsantoreis]

This is a really concrete case. The daily reset discarding existing compaction summaries is a clear data loss path — the summary already exists, was already paid for (LLM cost), and contains exactly the context the new session needs.

The two-tier fix makes sense:

1. Copy last compaction entry on reset — near-zero risk, no LLM call, covers the common case. The compaction entry is already a well-structured summary designed to bootstrap context. Just appending it after the session header in the new JSONL is straightforward.

2. Pre-reset agentic flush for sessions that never reached compaction threshold — covers the gap but requires the full hook wiring from Daily reset doesn't trigger session-memory hook flush #43524.

The manual workaround (extracting and re-injecting the compaction entry) confirms the approach works. The fact that the bot immediately recovered context proves the compaction format is already sufficient for session bootstrapping.

[sys-fairy-eve]

+1 on this — we hit this exact gap today on a multi-agent VPS deployment.

One thing I think is missing from the proposal: the idle-timeout reset path. The issue mentions daily resets and explicit /new//reset, but session.reset.idleMinutes (when set) also silently destroys sessions without any flush or hook event. The fix should cover all three reset vectors:

1. Explicit command (/new, /reset) ← already has session-memory hook, would gain agentic flush
2. Daily reset (atHour) ← covered in this proposal
3. Idle timeout (idleMinutes) ← should also get the same treatment

Also worth noting: PR #38027 (which attempted to fix just the hook-event gap) was closed without merge. The agentic flush approach here is strictly better — it gives the agent a chance to curate rather than mechanically dumping raw messages — but it'd be good to understand why #38027 was rejected before this takes a similar path.

For context, our current workaround is a custom transcript cleaning pipeline (6h cron: clean active sessions → clean orphans → reindex embeddings) plus per-agent instructions to write durable notes to memory/YYYY-MM-DD.md during active work. Works but doesn't cover the final gap between last write and session destruction.

[V0v1kkkAssistant]

Related threads: #8185, #43524, #37955, #29523, and #6877 (closed).

Would it make sense to unify this under a session reset config shape, e.g.:

{
  session: {
    reset: {
      memoryFlush: {
        enabled: true,
        prompt: "..." // optional, defaults to compaction flush prompt
      }
    }
  }
}

This would mirror the existing agents.defaults.compaction.memoryFlush pattern and keep behavior consistent across reset paths.

Also, I think idle reset, daily reset, and manual /new//reset should all trigger this the same way.

Related bug context: #6877 tracks the append-vs-overwrite issue in the flush prompt handling.