OpenClaw Session Reset: Daily, Idle, dmScope and Which Default You Have

Search for how OpenClaw resets a session and you will get three answers. All three are written confidently. They cannot all be right on your machine.

One FAQ says sessions expire after session.idleMinutes, default 60. A popular third-party guide says sessions reset daily at 4:00 AM gateway-host time. The current official page says the default is mode: "none", meaning no automatic reset at all, with compaction managing the context. Each was presumably accurate for some release. Every guide I read explains the keys, and the official page explains them best, at roughly 3,200 words. None of them tell you to find out which default your install is actually running before you change anything, and that is the step this page is built around.

What a Reset Does

A session is the conversation history attached to a chat key. A reset gives that chat key a new sessionId. Workspace files and the system prompt load again as normal; the turns from before are gone from the model's view. The old session still exists in the session list, which is why people send /new, open the dashboard, see yesterday's thread sitting there and decide the command did nothing. It did. It just does not delete anything.

Manual reset is /new or /reset, sent as its own message. /new <model> starts fresh and sets the model in one step, which is also the cleanest way out of the pinned-model trap described in the model failover guide.

Find Out Which Default You Have

Do this first. Leave the config alone for a day, then run:

openclaw sessions --json --active 1440

That lists sessions with activity in the last 24 hours. If your direct chat shows one session that started days ago, you are on none. If it shows a new session that began shortly after 4 a.m., you are on daily. If you see several short sessions split wherever you stopped talking for an hour, you are on an idle default. Inside a chat, /status shows context usage for the current session, and a number that only ever climbs (until compaction knocks it down) is the none signature.

Then stop depending on whichever answer you got. Write the policy into config. A behavior that changed once between releases can change again, and the upgrade guide is much shorter when your config says what you want instead of inheriting it.

The Three Modes

{
  session: {
    reset: { mode: "daily", atHour: 4 },
    resetByType: {
      direct: { mode: "daily", atHour: 4 },
      group:  { mode: "idle", idleMinutes: 240 }
    },
    resetByChannel: {
      discord: { mode: "idle", idleMinutes: 120 }
    }
  }
}

none keeps the same session forever. daily starts a new one at atHour (0 to 23, default 4) in the gateway host's local time, which matters if your gateway is a VPS in Frankfurt and you live in Denver. idle starts a new one after idleMinutes without a real message. Configure daily and idle together and whichever expires first wins.

resetByType overrides by session type: direct (older configs say dm, still accepted as an alias), group and thread. resetByChannel overrides by channel and is the more specific of the two. It earns its place on a busy Discord server, where conversations die and restart on their own rhythm and a two-hour idle window fits better than any clock.

Heartbeats Do Not Keep a Session Alive

Idle freshness counts only real user and channel interaction. Heartbeat turns, cron turns, exec completions and other system events do not reset the idle clock. This surprises people in both directions.

The good direction: a heartbeat every 30 minutes cannot pin an idle session open forever. The surprising direction: if your agent's only traffic in a day is a 7 a.m. briefing from a cron job, that briefing does not count as activity, and an idle policy will still roll the session over. Pending system-event notices addressed to the old session are dropped at rollover. If a cron job reports into your DM and you reply to it hours later, check that the reply landed in the session you think it did. The heartbeat guide and the cron guide cover where each of those turns runs.

dmScope Is the Setting That Leaks

Reset policy is a quality question. session.dmScope is a privacy question, and the default is the permissive one.

• main (default): every DM, from anyone, on any channel, shares your main session.
• per-peer: one session per sender, shared across channels.
• per-channel-peer: one session per channel plus sender. The docs recommend this one.
• per-account-channel-peer: adds the account, for setups running more than one bot account on the same channel.

The official page puts the risk plainly: without isolation, "Alice's private messages would be visible to Bob." If you are the only person who can DM your agent, main is fine and gives you one continuous thread across Telegram and Slack. The moment you approve a second person's pairing request, switch to per-channel-peer.

You will lose cross-channel continuity for yourself, and getting it back is what session.identityLinks is for. Map your Telegram identity and your Slack identity to one peer, and your own DMs share a session again while everyone else stays separate. Existing sessions keyed under the old scope can be migrated with openclaw sessions cleanup --fix-dm-scope.

The security best practices guide is about tools and permissions. This setting belongs on the same checklist.

The Config Worth Writing Down

{
  session: {
    dmScope: "per-channel-peer",
    identityLinks: { /* my Telegram + Slack ids -> one peer */ },
    reset: { mode: "daily", atHour: 4 },
    resetByType: {
      group: { mode: "idle", idleMinutes: 240 }
    }
  }
}

Daily for direct chats, because I want each morning to start clean and I do not want to remember to type /new. Anything worth keeping past 4 a.m. belongs in memory files, and the hook patterns post has a hook that saves context on /new so the handoff is automatic. Idle at four hours for groups, because group conversations come in bursts and a stale joke from Tuesday has no business steering Thursday.

I would not run none on a 24/7 agent. One session that lives for weeks leans entirely on compaction, and the context budget guide explains how much of the window is spoken for before your conversation gets any. Summaries of summaries drift. A daily boundary costs one cold start per day.

Old Sessions Still Pile Up

Resets create sessions; maintenance removes them. Preview before you let it act:

openclaw sessions cleanup --dry-run
openclaw sessions cleanup --enforce

The policy sits under session.maintenance (mode, pruneAfter, maxEntries). Sessions created by cron, hooks and heartbeats are treated as disposable. Pinned, active and model-locked sessions are protected. Run the dry run once after you switch to daily resets, because a month of daily resets is thirty sessions per chat key before groups are even counted.

Common Failure Modes

Final Verdict

Check what your install does with sessions --json --active 1440, then write dmScope and reset into config so the answer no longer depends on which release or which blog post you read last. Per-channel-peer the day a second person can reach your agent. Daily at 4 for yourself.