समूह

OpenClaw सभी सतहों पर समूह चैट को एकसमान मानता है: Discord, iMessage, Matrix, Microsoft Teams, QQBot, Signal, Slack, Telegram, WhatsApp, Zalo.

हमेशा चालू रहने वाले उन रूम के लिए, जिन्हें एजेंट के स्पष्ट रूप से दृश्य संदेश भेजने तक शांत संदर्भ देना चाहिए, परिवेशी रूम इवेंट देखें।

शुरुआती परिचय (2 मिनट)

OpenClaw आपके अपने मैसेजिंग खातों पर "रहता" है। कोई अलग WhatsApp बॉट उपयोगकर्ता नहीं होता। यदि आप किसी समूह में हैं, तो OpenClaw उस समूह को देख सकता है और वहीं जवाब दे सकता है।

डिफ़ॉल्ट व्यवहार:

• समूह प्रतिबंधित होते हैं (groupPolicy: "allowlist")।
• जवाबों के लिए mention आवश्यक है, जब तक आप स्पष्ट रूप से mention gating बंद न करें।
• समूहों/चैनलों में दृश्य जवाब डिफ़ॉल्ट रूप से message टूल का उपयोग करते हैं।

अर्थ: allowlist में शामिल भेजने वाले OpenClaw को mention करके ट्रिगर कर सकते हैं।

त्वरित प्रवाह (समूह संदेश के साथ क्या होता है):

groupPolicy? disabled -> dropgroupPolicy? allowlist -> group allowed? no -> droprequireMention? yes -> mentioned? no -> store for context onlymention/reply/command/DM -> user requestalways-on group chatter -> user request, or room event when configured

दृश्य जवाब

सामान्य समूह/चैनल अनुरोधों के लिए, OpenClaw डिफ़ॉल्ट रूप से messages.groupChat.visibleReplies: "automatic" का उपयोग करता है। अंतिम सहायक पाठ legacy दृश्य जवाब पथ से पोस्ट होता है, जब तक आप रूम को message-tool-only आउटपुट में ऑप्ट इन नहीं करते।

जब कोई साझा रूम एजेंट को message(action=send) कॉल करके बोलने का समय तय करने देना चाहिए, तब messages.groupChat.visibleReplies: "message_tool" उपयोग करें। यह GPT 5.5 जैसे नवीनतम पीढ़ी के, टूल-विश्वसनीय मॉडलों द्वारा समर्थित समूह रूम के लिए सबसे अच्छा काम करता है। यदि मॉडल वह टूल चूक जाता है और सार्थक अंतिम पाठ लौटाता है, तो OpenClaw उस अंतिम पाठ को रूम में पोस्ट करने के बजाय निजी रखता है।

कमज़ोर मॉडलों या ऐसे runtime के लिए "automatic" उपयोग करें जो tool-only delivery को भरोसेमंद ढंग से नहीं समझते। automatic मोड में, एजेंट का अंतिम सहायक पाठ दृश्य स्रोत जवाब पथ होता है, इसलिए जो मॉडल लगातार message(action=send) कॉल नहीं कर सकता, वह फिर भी सामान्य रूप से उत्तर दे सकता है।

automatic मोड में, सामान्य टेक्स्ट अंतिम जवाब सीधे रूम में पोस्ट किए जाते हैं। यदि दृश्य जवाब को फ़ाइलों, छवियों या अन्य attachments की आवश्यकता है, तो एजेंट उस attachment के लिए अंतिम टेक्स्ट जवाब से जबरन भेजने के बजाय फिर भी message(action=send) उपयोग कर सकता है।

यदि सक्रिय tool policy के अंतर्गत message टूल उपलब्ध नहीं है, तो OpenClaw प्रतिक्रिया को चुपचाप दबाने के बजाय automatic दृश्य जवाबों पर वापस लौटता है। openclaw doctor इस mismatch के बारे में चेतावनी देता है।

प्रत्यक्ष चैट और किसी भी अन्य स्रोत इवेंट के लिए, उसी tool-only दृश्य-जवाब व्यवहार को वैश्विक रूप से लागू करने के लिए messages.visibleReplies: "message_tool" उपयोग करें। आंतरिक WebChat प्रत्यक्ष turns automatic अंतिम-जवाब delivery पर डिफ़ॉल्ट होते हैं ताकि Pi और Codex को वही दृश्य-जवाब contract मिले। दृश्य आउटपुट के लिए जानबूझकर message(action=send) आवश्यक करने हेतु messages.visibleReplies: "message_tool" सेट करें। messages.groupChat.visibleReplies समूह/चैनल रूम के लिए अधिक विशिष्ट override बना रहता है।

यह पुराने पैटर्न को बदलता है जिसमें अधिकांश lurk-mode turns के लिए मॉडल को NO_REPLY उत्तर देने के लिए मजबूर किया जाता था। tool-only मोड में, prompt कोई NO_REPLY contract परिभाषित नहीं करता। कुछ भी दृश्य न करना बस message टूल कॉल न करने का अर्थ है।

Plugin-स्वामित्व वाली conversation bindings अपवाद हैं। जब कोई Plugin किसी thread को bind कर देता है और inbound turn का दावा करता है, तो Plugin द्वारा लौटाया गया reply ही दृश्य binding response होता है; उसे message(action=send) की आवश्यकता नहीं होती। वह reply Plugin runtime आउटपुट है, निजी मॉडल final text नहीं।

प्रत्यक्ष समूह अनुरोधों के लिए typing indicators अब भी भेजे जाते हैं। Ambient हमेशा-चालू रूम इवेंट, सक्षम होने पर, तब तक सख्त और शांत रहते हैं जब तक एजेंट message टूल कॉल नहीं करता।

Sessions डिफ़ॉल्ट रूप से verbose tool/progress summaries को दबा देते हैं। debugging के दौरान वर्तमान session के लिए वे summaries दिखाने हेतु /verbose on उपयोग करें, और final-reply-only व्यवहार पर लौटने के लिए /verbose off। वही verbose state प्रत्यक्ष चैट, समूहों, चैनलों और forum topics में लागू होती है।

बिना mention वाले हमेशा-चालू समूह chatter को user requests के बजाय शांत room context के रूप में जमा करने के लिए परिवेशी रूम इवेंट उपयोग करें:

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

डिफ़ॉल्ट unmentionedInbound: "user_request" है।

Mention किए गए संदेश, commands, abort requests, और DMs user requests बने रहते हैं।

समूह/चैनल अनुरोधों के लिए दृश्य आउटपुट को message टूल से गुजरना आवश्यक करने के लिए:

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

फ़ाइल सहेजे जाने के बाद Gateway messages config को hot-reload करता है। restart केवल तब करें जब deployment में file watching या config reload अक्षम हो।

हर स्रोत चैट के लिए दृश्य आउटपुट को message टूल से गुजरना आवश्यक करने के लिए:

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

Native slash commands (Discord, Telegram, और native command support वाली अन्य सतहें) visibleReplies: "message_tool" को bypass करते हैं और हमेशा दृश्य रूप से reply करते हैं ताकि channel-native command UI को अपेक्षित response मिले। यह केवल validated native command turns पर लागू होता है; text-typed /... commands और सामान्य chat turns अब भी configured group default का पालन करते हैं।

संदर्भ दृश्यता और allowlists

समूह सुरक्षा में दो अलग नियंत्रण शामिल हैं:

• Trigger authorization: एजेंट को कौन trigger कर सकता है (groupPolicy, groups, groupAllowFrom, channel-specific allowlists)।
• Context visibility: मॉडल में कौन सा supplemental context डाला जाता है (reply text, quotes, thread history, forwarded metadata)।

डिफ़ॉल्ट रूप से, OpenClaw सामान्य चैट व्यवहार को प्राथमिकता देता है और context को अधिकांशतः जैसा प्राप्त हुआ वैसा रखता है। इसका अर्थ है कि allowlists मुख्य रूप से तय करते हैं कि actions कौन trigger कर सकता है, न कि हर quoted या historical snippet के लिए सार्वभौमिक redaction boundary।

यदि आप चाहते हैं...

Reusable sender allowlists के लिए, Access groups देखें।

Session keys

• समूह sessions agent:<agentId>:<channel>:group:<id> session keys उपयोग करते हैं (rooms/channels agent:<agentId>:<channel>:channel:<id> उपयोग करते हैं)।
• Telegram forum topics समूह id में :topic:<threadId> जोड़ते हैं ताकि हर topic का अपना session हो।
• Direct chats main session उपयोग करते हैं (या configured होने पर per-sender)।
• समूह sessions के लिए Heartbeats छोड़ दिए जाते हैं।

पैटर्न: व्यक्तिगत DMs + सार्वजनिक समूह (single agent)

हाँ — यह अच्छी तरह काम करता है यदि आपका "personal" traffic DMs है और आपका "public" traffic groups है।

कारण: single-agent mode में, DMs आमतौर पर main session key (agent:main:main) में जाते हैं, जबकि groups हमेशा non-main session keys (agent:main:<channel>:group:<id>) उपयोग करते हैं। यदि आप mode: "non-main" के साथ sandboxing सक्षम करते हैं, तो वे group sessions configured sandbox backend में चलते हैं जबकि आपका main DM session on-host रहता है। यदि आप कोई backend नहीं चुनते, तो Docker डिफ़ॉल्ट backend है।

इससे आपको एक agent "brain" (shared workspace + memory) मिलता है, लेकिन दो execution postures:

• DMs: full tools (host)
• Groups: sandbox + restricted tools

{  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"],      },    },  },}

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

संबंधित:

• Configuration keys और defaults: Gateway configuration
• कोई tool क्यों blocked है, debug करना: Sandbox vs Tool Policy vs Elevated
• Bind mounts details: Sandboxing

Display labels

• UI labels उपलब्ध होने पर displayName उपयोग करते हैं, जिसे <channel>:<token> के रूप में format किया जाता है।
• #room rooms/channels के लिए reserved है; group chats g-<slug> उपयोग करते हैं (lowercase, spaces -> -, #@+._- रखें)।

Group policy

प्रति चैनल group/room messages कैसे handled होते हैं, नियंत्रित करें:

{  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 },      },    },  },}

त्वरित मानसिक मॉडल (समूह संदेशों के लिए मूल्यांकन क्रम):

Mention gating (डिफ़ॉल्ट)

समूह संदेशों के लिए mention आवश्यक होता है, जब तक कि प्रति समूह उसे override न किया गया हो। डिफ़ॉल्ट *.groups."*" के अंतर्गत प्रति subsystem रहते हैं।

जब channel reply metadata का समर्थन करता है, तो bot संदेश का उत्तर देना implicit mention माना जाता है। जिन channels में quote metadata उपलब्ध होता है, वहां bot संदेश को quote करना भी implicit mention माना जा सकता है। मौजूदा built-in मामलों में Telegram, WhatsApp, Slack, Discord, Microsoft Teams, और ZaloUser शामिल हैं।

{  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,        },      },    ],  },}

कॉन्फ़िगर किए गए mention patterns को scope करें

कॉन्फ़िगर किए गए mentionPatterns regex fallback triggers हैं। उनका उपयोग तब करें जब platform कोई native bot mention expose नहीं करता, या जब आप चाहते हों कि plain text जैसे openclaw: mention माना जाए। Native platform mentions अलग हैं: जब Discord, Slack, Telegram, Matrix, या कोई अन्य channel यह साबित कर सकता है कि संदेश ने bot को स्पष्ट रूप से mention किया है, तो वह native mention फिर भी trigger करता है, भले ही कॉन्फ़िगर किए गए regex patterns deny किए गए हों।

डिफ़ॉल्ट रूप से, कॉन्फ़िगर किए गए mention patterns हर उस जगह लागू होते हैं जहां वह channel provider और conversation facts को mention detection में पास करता है। broad patterns को हर समूह में agent को जगाने से रोकने के लिए, उन्हें प्रति channel channels.<channel>.mentionPatterns के साथ scope करें।

जब regex mention patterns किसी channel के लिए डिफ़ॉल्ट रूप से बंद होने चाहिए, तो mode: "deny" का उपयोग करें, फिर specific rooms में allowIn के साथ opt in करें:

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

जब regex mention patterns व्यापक रूप से लागू होने चाहिए, तो डिफ़ॉल्ट mode: "allow" का उपयोग करें (या mode छोड़ दें), फिर शोर-भरे rooms में उन्हें denyIn के साथ बंद करें:

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

नीति समाधान:

आज समर्थित scoped रेगेक्स नीति:

Account-level चैनल कॉन्फ़िग वही नीति channels.<channel>.accounts.<accountId>.mentionPatterns के अंतर्गत सेट कर सकते हैं, जब वह चैनल कई खातों का समर्थन करता है। उस खाते के लिए account नीति top-level चैनल नीति पर प्राथमिकता लेती है।

समूह/चैनल tool restrictions (वैकल्पिक)

कुछ चैनल कॉन्फ़िग यह सीमित करने का समर्थन करते हैं कि किसी विशिष्ट group/room/channel के अंदर कौन से tools उपलब्ध हैं।

• tools: पूरे समूह के लिए tools को allow/deny करें।
• toolsBySender: समूह के भीतर प्रति-sender overrides। स्पष्ट key prefixes का उपयोग करें: channel:<channelId>:<senderId>, id:<senderId>, e164:<phone>, username:<handle>, name:<displayName>, और "*" wildcard। Channel ids canonical OpenClaw channel ids का उपयोग करते हैं; teams जैसे aliases msteams में normalize होते हैं। Legacy unprefixed keys अभी भी स्वीकार की जाती हैं और केवल id: के रूप में matched होती हैं।

Resolution order (सबसे specific जीतता है):

उदाहरण (Telegram):

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

Group allowlists

जब channels.whatsapp.groups, channels.telegram.groups, या channels.imessage.groups कॉन्फ़िगर किया जाता है, तो keys group allowlist के रूप में काम करती हैं। सभी groups को allow करने के लिए "*" का उपयोग करें, साथ ही default mention behavior सेट करना जारी रखें।

सामान्य उद्देश्य (कॉपी/पेस्ट):

{  channels: { whatsapp: { groupPolicy: "disabled" } },}

{  channels: {    whatsapp: {      groups: {        "123@g.us": { requireMention: true },        "456@g.us": { requireMention: false },      },    },  },}

{  channels: {    whatsapp: {      groups: { "*": { requireMention: true } },    },  },}

{  channels: {    whatsapp: {      groupPolicy: "allowlist",      groupAllowFrom: ["+15551234567"],      groups: { "*": { requireMention: true } },    },  },}

सक्रियण (केवल स्वामी)

समूह स्वामी प्रति-समूह सक्रियण टॉगल कर सकते हैं:

• /activation mention
• /activation always

स्वामी channels.whatsapp.allowFrom से निर्धारित होता है (या सेट न होने पर बॉट के अपने E.164 से)। कमांड को अलग संदेश के रूप में भेजें। अन्य सतहें अभी /activation को अनदेखा करती हैं।

संदर्भ फ़ील्ड

समूह इनबाउंड पेलोड सेट करते हैं:

• ChatType=group
• GroupSubject (यदि ज्ञात हो)
• GroupMembers (यदि ज्ञात हो)
• WasMentioned (mention gating परिणाम)
• Telegram फ़ोरम विषयों में MessageThreadId और IsForum भी शामिल होते हैं।

एजेंट सिस्टम प्रॉम्प्ट में नए समूह सत्र के पहले turn पर समूह परिचय शामिल होता है। यह मॉडल को मनुष्य की तरह जवाब देने, खाली पंक्तियों को कम रखने और सामान्य चैट spacing का पालन करने, और literal \n sequences टाइप करने से बचने की याद दिलाता है। गैर-Telegram समूह Markdown tables को भी हतोत्साहित करते हैं; Telegram rich-text guidance Telegram चैनल प्रॉम्प्ट से आती है। चैनल-स्रोत समूह नाम और सहभागी labels fenced untrusted metadata के रूप में render किए जाते हैं, inline system instructions के रूप में नहीं।

iMessage विशेषताएँ

• routing या allowlisting करते समय chat_id:<id> को प्राथमिकता दें।
• chats सूचीबद्ध करें: imsg chats --limit 20।
• समूह उत्तर हमेशा उसी chat_id पर वापस जाते हैं।

WhatsApp सिस्टम प्रॉम्प्ट

canonical WhatsApp सिस्टम प्रॉम्प्ट नियमों के लिए WhatsApp देखें, जिसमें समूह और direct prompt resolution, wildcard behavior, और account override semantics शामिल हैं।

WhatsApp विशेषताएँ

WhatsApp-only behavior (history injection, mention handling details) के लिए समूह संदेश देखें।

संबंधित

• Broadcast समूह
• चैनल routing
• समूह संदेश
• Pairing