OpenClaw organizes conversations into sessions. Each message is routed to a session based on where it came from — DMs, group chats, cron jobs, etc.Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
How messages are routed
| Source | Behavior |
|---|---|
| Direct messages | Shared session by default |
| Group chats | Isolated per group |
| Rooms/channels | Isolated per room |
| Cron jobs | Fresh session per run |
| Webhooks | Isolated per hook |
DM isolation
By default, all DMs share one session for continuity. This is fine for single-user setups. The fix:main(default) — all DMs share one session.per-peer— isolate by sender (across channels).per-channel-peer— isolate by channel + sender (recommended).per-account-channel-peer— isolate by account + channel + sender.
Dock linked channels
Dock commands let a user move the current direct-chat session’s reply route to another linked channel without starting a new session. See Channel docking for examples, config, and troubleshooting. Verify your setup withopenclaw security audit.
Session lifecycle
Sessions are reused until they expire:- Daily reset (default) — new session at 4:00 AM local time on the gateway
host. Daily freshness is based on when the current
sessionIdstarted, not on later metadata writes. - Idle reset (optional) — new session after a period of inactivity. Set
session.reset.idleMinutes. Idle freshness is based on the last real user/channel interaction, so heartbeat, cron, and exec system events do not keep the session alive. - Manual reset — type
/newor/resetin chat./new <model>also switches the model.
/reset or configure session.reset explicitly when those
sessions should expire on a timer.
Where state lives
All session state is owned by the gateway. UI clients query the gateway for session data.- Store:
~/.openclaw/agents/<agentId>/sessions/sessions.json - Transcripts:
~/.openclaw/agents/<agentId>/sessions/<sessionId>.jsonl
sessions.json keeps separate lifecycle timestamps:
sessionStartedAt: when the currentsessionIdbegan; daily reset uses this.lastInteractionAt: last user/channel interaction that extends idle lifetime.updatedAt: last store-row mutation; useful for listing and pruning, but not authoritative for daily/idle reset freshness.
sessionStartedAt are resolved from the transcript JSONL
session header when available. If an older row also lacks lastInteractionAt,
idle freshness falls back to that session start time, not to later bookkeeping
writes.
Session maintenance
OpenClaw automatically bounds session storage over time. By default, it runs inwarn mode (reports what would be cleaned). Set session.maintenance.mode
to "enforce" for automatic cleanup:
maxEntries limits, Gateway runtime writes use a small high-water buffer and clean back down to the configured cap in batches. This avoids running full store cleanup on every isolated cron session. openclaw sessions cleanup --enforce applies the cap immediately.
Preview with openclaw sessions cleanup --dry-run.
Inspecting sessions
openclaw status— session store path and recent activity.openclaw sessions --json— all sessions (filter with--active <minutes>)./statusin chat — context usage, model, and toggles./context list— what is in the system prompt.
Further reading
- Session Pruning — trimming tool results
- Compaction — summarizing long conversations
- Session Tools — agent tools for cross-session work
- Session Management Deep Dive — store schema, transcripts, send policy, origin metadata, and advanced config
- Multi-Agent — routing and session isolation across agents
- Background Tasks — how detached work creates task records with session references
- Channel Routing — how inbound messages are routed to sessions