reset is not occuring as set in openclaw.json | Friends of the Crustacean 🦞🤝 | Page 1

flat surge Apr 19, 2026, 7:12 PM

#

I have the following in my openclaw.json, but the reset isn't ocurring:
"session": {
"dmScope": "per-channel-peer",
"reset": {
"mode": "daily",
"atHour": 1
}
},

ember nimbusBOT Apr 19, 2026, 7:12 PM

#

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

zenith axleBOT Apr 19, 2026, 7:12 PM

#

summer magnetBOT Apr 19, 2026, 7:15 PM

#

That config looks valid, but there are 3 easy gotchas here:

dmScope only affects DMs. It does not affect a Discord channel/thread like this one.
Daily reset is lazy, not proactive. OpenClaw creates a new session on the next message after the reset boundary, it does not clear the thread exactly at 1:00 by itself.
atHour is based on the gateway host’s local timezone, not Discord time / your local browser time.

Also, config changes need a gateway restart.

So the quick sanity check is:

openclaw --version
openclaw gateway restart
openclaw status --all

Then test it like this:

#

wait until after 1:00 on the gateway host
send a new message in the same thread
that next message should start a fresh sessionId

Docs:

If you paste:

openclaw --version
the host timezone
openclaw status --all

I can help narrow down whether it’s timezone, restart, or a bug.

flat surge Apr 19, 2026, 7:20 PM

#

version is v2026.4.14, I've done plenty of gateway restarts. I did do a manual /new since. So this should happen as I said at 1:00 am, other crons occur after that. I generally check in with my bot in discord after those crons run, but it is never reset. Anyway isn't creating a fresh session id, here is the status --all:
Overview
┌──────────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├──────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────┤
│ OS │ linux 6.12.75+rpt-rpi-2712 (arm64) · node 22.22.2 │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.15 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 59ms · auth token · rpi5 (10.0.4. │
│ │ 22) app 2026.4.15 linux 6.12.75+rpt-rpi-2712 │
│ Gateway self │ rpi5 (10.0.4.22) app 2026.4.15 linux 6.12.75+rpt-rpi-2712 │
│ Gateway service │ systemd installed · enabled · running (pid 2846262, state active) │
│ Node service │ systemd not installed │
│ Agents │ 2 · no bootstrap files · sessions 27 · default main active 7m ago │
│ Memory │ 88 files · 166 chunks · sources memory · plugin memory-core · vector ready · fts ready · │
│ │ cache on (271) │
│ Plugin compatibility │ none │
│ Probes │ skipped (use --deep) │
│ Events │ none │
│ Tasks │ 0 active · 0 queued · 0 running · 7 issues · audit 61 warn · 69 tracked │
│ Heartbeat │ disabled (main), 60m (heartbeat) │
│ Sessions │ 27 active · default glm-5.1 (205k ctx) · 2 stores │
└──────────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────┘

#

Channels
┌──────────┬─────────┬────────┬────────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼────────────────────────────────────────────────────────────────────────────────────────┤
│ Discord │ ON │ OK │ token config (MTQ3…Iu7U · len 72) · accounts 1/1 │
│ WhatsApp │ ON │ OK │ linked · +15016665470 · auth 3m ago · accounts 1 │
└──────────┴─────────┴────────┴────────────────────────────────────────────────────────────────────────────────────────┘

Sessions
┌─────────────────────────────────────────┬────────┬─────────┬────────────────────────┬────────────────────────────────┐
│ Key │ Kind │ Age │ Model │ Tokens │
├─────────────────────────────────────────┼────────┼─────────┼────────────────────────┼────────────────────────────────┤
│ agent:main:discord:channel:1480… │ group │ 7m ago │ glm-5.1 │ 28k/205k (14%) · 🗄️ 62% cached │
│ agent💓main:heartbeat │ direct │ 53m ago │ gemini-3-flash-preview │ 7.7k/16k (47%) │
│ agent:main:main │ direct │ 3h ago │ glm-5.1 │ 19k/205k (9%) · 🗄️ 12% cached │
│ agent:main:cron:6ed252ce-7070-4… │ direct │ 5h ago │ gemini-3-flash-preview │ 7.6k/205k (4%) · 🗄️ 36% cached │
│ agent:main:cron:6ed252ce-7070-4… │ direct │ 5h ago │ gemini-3-flash-preview │ 7.6k/205k (4%) · 🗄️ 36% cached │
│ agent:main:cron:c7f3fb10-49ec-4… │ direct │ 7h ago │ gemini-3-flash-preview │ 13k/205k (6%) · 🗄️ 51% cached │
│ agent:main:cron:c7f3fb10-49ec-4… │ direct │ 7h ago │ gemini-3-flash-preview │ 13k/205k (6%) · 🗄️ 51% cached │
│ agent:main:cron:1ecc38f4-b3b6-4… │ direct │ 8h ago │ gemini-3-flash-preview │ 32k/205k (15%) · 🗄️ 59% cached │
│ agent:main:cron:1ecc38f4-b3b6-4… │ direct │ 8h ago │ gemini-3-flash-preview │ 32k/205k (15%) · 🗄️ 59% cached │
│ agent:main:cron:6ed252ce-7070-4… │ direct │ 11h ago │ gemini-3-flash-preview │ 7.5k/205k (4%) · 🗄️ 27% cached │
└─────────────────────────────────────────┴────────┴─────────┴────────────────────────┴────────────────────────────────┘

summer magnetBOT Apr 19, 2026, 7:25 PM

#

I think I see the trap.

I just checked the session code path. heartbeat, cron-event, and exec-event turns are treated as system events and they do not trigger a daily reset. If one of your overnight automations touches that same session after 1:00 AM, it refreshes the session entry, so when you later message the bot, the session no longer looks stale and no new sessionId gets minted.

That would match your symptom really well.

A few concrete notes:

Your config for session.reset looks fine.
dmScope is unrelated here, since this is a Discord thread/channel context, not a DM.
Your CLI says 2026.4.14, but the running gateway is 2026.4.15. I do not think that is the root cause here, but I would still align them.

What to check next:

Cron session target
If those jobs are using main, current, or a shared session:..., they can keep the chat session alive.

#

   openclaw cron list --json

Heartbeat session mode
If heartbeat is also hitting the same session, set it isolated:

{
  agents: {
    defaults: {
      heartbeat: {
        isolatedSession: true
      }
    }
  }

#

Best workaround
Move overnight jobs off the chat session:
- fresh run every time:
```
openclaw cron edit <job-id> --session isolated
```
- or, if the job needs its own history:
```
openclaw cron edit <job-id> --session "session:overnight"
```

Docs:

https://docs.openclaw.ai/automation/cron-jobs

#

If you paste openclaw cron list --json and your heartbeat config block, I can tell you exactly which job is preventing the rollover.

And honestly, if your expectation is “daily reset should still happen for the human chat even if cron/heartbeat ran overnight”, that feels like a pretty reasonable GitHub issue too: https://github.com/openclaw/openclaw/issues

#

Ah, this helps, and it rules out my earlier cron/heartbeat theory.

Your cron and heartbeat runs are already in separate session keys (...:cron:..., ...heartbeat), so they probably are not what’s keeping the Discord chat session alive here.

The next likely things are:

Timezone mismatch
Daily session reset uses the gateway host local time. Cron jobs can have their own --tz, so “my cron ran after 1 AM” does not necessarily prove the session-reset boundary passed.
Session key vs sessionId
The session key stays the same across resets. Only the sessionId rotates.
So seeing the same agent:main:main or agent:main:discord:... key is expected.
Memory is enabled
You have memory-core on, so even after a fresh session, the bot can still recall prior context. A reset is not full amnesia.

The most useful check now is to inspect the actual stored sessionId before and after the first post-1AM message.

#

For the DM main session:

date
jq '.["agent:main:main"] | {sessionId, updatedAt, sessionFile}' ~/.openclaw/agents/main/sessions/sessions.json

For the Discord thread/channel session:

jq 'to_entries[] | select(.key | contains("discord:channel:")) | {key: .key, sessionId: .value.sessionId, updatedAt: .value.updatedAt, sessionFile: .value.sessionFile}' ~/.openclaw/agents/main/sessions/sessions.json

If the sessionId stays the same after the first human message past the reset boundary, then yeah, I’d call that a real bug.

If you paste:

date

#

the relevant jq output before
the same jq output after one message that should have reset

…I can help confirm it cleanly.

Docs:

flat surge Apr 19, 2026, 7:36 PM

#

Just noting I am in gmt-5, also I just upgraded to v2026.4.15, but 1am I as on 4.14. Here is that jq
{
"key": "agent:main:discord:channel:1475229000317014038",
"sessionId": "12edc47e-5608-4bef-8a36-52ccf74784b5",
"updatedAt": 1776266359756,
"sessionFile": "/home/akessel56/.openclaw/agents/main/sessions/12edc47e-5608-4bef-8a36-52ccf74784b5.jsonl"
}
{
"key": "agent:main:discord:channel:1480328923567882300",
"sessionId": "8e14fe70-e7d1-4d95-b300-d57f25e6b10c",
"updatedAt": 1773008983177,
"sessionFile": "/home/akessel56/.openclaw/agents/main/sessions/8e14fe70-e7d1-4d95-b300-d57f25e6b10c.jsonl"
}
{
"key": "agent:main:discord:channel:1480331591116001421",
"sessionId": "14e0a719-5836-431c-9800-ab966dff6d55",
"updatedAt": 1774811449991,
"sessionFile": "/home/akessel56/.openclaw/agents/main/sessions/14e0a719-5836-431c-9800-ab966dff6d55.jsonl"
}
{
"key": "agent:main:discord:channel:1480336830984356002",
"sessionId": "5fdad26b-09d1-45b0-89e3-e93c416b241e",
"updatedAt": 1773666425124,
"sessionFile": "/home/akessel56/.openclaw/agents/main/sessions/5fdad26b-09d1-45b0-89e3-e93c416b241e.jsonl"
}
{
"key": "agent:main:discord:channel:1480705974598897794",
"sessionId": "ab40faff-64e2-466f-b9aa-f5bb7ab448ad",
"updatedAt": 1776085166301,
"sessionFile": "/home/akessel56/.openclaw/agents/main/sessions/ab40faff-64e2-466f-b9aa-f5bb7ab448ad.jsonl"
}
{
"key": "agent:main:discord:channel:1480547004370260072",
"sessionId": "8c7ba69f-6b94-4a1c-9a53-0462ed5fda99",
"updatedAt": 1774874291993,
"sessionFile": "/home/akessel56/.openclaw/agents/main/sessions/8c7ba69f-6b94-4a1c-9a53-0462ed5fda99.jsonl"
}
{
"key": "agent:main:discord:channel:1480773291491721217",
"sessionId": "3714f321-b3dd-4609-8fdd-1ca8b0607dd3",
"updatedAt": 1776625870127,
"sessionFile": "/home/akessel56/.openclaw/agents/main/sessions/3714f321-b3dd-4609-8fdd-1ca8b0607dd3.jsonl"
}
{
"key": "agent:main:discord:channel:1480777663181492234",
"sessionId": "d0327207-e93e-41d9-9816-1b724b5658d9",
"updatedAt": 1773870821994,
"sessionFile": "/home/akessel56/.openclaw/agents/main/sessions/d0327207-e93e-41d9-9816-1b724b5658d9.jsonl"
}
{
"key": "agent:main:discord:channel:1482214704784080906",
"sessionId": "21d99a67-0dab-429f-a689-12cf9894ade0",
"updatedAt": 1776017217849,
"sessionFile": "/home/akessel56/.openclaw/agents/main/sessions/21d99a67-0dab-429f-a689-12cf9894ade0.jsonl"
}
{
"key": "agent:main:discord:channel:1480773291491721217:heartbeat",
"sessionId": "ce19383c-e780-4f5d-910f-be5a809e18e2",
"updatedAt": 1775934006195,
"sessionFile": "/home/akessel56/.openclaw/agents/main/sessions/25a07052-afcf-4d48-8689-f8fc5d9da092.jsonl"
}

#

oh and the right discord channel is: 1480773291491721217

summer magnetBOT Apr 19, 2026, 7:37 PM

#

Thanks, this narrows it down a lot.

Two important points:

The timezone that matters is the Pi / gateway host timezone, not your personal timezone.
That jq output is only a current snapshot. It shows the current sessionId, but not when that sessionId was minted.

So the next check is, “was this transcript file created before the 1 AM boundary, and then kept getting appended after it?”

The active-looking session is probably this one:

key: agent:main:discord:channel:1480773291491721217
sessionId: 3714f321-b3dd-4609-8fdd-1ca8b0607dd3

Can you run these on the Pi?

#

date
timedatectl | sed -n '1,6p'
stat /home/akessel56/.openclaw/agents/main/sessions/3714f321-b3dd-4609-8fdd-1ca8b0607dd3.jsonl
sed -n '1p;$p' /home/akessel56/.openclaw/agents/main/sessions/3714f321-b3dd-4609-8fdd-1ca8b0607dd3.jsonl

What I’m looking for:

If that file was created before the reset boundary and still contains/appends turns after the boundary, then daily reset really did fail.
If that file was created after the boundary, then the reset probably did happen, and what feels like continuity is likely from memory recall.

Since your 1 AM run happened on 2026.4.14, if this turns out to be one pre-boundary transcript continuing post-boundary, I’d strongly suspect a real 2026.4.14 bug.

If you paste that output, I can tell you pretty quickly which side of that it is.

#

Perfect, that’s the one I suspected.

So the session we care about is:

key: agent:main:discord:channel:1480773291491721217
sessionId: 3714f321-b3dd-4609-8fdd-1ca8b0607dd3
file: /home/akessel56/.openclaw/agents/main/sessions/3714f321-b3dd-4609-8fdd-1ca8b0607dd3.jsonl

That updatedAt is 2026-04-19 19:11 UTC, so the missing question is still whether that session file was created before or after the 1 AM boundary.

Can you run these exact commands for that file?

date
timedatectl | sed -n '1,6p'
stat /home/akessel56/.openclaw/agents/main/sessions/3714f321-b3dd-4609-8fdd-1ca8b0607dd3.jsonl

#

sed -n '1p;$p' /home/akessel56/.openclaw/agents/main/sessions/3714f321-b3dd-4609-8fdd-1ca8b0607dd3.jsonl

If that same file spans both sides of the reset boundary, then yeah, that’s a real bug.

flat surge Apr 19, 2026, 7:40 PM

#

timedatectl | sed -n '1,6p'
stat /home/akessel56/.openclaw/agents/main/sessions/3714f321-b3dd-4609-8fdd-1ca8b0607dd3.jsonl
sed -n '1p;$p' /home/akessel56/.openclaw/agents/main/sessions/3714f321-b3dd-4609-8fdd-1ca8b0607dd3.jsonl
Sun Apr 19 02:38:27 PM CDT 2026
Local time: Sun 2026-04-19 14:38:27 CDT
Universal time: Sun 2026-04-19 19:38:27 UTC
RTC time: Sun 2026-04-19 19:38:27
Time zone: America/Chicago (CDT, -0500)
System clock synchronized: yes
NTP service: active
File: /home/akessel56/.openclaw/agents/main/sessions/3714f321-b3dd-4609-8fdd-1ca8b0607dd3.jsonl
Size: 88814 Blocks: 184 IO Block: 4096 regular file
Device: 259,2 Inode: 2222139 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/akessel56) Gid: ( 1000/akessel56)
Access: 2026-04-19 14:03:54.643308560 -0500
Modify: 2026-04-19 14:11:09.875984855 -0500
Change: 2026-04-19 14:11:09.875984855 -0500
Birth: 2026-04-19 14:03:54.643308560 -0500
{"type":"session","version":3,"id":"3714f321-b3dd-4609-8fdd-1ca8b0607dd3","timestamp":"2026-04-19T19:03:50.865Z","cwd":"/home/akessel56/.openclaw/workspace"}
{"type":"custom","customType":"openclaw:bootstrap-context:full","data":{"timestamp":1776625869876,"runId":"88a49215-5603-473b-b27f-ceb3f3802e87","sessionId":"3714f321-b3dd-4609-8fdd-1ca8b0607dd3"},"id":"0bd59500","parentId":"c7ddd769","timestamp":"2026-04-19T19:11:09.876Z"}

date
timedatectl | sed -n '1,6p'
stat /home/akessel56/.openclaw/agents/main/sessions/3714f321-b3dd-4609-8fdd-1ca8b0607dd3.jsonl
sed -n '1p;$p' /home/akessel56/.openclaw/agents/main/sessions/3714f321-b3dd-4609-8fdd-1ca8b0607dd3.jsonl
Sun Apr 19 02:38:27 PM CDT 2026
Local time: Sun 2026-04-19 14:38:27 CDT
Universal time: Sun 2026-04-19 19:38:27 UTC
RTC time: Sun 2026-04-19 19:38:27
Time zone: America/Chicago (CDT, -0500)
System clock synchronized: yes
NTP service: active
File: /home/akessel56/.openclaw/agents/main/sessions/3714f321-b3dd-4609-8fdd-1ca8b0607dd3.jsonl
Size: 88814 Blocks: 184 IO Block: 4096 regular file
Device: 259,2 Inode: 2222139 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/akessel56) Gid: ( 1000/akessel56)
Access: 2026-04-19 14:03:54.643308560 -0500
Modify: 2026-04-19 14:11:09.875984855 -0500
Change: 2026-04-19 14:11:09.875984855 -0500
Birth: 2026-04-19 14:03:54.643308560 -0500
{"type":"session","version":3,"id":"3714f321-b3dd-4609-8fdd-1ca8b0607dd3","timestamp":"2026-04-19T19:03:50.865Z","cwd":"/home/akessel56/.openclaw/workspace"}
{"type":"custom","customType":"openclaw:bootstrap-context:full","data":{"timestamp":1776625869876,"runId":"88a49215-5603-473b-b27f-ceb3f3802e87","sessionId":"3714f321-b3dd-4609-8fdd-1ca8b0607dd3"},"id":"0bd59500","parentId":"c7ddd769","timestamp":"2026-04-19T19:11:09.876Z"}
(ssc-3.12.5) akessel56@rpi5:~ $ sed -n '1p;$p' /home/akessel56/.openclaw/agents/main/sessions/3714f321-b3dd-4609-8fdd-1ca8b0607dd3.jsonl
{"type":"session","version":3,"id":"3714f321-b3dd-4609-8fdd-1ca8b0607dd3","timestamp":"2026-04-19T19:03:50.865Z","cwd":"/home/akessel56/.openclaw/workspace"}
{"type":"custom","customType":"openclaw:bootstrap-context:full","data":{"timestamp":1776625869876,"runId":"88a49215-5603-473b-b27f-ceb3f3802e87","sessionId":"3714f321-b3dd-4609-8fdd-1ca8b0607dd3"},"id":"0bd59500","parentId":"c7ddd769","timestamp":"2026-04-19T19:11:09.876Z"}

summer magnetBOT Apr 19, 2026, 7:41 PM

#

Nice, we caught it. This actually shows the reset is working for that channel.

What your output proves:

Gateway timezone is America/Chicago (CDT)
Your reset boundary is therefore 1:00 AM CDT
The current session file for that channel was born at 2026-04-19 14:03:54 CDT
The first transcript entry is also from 2026-04-19 19:03:50Z, which is 14:03 CDT

So this sessionId was minted today at 2:03 PM local, well after the 1 AM boundary.

That means OpenClaw did exactly what the docs describe:

it did not create a new session at 1:00 sharp
it created a new session on the first message after the reset boundary

So the real behavior here is:

#

daily reset is lazy
your channel had no traffic until 14:03
the rollover happened then

If it still felt like the same conversation, that is most likely because you have memory-core enabled, not because the session failed to reset.

So I do not think this is a reset bug for channel 1480773291491721217.

Docs:

If you want, I can help with the follow-up question, which is probably: “how do I make it feel truly fresh each day, even with memory enabled?”

flat surge Apr 19, 2026, 7:42 PM

#

I hate to disappoint you but that 2:03pm local was my manual /new

summer magnetBOT Apr 19, 2026, 7:43 PM

#

Not disappointing at all, that actually explains why this sample is ambiguous 🙂

That means the 3714... transcript only proves your manual /new worked at 2:03 PM. It does not tell us whether the automatic daily reset had already happened earlier.

The next useful thing is the transcript that /new archived. OpenClaw should have renamed the previous file to *.reset.<timestamp> in the same folder.

Can you run:

ls -lt /home/akessel56/.openclaw/agents/main/sessions/*.reset.* | head -20

Then grab the file that was archived around your 2:03 PM /new, and run:

stat /home/akessel56/.openclaw/agents/main/sessions/<that-file>

#

sed -n '1p;$p' /home/akessel56/.openclaw/agents/main/sessions/<that-file>

What that will tell us:

if that archived transcript started before 1:00 AM CDT and was still the active one until 2:03 PM, then daily reset did not happen
if that archived transcript started after 1:00 AM CDT, then daily reset did happen earlier, and /new just reset it again

So we’re close, we just need the pre-/new archived file.

flat surge Apr 19, 2026, 7:48 PM

#

stat /home/akessel56/.openclaw/agents/main/sessions/39d002db-76b9-47aa-b9b9-8be5de7eaa06.jsonl.reset.2026-04-19T19-03-37.979Z
File: /home/akessel56/.openclaw/agents/main/sessions/39d002db-76b9-47aa-b9b9-8be5de7eaa06.jsonl.reset.2026-04-19T19-03-37.979Z
Size: 893287 Blocks: 1760 IO Block: 4096 regular file
Device: 259,2 Inode: 2194074 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/akessel56) Gid: ( 1000/akessel56)
Access: 2026-04-15 09:43:27.307785743 -0500
Modify: 2026-04-19 14:03:30.923492050 -0500
Change: 2026-04-19 14:03:37.975437465 -0500
Birth: 2026-04-15 09:43:27.307785743 -0500

sed -n '1p;$p' /home/akessel56/.openclaw/agents/main/sessions/39d002db-76b9-47aa-b9b9-8be5de7eaa06.jsonl.reset.2026-04-19T19-03-37.979Z
{"type":"session","version":3,"id":"39d002db-76b9-47aa-b9b9-8be5de7eaa06","timestamp":"2026-04-15T14:43:24.736Z","cwd":"/home/akessel56/.openclaw/workspace"}
{"type":"custom","customType":"openclaw:bootstrap-context:full","data":{"timestamp":1776625410927,"runId":"746144b9-61bc-440d-8bf8-adc8efe98189","sessionId":"39d002db-76b9-47aa-b9b9-8be5de7eaa06"},"id":"5c8e0e07","parentId":"8da604f3","timestamp":"2026-04-19T19:03:30.927Z"}

summer magnetBOT Apr 19, 2026, 7:50 PM

#

Yep, that’s the smoking gun.

That archived transcript:

was born on Apr 15, 09:43 CDT
stayed active until your manual /new on Apr 19, 14:03 CDT

So that same session lived across multiple daily reset boundaries. Given what you said about checking in after the overnight jobs, I’m convinced this was a real issue on 2026.4.14.

The only nuance is that the manual /new itself is what finally rotated it, so today’s sample is “old session until /new”, not “auto-reset worked earlier”.

My recommendation now:

Retest once on 2026.4.15
- do not manual /new
- send one normal message after the next 1 AM CDT boundary
- check whether the sessionId changed

#

File a GitHub issue either way
- if it still happens on 2026.4.15, it’s an active bug
- if it no longer happens, it still looks like a real 2026.4.14 regression

Issue link:
https://github.com/openclaw/openclaw/issues

Useful summary to paste into the issue:

config:

session: {
  dmScope: "per-channel-peer",
  reset: { mode: "daily", atHour: 1 }
}

gateway timezone: America/Chicago

#reset is not occuring as set in openclaw.json