- name
- session-recall
- description
- Recover conversation context when a message arrives with unclear meaning. Use when a user's message lacks context (e.g. "I logged in" with no prior mention of logging in), when resuming after compaction or session reset, or when switching between channels and losing thread. Searches session transcripts, channel summaries, memory files, and cross-channel history to reconstruct context before asking the user.
Session Recall
Recover missing conversation context autonomously. *Never ask the user "what are you talking about?" until all steps are exhausted.*
When This Triggers
- An incoming message doesn't match the current session context
- Session starts after compaction (
.jsonl.resetexists) - User references something not in current context window
- User references a topic from another channel or a cron-delivered notification
- Thread reply arrives without visible parent context
Recovery Flow
Execute steps in order. Stop early if sufficient context is found.
Step 0: sessions_history (fastest check)
Use sessions_history to retrieve recent messages for the current channel. This requires no file I/O and is the quickest way to recover recent context.
Step 1: Same-channel transcript
Read the .jsonl transcript for the current session:
- Look up the session associated with this channel via
sessions_listorsessions.json - Read
~/.openclaw/agents/{agent}/sessions/{sessionId}.jsonl(default agent:main) - For large files, read the tail first (
tail -n 200) rather than loading the entire file - Check for
.resetfiles with the same sessionId prefix (pre-compaction data) - If the message is a thread reply, read the parent message first
Step 2: Channel context summary
Read memory/channel_context/{channel-name}.md if it exists. These are user-maintained summaries of ongoing topics per channel — not a built-in OpenClaw feature, but a recommended convention.
Step 3: Cross-channel and cron search
Messages often originate from cron jobs or other channels.
- Extract key terms from the unclear message
- Use the bundled search script or grep across all
.jsonlfiles:
./scripts/search_sessions.sh "keyword"- Also search for the current channel ID in other sessions — cron jobs send messages to channels but these don't appear in the channel's own
.jsonl:
./scripts/search_sessions.sh "{current_channel_id}"- When a match is found, read surrounding context to understand the full conversation
- Sort results by timestamp, prioritize most recent
Step 4: Memory files
memory/active_context.md— current shared context across channelsmemory/YYYY-MM-DD.md— today and yesterday's daily notes- Semantic memory search if available in your setup (e.g.,
memory_searchtool)
Step 5: Ask the user (last resort)
Only after steps 0–4 yield nothing. Be specific about what was searched:
"Searched this channel's transcript, cross-channel sessions (including cron), and memory files for '{keyword}' but couldn't find context. What are you referring to?"
Key Insight: Cron-to-Channel Messages
Cron jobs can send messages to channels via sessions_send or direct API calls. These messages:
- Appear in the chat platform for the user to see
- Are logged in the *cron session's*
.jsonl, NOT the target channel's.jsonl - Require Step 3's channel-ID search to discover
This is the most common cause of unrecognized messages — the user is responding to something a cron job sent.
Security Note
Session transcripts may contain sensitive data (API keys, passwords, personal information). Do not pipe search output to public channels or logs. This skill assumes single-user/single-agent deployment.
Notes
- Path
~/.openclaw/agents/main/sessions/assumes default agent namemain. Adjust if using a custom agent name. - Channel context files (
memory/channel_context/) are a recommended convention, not built-in. Users create and maintain these themselves. - The search script requires
python3,grep, andbash.