Fresh-session continuity break: weak first message (e.g. 🤔) skips autoRecall after restart

[sinskl]

Summary

After restarting OpenClaw Gateway (with memory-lancedb-pro enabled), the first user message in the fresh session can be a very low-signal continuation such as:

• 🤔
• ?
• ...
• 嗯
• 继续

In this case, autoRecall is silently skipped by adaptive retrieval, which makes the assistant lose continuity at exactly the moment when continuity matters most.

This is especially confusing when the user is clearly continuing the conversation right after restart: the assistant behaves as if it suddenly forgot the previous topic and replies with a generic opener.

---

Environment

• OpenClaw: 2026.3.2
• Plugin: memory-lancedb-pro
• Memory slot: memory-lancedb-pro
• Config:
  • autoRecall: true
  • autoCapture: true
  • sessionStrategy: "memoryReflection"
• Embedding:
  • OpenAI-compatible / OpenRouter
  • model: qwen/qwen3-embedding-8b

---

Reproduction

1. Enable memory-lancedb-pro with autoRecall: true.
2. Have an active conversation with clear topic continuity.
3. Restart OpenClaw Gateway (or otherwise cause a fresh session to start).
4. Send a low-signal first message in the new session, for example: 🤔
5. Observe the assistant response.

Observed behavior

The assistant responds as if the conversation context was not continued, e.g. with something like:

“怎么啦，在想什么？”

instead of understanding that the user is continuing the immediately previous topic.

---

Root cause analysis

From local code inspection:

1. before_agent_start autoRecall gate

In index.ts, autoRecall runs only if:

!shouldSkipRetrieval(event.prompt, config.autoRecallMinLength)

2. normalizeQuery() strips OpenClaw wrappers

In src/adaptive-retrieval.ts, the query is normalized by stripping:

• Conversation info (untrusted metadata): ...
• Sender (untrusted metadata): ...
• timestamp wrappers
• cron prefixes

This is correct and desirable.

3. But after stripping, the first message may collapse to just 🤔

Then shouldSkipRetrieval() returns true because of rules like:

• pure emoji skip
• trimmed.length < 5
• short non-question skip

So on a fresh post-restart session, the plugin effectively says:

“this message is too weak to retrieve memory for”

But from the user experience perspective, this is exactly the moment where continuity recovery is needed most.

4. memoryReflection does not solve this

memoryReflection injects inheritance/derived guidance, but it does not restore the immediate prior conversational thread.
So the result is:

• fresh session
• no immediate continuity state
• first message too weak
• autoRecall skipped
• user sees an apparent “amnesia” moment

---

Why this matters

This is not just a minor retrieval heuristic edge case.
It directly affects trust in continuity:

• users often send very short continuation messages after restart
• on chat surfaces, emoji / ? / 继续 / 嗯 are normal follow-ups
• the current behavior makes the assistant feel like it “suddenly forgot everything”

That user-visible effect is much worse than a normal recall miss.

---

Expected behavior

At least one of these should happen for the first turn of a fresh session:

1. Do not blindly skip autoRecall for weak first-turn messages

   • e.g. relax skip rules on session-first turn

2. Fallback continuity recovery

   • inspect recent same-chat session tail / recent reflection / session summary before deciding to skip

3. Special handling for restart/new-session continuity turns

   • if the session is fresh and the message is weak, prefer continuity heuristics over generic skip heuristics

---

Suggested fix directions

Option A — session-aware skip logic

In shouldSkipRetrieval() or its caller, avoid skipping when all of the following are true:

• this is the first user turn of a fresh session
• the message is weak / ultra-short / pure emoji
• there was a recent prior session for the same chat/session key

Option B — continuity fallback before skip

If a fresh-session first turn is weak, try a small continuity recovery path before returning early:

• recent session tail
• latest session summary / reflection-derived continuity summary
• last-turn topic carryover

Option C — dedicated config switch

Add something like:

{
  "autoRecall": true,
  "continuityFirstTurnFallback": true
}

for users who want safer cross-restart continuity.

---

Related issues / PRs

In this repo

• autoRecall retrieval query not stripped of OpenClaw metadata — wrong memories returned #100 — autoRecall retrieval query not stripped of OpenClaw metadata — wrong memories returned
• memory-lancedb-pro 的 memoryReflection 在 /new / reset 后没有触发 | memory-lancedb-pro memoryReflection does not reliably fire on /new /reset #98 — memoryReflection does not reliably fire on /new / /reset
• fix: enhance normalizeQuery to strip OpenClaw v3.2 metadata and timestamps #47 — normalizeQuery strips OpenClaw metadata and timestamps
• Fix: strip OpenClaw metadata noise in autoCapture and normalizeQuery #50 — strip metadata noise in autoCapture and normalizeQuery

In OpenClaw core

• Context primer not auto-injected on session restart after compaction openclaw/openclaw#18539 — Context primer not auto-injected on session restart after compaction
• Discord continuity loss: provider health-monitor restart ("reason: stuck") causes sessionId rotation + messages=0 (no gateway restart) openclaw/openclaw#33477 — continuity loss after provider restart causes fresh context
• fix(session): recover continuity when session key lookup misses openclaw/openclaw#33646 — recover continuity when session key lookup misses
• Feature: add continuity context engine openclaw/openclaw#39049 — continuity context engine

This issue is related to the same continuity problem space, but is specifically about adaptive autoRecall skip behavior on the first weak-signal message after restart/new session.

[AliceLJY]

这个问题已经有对应修复方向了：#123 正在处理“fresh session 首条弱信号消息放宽 autoRecall skip”的逻辑。现在的关键点不是单纯放宽，而是要同时保住 system/control prompt 的跳过规则，避免把启动包装文本也拿去 recall。