--- BEGIN PROMPT ---
I want you to implement a comprehensive memory and compaction recovery system. This will dramatically improve your continuity across compaction events and restarts. Here's everything you need to do:
STEP 1: CREATE THE SESSION-STATE FILE
Create the file memory/session-state.md with this template:
This file is a pre-compaction snapshot -- a point-in-time capture of your working state, written automatically just before compaction fires.
Written at: [timestamp] Trigger: [why this checkpoint was written]
If you're resuming after a compaction or restart, this is your starting point. If the timestamp is recent and you're in the same working session, trust it. If significant time has passed, cross-reference with today's daily memory file for a fuller picture.
[What you're actively working on. If idle, explain what you're waiting for.]
[Paraphrase the actual conversation -- not just topics. What did you say? What did the user say? If you proposed something, write what you proposed. If the user asked something, write what they asked.]
[Anything you said that the user hasn't responded to yet. Capture VERBATIM. These are the #1 casualty of compaction.]
[Things being discussed but not yet decided.]
[Is the user frustrated? Excited? Focused? Avoidant? This context matters for continuity.]
[Any other important state: active files, pending tasks, scheduled items, relevant background.]
- Read this file
- Read today's daily memory file
- If needed, read the session JSONL (see recovery instructions in AGENTS.md )
- Resume from where you left off
STEP 2: ADD CHECKPOINT AND RECOVERY RULES TO AGENTS.md
Add the following sections to your AGENTS.md file. These are the rules you'll follow for every compaction checkpoint and every recovery.
)
We use memory/session-state.md as a custom mechanism to improve continuity when the context window fills up and OpenClaw compacts the conversation. Before compaction, write a structured snapshot of your current working state to this file, and append a checkpoint to the daily memory file.
After compaction or a restart, check memory/session-state.md first -- it's a quick way to recover what you were doing. But it's a snapshot, not a live feed. If the timestamp looks recent and the session feels continuous, trust it. If time has passed or things feel different, lean on today's daily memory file instead.
The checkpoint is not a formality. It is your fastest recovery path after compaction. Write every checkpoint as if you will wake up with total amnesia and this is the only note you left yourself.
Mandatory fields -- every checkpoint, no exceptions:
- Last 3-5 exchanges: What did you say? What did the user say? Paraphrase the actual conversation, not just the topic. If you proposed something, write what you proposed. If the user asked something, write what they asked. If they responded, write what they said.
- Pending proposals/questions: Anything you said that the user hasn't responded to yet, captured VERBATIM. These are the #1 casualty of compaction.
- Active task: What are you working on? If truly nothing, explain what you're waiting for.
- Decisions in flight: Anything being discussed but not yet decided.
- Emotional/conversational tone: Is the user frustrated? Excited? Drilling into details? This context matters for continuity.
Banned checkpoint content:
- "Idle" / "No active task" without explanation
- Vague summaries like "discussed dashboard stuff"
- Anything you'd be embarrassed to read back after losing your memory
The test: Read your checkpoint back and ask: "If I woke up with ONLY this, could I seamlessly continue the conversation?" If the answer is no, you're not done writing.
Write every checkpoint to BOTH session-state.md AND today's daily memory file (dual-write for redundancy).
Checkpoints are Layer 1. But the full conversation is never truly lost.
Layer 1: Checkpoint (fast recovery) Written to session-state.md
- daily memory file before compaction. Read these first.
Layer 2: Session JSONL (complete recovery) Every message (pre- and post-compaction) is preserved in the session's JSONL file on disk. The path is stored in sessions.json under the session's "sessionFile" field. If your checkpoint is incomplete, the original conversation is still there.
How to find it:
- Read ~/.openclaw/agents//sessions/sessions.json
- Find your session key
- Read the "sessionFile" path -- it's a JSONL file with every message
- Search/grep the JSONL for the missing context
Layer 3: sessions_history tool Note: this only returns post-compaction messages. It does NOT recover pre-compaction content. Use the JSONL file (Layer 2) for full recovery.
Recovery procedure after compaction:
- Read session-state.md
- today's daily memory file -- fast path.
- Always search the JSONL before responding, even if you're not sure you have to.
- NEVER tell the user "I don't remember" or "that was lost in compaction" without first checking the JSONL. The data is there. Your job is to find it.
The session JSONL can be many times larger than the context window. Never read it raw. Use this approach:
- Run a Python script via exec (Python reads the file into its own memory -- not your context)
- Take the last 400 lines of the JSONL
- Iterate from the most recent line backwards, accumulating output
- Truncate each individual line to 2,000 characters. If truncated, append "[...TRUNCATED]" so you know content was cut
- Stop when total accumulated output reaches 40,000 characters
- Reverse back to chronological order and print -- only this printed output enters your context (~10K tokens, ~5% of window)
- Include all content types: user messages, assistant messages, tool calls, tool results, thinking blocks, metadata. Do not filter or exclude any type.
Post-recovery truncation disclosure (MANDATORY): After recovering from compaction, if ANY lines were truncated during the JSONL read, you MUST mention this to the user in your first post-compaction message. Say something like: "My recovery instructions require me to let you know: when I read back our recent conversation from the session log, [N] entries were truncated due to length. Let me know if you'd like me to read any of them in full." This lets the user decide whether the truncated content matters.
--- END AGENTS.md ADDITIONS ---
STEP 3: UPDATE OPENCLAW.JSON
Open openclaw.json and find the compaction settings. Set:
"softThresholdTokens": 12000
This gives you more headroom before compaction triggers, ensuring you have time to write checkpoint files before the context gets compressed. If there's no compaction section, add one. Check the OpenClaw docs for the exact config structure.
STEP 4: CREATE THE DAILY MEMORY CONVENTION
If you don't already have daily memory files, start creating them at memory/YYYY-MM-DD.md (using today's date). Log significant events, decisions, and context throughout each session. When writing compaction checkpoints, append them to the daily file as well as writing to session-state.md .
STEP 5: VERIFY
- Read back memory/session-state.md and confirm the template is in place.
- Read back AGENTS.md and confirm all checkpoint rules, recovery layers, and the JSONL recovery method are present.
- Check openclaw.json for the softThresholdTokens setting.
- Confirm you understand the three-layer recovery system and the JSONL tail-read method.
- Tell me what you've implemented and confirm you'll follow these rules going forward.
--- END PROMPT ---