---
read_when:
    - Зміна поведінки групового чату або фільтрування за згадками
    - Обмеження mentionPatterns певними груповими розмовами
sidebarTitle: Groups
summary: Поведінка групових чатів на різних платформах (Discord/iMessage/Matrix/Microsoft Teams/QQBot/Signal/Slack/Telegram/WhatsApp/Zalo)
title: Групи
x-i18n:
    generated_at: "2026-07-16T17:39:39Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 2a708915ca9383d59b1bd2204b59a4df1de4caf677e68c9b7279f773275d67ee
    source_path: channels/groups.md
    workflow: 16
---

OpenClaw застосовує однакові правила груп у всіх каналах із підтримкою груп, зокрема Discord, iMessage, Matrix, Microsoft Teams, QQBot, Signal, Slack, Telegram, WhatsApp і Zalo.

Для постійно активних кімнат, які мають надавати фоновий контекст без зайвих повідомлень, якщо агент явно не надсилає видиме повідомлення, див. [Фонові події кімнати](/uk/channels/ambient-room-events).

## Вступ для початківців (2 хвилини)

OpenClaw «живе» у ваших власних облікових записах служб обміну повідомленнями. Окремого користувача-бота WhatsApp немає: якщо **ви** перебуваєте в групі, OpenClaw може бачити цю групу й відповідати в ній.

Типова поведінка:

- Групи обмежені (`groupPolicy: "allowlist"`); відправників у групах заблоковано, доки їх не додано до списку дозволених.
- Для відповідей потрібна згадка, якщо для групи не вимкнено обмеження за згадкою.
- Остаточний текст відповіді автоматично публікується в кімнаті (`visibleReplies: "automatic"`).

Інакше кажучи: відправники зі списку дозволених можуть активувати OpenClaw, згадавши його.

<Note>
**Коротко**

- **Доступ до особистих повідомлень** контролюється параметром `*.allowFrom`.
- **Доступ до груп** контролюється параметром `*.groupPolicy` і списками дозволених (`*.groups`, `*.groupAllowFrom`).
- **Активація відповіді** контролюється обмеженням за згадкою (`requireMention`, `/activation`).

</Note>

Коротка схема (що відбувається з повідомленням у групі):

```text
groupPolicy? disabled -> відкинути
groupPolicy? allowlist -> групу дозволено? ні -> відкинути
requireMention? так -> згадано? ні -> зберегти лише для контексту
згадка/відповідь/команда/особисте повідомлення -> запит користувача
повідомлення в постійно активній групі -> запит користувача або подія кімнати, якщо це налаштовано
```

## Видимі відповіді

Для звичайних запитів у групах і каналах OpenClaw типово використовує `messages.groupChat.visibleReplies: "automatic"`: остаточний текст асистента публікується в кімнаті як видима відповідь.

Використовуйте `messages.groupChat.visibleReplies: "message_tool"`, якщо в спільній кімнаті агент має сам вирішувати, коли говорити, викликаючи `message(action=send)`. Це найкраще працює з моделями, які надійно використовують інструменти (наприклад, GPT-5.6 Sol). Якщо модель не викликає інструмент і повертає змістовний остаточний текст, OpenClaw зберігає цей текст приватним замість публікації в кімнаті.

Використовуйте `"automatic"` для моделей або середовищ виконання, які ненадійно дотримуються доставлення лише через інструменти: звичайний остаточний текст публікується безпосередньо в кімнаті, а агент усе ще може викликати `message(action=send)` для файлів, зображень або інших вкладень, які неможливо передати разом з остаточним текстом.

Якщо інструмент повідомлень недоступний згідно з активною політикою інструментів, OpenClaw повертається до автоматичних видимих відповідей замість того, щоб без пояснень приховувати відповідь. `openclaw doctor` попереджає про цю невідповідність.

Для прямих чатів і будь-яких інших вихідних подій `messages.visibleReplies: "message_tool"` застосовує ту саму глобальну поведінку лише через інструменти; `messages.groupChat.visibleReplies` залишається конкретнішим перевизначенням для групових і канальних кімнат. Для прямих звернень у внутрішньому WebChat типово використовується автоматичне доставлення остаточної відповіді, щоб Pi й Codex мали однаковий контракт видимої відповіді.

Режим лише через інструменти замінює старий підхід, за якого модель змушували відповідати `NO_REPLY` у більшості пасивних звернень. У режимі лише через інструменти запит не визначає контракт `NO_REPLY`; відсутність видимої дії просто означає, що інструмент повідомлень не викликано.

Прив’язки розмов, якими керують плагіни, є винятком. Щойно плагін прив’язує гілку й приймає вхідне звернення, повернена плагіном відповідь стає видимою відповіддю прив’язки; для неї не потрібен `message(action=send)`. Ця відповідь є результатом роботи середовища виконання плагіна, а не приватним остаточним текстом моделі.

Індикатори набору тексту й надалі надсилаються для прямих групових запитів. Фонові події постійно активних кімнат, коли їх увімкнено, залишаються суворо беззвучними, якщо агент не викликає інструмент повідомлень.

Типово сеанси приховують докладні підсумки щодо інструментів і перебігу виконання. Використовуйте `/verbose on` (або `/verbose full`), щоб показувати їх у поточному сеансі під час налагодження, і `/verbose off`, щоб повернутися до поведінки лише з остаточною відповіддю. Стан докладного виведення визначається окремо для кожного сеансу й однаково працює в прямих чатах, групах, каналах і темах форуму.

Щоб надсилати незгадані повідомлення з постійно активних груп як фоновий контекст кімнати замість запитів користувача, використовуйте [Фонові події кімнати](/uk/channels/ambient-room-events):

```json5
{
  messages: {
    groupChat: {
      unmentionedInbound: "room_event",
    },
  },
}
```

Типове значення — `unmentionedInbound: "user_request"`. Повідомлення зі згадками, команди, запити на переривання та особисті повідомлення залишаються запитами користувача.

Щоб вимагати надсилання видимого виведення через інструмент повідомлень для запитів у групах і каналах:

```json5
{
  messages: {
    groupChat: {
      visibleReplies: "message_tool",
    },
  },
}
```

Щоб вимагати цього для кожного вихідного чату:

```json5
{
  messages: {
    visibleReplies: "message_tool",
  },
}
```

Gateway застосовує зміни конфігурації `messages` без перезапуску після збереження файлу. Перезапуск потрібен лише тоді, коли перезавантаження конфігурації вимкнено (`gateway.reload.mode: "off"`).

Звернення з командами обходять `visibleReplies: "message_tool"` і завжди відповідають видимо: як вбудовані команди з косою рискою (Discord, Telegram та інші середовища з вбудованою підтримкою команд), так і авторизовані текстові команди `/...` публікують відповідь у вихідному чаті. Неавторизовані текстові звернення `/...` у групах залишаються доступними лише через інструмент повідомлень; звичайні звернення в чаті дотримуються налаштованого типового значення.

## Видимість контексту та списки дозволених

За безпеку груп відповідають два різні механізми:

- **Авторизація активації**: хто може активувати агента (`groupPolicy`, `groups`, `groupAllowFrom`, списки дозволених для окремих каналів).
- **Видимість контексту**: який додатковий контекст передається моделі (текст відповіді або цитати, історія гілки, метадані пересилання).

Типово OpenClaw зберігає контекст у отриманому вигляді: списки дозволених визначають, хто може активувати дії, а не те, які цитовані чи історичні фрагменти бачить модель. Щоб також фільтрувати додатковий контекст, налаштуйте `contextVisibility`:

| Режим                | Поведінка                                                                         |
| ------------------- | -------------------------------------------------------------------------------- |
| `"all"` (типово)   | Зберігати додатковий контекст у отриманому вигляді.                                           |
| `"allowlist"`       | Передавати контекст історії, гілки, цитат і пересилань лише від відправників зі списку дозволених.     |
| `"allowlist_quote"` | `allowlist`, а також зберігати явно процитоване повідомлення або повідомлення, на яке відповідають, від будь-якого відправника. |

Налаштуйте це для окремого каналу (`channels.<channel>.contextVisibility`), облікового запису (`channels.<channel>.accounts.<accountId>.contextVisibility`) або глобально (`channels.defaults.contextVisibility`). Канали, що отримують додатковий контекст (Discord, Feishu, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp), застосовують політику під час формування вхідного контексту; невідомі комбінації політик закривають доступ і вилучають контекст.

![Схема обробки повідомлень у групі](/images/groups-flow.svg)

Якщо потрібно...

| Мета                                         | Що налаштувати                                                |
| -------------------------------------------- | ---------------------------------------------------------- |
| Дозволити всі групи, але відповідати лише на @згадки | `groups: { "*": { requireMention: true } }`                |
| Вимкнути всі відповіді в групах                    | `groupPolicy: "disabled"`                                  |
| Лише конкретні групи                         | `groups: { "<group-id>": { ... } }` (без ключа `"*"`)         |
| Лише ви можете активувати агента в групах               | `groupPolicy: "allowlist"`, `groupAllowFrom: ["+1555..."]` |
| Використовувати один набір довірених відправників у різних каналах | `groupAllowFrom: ["accessGroup:operators"]`                |

Про повторно використовувані списки дозволених відправників див. [Групи доступу](/uk/channels/access-groups).

## Ключі сеансів

- Групові сеанси використовують ключі сеансів `agent:<agentId>:<channel>:group:<id>` (кімнати й канали використовують `agent:<agentId>:<channel>:channel:<id>`).
- Теми форуму Telegram додають `:topic:<threadId>` до ідентифікатора групи, тому кожна тема має власний сеанс.
- Прямі чати використовують основний сеанс (або окремі сеанси для кожного відправника, якщо налаштовано `session.dmScope`).
- Heartbeat виконуються в налаштованому сеансі Heartbeat (типово — в основному сеансі агента); групові сеанси не запускають власні Heartbeat.

<a id="pattern-personal-dms-public-groups-single-agent"></a>

## Схема: особисті повідомлення + публічні групи (один агент)

Так, це добре працює, якщо ваш «особистий» трафік — це **особисті повідомлення**, а «публічний» — **групи**.

Причина: у режимі одного агента особисті повідомлення зазвичай потрапляють до ключа **основного** сеансу (`agent:main:main`), тоді як групи завжди використовують ключі **неосновних** сеансів (`agent:main:<channel>:group:<id>`). Якщо ввімкнути ізоляцію за допомогою `mode: "non-main"`, ці групові сеанси виконуватимуться в налаштованому ізольованому середовищі, а основний сеанс особистих повідомлень залишатиметься на хості. Якщо не вибрати інше середовище, типовим є Docker.

Це забезпечує один «мозок» агента (спільний робочий простір і пам’ять), але два режими виконання:

- **Особисті повідомлення**: усі інструменти (хост)
- **Групи**: ізольоване середовище й обмежені інструменти

<Note>
Якщо потрібні справді окремі робочі простори або персони («особисте» й «публічне» ніколи не мають перетинатися), використовуйте другого агента та прив’язки. Див. [Маршрутизація між кількома агентами](/uk/concepts/multi-agent).
</Note>

<Tabs>
  <Tab title="Особисті повідомлення на хості, групи в ізольованому середовищі">
    ```json5
    {
      agents: {
        defaults: {
          sandbox: {
            mode: "non-main", // групи/канали є неосновними -> в ізольованому середовищі
            scope: "session", // найсильніша ізоляція (один контейнер на групу/канал)
            workspaceAccess: "none",
          },
        },
      },
      tools: {
        sandbox: {
          tools: {
            // Якщо allow не порожній, усе інше заблоковано (deny однаково має перевагу).
            allow: ["group:messaging", "group:sessions"],
            deny: ["group:runtime", "group:fs", "group:ui", "nodes", "cron", "gateway"],
          },
        },
      },
    }
    ```
  </Tab>
  <Tab title="Групи бачать лише папку зі списку дозволених">
    Потрібно, щоб «групи могли бачити лише папку X», а не «не мали доступу до хоста»? Залиште `workspaceAccess: "none"` і підключіть до ізольованого середовища лише шляхи зі списку дозволених:

    ```json5
    {
      agents: {
        defaults: {
          sandbox: {
            mode: "non-main",
            scope: "session",
            workspaceAccess: "none",
            docker: {
              binds: [
                // hostPath:containerPath:mode
                "/home/user/FriendsShared:/data:ro",
              ],
            },
          },
        },
      },
    }
    ```

  </Tab>
</Tabs>

Пов’язані матеріали:

- Ключі конфігурації та типові значення: [Конфігурація Gateway](/uk/gateway/config-agents#agentsdefaultssandbox)
- Налагодження причин блокування інструмента: [Ізольоване середовище, політика інструментів і підвищені привілеї](/uk/gateway/sandbox-vs-tool-policy-vs-elevated)
- Докладніше про підключення каталогів: [Ізоляція](/uk/gateway/sandboxing#custom-bind-mounts)

## Відображувані мітки

- Мітки інтерфейсу використовують `displayName`, коли він доступний, у форматі `<channel>:<token>`.
- `#room` зарезервовано для кімнат і каналів; групові чати використовують `g-<slug>` (нижній регістр, пробіли -> `-`, зберігати `#@+._-`). Дуже довгі непрозорі ідентифікатори скорочуються до стабільного токена, щоб повні ідентифікатори маршрутів не потрапляли до інтерфейсу.

## Політика груп

Керуйте обробкою повідомлень груп і кімнат окремо для кожного каналу:

```json5
{
  channels: {
    whatsapp: {
      groupPolicy: "disabled", // "open" | "disabled" | "allowlist"
      groupAllowFrom: ["+15551234567"],
    },
    telegram: {
      groupPolicy: "disabled",
      groupAllowFrom: ["123456789"], // числовий ідентифікатор користувача Telegram (під час налаштування @username перетворюється на ідентифікатор)
    },
    signal: {
      groupPolicy: "disabled",
      groupAllowFrom: ["+15551234567"],
    },
    imessage: {
      groupPolicy: "disabled",
      groupAllowFrom: ["chat_id:123"],
    },
    msteams: {
      groupPolicy: "disabled",
      groupAllowFrom: ["user@org.com"],
    },
    discord: {
      groupPolicy: "allowlist",
      guilds: {
        GUILD_ID: { channels: { help: { enabled: true } } },
      },
    },
    slack: {
      groupPolicy: "allowlist",
      channels: { "#general": { enabled: true } },
    },
    matrix: {
      groupPolicy: "allowlist",
      groupAllowFrom: ["@owner:example.org"],
      groups: {
        "!roomId:example.org": { enabled: true },
        "#alias:example.org": { enabled: true },
      },
    },
  },
}
```

| Політика        | Поведінка                                                     |
| ------------- | ------------------------------------------------------------ |
| `"open"`      | Групи оминають списки дозволених; вимога згадки все одно застосовується.      |
| `"disabled"`  | Повністю блокувати всі групові повідомлення.                           |
| `"allowlist"` | Дозволяти лише групи/кімнати, що відповідають налаштованому списку дозволених. |

<AccordionGroup>
  <Accordion title="Примітки для окремих каналів">
    - `groupPolicy` не залежить від вимоги згадки (яка потребує @згадок).
    - WhatsApp/Telegram/Signal/iMessage/Microsoft Teams/Zalo: використовуйте `groupAllowFrom` (резервний варіант: явний `allowFrom`).
    - Signal: `groupAllowFrom` може відповідати або ідентифікатору вхідної групи Signal, або телефону/UUID відправника.
    - Схвалення сполучення для приватних повідомлень (записи сховища `*-allowFrom`) застосовуються лише до доступу через приватні повідомлення; авторизація відправників у групах і надалі явно визначається списками дозволених для груп.
    - Discord: список дозволених використовує `channels.discord.guilds.<id>.channels`.
    - Slack: список дозволених використовує `channels.slack.channels`.
    - Matrix: список дозволених використовує `channels.matrix.groups`. Використовуйте ідентифікатори кімнат (`!room:server`) або псевдоніми (`#alias:server`); ключі з назвами кімнат збігаються лише з `channels.matrix.dangerouslyAllowNameMatching: true`, а нерозпізнані записи ігноруються під час виконання. Використовуйте `channels.matrix.groupAllowFrom`, щоб обмежити відправників; також підтримуються списки дозволених `users` для окремих кімнат.
    - Групові приватні повідомлення керуються окремо (`channels.discord.dm.*`, `channels.slack.dm.*`: `groupEnabled`, `groupChannels`).
    - Telegram: списки дозволених відправників приймають лише числові ідентифікатори користувачів (`"123456789"`; префікси `telegram:`/`tg:` вилучаються без урахування регістру). Записи `@username` не збігаються під час виконання, і до журналу записується попередження; під час налаштування `@username` перетворюються на ідентифікатори. Від’ємні ідентифікатори чатів мають бути в `channels.telegram.groups`, а не в списках дозволених відправників.
    - Значення за замовчуванням — `groupPolicy: "allowlist"`; якщо список дозволених для груп порожній, групові повідомлення блокуються.
    - Безпека під час виконання: якщо блок провайдера повністю відсутній (`channels.<provider>` відсутній), групова політика переходить у закритий стан `allowlist` замість успадкування `channels.defaults.groupPolicy`, а Gateway одноразово записує цей резервний перехід до журналу для кожного облікового запису.

  </Accordion>
</AccordionGroup>

Коротка ментальна модель (порядок оцінювання групових повідомлень):

<Steps>
  <Step title="groupPolicy">
    `groupPolicy` (open/disabled/allowlist).
  </Step>
  <Step title="Списки дозволених для груп">
    Списки дозволених для груп (`*.groups`, `*.groupAllowFrom`, список дозволених для певного каналу).
  </Step>
  <Step title="Вимога згадки">
    Вимога згадки (`requireMention`, `/activation`).
  </Step>
</Steps>

## Вимога згадки (за замовчуванням)

Групові повідомлення потребують згадки, якщо це не перевизначено для окремої групи. Значення за замовчуванням розташовані для кожної підсистеми в `*.groups."*"`.

Відповідь на повідомлення бота вважається неявною згадкою, коли канал надає метадані відповіді; цитування повідомлення бота також може вважатися згадкою в каналах, що надають метадані цитування. Поточні вбудовані випадки: Discord, Microsoft Teams, QQBot, Slack, Telegram, WhatsApp і персональний Zalo.

```json5
{
  channels: {
    whatsapp: {
      groups: {
        "*": { requireMention: true },
        "123@g.us": { requireMention: false },
      },
    },
    telegram: {
      groups: {
        "*": { requireMention: true },
        "123456789": { requireMention: false },
      },
    },
    imessage: {
      groups: {
        "*": { requireMention: true },
        "123": { requireMention: false },
      },
    },
  },
  agents: {
    list: [
      {
        id: "main",
        groupChat: {
          mentionPatterns: ["@openclaw", "openclaw", "\\+15555550123"],
          historyLimit: 50,
        },
      },
    ],
  },
}
```

## Обмеження області налаштованих шаблонів згадок

Налаштовані `mentionPatterns` — це резервні тригери на основі регулярних виразів. Використовуйте їх, коли
платформа не надає нативної згадки бота або коли потрібно, щоб звичайний текст,
наприклад `openclaw:`, вважався згадкою. Нативні згадки платформи обробляються окремо:
коли Discord, Slack, Telegram, Matrix, Signal або інший канал може підтвердити, що повідомлення
явно згадує бота, ця нативна згадка все одно спрацьовує, навіть якщо
налаштовані шаблони регулярних виразів заборонено.

За замовчуванням налаштовані шаблони згадок застосовуються всюди, де канал передає дані про провайдера та розмову до механізму виявлення згадок. Щоб широкі шаблони не активували агента в кожній групі, обмежте їхню область для кожного каналу за допомогою `channels.<channel>.mentionPatterns`.

Використовуйте `mode: "deny"`, коли шаблони згадок на основі регулярних виразів мають бути за замовчуванням вимкнені для каналу, а потім увімкніть їх у певних кімнатах за допомогою `allowIn`:

```json5
{
  messages: {
    groupChat: {
      mentionPatterns: ["\\bopenclaw\\b", "\\bops bot\\b"],
    },
  },
  channels: {
    slack: {
      mentionPatterns: {
        mode: "deny",
        allowIn: ["C0123OPS"],
      },
    },
  },
}
```

Використовуйте стандартний `mode: "allow"` (або не вказуйте `mode`), коли шаблони згадок на основі регулярних виразів мають застосовуватися широко, а потім вимкніть їх у галасливих кімнатах за допомогою `denyIn`:

```json5
{
  messages: {
    groupChat: {
      mentionPatterns: ["\\bopenclaw\\b"],
    },
  },
  channels: {
    telegram: {
      mentionPatterns: {
        denyIn: ["-1001234567890", "-1001234567890:topic:42"],
      },
    },
  },
}
```

Визначення політики:

| Поле           | Результат                                                                                                                |
| --------------- | --------------------------------------------------------------------------------------------------------------------- |
| `mode: "allow"` | Шаблони згадок на основі регулярних виразів увімкнені, якщо ідентифікатора розмови немає в `denyIn`. Це значення за замовчуванням.                    |
| `mode: "deny"`  | Шаблони згадок на основі регулярних виразів вимкнені, якщо ідентифікатора розмови немає в `allowIn`.                                       |
| `allowIn`       | Ідентифікатори розмов, у яких шаблони згадок на основі регулярних виразів увімкнені в режимі заборони.                                               |
| `denyIn`        | Ідентифікатори розмов, у яких шаблони згадок на основі регулярних виразів вимкнені. `denyIn` має перевагу над `allowIn`, якщо обидва містять той самий ідентифікатор. |

Підтримувана нині політика обмеження області регулярних виразів:

| Канал  | Ідентифікатори, що використовуються в `allowIn` / `denyIn`                             |
| -------- | ------------------------------------------------------------ |
| Discord  | Ідентифікатори каналів Discord.                                         |
| Matrix   | Ідентифікатори кімнат Matrix.                                             |
| Slack    | Ідентифікатори каналів Slack.                                           |
| Telegram | Ідентифікатори групових чатів або `chatId:topic:threadId` для тем форуму. |
| WhatsApp | Ідентифікатори розмов WhatsApp, наприклад `123@g.us`.                |

У конфігураціях каналів на рівні облікового запису можна налаштувати таку саму політику в `channels.<channel>.accounts.<accountId>.mentionPatterns`, якщо канал підтримує кілька облікових записів. Для цього облікового запису політика облікового запису має перевагу над політикою каналу верхнього рівня.

<AccordionGroup>
  <Accordion title="Примітки щодо вимоги згадки">
    - `mentionPatterns` — це безпечні шаблони регулярних виразів без урахування регістру; недійсні шаблони та небезпечні форми з вкладеним повторенням ігноруються (з попередженням).
    - Пріоритет шаблонів: `agents.list[].groupChat.mentionPatterns` (корисно, коли кілька агентів спільно використовують групу) перевизначає `messages.groupChat.mentionPatterns`; якщо не задано жодного, шаблони утворюються з імені/емодзі ідентичності агента.
    - Вимога згадки застосовується лише тоді, коли виявлення згадок можливе (налаштовано нативні згадки або `mentionPatterns`).
    - Додавання групи або відправника до списку дозволених не вимикає вимогу згадки; установіть для `requireMention` цієї групи значення `false`, якщо всі повідомлення мають запускати обробку.
    - Автоматичний контекст запиту для групового чату передає визначену інструкцію щодо тихої відповіді під час кожного ходу; файли робочого простору не повинні дублювати механіку `NO_REPLY`.
    - У групах, де дозволені автоматичні тихі відповіді, чисті порожні ходи моделі або ходи лише з міркуваннями вважаються тихими, еквівалентними `NO_REPLY`. Приватні чати ніколи не отримують настанови `NO_REPLY`, а групові відповіді лише через інструмент повідомлень залишаються тихими, не викликаючи `message(action=send)`.
    - Фонове постійне спілкування в групі за замовчуванням використовує семантику запиту користувача. Установіть `messages.groupChat.unmentionedInbound: "room_event"`, щоб натомість передавати його як тихий контекст. Приклади налаштування див. у розділі [Фонові події кімнати](/uk/channels/ambient-room-events).
    - Події кімнати не зберігаються як фіктивні запити користувачів, а приватний текст асистента з подій кімнати без інструмента повідомлень не відтворюється як історія чату.
    - Значення Discord за замовчуванням розташовані в `channels.discord.guilds."*"` (їх можна перевизначити для окремої гільдії/каналу).
    - Контекст історії груп уніфіковано обгортається в усіх каналах. Групи з вимогою згадки зберігають пропущені повідомлення, що очікують обробки; постійно активні групи також можуть зберігати нещодавно оброблені повідомлення кімнати, якщо канал це підтримує. Використовуйте `messages.groupChat.historyLimit` для глобального значення за замовчуванням і `channels.<channel>.historyLimit` (або `channels.<channel>.accounts.*.historyLimit`) для перевизначень. Установіть `0`, щоб вимкнути.

  </Accordion>
</AccordionGroup>

## Обмеження інструментів для групи/каналу (необов’язково)

Деякі конфігурації каналів підтримують обмеження інструментів, доступних **у певній групі/кімнаті/каналі**.

- `tools`: дозволяє/забороняє інструменти для всієї групи (`allow`, `alsoAllow`, `deny`; заборона має перевагу).
- `toolsBySender`: перевизначення для окремих відправників у групі. Використовуйте явні префікси ключів: `channel:<channelId>:<senderId>`, `id:<senderId>`, `e164:<phone>`, `username:<handle>`, `name:<displayName>` і шаблон `"*"`. Ідентифікатори каналів використовують канонічні ідентифікатори каналів OpenClaw; псевдоніми на кшталт `teams` нормалізуються до `msteams`. Застарілі ключі без префіксів усе ще приймаються, зіставляються лише як `id:` і спричиняють запис попередження про застарілість до журналу.

Порядок визначення (найконкретніше правило має перевагу):

<Steps>
  <Step title="Груповий toolsBySender">
    Збіг `toolsBySender` групи/каналу.
  </Step>
  <Step title="Групові tools">
    `tools` групи/каналу.
  </Step>
  <Step title="Стандартний toolsBySender">
    Збіг `toolsBySender` за замовчуванням (`"*"`).
  </Step>
  <Step title="Стандартні tools">
    `tools` за замовчуванням (`"*"`).
  </Step>
</Steps>

Приклад (Telegram):

```json5
{
  channels: {
    telegram: {
      groups: {
        "*": { tools: { deny: ["exec"] } },
        "-1001234567890": {
          tools: { deny: ["exec", "read", "write"] },
          toolsBySender: {
            "id:123456789": { alsoAllow: ["exec"] },
          },
        },
      },
    },
  },
}
```

<Note>
Обмеження інструментів для груп/каналів застосовуються на додачу до глобальної політики та політики інструментів агента (заборона все одно має перевагу). Деякі канали використовують різну вкладеність для кімнат/каналів (наприклад, Discord `guilds.*.channels.*`, Slack `channels.*`, Microsoft Teams `teams.*.channels.*`).
</Note>

## Списки дозволених груп

Коли налаштовано `channels.whatsapp.groups`, `channels.telegram.groups` або `channels.imessage.groups`, ключі діють як список дозволених груп. Використовуйте `"*"`, щоб дозволити всі групи, водночас задавши типову поведінку щодо згадок.

<Warning>
Поширена плутанина: схвалення сполучення в особистих повідомленнях — не те саме, що авторизація групи. Для каналів, які підтримують сполучення в особистих повідомленнях, сховище сполучень розблоковує лише особисті повідомлення. Для групових команд усе одно потрібна явна авторизація відправника групи через списки дозволених у конфігурації, як-от `groupAllowFrom`, або задокументований резервний варіант конфігурації для цього каналу.
</Warning>

Поширені сценарії (скопіюйте та вставте):

<Tabs>
  <Tab title="Вимкнути всі відповіді в групах">
    ```json5
    {
      channels: { whatsapp: { groupPolicy: "disabled" } },
    }
    ```
  </Tab>
  <Tab title="Дозволити лише певні групи (WhatsApp)">
    ```json5
    {
      channels: {
        whatsapp: {
          groups: {
            "123@g.us": { requireMention: true },
            "456@g.us": { requireMention: false },
          },
        },
      },
    }
    ```
  </Tab>
  <Tab title="Дозволити всі групи, але вимагати згадку">
    ```json5
    {
      channels: {
        whatsapp: {
          groups: { "*": { requireMention: true } },
        },
      },
    }
    ```
  </Tab>
  <Tab title="Активація лише власником (WhatsApp)">
    ```json5
    {
      channels: {
        whatsapp: {
          groupPolicy: "allowlist",
          groupAllowFrom: ["+15551234567"],
          groups: { "*": { requireMention: true } },
        },
      },
    }
    ```
  </Tab>
</Tabs>

## Активація (лише власником)

Власники груп можуть перемикати активацію окремо для кожної групи за допомогою окремого повідомлення:

- `/activation mention`
- `/activation always`

`/activation` — це основна команда з доступом лише для власника, яка застосовується тільки в групових чатах. Власником вважається відправник, який відповідає `commands.ownerAllowFrom`; списки `allowFrom` каналу керують лише звичайним доступом до каналу та команд. Збережений режим перевизначає `requireMention` цієї групи в каналах, які його враховують (Google Chat, QQBot, Telegram, WhatsApp), а вступ системного запиту для групи всюди відображає активний режим.

## Поля контексту

Вхідні корисні навантаження груп задають:

- `ChatType=group`
- `GroupSubject` (якщо відомо)
- `GroupMembers` (якщо відомо)
- `WasMentioned` (результат перевірки згадки)
- Теми форумів Telegram також містять `MessageThreadId` і `IsForum`.

Системний запит агента містить вступ для групи на першому кроці нового групового сеансу (і після зміни `/activation`). Він нагадує моделі відповідати як людина, зводити до мінімуму порожні рядки, дотримуватися звичайних інтервалів у чаті та не вводити буквальні послідовності `\n`. Канали, заявлений режим таблиць яких не зберігає нативні або необроблені таблиці, також не рекомендують використовувати таблиці Markdown. Назви груп і позначення учасників, отримані з каналів, відтворюються як ненадійні метадані в огородженому блоці, а не як вбудовані системні інструкції.

## Особливості iMessage

- Для маршрутизації або додавання до списку дозволених віддавайте перевагу `chat_id:<id>`.
- Перегляд списку чатів: `imsg chats --limit 20`.
- Групові відповіді завжди надсилаються назад до того самого `chat_id`.

## Системні запити WhatsApp

Канонічні правила системних запитів WhatsApp, зокрема визначення групових і прямих запитів, поведінку символу підстановки та семантику перевизначення облікового запису, див. у [WhatsApp](/uk/channels/whatsapp#system-prompts).

## Особливості WhatsApp

Поведінку лише для WhatsApp (додавання історії, подробиці обробки згадок) див. у розділі [Групові повідомлення](/uk/channels/group-messages).

## Пов’язане

- [Групи розсилки](/uk/channels/broadcast-groups)
- [Маршрутизація каналів](/uk/channels/channel-routing)
- [Групові повідомлення](/uk/channels/group-messages)
- [Сполучення](/uk/channels/pairing)
