Configuration
पेयरिंग
"पेयरिंग" OpenClaw का स्पष्ट पहुँच-अनुमोदन चरण है। इसका उपयोग दो स्थानों पर किया जाता है:
- DM पेयरिंग (बॉट से बात करने की अनुमति किसे है)
- 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 से अनुमोदन करें
openclaw pairing list telegramopenclaw pairing approve telegram <CODE>उसी चैनल पर अनुरोधकर्ता को बताने के लिए --notify जोड़ें। एकाधिक अकाउंट वाले चैनल
--account <id> लेते हैं।
Control UI के स्पष्ट चेकबॉक्स के विपरीत, जब कोई कमांड स्वामी कॉन्फ़िगर नहीं होता, तो CLI
commands.ownerAllowFrom को स्वचालित रूप से बूटस्ट्रैप करता है और
telegram:123456789 जैसी प्रविष्टि का उपयोग करता है। इससे पहली बार किए जाने वाले सेटअप को
विशेषाधिकार-प्राप्त कमांड और exec अनुमोदन प्रॉम्प्ट के लिए एक स्पष्ट स्वामी मिलता है। स्वामी मौजूद होने के बाद,
बाद के पेयरिंग अनुमोदन केवल 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> द्वारा संदर्भित किए जाते हैं:
{ 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"] }, },}पहुँच समूहों का विस्तृत दस्तावेज़ यहाँ उपलब्ध है: पहुँच समूह
स्थिति कहाँ रहती है
साझा 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 डेटाबेस को
संवेदनशील मानें, क्योंकि ये पंक्तियाँ आपके सहायक की पहुँच नियंत्रित करती हैं।
2) Node डिवाइस पेयरिंग (iOS/Android/macOS/हेडलेस नोड्स)
नोड्स role: node वाले डिवाइसों के रूप में Gateway से कनेक्ट होते हैं। Gateway
एक डिवाइस पेयरिंग अनुरोध बनाता है, जिसे अनुमोदित करना आवश्यक है।
Control UI से पेयर करें (अनुशंसित)
operator.admin पहुँच वाले पहले से कनेक्ट किए गए Control UI सत्र का उपयोग करें:
- Control UI खोलें और Settings → Devices पर जाएँ।
- Devices पृष्ठ पर Pair mobile device क्लिक करें।
- Full access (recommended) बनाए रखें या प्रशासनिक Gateway नियंत्रणों को छोड़ने के लिए Limited access चुनें।
- Create setup code क्लिक करें।
- अपने फ़ोन पर OpenClaw ऐप → Settings → Gateway खोलें।
- QR कोड स्कैन करें या सेटअप कोड पेस्ट करें, फिर कनेक्ट करें।
आधिकारिक OpenClaw iOS और Android ऐप तब स्वचालित रूप से अनुमोदित हो जाते हैं, जब उनका सेटअप-कोड मेटाडेटा मेल खाता है। यदि Pending approval कोई अनुरोध दिखाता है (उदाहरण के लिए, किसी गैर-आधिकारिक क्लाइंट या मेल न खाने वाले मेटाडेटा के लिए), तो उसे अनुमोदित करने से पहले उसकी भूमिका और स्कोप की समीक्षा करें।
वर्तमान Control UI सत्र के पास प्रशासक पहुँच न होने पर बटन अक्षम रहता है। ऐसी स्थिति में Gateway होस्ट से नीचे दिए गए CLI अनुमोदन प्रवाह का उपयोग करें।
Telegram के माध्यम से पेयर करें
यदि आप device-pair plugin का उपयोग करते हैं, तो पहली बार की डिवाइस पेयरिंग पूरी तरह Telegram से कर सकते हैं:
- Telegram में अपने बॉट को संदेश भेजें:
/pair - बॉट दो संदेशों के साथ उत्तर देता है: एक निर्देश संदेश और एक अलग सेटअप कोड संदेश (Telegram में आसानी से कॉपी/पेस्ट करने योग्य)।
- अपने फ़ोन पर OpenClaw iOS ऐप → Settings → Gateway खोलें।
- QR कोड (
/pair qr) स्कैन करें या सेटअप कोड पेस्ट करके कनेक्ट करें। - आधिकारिक मोबाइल ऐप स्वचालित रूप से कनेक्ट हो जाता है। यदि
/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 डिवाइस को अनुमोदित करें
openclaw devices listopenclaw devices approve <requestId>openclaw devices reject <requestId>जब किसी स्पष्ट अनुमोदन को इसलिए अस्वीकार किया जाता है क्योंकि अनुमोदन करने वाला पेयर्ड-डिवाइस सत्र
केवल-पेयरिंग स्कोप के साथ खोला गया था, तो CLI उसी अनुरोध को
operator.admin के साथ दोबारा आज़माता है। इससे प्रशासक-सक्षम मौजूदा पेयर्ड डिवाइस
पेयरिंग स्टोर को हाथ से संपादित किए बिना नई Control UI/ब्राउज़र पेयरिंग पुनर्प्राप्त कर सकता है।
Gateway फिर भी दोबारा आज़माए गए कनेक्शन को सत्यापित करता है; जो टोकन
operator.admin के साथ प्रमाणित नहीं हो सकते, वे अवरुद्ध रहते हैं।
यदि वही डिवाइस अलग प्रमाणीकरण विवरणों (उदाहरण के लिए अलग
भूमिका/स्कोप/सार्वजनिक कुंजी) के साथ दोबारा प्रयास करता है, तो पिछला लंबित अनुरोध अधिक्रमित हो जाता है और नया
requestId बनाया जाता है।
वैकल्पिक विश्वसनीय-CIDR Node स्वतः-अनुमोदन
डिवाइस पेयरिंग डिफ़ॉल्ट रूप से मैन्युअल रहती है। सख्ती से नियंत्रित नोड नेटवर्क के लिए, आप स्पष्ट CIDR या सटीक IP के साथ पहली बार के नोड स्वतः-अनुमोदन को सक्षम कर सकते हैं:
{ gateway: { nodes: { pairing: { autoApproveCidrs: ["192.168.1.0/24"], }, }, },}यह केवल बिना किसी अनुरोधित स्कोप वाले नए 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 युग्मन देखें।- युग्मन रिकॉर्ड अनुमोदित भूमिकाओं के लिए स्थायी सत्य स्रोत है। सक्रिय डिवाइस टोकन उस अनुमोदित भूमिका-समूह तक सीमित रहते हैं; अनुमोदित भूमिकाओं से बाहर की कोई असंबद्ध टोकन प्रविष्टि नई पहुँच नहीं बनाती।