Main Session: Unified Agent Conversations

OpenClaw operates as a personal agent first and foremost. Any direct message you send it, whether from Telegram, WhatsApp, iMessage, Slack DMs, the web app, or elsewhere, is routed by default into a single continuous conversation: the main session. You can start a query on your phone and pick it up from your laptop, and the agent retains identical context in both locations. This is the single brain, and it does its thinking here.

Technically, the main session is just a regular session using the default key agent:<agentId>:main (for instance agent:main:main; the final segment can be altered via session.mainKey). Its uniqueness comes from two factors: the default DM scope funnels every direct message into this one session, and the broader system designates it as the agent's root. Heartbeats activate it, background tasks send their results back to it, and activity occurring elsewhere gets aggregated upward to it.

Home

Within the web app, the main session corresponds to the Home page, which is the first item in the sidebar. The identity row at the top represents your agent (click it to access the agent menu), and Home is where you interact with it. Sessions that branch off from the main conversation are listed under Threads, group chats appear under Groups, and coding or CLI sessions show up under Coding.

What flows into the main session

The main session serves as more than a simple chat history; it is the central point where your agent's activities converge:

Group activity. With session.groupScope: "per-group" as the default, group and room sessions remain separate, yet the main session automatically monitors them. Activity is queued as brief notifications, aggregated per conversation rather than triggering a wake-up for each message, and the agent processes them at its next run, whether that is triggered by your next message or a scheduled heartbeat. Under the default tree visibility setting, the main session can employ session tools across all sessions belonging to the same agent, and its system prompt lists watched groups so it knows where recent activity originated.
Background work. Sub-agents and spawned sessions report their outcomes back to the session that launched them, meaning work initiated from Home gets reported back to Home.
Heartbeats. Scheduled heartbeats are directed at the main session, which is how queued notifications become awareness even when you have not sent any messages.

Memory across resets and conversations

The rolling conversation is constrained by the model's context window, so continuity is provided by the surrounding layers:

MEMORY.md, the agent's curated long-term memory, gets loaded into every new session. Daily notes (memory/YYYY-MM-DD.md) can be searched on demand, and recent ones are re-primed following a /new or /reset. Before compaction happens, the agent writes durable facts into the daily notes so that lengthy conversations do not lose them silently.
Memory recall across conversations enables the agent to pull content from its other private sessions. On personal setups, where global session.dmScope resolves to main without any per-binding DM overrides, this feature is turned on by default; any configured DM isolation disables it unless you explicitly opt in. Refer to Memory configuration for details.

A rolling session with durable history

The main session moves forward through resets and compaction instead of requiring the model to hold its full history at once:

No automatic reset occurs by default; compaction keeps the active context within bounds while preserving the rolling session. Daily and idle resets are optional (see Session management). On /new and /reset, the tail end of the concluding conversation is saved to daily memory notes, and the subsequent session re-primes recent notes. A reset assigns a new live session id, but the previous SQLite transcript remains searchable under the same main-session key.
As the conversation nears the context window limit, compaction summarizes and continues in place, with the transcript history retained in the session store.
Session lists display the current live conversation only, not every historical session id behind it.
When the per-agent store's physical database, WAL, and session artifacts surpass the disk budget (10 GB by default), OpenClaw pulls the oldest unreferenced history into a verified compressed archive before deleting its database rows. Live, routed, and in-flight sessions are never subject to budget removal.

When you want isolation instead

The shared main session is the ideal default for an agent that only you communicate with. If multiple people can message your agent, you should isolate DMs:

{
  session: {
    dmScope: "per-channel-peer",
  },
}

With an isolating scope, each sender receives their own session, and cross-conversation memory recall defaults to off. Group watching is controlled separately by session.groupScope: per-group preserves ambient main-session visibility, while main brings the room directly into the main conversation. openclaw security audit recommends DM isolation when it detects multiple senders. The complete scope matrix, identity linking, and per-route overrides are detailed in Session management and Channel routing.

Groups and rooms use separate sessions by default. To include selected trusted team rooms in the rolling main conversation, apply bindings[].session.groupScope: "main" to their route bindings. This alters the session key and shared context, though mention gating and reply routing continue to use the originating room. See Session management for more.

Session management, routing, scopes, resets
Channel routing, how agents and sessions are selected
Memory, durable memory layers
Multi-agent, running several isolated agents