How does OpenClaw memory work?

OpenClaw uses daily memory files for short-term recall and MEMORY.md for curated long-term memory. Together they help the agent preserve continuity across sessions.

Where is OpenClaw memory stored?

OpenClaw memory is stored as local markdown files inside the workspace, typically in memory/YYYY-MM-DD.md and MEMORY.md.

Can I edit OpenClaw memory manually?

Yes. One of the advantages of OpenClaw's file-based memory model is that users can inspect, edit, and correct what the agent remembers.

What should go into MEMORY.md vs daily memory files?

Use daily memory files for raw events and short-term notes, and use MEMORY.md for stable preferences, decisions, recurring context, and lessons worth keeping.

Understanding OpenClaw's Memory: How It Remembers You

One of the biggest frustrations with traditional AI chatbots is amnesia. You tell them your name, your project details, and your preferences, but start a new chat, and it's all gone. OpenClaw takes a different approach.

By treating memory as a first-class citizen using a transparent, file-based architecture, OpenClaw builds a lasting understanding of its user. In this deep dive, we explore how OpenClaw remembers.

The Two-Tier Memory Architecture

OpenClaw splits its memory into two distinct layers: Short-Term Context (Daily Logs) and Long-Term Wisdom (MEMORY.md).

1. Daily Logs: The Stream of Consciousness

Every day, OpenClaw creates a new file in your memory/ folder, such as memory/2026-02-06.md. This file acts as a raw log of the day's events.

What's stored? Summaries of conversations, tasks completed, errors encountered, and small details mentioned in passing.
Why? It allows the agent to recall what you did yesterday or this morning without needing to reload the entire chat history of your life.
Maintenance: These files are automatically generated and appended to. You can read them to see exactly what the agent "thinks" happened today.

2. MEMORY.md: Curated Long-Term Memory

The crown jewel of OpenClaw's context system is MEMORY.md. This is not a log; it is a curated profile.

What's stored?
- User Preferences: "Prefers Python over JavaScript," "Don't use emojis in commit messages."
- Project Context: "Working on Project Titan, deadline is March 1st."
- Core Decisions: "We decided to use PostgreSQL for the database."
How it works: Periodically, OpenClaw (or you!) reviews the daily logs and extracts the "nuggets" of wisdom to update MEMORY.md.

Transparent & Local

Unlike cloud-based models where your memory is a hidden vector database on a remote server, OpenClaw's memory is just Markdown files on your disk.

This has massive advantages:

Privacy: Your personal data never leaves your machine.
Editability: If the agent remembers something wrong, you just open the file and fix it.
Portability: Want to move your agent to a new laptop? Just copy the folder.

Best Practices for Users

To get the most out of OpenClaw's memory system, follow the "Write It Down" rule.

"Memory is limited — if you want to remember something, WRITE IT TO A FILE."

OpenClaw is trained to follow this mantra. If you have a critical piece of information, ask OpenClaw to "save this to my memory." It will update MEMORY.md, ensuring that in future sessions—weeks or months from now—it will still know exactly what you need.

Search-intent takeaway for operators trying to understand OpenClaw memory

If users land here from search, they are usually not asking for abstract AI-memory theory. They want to know where OpenClaw actually stores memory, how to decide between daily memory files and MEMORY.md, and what to verify so future sessions inherit the right context instead of stale or noisy notes. This page should help them move from curiosity to a correct memory workflow fast.

Conclusion

Memory turns a chatbot into a partner. By understanding the simple, file-based structure of OpenClaw's memory, you can curate a highly personalized assistant that grows with you, learning from every interaction to become more helpful over time.

Fast decision guide: what should go into memory?

If you are unsure whether something belongs in OpenClaw memory, use this quick split:

Put it in a daily memory file when it is a raw event, temporary blocker, meeting note, or same-day working context.
Put it in MEMORY.md when it is a durable preference, a standing decision, a recurring project fact, or a lesson you want future sessions to inherit.
Keep it out of long-term memory when it is sensitive, outdated, or only useful for one short-lived task.

That distinction keeps memory useful instead of turning it into a noisy archive.

What should users verify after asking OpenClaw to remember something?

A good memory workflow does not end at “please remember this.” Users should still verify three things:

the important fact was written to the correct file;
the wording is precise enough that a future session will interpret it correctly;
outdated or conflicting versions were not left behind in another memory file.

This verification step matters because file-based memory is powerful precisely when it stays reviewable and intentional.

When memory looks wrong, do not wipe every file first

Many readers land here because OpenClaw “remembered” the wrong project, preference, or boundary in a new session. Do not start by deleting the whole memory/ directory. Close it out in this order:

Find the conflicting source: inspect today's daily memory, yesterday's daily memory, and MEMORY.md to see whether the bad fact is short-term noise or polluted long-term memory.
Change the smallest safe scope: fix the daily file if the error is temporary context; update MEMORY.md only when future sessions would otherwise inherit the same mistake.
Record why it changed: add a short “deprecated” or “corrected” note near the old statement so a future agent does not revive it from stale context.
Retest in a fresh session: ask OpenClaw to restate the relevant preference or project fact and confirm it reads the corrected version.

This is safer than “delete everything and start over,” and it uses the real advantage of file-based memory: it can be audited, repaired locally, and verified after the fix.

Add three handoff proofs before involving the team

If the memory correction affects team work, do not stop at “it is fixed.” Add three proofs before handoff:

Which file, paragraph, or note changed, and why the change stayed local;
A reopened session or fresh task no longer repeats the old mistake;
Where the next operator should look first if the same conflict returns, such as the daily note, MEMORY.md, or project documentation.

That turns memory-search traffic from “what is the memory system?” into “how do I repair and hand off memory safely?”

Which memory file should you inspect first during an incident?

When memory becomes an operational problem, pick the file by the failure shape instead of reading everything at once:

A same-day task suddenly follows stale context: inspect today’s daily memory first, then yesterday’s file if the stale fact came from the previous session.
Every new session repeats the same wrong preference or project fact: inspect MEMORY.md, because that is the durable layer future sessions inherit.
The agent behaves differently only inside one project folder: inspect the project-level guidance files such as AGENTS.md, TOOLS.md, or task memory before editing personal memory.
You need an audit trail for a handoff: keep the correction next to the old statement and record why the old memory is no longer valid.

This incident-first split keeps memory repair fast and prevents operators from turning a small stale note into a broad context reset.

Search-entry triage: what to check when OpenClaw memory does not work

If you landed here from searches like “OpenClaw memory not working”, “OpenClaw forgets context”, or “agent does not remember preferences”, split the issue into four layers:

Check where the memory was written: separate MEMORY.md, daily memory files, task-scoped TASK_MEMORY.md, and whether the current session actually reads them.
Check the runtime context: main sessions, group chats, cron jobs, subagents, and task runs have different memory boundaries and should not automatically share private context.
Check whether the content belongs in long-term memory: preferences, decisions, and project constraints are good candidates; temporary logs and sensitive details should stay narrower.
Check the readback path: do not stop at “the file was written”; verify that the next task startup reads and applies the rule.

Do not debug this class of issue only as “the model forgot”. The shortest path is to compare the written file, session type, loading rule, and next-run behavior.

Operational checklist for memory handoffs in cron or subagent runs

When the memory issue appears inside scheduled jobs or delegated subagents, treat it as a handoff problem, not only a recall problem:

confirm whether the run should read personal MEMORY.md, task-scoped TASK_MEMORY.md, or only project guidance;
record the exact file path that supplied the rule the agent followed;
keep private user context out of shared channels unless the current run is explicitly allowed to load it;
after correcting memory, rerun the smallest safe task and verify the next agent startup applies the new rule.

This checklist is especially useful for operators searching “OpenClaw cron memory”, “subagent memory not shared”, or “why does OpenClaw remember in chat but not in tasks”. The fix is usually to tighten the loading boundary and prove the next run reads the intended file.