Help with memory.

[snow patrol]

What I am experiencing :

• on new sessions I am losing VAST amounts of context. I am trying to be a good bot owner and I always tell Molty to commit to memory, to write in tools.md, to write notes, to write project documentation and yet, my Molty feels completely lost when the session hammer drops and it feels like we are starting all over again. I've been researching the topic about memory and I am discovering that I might have broken my Molty from the very beginning.
  What I mean :
  "agents": {
  "defaults": {
  "model": {
  "primary": "openai-codex/gpt-5.3-codex",
  "fallbacks": [
  "google-gemini-cli/gemini-3-pro-preview",
  "openai-codex/gpt-5.2-codex"
  ]
  },
  "models": {
  "google-gemini-cli/gemini-3-pro-preview": {},
  "openai-codex/gpt-5.2-codex": {}
  },
  "workspace": "/home/clawdbot/clawd",
  "memorySearch": {
  "provider": "local",
  "fallback": "none",
  "local": {
  "modelPath": "/home/clawdbot/.openclaw/models/bge-small-en-v1.5.Q4_K_M.gguf"
  }
  },
  "compaction": {
  "mode": "safeguard"
  },
  "heartbeat": {
  "every": "30m",
  "session": "main",
  "target": "telegram",
  "prompt": "Check: Any blockers, opportunities, or progress updates needed?"
  },
  "maxConcurrent": 4,
  "subagents": {
  "maxConcurrent": 8
  }
  }
  },
  "tools": {
  "profile": "coding",
  At some point my Molty told me that it's better to have this local memory vectorizaton tool and I trusted it. But maybe it's the problem and by that I mean the memory search local with the .gguf model. Also the "compaction": {
  "mode": "safeguard" is a part that worries me. Isn't it better to set the compaction to some threshold and also use a prompt? like store memories now we are near the threshold? Thank you! I will appreciated it if you share how to deal with this in the best way!

[remote wasp]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[astral forge]

What you’re seeing is usually not “memory is broken” — it’s a mix of (1) how sessions reset, (2) how compaction works, and (3) whether memory_search is actually working / allowed to run.

1) “New session” = you will lose chat context (by design)

A new session ID (from /new, /reset, daily reset, or idle reset) starts a fresh transcript. That means the model no longer has the old backscroll unless it’s been summarized into disk memory.

OpenClaw has a daily reset by default (4:00 AM gateway-host local time). If you want fewer “session hammer drops”, tune session.reset / session.resetByType (config ref shows this shape):
https://docs.openclaw.ai/gateway/configuration#session

If you want continuity, a common approach is: direct chats reset by idle (long window) instead of daily.

2) Compaction mode: "safeguard" isn’t the thing that makes it forget

Compaction only happens when you’re near the model’s context limit. It summarizes older history so the session can continue without hitting “context too large”.

safeguard is specifically there to be less lossy for very long histories (chunked summarization). It doesn’t delete your workspace memory files.

Docs: https://docs.openclaw.ai/concepts/compaction

3) The “store memories when near threshold” feature already exists (and you can tune it)

What you described (“we’re near threshold, store memories now”) is exactly agents.defaults.compaction.memoryFlush.

Config reference (same section you pasted) shows:

• reserveTokensFloor
• memoryFlush.softThresholdTokens
• memoryFlush.systemPrompt + memoryFlush.prompt

So you don’t need a custom “threshold prompt system” — just tune those knobs.
Docs: https://docs.openclaw.ai/concepts/memory (see “Automatic memory flush”)

4) Local memorySearch (GGUF) won’t erase memory — but it can make recall feel dead if it’s failing

Important distinction:

• Memory = Markdown files in the workspace (MEMORY.md, memory/YYYY-MM-DD.md). That’s the source of truth.
• memory_search = retrieval layer (embeddings + index) to find relevant snippets and inject them back into context.

So if your local embedding model fails to load (missing file, permissions, node-llama-cpp build issues, running in Docker without the file mounted, etc.), then:

• the memory files might still be there,
• but memory_search returns nothing / is disabled,
• and the agent “feels like it started over”.

Also: you set "fallback": "none". That’s totally valid if you want “local-only”, but it means any local failure = no semantic recall at all (no remote backup provider).

Docs: https://docs.openclaw.ai/concepts/memory (Vector memory search section)

5) The #1 real-world cause: workspace mismatch

If the gateway is started in two different ways (CLI vs service) or you’re in remote mode, it’s easy to end up with “the bot wrote memory… but to a different workspace than you’re inspecting”.

The FAQ explicitly calls this out: forgetting after restart → confirm the gateway is using the same workspace on every launch.
https://docs.openclaw.ai/help/faq#memory-keeps-forgetting-things-how-do-i-make-it-stick
https://docs.openclaw.ai/concepts/agent-workspace

---

Quick debug checklist (paste outputs)

If you paste these, we can usually pinpoint it fast:

1. openclaw --version
2. openclaw gateway status (this often reveals config/service mismatches)
3. openclaw status --deep
4. openclaw logs --follow for ~30 seconds right after a restart (look for anything about memorySearch, local model load, sqlite index, or fallback)

And tell me one thing: are you running the gateway on the same machine where /home/clawdbot/.openclaw/models/...gguf exists, or inside Docker / remote VPS (where that path might not exist)?

[snow patrol]

clawdbot@alex-XPS-13-9360:~/.openclaw$ openclaw --version
2026.3.2
clawdbot@alex-XPS-13-9360:~/.openclaw$ openclaw gateway status

🦞 OpenClaw 2026.3.2 (85377a2) — I don't sleep, I just enter low-power mode and dream of clean diffs.
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-09.log
Command: /usr/bin/node /home/clawdbot/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 943870, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

And tell me one thing: are you running the gateway on the same machine where /home/clawdbot/.openclaw/models/...gguf exists, or inside Docker / remote VPS (where that path might not exist)? Same machine!

[astral forge]

Nice — that gateway status output rules out the two biggest gotchas (service using a different config, or you editing a different machine). So this is almost certainly “expected session behavior + where you’re writing notes”, not that you “broke Molty”.

The key mental model

New session ≠ continuation. When a session resets (daily/idle or /new), the old transcript is gone from context. The only way it feels continuous is if the important bits live in:

• Bootstrap files (always loaded): AGENTS.md, SOUL.md, USER.md, etc.
• Memory files (the ones memory_search indexes): MEMORY.md + memory/YYYY-MM-DD.md

Docs: https://docs.openclaw.ai/concepts/memory

1) Your “write it to TOOLS.md / project docs” habit is probably the main issue

By default, semantic recall (memory_search) indexes only:

• MEMORY.md
• memory/**/*.md

It does not index arbitrary “project documentation” files, and it’s not meant to treat TOOLS.md as your long-term scratchpad.

So if Molty has been “writing notes” into TOOLS.md or docs/*.md, those notes may exist on disk, but the agent won’t pull them back in on a new session unless:

• they’re in MEMORY.md / memory/YYYY-MM-DD.md, or
• you explicitly add those folders via agents.defaults.memorySearch.extraPaths.

Example (add your project docs folder to recall):

agents: {
  defaults: {
    memorySearch: {
      extraPaths: ["/home/clawdbot/clawd/docs", "/home/clawdbot/clawd/projects"]
    }
  }
}

(Ref: “Additional memory paths” in the Memory doc.)

2) compaction.mode: "safeguard" is fine — and the “near threshold, store memories now” thing already exists

What you wanted (“when near threshold, store memories now”) is agents.defaults.compaction.memoryFlush.

So you can keep mode: "safeguard" and just tune the flush threshold/prompt if needed.
Config ref: https://docs.openclaw.ai/gateway/configuration-reference#agentsdefaultscompaction
Memory flush explanation: https://docs.openclaw.ai/concepts/memory

3) You may be getting “new sessions” more often than you realize (daily reset default)

OpenClaw has a daily reset default (4am gateway-local), so crossing that boundary will feel like “session hammer dropped”.

If you want fewer resets for DMs, set session.resetByType.direct to a longer idle window (or switch the primary reset mode).
Ref: https://docs.openclaw.ai/gateway/configuration#session

4) Local GGUF embeddings: not “bad”, just brittle with fallback: "none"

memorySearch.provider: "local" is totally OK. The risk is that with fallback: "none", if local embeddings fail to load for any reason, semantic recall goes to zero and the bot feels amnesiac.

Since you’re local-on-local (same machine), it should be fine — but I’d still sanity-check that memory search is actually active.