#Constant memory loss
1 messages · Page 1 of 1 (latest)
OpenClaw isn’t “forgetting” in the human sense — there are a few different mechanisms that can look like memory loss:
-
LLMs are stateless. They only “remember” what’s in the current context window unless it gets written to disk (memory files).
Docs: https://docs.openclaw.ai/concepts/memory -
Sessions reset. By default OpenClaw will start a fresh session on a schedule (default is a daily reset at 04:00 local time on the gateway host, and/or idle resets depending on config). That can feel like it “forgot everything overnight” even though nothing is broken.
Docs: https://docs.openclaw.ai/concepts/session -
Discord threads/channels are isolated. If you talk in a different thread/channel, that’s a different session key → different “brain”.
-
Important gotcha in group contexts:
MEMORY.md(the curated long-term memory) is only loaded in the main, private session — not in group contexts (to avoid leaking private info into servers). So if you’re mostly talking to it in a Discord channel/thread, it may never load your long-term memory file.
(This is explicitly called out in the Memory docs.)
What to do (practical fixes)
- Use a DM for “remember this forever” stuff, and say explicitly: “Write this to MEMORY.md” / “Write this to today’s memory/YYYY-MM-DD.md”.
- Make sure the workspace is writable, otherwise automatic “memory flush before compaction” is skipped (and it won’t be able to persist notes).
- Adjust session reset policy if it’s resetting too aggressively (daily/idle). Config is under
session.reset/session.resetByType.
Reference: https://docs.openclaw.ai/gateway/configuration-reference (see the “Session” section)
Example (make DMs stick around much longer):
session: {
resetByType: {
direct: { mode: "idle", idleMinutes: 1440 }, // 24h
thread: { mode: "idle", idleMinutes: 1440 },
group: { mode: "idle", idleMinutes: 360 } // 6h
}
}
Quick questions so we can pinpoint which one you’re hitting
- What does
openclaw --versionshow? - Where are you chatting when it “forgets” — DM, server channel, or Discord thread?
- Is the forgetting correlated with next day (around 4am gateway-local time) or after the gateway restarts?
Answer those and I’ll tell you exactly which knob to turn.
- Version 2026.2.19
- Telegram
- No not always the next day. We can work on a project and it forgets maybe after 10 minutes and i have to remind it
If it forgets after ~10 minutes on Telegram, that’s usually not “memory” (the long-term file) — it’s almost always one of these:
1) Your session is being reset on idle
If your config has something like session.reset.mode: "idle" with a small idleMinutes (e.g. 10), OpenClaw will start a fresh session after you pause… which looks exactly like “it forgot the project”.
Check your reset policy:
openclaw config get session.reset
openclaw config get session.resetByType
openclaw config get session.resetByChannel
If you see idleMinutes: 10, increase it (or switch to daily resets).
Config reference: https://docs.openclaw.ai/gateway/configuration-reference#session
2) Tool outputs can get pruned after a TTL (common “we were working on X and now it doesn’t remember”)
If your workflow involves tool output (web fetches, browsing, reading files, etc), OpenClaw may trim old tool results after some idle time to keep costs down. Then the model no longer has those details in-context.
Docs: https://docs.openclaw.ai/concepts/session-pruning
Two fixes:
- Best practice: have it summarize + write the important bits to
memory/YYYY-MM-DD.mdas you go. - Or tune pruning (increase TTL / disable) via
agents.defaults.contextPruning.
3) You might be jumping between different Telegram contexts
Telegram DM vs group, or different threads/topics, can map to different session keys.
To verify whether you’re actually getting a new session, run:
openclaw sessions --active 120 --json
…and look for your Telegram session key(s) (usually like agent:main:telegram:dm:...).
If you paste the output of:
openclaw config get session.resetopenclaw sessions --active 120 --json(you can redact IDs if you want)
…I can tell you exactly which one is happening and what to change.
root@Olisinos:~# openclaw config get session.reset
🦞 OpenClaw 2026.2.19 (2435499) — I'll refactor your busywork like it owes me money.
Config path not found: session.reset
root@Olisinos:~# openclaw config get session.resetByType
🦞 OpenClaw 2026.2.19 (2435499) — iMessage green bubble energy, but for everyone.
Config path not found: session.resetByType
root@Olisinos:~# openclaw config get session.resetByChannel
🦞 OpenClaw 2026.2.19 (2435499)
Gateway online—please keep hands, feet, and appendages inside the shell at all times.
Config path not found: session.resetByChannel
That output is actually useful: Config path not found just means you haven’t overridden those settings in your config file. OpenClaw is still using its defaults (so this probably isn’t an “idleMinutes=10” session reset you configured).
If it “forgets the project after ~10 minutes” in the same Telegram chat, the usual culprits are:
A) You’re not in the same session (session key/session id is changing)
This can happen if:
- you’re actually talking in different Telegram contexts (DM vs group, different topic/thread), or
- you have two gateways/instances receiving Telegram updates (split brain), so replies come from different session stores.
Check this first:
openclaw sessions --active 120 --json
Send that output (you can redact ids). We’re looking for whether your Telegram conversation stays on one stable key like agent:main:telegram:dm:... and whether it’s one session or many.
Also tail logs while you send 2–3 messages:
openclaw logs --follow --local-time
If we see “new session” / “session reset” / different keys, that explains the “10 minute amnesia”.
Docs: https://docs.openclaw.ai/cli/sessions and https://docs.openclaw.ai/cli/logs
B) Context window / compaction (you paste big stuff → earlier details drop out)
If you paste long code/logs/specs, you can blow past the model’s usable context fast. Then the assistant may act like it “forgot” even though the session didn’t reset.
Mitigations:
- Don’t paste huge blobs repeatedly; instead keep a living project scratchpad file and have the agent update it.
- Explicitly tell it: “Create
memory/projects/<name>.mdand keep it updated with current goals, decisions, TODOs, and links.”
Memory is file-based in OpenClaw (Markdown in workspace):
https://docs.openclaw.ai/concepts/memory
Compaction overview:
https://docs.openclaw.ai/concepts/compaction
C) Tool-result pruning (only affects tool outputs, but can feel like forgetting)
If your workflow depends on tool output (browser/web_fetch/read/etc), old tool results may get trimmed from the in-memory context.
Docs: https://docs.openclaw.ai/concepts/session-pruning
Two quick questions
- Are you chatting with it on Telegram DM or in a group?
- When it “forgets”, does it also forget your last few plain messages, or mainly things that came from tools / long pasted content?
If you paste openclaw sessions --active 120 --json plus ~20 lines of openclaw logs --follow around the moment it forgets, we can usually pinpoint the exact cause immediately.
root@Olisinos:~# openclaw sessions --active 120 --json
{
"path": "/root/.openclaw/agents/main/sessions/sessions.json",
"count": 3,
"activeMinutes": 120,
"sessions": [
{
"key": "agent:main:main",
"kind": "direct",
"updatedAt": 1772406748845,
"ageMs": 134270,
"sessionId": "e9aef521-f584-494c-8811-88262b7604ed",
"systemSent": true,
"abortedLastRun": false,
"inputTokens": 352201,
"outputTokens": 3950,
"totalTokens": 177506,
"totalTokensFresh": true,
"model": "kimi-k2.5",
"modelProvider": "openrouter",
"providerOverride": "anthropic",
"modelOverride": "claude-sonnet-4-6",
"contextTokens": 262144
},
{
"key": "agent:main:cron:503d4478-9095-4bfe-9fa1-26e17a4814dd",
"kind": "direct",
"updatedAt": 1772402691735,
"ageMs": 4191380,
"sessionId": "7072ca06-daea-4669-9d27-0bcd861729ce",
"systemSent": true,
"inputTokens": 111892,
"outputTokens": 1102,
"totalTokens": 58766,
"totalTokensFresh": true,
"model": "kimi-k2.5",
"modelProvider": "openrouter",
"contextTokens": 262144
},
{
"key": "agent:main:cron:503d4478-9095-4bfe-9fa1-26e17a4814dd:run:7072ca06-daea-4669-9d27-0bcd861729ce",
"kind": "direct",
"updatedAt": 1772402691735,
"ageMs": 4191381,
"sessionId": "7072ca06-daea-4669-9d27-0bcd861729ce",
"systemSent": true,
"inputTokens": 111892,
"outputTokens": 1102,
"totalTokens": 58766,
"totalTokensFresh": true,
"model": "kimi-k2.5",
"modelProvider": "openrouter",
"contextTokens": 262144
}
]
}
Your openclaw sessions output is the smoking gun:
- You only have one active direct-chat session:
agent:main:main - It’s massive:
inputTokens: 352201,totalTokens: 177506(with acontextTokenswindow of262144)
When you keep everything in one ever-growing “main” session, models start behaving exactly like what you describe: they’ll drop details, get fuzzy about “what project are we on”, and you’ll end up re-explaining things even minutes later. That’s not OpenClaw “deleting memory” — it’s the LLM struggling with a huge, mixed context.
Fix 1 (recommended): stop using one giant “main” DM for everything
Change DM session grouping so Telegram doesn’t all collapse into the one agent:main:main bucket:
openclaw config set session.dmScope "per-channel-peer"
openclaw gateway restart
Config reference (dmScope options): https://docs.openclaw.ai/gateway/configuration-reference#session
Session concept: https://docs.openclaw.ai/concepts/session
Fix 2: use “project state on disk” instead of hoping the chat scroll stays coherent
For any project you care about, have it maintain a short canonical file (and update it regularly), e.g.:
memory/projects/<project>.md(goals, current plan, decisions, TODO, links)
Docs on how OpenClaw memory works (it’s Markdown in the workspace):
https://docs.openclaw.ai/concepts/memory
Quick check: is it actually resetting sessions?
Next time it “forgets”, run this twice (before/after) and see if sessionId changes:
openclaw sessions --active 120 --json
- If
sessionIdchanges → something is resetting/creating new sessions (then we should look atopenclaw logs --followto see why). - If
sessionIdstays the same → it’s context overload/mixed context, and Fix #1 + #2 will help a lot.
If you want, paste the output of:
openclaw config get session.dmScope
(and if it says “path not found”, that just means it’s still on the default).
root@Olisinos:~# openclaw sessions --active 120 --json
{
"path": "/root/.openclaw/agents/main/sessions/sessions.json",
"count": 3,
"activeMinutes": 120,
"sessions": [
{
"key": "agent:main:main",
"kind": "direct",
"updatedAt": 1772406748845,
"ageMs": 400749,
"sessionId": "e9aef521-f584-494c-8811-88262b7604ed",
"systemSent": true,
"abortedLastRun": false,
"inputTokens": 352201,
"outputTokens": 3950,
"totalTokens": 177506,
"totalTokensFresh": true,
"model": "kimi-k2.5",
"modelProvider": "openrouter",
"providerOverride": "anthropic",
"modelOverride": "claude-sonnet-4-6",
"contextTokens": 262144
},
{
"key": "agent:main:cron:503d4478-9095-4bfe-9fa1-26e17a4814dd",
"kind": "direct",
"updatedAt": 1772402691735,
"ageMs": 4457859,
"sessionId": "7072ca06-daea-4669-9d27-0bcd861729ce",
"systemSent": true,
"inputTokens": 111892,
"outputTokens": 1102,
"totalTokens": 58766,
"totalTokensFresh": true,
"model": "kimi-k2.5",
"modelProvider": "openrouter",
"contextTokens": 262144
},
{
"key": "agent:main:cron:503d4478-9095-4bfe-9fa1-26e17a4814dd:run:7072ca06-daea-4669-9d27-0bcd861729ce",
"kind": "direct",
"updatedAt": 1772402691735,
"ageMs": 4457860,
"sessionId": "7072ca06-daea-4669-9d27-0bcd861729ce",
"systemSent": true,
"inputTokens": 111892,
"outputTokens": 1102,
"totalTokens": 58766,
"totalTokensFresh": true,
"model": "kimi-k2.5",
"modelProvider": "openrouter",
"contextTokens": 262144
}
]
}
root@Olisinos:~# openclaw config session.dmScope
error: too many arguments for 'config'. Expected 0 arguments but got 1.
root@Olisinos:~# openclaw config get session.dmScope
🦞 OpenClaw 2026.2.19 (2435499) — Chat automation for people who peaked at IRC.
per-channel-peer
Nice — session.dmScope is already set correctly now (per-channel-peer). Two important follow-ups:
1) Restart the gateway (otherwise the running gateway may still be using the old dmScope)
Config edits don’t affect the already-running gateway process until restart.
openclaw gateway restart
Then send a message to the bot on Telegram and re-run:
openclaw sessions --active 120 --json
You should now see a session key that looks like:
agent:main:telegram:dm:<yourId>(ortelegram:group:<id>if it’s a group)
If you still only see agent:main:main, that strongly suggests your Telegram traffic is being handled by a different OpenClaw instance (or you’re not actually hitting this gateway).
2) Your current active session is enormous (that alone can cause “10 minute amnesia”)
agent:main:main is at ~177k totalTokens. Even with a big context window, once a session gets that large/mixed, the model will start dropping details.
In Telegram, do a clean slate for the project:
- send:
/reset(or/new)
Then immediately ask it to create/update a project state file, e.g.: - “Create
memory/projects/<project>.mdwith goals, current plan, decisions, TODOs. Keep it updated.”
Docs: https://docs.openclaw.ai/concepts/memory
If after the restart you still don’t get a telegram:... session key, paste just the first ~30 lines around an inbound message from:
openclaw logs --follow --local-time
That will show which session key the gateway is assigning (and whether multiple gateways are involved).
root@Olisinos:~# openclaw sessions --active 120 --json
{
"path": "/root/.openclaw/agents/main/sessions/sessions.json",
"count": 4,
"activeMinutes": 120,
"sessions": [
{
"key": "agent:main:telegram:direct:1818300685",
"kind": "direct",
"updatedAt": 1772407419340,
"ageMs": 19462,
"sessionId": "f402bf42-ea9d-4eeb-83ec-0782032ce94d",
"systemSent": true,
"abortedLastRun": false,
"totalTokens": null,
"totalTokensFresh": false,
"model": "moonshotai/kimi-k2.5",
"contextTokens": 262144
},
{
"key": "agent:main:main",
"kind": "direct",
"updatedAt": 1772407418949,
"ageMs": 19852,
"sessionId": "e9aef521-f584-494c-8811-88262b7604ed",
"systemSent": true,
"abortedLastRun": false,
"inputTokens": 352201,
"outputTokens": 3950,
"totalTokens": 177506,
"totalTokensFresh": true,
"model": "kimi-k2.5",
"modelProvider": "openrouter",
"providerOverride": "anthropic",
"modelOverride": "claude-sonnet-4-6",
"contextTokens": 262144
},
{
"key": "agent:main:cron:503d4478-9095-4bfe-9fa1-26e17a4814dd",
"kind": "direct",
"updatedAt": 1772402691735,
"ageMs": 4747066,
"sessionId": "7072ca06-daea-4669-9d27-0bcd861729ce",
"systemSent": true,
"inputTokens": 111892,
"outputTokens": 1102,
"totalTokens": 58766,
"totalTokensFresh": true,
"model": "kimi-k2.5",
"modelProvider": "openrouter",
"contextTokens": 262144
},
{
"key": "agent:main:cron:503d4478-9095-4bfe-9fa1-26e17a4814dd:run:7072ca06-daea-4669-9d27-0bcd861729ce",
"kind": "direct",
"updatedAt": 1772402691735,
"ageMs": 4747067,
"sessionId": "7072ca06-daea-4669-9d27-0bcd861729ce",
"systemSent": true,
"inputTokens": 111892,
"outputTokens": 1102,
"totalTokens": 58766,
"totalTokensFresh": true,
"model": "kimi-k2.5",
"modelProvider": "openrouter",
"contextTokens": 262144
}
]
}
Perfect — that’s the fix taking effect.
You now have a Telegram-specific session key:
agent:main:telegram:direct:1818300685
That means Telegram is no longer dumping everything into the giant agent:main:main session (which was ~177k tokens and absolutely can cause “we talked about this 10 minutes ago and now it’s gone” behavior due to sheer context bloat / mixed topics).
What to do next (so it actually feels better day-to-day)
- Start fresh in that Telegram chat
In Telegram, send a standalone:
/reset(or/new)
This clears any leftover messy context and gives you a clean project run.
- Put project state on disk (real “memory”)
Tell it something like:
- “Create
memory/projects/<project>.mdwith: goal, current plan, decisions, open TODOs, and links. Keep it updated as we work.”
That way even if the chat gets long, it has a canonical source of truth.
Docs: https://docs.openclaw.ai/concepts/memory
- Quick sanity check that you’re always in the same session
Send 1 message in Telegram, then run:
openclaw sessions --active 120 --json
You should see the same key and the updatedAt ticking forward on that Telegram entry.
Note about totalTokens: null
Not a problem. It just means token accounting for that session entry isn’t currently populated/fresh (depends on provider/model + when the gateway last computed it). It’s not related to memory.
If after this change you still get “forgetting after 10 minutes” within the same Telegram chat, grab ~20–30 lines from:
openclaw logs --follow --local-time
right when it “forgets” — we can tell immediately if it’s a session reset/compaction event or just context overload from large pasted content.
Yep — seeing both entries is normal.
agent:main:telegram:direct:1818300685= your Telegram DM session (this is the one you care about)agent:main:main= an older “main bucket” session that’s still in the store (and may still be used by some other transport/UI you’ve talked to, or just lingering from before you changeddmScope)
The important part: your Telegram chat now has its own stable key, so it won’t keep ballooning into that 177k‑token agent:main:main monster anymore.
What I’d do next
- In Telegram, send
/resetonce to start clean in the new Telegram session. - For any longer project, tell it to maintain a file like
memory/projects/<project>.md(goals/decisions/TODO). That’s the “real” durable memory in OpenClaw.
If you still see 10‑minute “amnesia” after this change
Run this while you send a message in Telegram:
openclaw logs --follow --local-time
You should see that inbound message being attached to agent:main:telegram:direct:1818300685.
If sometimes Telegram messages are answered by a different OpenClaw instance (common when two gateways are running with the same Telegram bot token), you’ll still get memory loss — and the logs will make that obvious.
If you paste ~20 lines of the log around an inbound Telegram message, I can confirm whether it’s routing consistently to the Telegram session key.
root@Olisinos:~# openclaw sessions --active 120 --json
{
"path": "/root/.openclaw/agents/main/sessions/sessions.json",
"count": 4,
"activeMinutes": 120,
"sessions": [
{
"key": "agent:main:telegram:direct:1818300685",
"kind": "direct",
"updatedAt": 1772407688787,
"ageMs": 11526,
"sessionId": "f402bf42-ea9d-4eeb-83ec-0782032ce94d",
"systemSent": true,
"abortedLastRun": false,
"inputTokens": 9392,
"outputTokens": 361,
"totalTokens": 16304,
"totalTokensFresh": true,
"model": "kimi-k2.5",
"modelProvider": "openrouter",
"contextTokens": 262144
},
{
"key": "agent:main:main",
"kind": "direct",
"updatedAt": 1772407688758,
"ageMs": 11555,
"sessionId": "e9aef521-f584-494c-8811-88262b7604ed",
"systemSent": true,
"abortedLastRun": false,
"inputTokens": 352201,
"outputTokens": 3950,
"totalTokens": 177506,
"totalTokensFresh": true,
"model": "kimi-k2.5",
"modelProvider": "openrouter",
"providerOverride": "anthropic",
"modelOverride": "claude-sonnet-4-6",
"contextTokens": 262144
},
{
"key": "agent:main:cron:503d4478-9095-4bfe-9fa1-26e17a4814dd",
"kind": "direct",
"updatedAt": 1772402691735,
"ageMs": 5008578,
"sessionId": "7072ca06-daea-4669-9d27-0bcd861729ce",
"systemSent": true,
"inputTokens": 111892,
"outputTokens": 1102,
"totalTokens": 58766,
"totalTokensFresh": true,
"model": "kimi-k2.5",
"modelProvider": "openrouter",
"contextTokens": 262144
},
{
"key": "agent:main:cron:503d4478-9095-4bfe-9fa1-26e17a4814dd:run:7072ca06-daea-4669-9d27-0bcd861729ce",
"kind": "direct",
"updatedAt": 1772402691735,
"ageMs": 5008578,
"sessionId": "7072ca06-daea-4669-9d27-0bcd861729ce",
"systemSent": true,
"inputTokens": 111892,
"outputTokens": 1102,
"totalTokens": 58766,
"totalTokensFresh": true,
"model": "kimi-k2.5",
"modelProvider": "openrouter",
"contextTokens": 262144
}
]
}
Nice — this looks healthy now.
Your Telegram session is:
agent:main:telegram:direct:1818300685- and it’s only ~16k total tokens right now (vs the old
agent:main:mainat ~177k)
That’s exactly what we wanted: Telegram is no longer piling into the giant “main” bucket, so you should see way less “we were just talking about this and now it’s gone” behavior.
Next steps I’d do to lock it in:
- In Telegram, send
/resetonce to start the project with a clean slate in this new Telegram session. - For any real project, have it keep a canonical state file, e.g.
memory/projects/<project>.md(goals / current plan / decisions / TODO). That’s the durable memory OpenClaw can reliably reload.
If you still see sudden amnesia within the same Telegram chat after this, paste a short snippet from openclaw logs --follow --local-time around the moment it happens — but with the session key now correct, odds are this was the main issue.