#Constant memory loss

1 messages · Page 1 of 1 (latest)

long viper
#

My openclaw constantly have a memory loss.
I have to remind it all the time things that we are working on and many times it does not even have any memory of things that we have worked on.

Is there a solution to this?

ornate pagodaBOT
#

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

hybrid pelicanBOT
#

OpenClaw isn’t “forgetting” in the human sense — there are a few different mechanisms that can look like memory loss:

  1. 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

  2. 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

  3. Discord threads/channels are isolated. If you talk in a different thread/channel, that’s a different session key → different “brain”.

  4. 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

  1. What does openclaw --version show?
  2. Where are you chatting when it “forgets” — DM, server channel, or Discord thread?
  3. 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.

long viper
#
  1. Version 2026.2.19
  2. Telegram
  3. 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
hybrid pelicanBOT
#

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.md as 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:

  1. openclaw config get session.reset
  2. openclaw sessions --active 120 --json (you can redact IDs if you want)

…I can tell you exactly which one is happening and what to change.

long viper
#

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

hybrid pelicanBOT
#

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>.md and 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

  1. Are you chatting with it on Telegram DM or in a group?
  2. 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.

long viper
#

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
}
]
}

hybrid pelicanBOT
#

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 a contextTokens window of 262144)

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 sessionId changes → something is resetting/creating new sessions (then we should look at openclaw logs --follow to see why).
  • If sessionId stays 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).

long viper
#

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

hybrid pelicanBOT
#

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> (or telegram: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>.md with 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).

long viper
#

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
}
]
}

hybrid pelicanBOT
#

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)

  1. 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.

  1. Put project state on disk (real “memory”)
#

Tell it something like:

  • “Create memory/projects/<project>.md with: 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

  1. 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 changed dmScope)

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

  1. In Telegram, send /reset once to start clean in the new Telegram session.
  2. 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.

long viper
#

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
}
]
}

hybrid pelicanBOT
#

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:main at ~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:

  1. In Telegram, send /reset once to start the project with a clean slate in this new Telegram session.
  2. 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.