---
read_when:
    - Зміна поведінки групового чату або обмеження за згадкою
    - Обмеження області дії mentionPatterns конкретними груповими розмовами
sidebarTitle: Groups
summary: Поведінка групових чатів на різних поверхнях (Discord/iMessage/Matrix/Microsoft Teams/QQBot/Signal/Slack/Telegram/WhatsApp/Zalo)
title: Групи
x-i18n:
    generated_at: "2026-06-27T17:10:15Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 48660e36ac642956842d453fd4caf2cbd7f4193efee9ac864fd7cf700c3c43b6
    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"`).
- Відповіді потребують згадки, якщо ви явно не вимкнули шлюзування за згадкою.
- Видимі відповіді в групах/каналах за замовчуванням використовують інструмент `message`.

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

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

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

</Note>

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

```
groupPolicy? disabled -> drop
groupPolicy? allowlist -> group allowed? no -> drop
requireMention? yes -> mentioned? no -> store for context only
mention/reply/command/DM -> user request
always-on group chatter -> user request, or room event when configured
```

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

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

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

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

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

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

Для прямих чатів і будь-якої іншої події джерела використовуйте `messages.visibleReplies: "message_tool"`, щоб застосувати таку саму поведінку видимої відповіді лише через інструмент глобально. Внутрішні прямі звернення WebChat за замовчуванням використовують автоматичну доставку фінальної відповіді, щоб Pi і Codex отримували однаковий контракт видимої відповіді. Установіть `messages.visibleReplies: "message_tool"`, щоб навмисно вимагати `message(action=send)` для видимого виведення. `messages.groupChat.visibleReplies` лишається специфічнішим перевизначенням для групових/канальних кімнат.

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

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

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

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

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

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

За замовчуванням використовується `unmentionedInbound: "user_request"`.

Згадані повідомлення, команди, запити переривання та DM залишаються користувацькими запитами.

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

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

Gateway гаряче перезавантажує конфігурацію `messages` після збереження файла. Перезапускайте лише тоді, коли спостереження за файлами або перезавантаження конфігурації вимкнено в розгортанні.

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

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

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

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

У безпеці груп задіяні два різні елементи керування:

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

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

<AccordionGroup>
  <Accordion title="Current behavior is channel-specific">
    - Деякі канали вже застосовують фільтрацію на основі відправника для додаткового контексту в конкретних шляхах (наприклад, початкове наповнення потоків Slack, пошуки відповідей/потоків Matrix).
    - Інші канали все ще передають контекст цитат/відповідей/пересилань таким, яким його отримано.

  </Accordion>
  <Accordion title="Hardening direction (planned)">
    - `contextVisibility: "all"` (за замовчуванням) зберігає поточну поведінку «як отримано».
    - `contextVisibility: "allowlist"` фільтрує додатковий контекст до дозволених відправників.
    - `contextVisibility: "allowlist_quote"` — це `allowlist` плюс один явний виняток для цитати/відповіді.

    Доки цю модель посилення не реалізовано послідовно в усіх каналах, очікуйте відмінностей залежно від поверхні.

  </Accordion>
</AccordionGroup>

![Потік групових повідомлень](/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>` до ідентифікатора групи, щоб кожна тема мала власний сеанс.
- Прямі чати використовують основний сеанс (або окремий для кожного відправника, якщо налаштовано).
- Heartbeat пропускаються для групових сеансів.

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

## Шаблон: особисті DM + публічні групи (один агент)

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

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

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

- **DM**: повні інструменти (хост)
- **Групи**: ізоляція + обмежені інструменти

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

<Tabs>
  <Tab title="DMs on host, groups sandboxed">
    ```json5
    {
      agents: {
        defaults: {
          sandbox: {
            mode: "non-main", // groups/channels are non-main -> sandboxed
            scope: "session", // strongest isolation (one container per group/channel)
            workspaceAccess: "none",
          },
        },
      },
      tools: {
        sandbox: {
          tools: {
            // If allow is non-empty, everything else is blocked (deny still wins).
            allow: ["group:messaging", "group:sessions"],
            deny: ["group:runtime", "group:fs", "group:ui", "nodes", "cron", "gateway"],
          },
        },
      },
    }
    ```
  </Tab>
  <Tab title="Groups see only an allowlisted folder">
    Хочете, щоб «групи могли бачити лише папку 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)
- Налагодження, чому інструмент заблоковано: [Ізоляція vs політика інструментів vs підвищені права](/uk/gateway/sandbox-vs-tool-policy-vs-elevated)
- Подробиці bind mount: [Ізоляція](/uk/gateway/sandboxing#custom-bind-mounts)

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

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

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

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

```json5
{
  channels: {
    whatsapp: {
      groupPolicy: "disabled", // "open" | "disabled" | "allowlist"
      groupAllowFrom: ["+15551234567"],
    },
    telegram: {
      groupPolicy: "disabled",
      groupAllowFrom: ["123456789"], // numeric Telegram user id (wizard can resolve @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: { allow: true } } },
      },
    },
    slack: {
      groupPolicy: "allowlist",
      channels: { "#general": { allow: 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="Per-channel notes">
    - `groupPolicy` відокремлена від фільтрації за згадками (яка вимагає @згадок).
    - WhatsApp/Telegram/Signal/iMessage/Microsoft Teams/Zalo: використовуйте `groupAllowFrom` (резервний варіант: явний `allowFrom`).
    - Signal: `groupAllowFrom` може відповідати або вхідному ID групи Signal, або телефону/UUID відправника.
    - Схвалення прив’язування DM (записи сховища `*-allowFrom`) застосовуються лише до доступу DM; авторизація відправника в групі лишається явно прив’язаною до групових списків дозволів.
    - Discord: список дозволів використовує `channels.discord.guilds.<id>.channels`.
    - Slack: список дозволів використовує `channels.slack.channels`.
    - Matrix: список дозволів використовує `channels.matrix.groups`. Надавайте перевагу ID кімнат або псевдонімам; пошук назви приєднаної кімнати виконується за принципом найкращої спроби, а нерозв’язані назви ігноруються під час виконання. Використовуйте `channels.matrix.groupAllowFrom`, щоб обмежити відправників; також підтримуються списки дозволів `users` для окремих кімнат.
    - Групові DM керуються окремо (`channels.discord.dm.*`, `channels.slack.dm.*`).
    - Список дозволів Telegram може відповідати ID користувачів (`"123456789"`, `"telegram:123456789"`, `"tg:123456789"`) або іменам користувачів (`"@alice"` чи `"alice"`); префікси не чутливі до регістру.
    - Типове значення — `groupPolicy: "allowlist"`; якщо ваш груповий список дозволів порожній, групові повідомлення блокуються.
    - Безпека під час виконання: коли блок провайдера повністю відсутній (`channels.<provider>` відсутній), групова політика повертається до fail-closed режиму (зазвичай `allowlist`) замість успадкування `channels.defaults.groupPolicy`.

  </Accordion>
</AccordionGroup>

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

<Steps>
  <Step title="groupPolicy">
    `groupPolicy` (open/disabled/allowlist).
  </Step>
  <Step title="Group allowlists">
    Групові списки дозволів (`*.groups`, `*.groupAllowFrom`, список дозволів, специфічний для каналу).
  </Step>
  <Step title="Mention gating">
    Фільтрація за згадками (`requireMention`, `/activation`).
  </Step>
</Steps>

## Фільтрація за згадками (типово)

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

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

```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` є резервними тригерами regex. Використовуйте їх, коли
платформа не надає нативної згадки бота або коли ви хочете, щоб звичайний текст,
наприклад `openclaw:`, рахувався як згадка. Нативні згадки платформи є окремими:
коли Discord, Slack, Telegram, Matrix або інший канал може довести, що повідомлення
явно згадало бота, ця нативна згадка все одно спрацьовує, навіть якщо
налаштовані regex-шаблони заборонені.

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

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

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

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

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

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

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

Підтримувана сьогодні політика scoped regex:

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

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

<AccordionGroup>
  <Accordion title="Mention gating notes">
    - `mentionPatterns` — це безпечні regex-шаблони без чутливості до регістру; недійсні шаблони й небезпечні форми вкладених повторень ігноруються.
    - Поверхні, що надають явні згадки, усе одно проходять; налаштовані regex-шаблони є резервним варіантом.
    - `channels.<channel>.mentionPatterns.mode: "deny"` типово вимикає налаштовані шаблони згадок для цього каналу; поверніть вибрані розмови через `allowIn`.
    - `channels.<channel>.mentionPatterns.denyIn` вимикає налаштовані шаблони згадок для конкретних ID розмов, тоді як нативні @згадки платформи все одно проходять.
    - Перевизначення для агента: `agents.list[].groupChat.mentionPatterns` (корисно, коли кілька агентів спільно використовують групу).
    - Фільтрація за згадками застосовується лише тоді, коли виявлення згадок можливе (налаштовані нативні згадки або `mentionPatterns`).
    - Додавання групи або відправника до списку дозволів не вимикає фільтрацію за згадками; установіть для цієї групи `requireMention` значення `false`, коли всі повідомлення мають запускати обробку.
    - Автоматичний контекст підказки групового чату переносить розв’язану інструкцію тихої відповіді в кожному ході; файли робочого простору не мають дублювати механіку `NO_REPLY`.
    - Групи, де дозволені автоматичні тихі відповіді, трактують чисті порожні ходи моделі або ходи лише з reasoning як тихі, еквівалентні `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`: дозволити/заборонити інструменти для всієї групи.
- `toolsBySender`: перевизначення для окремих відправників у групі. Використовуйте явні префікси ключів: `channel:<channelId>:<senderId>`, `id:<senderId>`, `e164:<phone>`, `username:<handle>`, `name:<displayName>` і wildcard `"*"`. ID каналів використовують канонічні ID каналів OpenClaw; псевдоніми, як-от `teams`, нормалізуються до `msteams`. Застарілі ключі без префікса все ще приймаються й зіставляються лише як `id:`.

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

<Steps>
  <Step title="Group toolsBySender">
    Збіг `toolsBySender` групи/каналу.
  </Step>
  <Step title="Group tools">
    `tools` групи/каналу.
  </Step>
  <Step title="Default toolsBySender">
    Збіг типового (`"*"`) `toolsBySender`.
  </Step>
  <Step title="Default tools">
    Типове (`"*"`) `tools`.
  </Step>
</Steps>

Приклад (Telegram):

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

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

## Групові списки дозволів

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

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

Поширені наміри (копіювати/вставити):

<Tabs>
  <Tab title="Disable all group replies">
    ```json5
    {
      channels: { whatsapp: { groupPolicy: "disabled" } },
    }
    ```
  </Tab>
  <Tab title="Allow only specific groups (WhatsApp)">
    ```json5
    {
      channels: {
        whatsapp: {
          groups: {
            "123@g.us": { requireMention: true },
            "456@g.us": { requireMention: false },
          },
        },
      },
    }
    ```
  </Tab>
  <Tab title="Allow all groups but require mention">
    ```json5
    {
      channels: {
        whatsapp: {
          groups: { "*": { requireMention: true } },
        },
      },
    }
    ```
  </Tab>
  <Tab title="Owner-only triggers (WhatsApp)">
    ```json5
    {
      channels: {
        whatsapp: {
          groupPolicy: "allowlist",
          groupAllowFrom: ["+15551234567"],
          groups: { "*": { requireMention: true } },
        },
      },
    }
    ```
  </Tab>
</Tabs>

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

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

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

Власник визначається за `channels.whatsapp.allowFrom` (або за власним E.164 бота, якщо не задано). Надішліть команду як окреме повідомлення. Інші поверхні наразі ігнорують `/activation`.

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

Вхідні групові payload задають:

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

Системний промпт агента містить груповий вступ на першому ході нової групової сесії. Він нагадує моделі відповідати як людина, мінімізувати порожні рядки й дотримуватися звичайних інтервалів чату, а також не вводити буквальні послідовності `\n`. Групи не в Telegram також не заохочують Markdown-таблиці; настанови щодо форматованого тексту Telegram надходять із промпта каналу Telegram. Назви груп і мітки учасників, отримані з каналу, відображаються як fenced недовірені метадані, а не як вбудовані системні інструкції.

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

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

## Системні промпти WhatsApp

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

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

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

## Пов’язане

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