Neura Market Logo

Main Session: Your Single Continuous Conversation with OpenClaw

This page explains the main session, the default rolling conversation that collects all direct messages across channels. It is essential for users who want to understand how OpenClaw maintains context across devices.

Read this when

  • You want to understand where your agent "lives"
  • You expect the same context whether you write on Telegram, WhatsApp, or the web
  • You want your agent to know what happens in groups and side threads

OpenClaw functions primarily as a personal agent. By default, any direct message you send to it, whether from Telegram, WhatsApp, iMessage, Slack DMs, the web app, or another platform, is funneled into a single continuous conversation called the main session. You can ask a question on your phone and then follow up from your laptop, and the agent retains the same context across both devices. This is the single location where the agent's reasoning takes place.

Internally, the main session is a standard session with the agent:<agentId>:main parameter set (for instance, agent:main:main). Its uniqueness comes from two factors: the default DM scope directs all private messages into this single session, and the broader system treats it as the agent's central hub. Heartbeats activate it, background tasks report their findings back to it, and activity occurring elsewhere is channeled upward to it.

Home

Within the web application, the main session is represented by the Home page, which is the first item in the sidebar. The identity row at the top shows your agent (click it to access the agent menu), and Home is where you communicate with it. Conversations that branch off from the main session appear under Threads, group chats are listed under Groups, and coding or CLI sessions are found under Coding.

What flows into the main session

The main session is more than a simple chat log; it serves as the convergence point for all agent activity:

  • Group activity. Group and room sessions remain isolated (explained below), but with the default DM scope, the main session automatically monitors them. Activity is queued as compact notifications, coalesced per conversation to avoid one wake-up per message. The agent sees these notifications the next time it runs, either when you send a new message or during a scheduled heartbeat. The agent can also read the sessions it monitors, so asking "what did I miss in the family group?" is possible.
  • Background work. Sub-agents and spawned sessions send their results back to the session that initiated them. Therefore, work the agent started from Home reports back to Home.
  • Heartbeats. Scheduled heartbeats are directed at the main session, which converts queued notices into awareness even when you haven't sent any messages.

Memory across resets and conversations

The rolling conversation is limited by the model's context window, so continuity is maintained through surrounding layers:

  • MEMORY.md, the agent's curated long-term memory, is loaded into every new session. Daily notes (memory/YYYY-MM-DD.md) can be searched on demand, and recent ones are re-primed after a /new or /reset. Before compaction occurs, the agent writes durable facts into the daily notes so that long conversations do not silently lose information.
  • Memory recall across conversations allows the agent to retrieve content from its other private sessions. On personal setups, where global session.dmScope resolves to main with no per-binding DM overrides, this feature is enabled by default. Any configured DM isolation disables it unless you explicitly opt in. Refer to Memory configuration.

A rolling session with durable history

The main session progresses through resets and compaction rather than forcing the model to carry its entire history at once:

  • No automatic reset is configured by default; compaction keeps the active context bounded while preserving the rolling session. Daily and idle resets are opt-in (see Session management). On /new and /reset, the tail of the ending conversation is saved to daily memory notes, and the next session re-primes recent notes. A reset assigns a new live session ID but keeps the previous SQLite transcript searchable under the same main-session key.
  • When the conversation approaches the context window limit, compaction summarizes the content and continues in place, with the transcript history remaining in the session store.
  • Session lists display only the current live conversation, not every historical session ID behind it.
  • When the per-agent store's physical database, WAL, and session artifacts exceed the disk budget (default 10 GB), OpenClaw extracts the oldest unreferenced history to a verified compressed archive before removing its database rows. Live, routed, and in-flight sessions are never removed as part of budget enforcement.

When you want isolation instead

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

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

With an isolating scope, each sender receives their own session, group watching from the main session is disabled, and cross-conversation memory recall defaults to off. openclaw security audit recommends isolation when it detects multiple DM senders. The full scope matrix, identity linking, and per-route overrides are detailed in Session management and Channel routing.