OpenClaw memory: how it works, how to fix it, and why we stopped running it

Yes, OpenClaw has memory, and it's the most transparent of any agent we've run: plain Markdown files in each agent's workspace, MEMORY.md for durable facts, dated notes in memory/, USER.md for preferences, with a search index on top. OpenClaw's docs say "there is no hidden state", so anything not written to disk isn't remembered. We ran OpenClaw for a few months and liked that about it, and we stopped anyway; the memory architecture was part of why. The mechanics first, then that. Docs checked 2026-10-21.

How does OpenClaw memory work?

Memory is a set of files in the agent workspace, ~/.openclaw/workspace by default:

MEMORY.md loads only "in the main, private session (not shared/group contexts)" (workspace docs). The default dreaming sweep distills daily notes into it. The agent reads memory through memory_search, which finds relevant notes, and memory_get, which reads a file or line range. To make it remember something, ask: "Remember that I prefer TypeScript."

The index lives in the agent's SQLite database at agents/<agentId>/agent/openclaw-agent.sqlite in the state directory (CLI docs). Don't delete that file to reset memory. Search uses embeddings, keywords or both, OpenAI embeddings by default with local options (docs).

How do I reset or rebuild the OpenClaw memory index?

openclaw memory reset, then openclaw memory index: reset clears the derived index, and index rebuilds it from your memory files, which reset never touches (CLI docs).

1. Stop the Gateway. Except for search, the memory commands refuse to run while a Gateway owns the state directory.
2. Check: openclaw memory status --deep. Add --index to reindex only if the store is dirty, or --fix to repair stale recall locks.
3. Clear: openclaw memory reset --agent main --yes. It drops and recreates only the memory tables; sessions, transcripts and memory files stay. Without --agent it resets every agent.
4. Rebuild: openclaw memory index --agent main. Reset doesn't rebuild on its own; --force runs a full reindex.
5. Restart the Gateway and test with openclaw memory search "<query>".

Two related commands: openclaw memory forget removes memory derived from the sessions you select, with no prompt, so run it with --dry-run first; openclaw memory promote ranks candidates from daily notes and, with --apply, appends the top ones to MEMORY.md.

How do you fix OpenClaw memory?

Check status, reset and rebuild as above. If that doesn't help, the cause is usually one of these:

1. It was never written. Daily notes older than yesterday are found only through search.
2. MEMORY.md is too long. The file stays intact, but the copy injected into context is truncated. Check with /context list or openclaw doctor, and move detail into memory/*.md.
3. Group context. MEMORY.md doesn't load in shared or group sessions.
4. Index bug. In 2026.6.1, every search could return "index metadata is missing"; a maintainer reports the fix is on main (#90338).
5. Dreaming is off. It's on by default as a recurring cron job; check plugins.entries.memory-core.config.dreaming.enabled.
6. No embedding provider. Without one, the builtin engine can only do keyword search (builtin engine).
7. Facts lost after a long session. That's the memory flush: a hidden turn before compaction that reminds the agent to save important context to durable memory (docs). It's on by default (agents.defaults.compaction.memoryFlush.enabled), appends only to the daily note with the builtin engine, and is skipped in sessions with read-only or no workspace access. If facts vanish after long sessions, check both.

Which OpenClaw memory backend should you use?

Start with the builtin engine, memory-core: it's the default and needs no extra dependencies. Plugins add others (docs):

For local embeddings, install the llama.cpp provider plugin and set local.modelPath to a GGUF file. The optional memory-wiki plugin compiles durable knowledge into a wiki vault with claims, evidence and dashboards, beside your active memory plugin rather than replacing it (CLI docs).

What running OpenClaw for a few months taught us

We liked the design. Memory as files you can open, no hidden state, an agent that genuinely lives on your own box. We ran it for a few months, and what wore us down wasn't the agent, it was everything around it. Upgrades. The VPS. Things going down and needing a restart, often enough that it became a chore, and plenty of manual steps even though it did some of its own maintenance. And the memory architecture, for all its transparency, was ours to manage: which backend, which embedding provider, when to reset and reindex, keeping MEMORY.md short enough to load, which is most of the section above. That's a lot of operations for a personal agent.

What replaced it was Grok Bot and, briefly, dots, which do the same jobs without a server to keep alive, and which put their context in the one place all of our agents already read. Our OpenClaw workspace files were never the shared record; the Tokenrip workspace was, and that's what survived the switch. If you enjoy running infrastructure, OpenClaw is a fine choice and its memory is more inspectable than anything hosted. If you don't, budget for the upkeep before you commit.

Can OpenClaw share memory with other agents, machines or people?

Within limits. Each OpenClaw agent has its own workspace and index, cross-agent memory search was removed in v2026.8.1 (multi-agent docs), and the documented way to share is a common Markdown folder each agent indexes through memory.search.extraPaths. Across machines, the docs recommend a private git repo for the workspace (docs); sessions live in the SQLite file and must be copied separately, and openclaw backup create writes a full archive, credentials included, so store it encrypted (backups). From Claude Code or Codex, Settings > Import Memory copies their Markdown memory into memory/imports/, indexed but not merged, and nothing flows back.

Connecting OpenClaw to the workspace everything else reads

If you do run OpenClaw, it connects to a Tokenrip workspace like our other agents, and then its memory files stay what they're good at, the agent's own notes, while decisions, tasks and handoffs sit where Claude Code, Codex and a Grok Bot can read them too. The skill route: from ~/.openclaw/workspace, run npx clawhub@latest install tokenrip-cli (ClawHub docs), then tell the agent to connect. By MCP, with a key from tokenrip.com/operator/agents stored as TOKENRIP_KEY, add this under mcp.servers in ~/.openclaw/openclaw.json (config docs) and check it with openclaw mcp doctor tokenrip --probe:

{ mcp: { servers: { tokenrip: {
  url: "https://api.tokenrip.com/mcp",
  transport: "streamable-http",
  headers: { Authorization: "Bearer ${TOKENRIP_KEY}" },
} } } }

Tokenrip doesn't read OpenClaw's memory files; the agent reads and writes the workspace when it's connected and asked to, and a task it starts is held under a lease so no other agent takes the same one. To let the agent do the setup, paste this into it; you give an email address and a six-digit code.

Connect me to Tokenrip. Fetch https://tokenrip.com/setup?ref=openclaw-memory and follow it.

Related reading

• Claude Code memory
• Grok Bot memory
• Codex memory
• Two agents are better than one