---
read_when:
    - Ви хочете зрозуміти маршрутизацію та ізоляцію сеансів
    - Ви хочете налаштувати область DM для багатокористувацьких конфігурацій
    - Ви налагоджуєте щоденні скидання сеансів або скидання через неактивність
summary: Як OpenClaw керує сеансами розмови
title: Керування сеансами
x-i18n:
    generated_at: "2026-04-27T21:41:20Z"
    model: gpt-5.4
    provider: openai
    source_hash: 2bbb8f8fddf8ac942bc24b8b94a6464ec31d0aee035bf367726d2112269095f4
    source_path: concepts/session.md
    workflow: 15
---

OpenClaw організовує розмови в **сеанси**. Кожне повідомлення спрямовується до
сеансу на основі того, звідки воно надійшло — DM, групові чати, завдання Cron тощо.

## Як маршрутизуються повідомлення

| Джерело         | Поведінка                   |
| --------------- | --------------------------- |
| Прямі повідомлення | Спільний сеанс за замовчуванням |
| Групові чати    | Ізольовано для кожної групи |
| Кімнати/канали  | Ізольовано для кожної кімнати |
| Завдання Cron   | Новий сеанс для кожного запуску |
| Webhook         | Ізольовано для кожного hook |

## Ізоляція DM

За замовчуванням усі DM використовують один спільний сеанс для безперервності. Це підходить для
одноосібних конфігурацій.

<Warning>
Якщо вашому агенту можуть писати кілька людей, увімкніть ізоляцію DM. Без неї всі
користувачі спільно використовують той самий контекст розмови — приватні повідомлення Alice будуть
видимі Bob.
</Warning>

**Рішення:**

```json5
{
  session: {
    dmScope: "per-channel-peer", // ізоляція за каналом + відправником
  },
}
```

Інші варіанти:

- `main` (за замовчуванням) — усі DM використовують один спільний сеанс.
- `per-peer` — ізоляція за відправником (між каналами).
- `per-channel-peer` — ізоляція за каналом + відправником (рекомендовано).
- `per-account-channel-peer` — ізоляція за обліковим записом + каналом + відправником.

<Tip>
Якщо та сама людина звертається до вас через кілька каналів, використовуйте
`session.identityLinks`, щоб пов’язати її ідентичності й дати їм спільний сеанс.
</Tip>

### Dock для пов’язаних каналів

Команди Dock дають змогу користувачу перенести маршрут відповіді поточного сеансу прямого чату до
іншого пов’язаного каналу без запуску нового сеансу. Див. [Прив’язка каналів](/uk/concepts/channel-docking), щоб ознайомитися з прикладами, конфігурацією та
усуненням несправностей.

Перевірте свою конфігурацію за допомогою `openclaw security audit`.

## Життєвий цикл сеансу

Сеанси використовуються повторно, доки не завершиться їхній строк дії:

- **Щоденне скидання** (за замовчуванням) — новий сеанс о 4:00 ранку за місцевим часом на хості Gateway.
  Щоденна свіжість визначається тим, коли почався поточний `sessionId`, а не
  пізнішими записами метаданих.
- **Скидання через неактивність** (необов’язково) — новий сеанс після періоду бездіяльності. Встановіть
  `session.reset.idleMinutes`. Свіжість за неактивністю визначається за останньою реальною
  взаємодією користувача/каналу, тому Heartbeat, Cron і системні події exec не
  підтримують сеанс активним.
- **Ручне скидання** — введіть у чаті `/new` або `/reset`. `/new <model>` також
  перемикає модель.

Коли налаштовано і щоденне скидання, і скидання через неактивність, спрацьовує те, чий строк спливе раніше.
Heartbeat, Cron, exec та інші ходи системних подій можуть записувати метадані сеансу,
але ці записи не подовжують свіжість для щоденного скидання чи скидання через неактивність. Коли скидання
перемикає сеанс, поставлені в чергу сповіщення системних подій для старого сеансу
відкидаються, щоб застарілі фонові оновлення не додавалися на початок першого запиту в
новому сеансі.

Сеанси з активним CLI-сеансом, яким володіє провайдер, не перериваються неявним
щоденним значенням за замовчуванням. Використовуйте `/reset` або явно налаштуйте `session.reset`, якщо такі
сеанси мають завершуватися за таймером.

## Де зберігається стан

Увесь стан сеансу належить **Gateway**. Клієнти інтерфейсу користувача звертаються до Gateway по
дані сеансу.

- **Сховище:** `~/.openclaw/agents/<agentId>/sessions/sessions.json`
- **Транскрипти:** `~/.openclaw/agents/<agentId>/sessions/<sessionId>.jsonl`

`sessions.json` зберігає окремі часові позначки життєвого циклу:

- `sessionStartedAt`: коли почався поточний `sessionId`; саме це використовує щоденне скидання.
- `lastInteractionAt`: остання взаємодія користувача/каналу, що подовжує час життя бездіяльності.
- `updatedAt`: остання мутація рядка сховища; корисно для переліку та очищення, але не
  є авторитетним джерелом для свіжості щоденного скидання/скидання через неактивність.

Старіші рядки без `sessionStartedAt` за можливості відновлюються із заголовка сеансу в JSONL-транскрипті.
Якщо в старішому рядку також немає `lastInteractionAt`,
свіжість за неактивністю повертається до часу початку цього сеансу, а не до пізніших службових записів.

## Обслуговування сеансів

OpenClaw автоматично з часом обмежує обсяг сховища сеансів. За замовчуванням він працює
в режимі `warn` (повідомляє, що було б очищено). Встановіть `session.maintenance.mode`
у значення `"enforce"` для автоматичного очищення:

```json5
{
  session: {
    maintenance: {
      mode: "enforce",
      pruneAfter: "30d",
      maxEntries: 500,
    },
  },
}
```

Для меж `maxEntries` виробничого масштабу записи середовища виконання Gateway використовують невеликий буфер верхнього порога та пакетно очищують сховище назад до налаштованого ліміту. Це дає змогу уникнути повного очищення сховища під час кожного ізольованого сеансу Cron. `openclaw sessions cleanup --enforce` застосовує обмеження негайно.

Попередній перегляд: `openclaw sessions cleanup --dry-run`.

## Перегляд сеансів

- `openclaw status` — шлях до сховища сеансів і нещодавня активність.
- `openclaw sessions --json` — усі сеанси (фільтруйте за допомогою `--active <minutes>`).
- `/status` у чаті — використання контексту, модель і перемикачі.
- `/context list` — що входить до системного запиту.

## Додаткові матеріали

- [Обрізання сеансів](/uk/concepts/session-pruning) — скорочення результатів інструментів
- [Compaction](/uk/concepts/compaction) — підсумовування довгих розмов
- [Інструменти сеансів](/uk/concepts/session-tool) — інструменти агента для роботи між сеансами
- [Поглиблений розбір керування сеансами](/uk/reference/session-management-compaction) —
  схема сховища, транскрипти, політика надсилання, метадані джерела та розширена конфігурація
- [Multi-Agent](/uk/concepts/multi-agent) — маршрутизація та ізоляція сеансів між агентами
- [Фонові завдання](/uk/automation/tasks) — як відокремлена робота створює записи завдань із посиланнями на сеанси
- [Маршрутизація каналів](/uk/channels/channel-routing) — як вхідні повідомлення спрямовуються до сеансів

## Пов’язане

- [Обрізання сеансів](/uk/concepts/session-pruning)
- [Інструменти сеансів](/uk/concepts/session-tool)
- [Черга команд](/uk/concepts/queue)
