Skip to main content
“पेयरिंग” OpenClaw का स्पष्ट पहुँच-अनुमोदन चरण है। इसका उपयोग दो स्थानों पर किया जाता है:
  1. DM पेयरिंग (बॉट से बात करने की अनुमति किसे है)
  2. Node पेयरिंग (किन डिवाइसों/नोड्स को Gateway नेटवर्क में शामिल होने की अनुमति है)
सुरक्षा संदर्भ: सुरक्षा

​
1) DM पेयरिंग (इनबाउंड चैट पहुँच)

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

​
Control UI से अनुमोदन करें

Settings → Channels → DM access requests खोलें। कतार उन सभी कॉन्फ़िगर किए गए चैनल अकाउंट के लंबित अनुरोधों को एक साथ दिखाती है, जिनकी DM नीति pairing है। चैनल या अकाउंट के अनुसार फ़िल्टर करें, प्रेषक ID और मेटाडेटा की समीक्षा करें, फिर Approve चुनें। अनुमोदन केवल डायरेक्ट-मैसेज पहुँच देता है। यह समूह पहुँच नहीं देता। समर्थित होने पर अनुमोदन संवाद ये स्पष्ट विकल्प भी प्रदान करता है:
  • अनुमोदन के बाद अनुरोधकर्ता को सूचित करें
  • इस प्रेषक को पहला कमांड स्वामी भी बनाएँ, यह केवल तब दिखता है जब कोई कमांड स्वामी मौजूद न हो और Control UI सत्र के पास operator.admin हो
किसी लंबित अनुरोध को अनुमोदित किए बिना हटाने के लिए Dismiss चुनें। निरस्तीकरण स्थायी अवरोध नहीं है; प्रेषक बाद में फिर से पहुँच का अनुरोध कर सकता है।

​
CLI से अनुमोदन करें

उसी चैनल पर अनुरोधकर्ता को बताने के लिए --notify जोड़ें। एकाधिक अकाउंट वाले चैनल --account <id> लेते हैं। Control UI के स्पष्ट चेकबॉक्स के विपरीत, जब कोई कमांड स्वामी कॉन्फ़िगर नहीं होता, तो CLI commands.ownerAllowFrom को स्वचालित रूप से बूटस्ट्रैप करता है और telegram:123456789 जैसी प्रविष्टि का उपयोग करता है। इससे पहली बार किए जाने वाले सेटअप को विशेषाधिकार-प्राप्त कमांड और exec अनुमोदन प्रॉम्प्ट के लिए एक स्पष्ट स्वामी मिलता है। स्वामी मौजूद होने के बाद, बाद के पेयरिंग अनुमोदन केवल DM पहुँच देते हैं; वे और स्वामी नहीं जोड़ते।
WhatsApp का लॉगिन QR किसी WhatsApp अकाउंट को OpenClaw से लिंक करता है। DM पहुँच अनुरोध उस अकाउंट को संदेश भेजने वाले लोगों को अनुमोदित करते हैं। ये अलग-अलग प्रवाह हैं।
समर्थित चैनल (पेयरिंग घोषित करने वाला कोई भी इंस्टॉल किया गया चैनल plugin; openclaw-weixin जैसे बाहरी plugins और जोड़ सकते हैं): discord, feishu, googlechat, imessage, irc, line, matrix, mattermost, msteams, nextcloud-talk, nostr, signal, slack, sms, synology-chat, telegram, twitch, whatsapp, zalo, zalouser।

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

जब विश्वसनीय प्रेषकों का वही सेट एकाधिक संदेश चैनलों या DM और समूह, दोनों की अनुमति-सूचियों पर लागू होना चाहिए, तब शीर्ष-स्तरीय accessGroups का उपयोग करें। स्थिर समूह type: "message.senders" का उपयोग करते हैं और चैनल अनुमति-सूचियों से accessGroup:<name> द्वारा संदर्भित किए जाते हैं:
पहुँच समूहों का विस्तृत दस्तावेज़ यहाँ उपलब्ध है: पहुँच समूह

​
स्थिति कहाँ रहती है

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

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

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

​
Control UI से पेयर करें (अनुशंसित)

operator.admin पहुँच वाले पहले से कनेक्ट किए गए Control UI सत्र का उपयोग करें:
  1. Control UI खोलें और Settings → Devices पर जाएँ।
  2. Devices पृष्ठ पर Pair mobile device क्लिक करें।
  3. Full access (recommended) बनाए रखें या प्रशासनिक Gateway नियंत्रणों को छोड़ने के लिए Limited access चुनें।
  4. Create setup code क्लिक करें।
  5. अपने फ़ोन पर OpenClaw ऐप → Settings → Gateway खोलें।
  6. QR कोड स्कैन करें या सेटअप कोड पेस्ट करें, फिर कनेक्ट करें।
आधिकारिक OpenClaw iOS और Android ऐप तब स्वचालित रूप से अनुमोदित हो जाते हैं, जब उनका सेटअप-कोड मेटाडेटा मेल खाता है। यदि Pending approval कोई अनुरोध दिखाता है (उदाहरण के लिए, किसी गैर-आधिकारिक क्लाइंट या मेल न खाने वाले मेटाडेटा के लिए), तो उसे अनुमोदित करने से पहले उसकी भूमिका और स्कोप की समीक्षा करें। वर्तमान Control UI सत्र के पास प्रशासक पहुँच न होने पर बटन अक्षम रहता है। ऐसी स्थिति में Gateway होस्ट से नीचे दिए गए CLI अनुमोदन प्रवाह का उपयोग करें।

​
Telegram के माध्यम से पेयर करें

यदि आप device-pair plugin का उपयोग करते हैं, तो पहली बार की डिवाइस पेयरिंग पूरी तरह Telegram से कर सकते हैं:
  1. Telegram में अपने बॉट को संदेश भेजें: /pair
  2. बॉट दो संदेशों के साथ उत्तर देता है: एक निर्देश संदेश और एक अलग सेटअप कोड संदेश (Telegram में आसानी से कॉपी/पेस्ट करने योग्य)।
  3. अपने फ़ोन पर OpenClaw iOS ऐप → Settings → Gateway खोलें।
  4. QR कोड (/pair qr) स्कैन करें या सेटअप कोड पेस्ट करके कनेक्ट करें।
  5. आधिकारिक मोबाइल ऐप स्वचालित रूप से कनेक्ट हो जाता है। यदि /pair pending कोई अनुरोध दिखाता है, तो उसे अनुमोदित करने से पहले उसकी भूमिका और स्कोप की समीक्षा करें।
सेटअप कोड base64-एन्कोडेड JSON पेलोड है, जिसमें ये शामिल होते हैं:
  • url: Gateway WebSocket URL (ws://... या wss://...)
  • urls: उपलब्ध होने पर क्रमबद्ध LAN/Tailnet रूट, जिन्हें मोबाइल ऐप आज़मा सकता है
  • bootstrapToken: आरंभिक पेयरिंग हैंडशेक के लिए एकल-उपयोग बूटस्ट्रैप टोकन; Gateway इसे 10 मिनट बाद समाप्त कर देता है
पेयरिंग पूरी होने पर अप्रयुक्त सेटअप कोड अमान्य करने के लिए /pair cleanup चलाएँ। उस बूटस्ट्रैप टोकन में अंतर्निहित पेयरिंग बूटस्ट्रैप प्रोफ़ाइल होती है:
  • एक सुरक्षित wss:// सेटअप (या समान-होस्ट लूपबैक) डिफ़ॉल्ट रूप से node और पूर्ण नेटिव-मोबाइल operator पहुँच देता है
  • हस्तांतरित node टोकन scopes: [] बना रहता है
  • डिफ़ॉल्ट हस्तांतरित operator टोकन में operator.admin, operator.approvals, operator.read, operator.talk.secrets, और operator.write शामिल हैं
  • Control UI Limited access और openclaw qr --limited, अन्य ऑपरेटर स्कोप बनाए रखते हुए operator.admin को छोड़ देते हैं
  • प्लेनटेक्स्ट LAN ws:// सेटअप स्वचालित रूप से उसी सीमित प्रोफ़ाइल का उपयोग करता है; पूर्ण पहुँच के लिए wss:// या Tailscale Serve कॉन्फ़िगर करें और नया कोड जनरेट करें
  • बाद का टोकन रोटेशन/निरस्तीकरण डिवाइस के अनुमोदित भूमिका अनुबंध और कॉलर सत्र के ऑपरेटर स्कोप, दोनों द्वारा सीमित रहता है
सेटअप कोड के मान्य रहने तक उसे पासवर्ड की तरह सुरक्षित रखें। iOS और Android के Settings → Gateway पृष्ठ Full या Limited पहुँच दिखाते हैं। सीमित फ़ोन को अपग्रेड करने के लिए पहले सुरक्षित wss:// या Tailscale Serve रूट कॉन्फ़िगर करें, फिर नया पूर्ण-पहुँच सेटअप कोड जनरेट करें, उस सेटिंग पृष्ठ पर उसे स्कैन या पेस्ट करें और दोबारा कनेक्ट करें। Tailscale, सार्वजनिक या अन्य रिमोट मोबाइल पेयरिंग के लिए Tailscale Serve/Funnel या किसी अन्य wss:// Gateway URL का उपयोग करें। प्लेनटेक्स्ट ws:// सेटअप कोड केवल लूपबैक, निजी LAN पतों, .local Bonjour होस्ट और Android एमुलेटर होस्ट के लिए स्वीकार किए जाते हैं। गैर-लूपबैक प्लेनटेक्स्ट रूट को सीमित पहुँच मिलती है। Tailnet CGNAT पते, .ts.net नाम और सार्वजनिक होस्ट अब भी QR/सेटअप-कोड जारी किए जाने से पहले सुरक्षित रूप से विफल होते हैं। gateway.bind=lan सेटअप URL के लिए OpenClaw उन स्थायी Tailscale Serve HTTPS रूट का पता लगाता है, जो सक्रिय Gateway के लूपबैक पोर्ट को प्रॉक्सी करते हैं और उन्हें LAN रूट के साथ विज्ञापित करता है। सेटअप कमांड यह फ़ॉलबैक केवल lan के लिए जोड़ता है; custom और tailnet अपने स्पष्ट रूप से विज्ञापित रूट बनाए रखते हैं। iOS ऐप विज्ञापित रूट को क्रम से जाँचता है और पहले पहुँच योग्य एंडपॉइंट को सहेजता है।

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

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

​
वैकल्पिक विश्वसनीय-CIDR Node स्वतः-अनुमोदन

डिवाइस पेयरिंग डिफ़ॉल्ट रूप से मैन्युअल रहती है। सख्ती से नियंत्रित नोड नेटवर्क के लिए, आप स्पष्ट CIDR या सटीक IP के साथ पहली बार के नोड स्वतः-अनुमोदन को सक्षम कर सकते हैं:
यह केवल बिना किसी अनुरोधित स्कोप वाले नए role: node पेयरिंग अनुरोधों पर लागू होता है। ऑपरेटर, ब्राउज़र, Control UI और WebChat क्लाइंट को अब भी मैन्युअल अनुमोदन की आवश्यकता होती है। भूमिका, स्कोप, मेटाडेटा और सार्वजनिक-कुंजी परिवर्तनों के लिए भी मैन्युअल अनुमोदन आवश्यक रहता है।

​
Node पेयरिंग स्थिति संग्रहण

साझा SQLite स्थिति डेटाबेस में ~/.openclaw/state/openclaw.sqlite पर संग्रहीत:
  • लंबित डिवाइस पेयरिंग अनुरोध (अल्पकालिक; वे 5 मिनट बाद समाप्त हो जाते हैं)
  • पेयर्ड डिवाइस + टोकन
पुराने Gateway इस स्थिति को ~/.openclaw/devices/*.json में रखते थे; उन फ़ाइलों को Gateway शुरू होने पर SQLite में आयात किया जाता है और .migrated प्रत्यय के साथ संग्रहित किया जाता है।

​
टिप्पणियाँ

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

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