---
read_when:
    - Ви хочете зрозуміти маршрутизацію та ізоляцію сесій
    - Ви хочете налаштувати область дії DM для багатокористувацьких конфігурацій
    - Ви діагностуєте щоденні скидання сеансів або скидання через бездіяльність
summary: Як OpenClaw керує сеансами розмов
title: Керування сеансами
x-i18n:
    generated_at: "2026-05-07T13:16:03Z"
    model: gpt-5.5
    provider: openai
    source_hash: 4e5ec741a33262ce5c42caf021ad81892e89b3315db31ac7b141d5a13e8b22a2
    source_path: concepts/session.md
    workflow: 16
---

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

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

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

## Ізоляція приватних повідомлень

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

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

**Виправлення:**

```json5
{
  session: {
    dmScope: "per-channel-peer", // isolate by channel + sender
  },
}
```

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

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

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

### Пристикування пов'язаних каналів

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

Перевірте своє налаштування за допомогою `openclaw security audit`.

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

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

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

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

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

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

Усім станом сеансів володіє **Gateway**. UI-клієнти запитують дані сеансів у 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` записи runtime Gateway використовують невеликий буфер верхньої межі й пакетами очищають сховище назад до налаштованого ліміту. Читання сховища сеансів не обрізають і не обмежують записи під час запуску Gateway. Це дозволяє уникнути повного очищення сховища під час кожного запуску або ізольованого сеансу Cron. `openclaw sessions cleanup --enforce` застосовує ліміт негайно.

Обслуговування зберігає довговічні зовнішні вказівники розмов, зокрема групові
сеанси та чат-сеанси в межах thread, і водночас дає змогу синтетичним записам Cron,
hook, Heartbeat, ACP і під-агентів застарівати.

Якщо раніше ви використовували ізоляцію прямих повідомлень, а потім повернули
`session.dmScope` до `main`, перегляньте застарілі peer-keyed рядки приватних повідомлень за допомогою
`openclaw sessions cleanup --dry-run --fix-dm-scope`. Застосування того самого прапорця
виводить ці старі рядки direct-DM з ужитку й зберігає їхні транскрипти як видалені
архіви.

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

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

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

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

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

## Пов'язане

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