मुख्य सामग्री पर जाएं
“पेयरिंग” OpenClaw का स्पष्ट एक्सेस अनुमोदन चरण है। इसका उपयोग दो जगहों पर होता है:
  1. DM पेयरिंग (किसे बॉट से बात करने की अनुमति है)
  2. Node पेयरिंग (किन डिवाइस/नोड को gateway नेटवर्क से जुड़ने की अनुमति है)
सुरक्षा संदर्भ: सुरक्षा

​
1) DM पेयरिंग (इनबाउंड चैट एक्सेस)

जब कोई चैनल DM नीति pairing के साथ कॉन्फ़िगर होता है, तो अज्ञात प्रेषकों को एक छोटा कोड मिलता है और उनका संदेश तब तक प्रोसेस नहीं किया जाता जब तक आप अनुमोदन नहीं देते। डिफ़ॉल्ट DM नीतियां यहां दस्तावेज़ित हैं: सुरक्षा dmPolicy: "open" केवल तब सार्वजनिक होता है जब प्रभावी DM अनुमति-सूची में "*" शामिल हो। सार्वजनिक-ओपन कॉन्फ़िग के लिए सेटअप और सत्यापन में उस वाइल्डकार्ड की आवश्यकता होती है। यदि मौजूदा स्टेट में ठोस allowFrom प्रविष्टियों के साथ open है, तो रनटाइम अभी भी केवल उन प्रेषकों को स्वीकार करता है, और पेयरिंग-स्टोर अनुमोदन open एक्सेस को विस्तृत नहीं करते। पेयरिंग कोड:
  • 8 अक्षर, अपरकेस, कोई अस्पष्ट अक्षर नहीं (0O1I)।
  • 1 घंटे बाद समाप्त हो जाते हैं। बॉट पेयरिंग संदेश केवल तब भेजता है जब नया अनुरोध बनाया जाता है (लगभग हर प्रेषक के लिए प्रति घंटे एक बार)।
  • लंबित DM पेयरिंग अनुरोध डिफ़ॉल्ट रूप से प्रति चैनल 3 तक सीमित हैं; अतिरिक्त अनुरोध तब तक अनदेखे किए जाते हैं जब तक कोई समाप्त या अनुमोदित नहीं हो जाता।

​
प्रेषक को अनुमोदित करें

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>
यदि अभी तक कोई कमांड स्वामी कॉन्फ़िगर नहीं है, तो DM पेयरिंग कोड को अनुमोदित करना commands.ownerAllowFrom को अनुमोदित प्रेषक, जैसे telegram:123456789, से भी बूटस्ट्रैप करता है। यह पहली बार के सेटअप को विशेषाधिकार प्राप्त कमांड और exec अनुमोदन प्रॉम्प्ट के लिए एक स्पष्ट स्वामी देता है। स्वामी मौजूद होने के बाद, बाद के पेयरिंग अनुमोदन केवल DM एक्सेस देते हैं; वे और स्वामी नहीं जोड़ते। समर्थित चैनल: discord, feishu, googlechat, imessage, irc, line, matrix, mattermost, msteams, nextcloud-talk, nostr, openclaw-weixin, signal, slack, synology-chat, telegram, twitch, whatsapp, zalo, zalouser।

​
पुन: उपयोग योग्य प्रेषक समूह

जब एक ही विश्वसनीय प्रेषक सेट कई संदेश चैनलों पर या DM और समूह अनुमति-सूचियों दोनों पर लागू होना चाहिए, तो शीर्ष-स्तरीय accessGroups का उपयोग करें। स्थिर समूह type: "message.senders" का उपयोग करते हैं और चैनल अनुमति-सूचियों से accessGroup:<name> के साथ संदर्भित होते हैं: 
{
  accessGroups: {
    operators: {
      type: "message.senders",
      members: {
        discord: ["discord:123456789012345678"],
        telegram: ["987654321"],
        whatsapp: ["+15551234567"],
      },
    },
  },
  channels: {
    telegram: { dmPolicy: "allowlist", allowFrom: ["accessGroup:operators"] },
    whatsapp: { groupPolicy: "allowlist", groupAllowFrom: ["accessGroup:operators"] },
  },
}
एक्सेस समूहों का विस्तृत दस्तावेज़ यहां है: एक्सेस समूह

​
स्टेट कहां रहता है

~/.openclaw/credentials/ के अंतर्गत संग्रहीत:
  • लंबित अनुरोध: <channel>-pairing.json
  • अनुमोदित अनुमति-सूची स्टोर:
    • डिफ़ॉल्ट खाता: <channel>-allowFrom.json
    • गैर-डिफ़ॉल्ट खाता: <channel>-<accountId>-allowFrom.json
खाता स्कोपिंग व्यवहार:
  • गैर-डिफ़ॉल्ट खाते केवल अपनी स्कोप की गई अनुमति-सूची फ़ाइल पढ़ते/लिखते हैं।
  • डिफ़ॉल्ट खाता चैनल-स्कोप वाली अनस्कोप्ड अनुमति-सूची फ़ाइल का उपयोग करता है।
इन्हें संवेदनशील मानें (ये आपके assistant तक एक्सेस को नियंत्रित करते हैं)।
पेयरिंग अनुमति-सूची स्टोर DM एक्सेस के लिए है। समूह प्राधिकरण अलग है। DM पेयरिंग कोड को अनुमोदित करने से वह प्रेषक अपने-आप समूह कमांड चलाने या समूहों में बॉट को नियंत्रित करने की अनुमति नहीं पाता। पहला-स्वामी बूटस्ट्रैप अलग कॉन्फ़िग स्टेट है commands.ownerAllowFrom में, और समूह चैट डिलीवरी अभी भी चैनल की समूह अनुमति-सूचियों का पालन करती है (उदाहरण के लिए groupAllowFrom, groups, या चैनल के अनुसार प्रति-समूह या प्रति-विषय ओवरराइड)।

​
2) Node डिवाइस पेयरिंग (iOS/Android/macOS/headless नोड)

नोड Gateway से role: node वाले डिवाइस के रूप में जुड़ते हैं। Gateway एक डिवाइस पेयरिंग अनुरोध बनाता है जिसे अनुमोदित किया जाना चाहिए।

​
Telegram के माध्यम से पेयर करें (iOS के लिए अनुशंसित)

यदि आप device-pair Plugin का उपयोग करते हैं, तो आप पहली बार की डिवाइस पेयरिंग पूरी तरह Telegram से कर सकते हैं:
  1. Telegram में, अपने बॉट को संदेश भेजें: /pair
  2. बॉट दो संदेशों के साथ उत्तर देता है: एक निर्देश संदेश और एक अलग सेटअप कोड संदेश (Telegram में कॉपी/पेस्ट करना आसान)।
  3. अपने फ़ोन पर, OpenClaw iOS ऐप खोलें → Settings → Gateway।
  4. QR कोड स्कैन करें या सेटअप कोड पेस्ट करें और कनेक्ट करें।
  5. फिर Telegram में: /pair pending (अनुरोध ID, भूमिका और दायरों की समीक्षा करें), फिर अनुमोदित करें।
सेटअप कोड एक base64-एन्कोडेड JSON पेलोड है जिसमें शामिल है:
  • url: Gateway WebSocket URL (ws://... या wss://...)
  • bootstrapToken: प्रारंभिक पेयरिंग हैंडशेक के लिए उपयोग किया जाने वाला अल्पकालिक सिंगल-डिवाइस बूटस्ट्रैप टोकन
वह बूटस्ट्रैप टोकन अंतर्निहित पेयरिंग बूटस्ट्रैप प्रोफ़ाइल ले जाता है:
  • अंतर्निहित सेटअप प्रोफ़ाइल केवल ताज़ा QR/सेटअप-कोड बेसलाइन की अनुमति देती है: node और सीमित operator हैंडऑफ़
  • हैंड-ऑफ़ किया गया node टोकन scopes: [] ही रहता है
  • हैंड-ऑफ़ किया गया operator टोकन operator.approvals, operator.read, और operator.write तक सीमित है
  • operator.admin और operator.pairing QR/सेटअप-कोड बूटस्ट्रैप द्वारा नहीं दिए जाते; इनके लिए अलग से अनुमोदित operator पेयरिंग या टोकन फ़्लो चाहिए
  • बाद का टोकन रोटेशन/निरस्तीकरण डिवाइस के अनुमोदित भूमिका अनुबंध और कॉलर सत्र के operator दायरों, दोनों से सीमित रहता है
सेटअप कोड को वैध रहने तक पासवर्ड जैसा मानें। Tailscale, सार्वजनिक, या अन्य रिमोट मोबाइल पेयरिंग के लिए, Tailscale Serve/Funnel या किसी अन्य wss:// Gateway URL का उपयोग करें। प्लेनटेक्स्ट ws:// सेटअप कोड केवल loopback, निजी LAN पतों, .local Bonjour होस्ट, और Android emulator होस्ट के लिए स्वीकार किए जाते हैं। Tailnet CGNAT पते, .ts.net नाम, और सार्वजनिक होस्ट अभी भी QR/सेटअप-कोड जारी होने से पहले fail closed होते हैं।

​
Node डिवाइस को अनुमोदित करें

openclaw devices list
openclaw devices approve <requestId>
openclaw devices reject <requestId>
जब स्पष्ट अनुमोदन इसलिए अस्वीकार होता है क्योंकि अनुमोदन देने वाला paired-device सत्र pairing-only दायरे के साथ खोला गया था, तो CLI उसी अनुरोध को operator.admin के साथ फिर से आज़माता है। इससे मौजूदा admin-सक्षम paired device, devices/paired.json को हाथ से संपादित किए बिना, नई Control UI/ब्राउज़र पेयरिंग को पुनर्प्राप्त कर सकता है। Gateway फिर भी पुनः आज़माए गए कनेक्शन को सत्यापित करता है; जो टोकन operator.admin के साथ प्रमाणित नहीं हो सकते, वे अवरुद्ध रहते हैं। यदि वही डिवाइस अलग auth विवरणों के साथ फिर कोशिश करता है (उदाहरण के लिए अलग भूमिका/दायरे/public key), तो पिछला लंबित अनुरोध प्रतिस्थापित हो जाता है और नया requestId बनाया जाता है।
पहले से paired डिवाइस को चुपचाप व्यापक एक्सेस नहीं मिलता। यदि वह अधिक दायरों या व्यापक भूमिका के लिए फिर से कनेक्ट करता है, तो OpenClaw मौजूदा अनुमोदन को जैसा है वैसा रखता है और एक नया लंबित अपग्रेड अनुरोध बनाता है। अनुमोदन देने से पहले वर्तमान में अनुमोदित एक्सेस की नए अनुरोधित एक्सेस से तुलना करने के लिए openclaw devices list का उपयोग करें।

​
वैकल्पिक trusted-CIDR Node auto-approve

डिवाइस पेयरिंग डिफ़ॉल्ट रूप से मैनुअल रहती है। कड़ाई से नियंत्रित नोड नेटवर्क के लिए, आप स्पष्ट CIDR या सटीक IP के साथ पहली बार के नोड auto-approval में opt in कर सकते हैं: 
{
  gateway: {
    nodes: {
      pairing: {
        autoApproveCidrs: ["192.168.1.0/24"],
      },
    },
  },
}
यह केवल ताज़ा role: node पेयरिंग अनुरोधों पर लागू होता है जिनमें कोई अनुरोधित दायरे नहीं होते। Operator, ब्राउज़र, Control UI, और WebChat क्लाइंट को अभी भी मैनुअल अनुमोदन चाहिए। भूमिका, दायरा, मेटाडेटा, और public-key बदलावों को अभी भी मैनुअल अनुमोदन चाहिए।

​
Node पेयरिंग स्टेट स्टोरेज

~/.openclaw/devices/ के अंतर्गत संग्रहीत:
  • pending.json (अल्पकालिक; लंबित अनुरोध समाप्त हो जाते हैं)
  • paired.json (paired डिवाइस + टोकन)

​
नोट्स

  • legacy node.pair.* API (CLI: openclaw nodes pending|approve|reject|remove|rename) एक अलग gateway-स्वामित्व वाला पेयरिंग स्टोर है। WS नोड को अभी भी डिवाइस पेयरिंग चाहिए।
  • पेयरिंग रिकॉर्ड अनुमोदित भूमिकाओं के लिए टिकाऊ सत्य स्रोत है। Active डिवाइस टोकन उसी अनुमोदित भूमिका सेट तक सीमित रहते हैं; अनुमोदित भूमिकाओं के बाहर कोई इधर-उधर की टोकन प्रविष्टि नया एक्सेस नहीं बनाती।

​
संबंधित दस्तावेज़