openclaw devices

डिवाइस पेयरिंग अनुरोधों और डिवाइस-स्कोप वाले टोकनों को प्रबंधित करें।

सामान्य विकल्प

• --url <url>: Gateway WebSocket URL (कॉन्फ़िगर होने पर डिफ़ॉल्ट रूप से gateway.remote.url)
• --token <token>: Gateway टोकन (यदि आवश्यक हो)
• --password <password>: Gateway पासवर्ड (पासवर्ड प्रमाणीकरण)
• --timeout <ms>: RPC टाइमआउट
• --json: JSON आउटपुट (स्क्रिप्टिंग के लिए अनुशंसित)

कमांड

openclaw devices list

लंबित पेयरिंग अनुरोधों और पेयर किए गए डिवाइसों की सूची दिखाएँ।

openclaw devices listopenclaw devices list --json

पहले से पेयर किए गए डिवाइस के लंबित अनुरोध के लिए, आउटपुट डिवाइस की वर्तमान स्वीकृत पहुँच के पास अनुरोधित पहुँच दिखाता है, ताकि स्कोप/भूमिका अपग्रेड खोई हुई पेयरिंग जैसे दिखाई देने के बजाय स्पष्ट रहें।

पेयर किए गए डिवाइस के प्रदर्शन नाम इस प्राथमिकता क्रम का उपयोग करते हैं: ऑपरेटर लेबल (operatorLabel, devices rename से), फिर क्लाइंट displayName, फिर clientId, फिर deviceId।

openclaw devices approve [requestId] [--latest]

सटीक requestId द्वारा लंबित पेयरिंग अनुरोध स्वीकृत करें। requestId छोड़ने या --latest देने पर केवल नवीनतम लंबित अनुरोध का पूर्वावलोकन होता है और कमांड बाहर निकल जाता है (कोड 1); स्वीकृत करने के लिए सटीक अनुरोध ID के साथ दोबारा चलाएँ।

openclaw devices approveopenclaw devices approve <requestId>openclaw devices approve --latest

स्वीकृति व्यवहार:

• यदि डिवाइस पहले से पेयर है और अधिक व्यापक स्कोप या भूमिका का अनुरोध करता है, तो OpenClaw मौजूदा स्वीकृति बनाए रखता है और नया लंबित अपग्रेड अनुरोध बनाता है। स्वीकृत करने से पहले openclaw devices list में Requested और Approved की तुलना करें, या --latest से पूर्वावलोकन करें।
• node भूमिका या किसी अन्य गैर-ऑपरेटर भूमिका को स्वीकृत करने के लिए operator.admin आवश्यक है। ऑपरेटर-डिवाइस स्वीकृतियों के लिए operator.pairing पर्याप्त है, लेकिन केवल तब, जब अनुरोधित ऑपरेटर स्कोप कॉलर के अपने स्कोप के भीतर रहें। ऑपरेटर स्कोप देखें।
• यदि gateway.nodes.pairing.autoApproveCidrs कॉन्फ़िगर किया गया है, तो मेल खाने वाले क्लाइंट IP से पहली बार आने वाले role: node अनुरोध इस सूची में दिखाई देने से पहले स्वतः स्वीकृत हो सकते हैं। यह डिफ़ॉल्ट रूप से अक्षम है; ऑपरेटर/ब्राउज़र क्लाइंट या अपग्रेड अनुरोधों पर कभी लागू नहीं होता।
• gateway.nodes.pairing.sshVerify (डिफ़ॉल्ट रूप से चालू) पहली बार आने वाले role: node अनुरोधों को स्वतः स्वीकृत करता है, जब Gateway SSH के माध्यम से नोड होस्ट पर डिवाइस कुंजी सत्यापित करता है। इसलिए अनुरोध दिखाई देने के कुछ ही समय बाद स्वीकृत हो सकते हैं। SSH सत्यापन अक्षम करने के लिए sshVerify: false सेट करें; यह autoApproveCidrs से स्वतंत्र है, इसलिए केवल मैन्युअल पेयरिंग के लिए उसे भी अनसेट करें।

openclaw devices reject <requestId>

लंबित डिवाइस पेयरिंग अनुरोध अस्वीकार करें।

openclaw devices reject <requestId>

openclaw devices remove <deviceId>

पेयर किए गए किसी एक डिवाइस का रिकॉर्ड हटाएँ।

openclaw devices remove <deviceId>openclaw devices remove <deviceId> --json

पेयर किए गए डिवाइस टोकन से प्रमाणित कॉलर केवल अपने स्वयं के डिवाइस का रिकॉर्ड हटा सकता है। किसी अन्य डिवाइस को हटाने के लिए operator.admin आवश्यक है।

openclaw devices rename --device <id> --name <label>

पेयर किए गए डिवाइस को ऑपरेटर लेबल असाइन करें। लेबल स्वामी-पक्ष की स्थिति हैं: वे पेयरिंग सुधारों और भूमिका की पुनः स्वीकृतियों के बाद भी बने रहते हैं और स्थिर deviceId को नहीं बदलते।

openclaw devices rename --device <deviceId> --name "Kitchen Mac"openclaw devices rename --device <deviceId> --name "Kitchen Mac" --json

• --name आवश्यक है, इसके आगे-पीछे के रिक्त स्थान हटाए जाते हैं, यह खाली नहीं हो सकता और अधिकतम 64 वर्णों तक सीमित है।
• प्रदर्शन सतहें (CLI सूची, Control UI इन्वेंटरी) क्लाइंट द्वारा बताए गए प्रदर्शन नाम के बजाय ऑपरेटर लेबल को प्राथमिकता देती हैं।
• गैर-एडमिन पेयर-डिवाइस कॉलर केवल अपने स्वयं के डिवाइस का नाम बदल सकता है। किसी अन्य डिवाइस का नाम बदलने के लिए operator.admin आवश्यक है।

openclaw devices clear --yes [--pending]

पेयर किए गए डिवाइसों को सामूहिक रूप से साफ़ करें। यह --yes द्वारा नियंत्रित है।

openclaw devices clear --yesopenclaw devices clear --yes --pendingopenclaw devices clear --yes --pending --json

--pending सभी लंबित पेयरिंग अनुरोध भी अस्वीकार करता है।

openclaw devices rotate --device <id> --role <role> [--scope <scope...>]

किसी भूमिका के लिए डिवाइस टोकन रोटेट करें और वैकल्पिक रूप से उसके स्कोप अपडेट करें।

openclaw devices rotate --device <deviceId> --role operator --scope operator.read --scope operator.write

• लक्षित भूमिका उस डिवाइस के स्वीकृत पेयरिंग अनुबंध में पहले से मौजूद होनी चाहिए; रोटेशन नई अस्वीकृत भूमिका जारी नहीं कर सकता।
• --scope छोड़ने पर बाद के पुनः कनेक्शन में संग्रहीत टोकन के कैश किए गए स्वीकृत स्कोप दोबारा उपयोग होते हैं। स्पष्ट --scope मान देने पर भविष्य के कैश-टोकन पुनः कनेक्शन के लिए संग्रहीत स्कोप सेट बदल जाता है।
• गैर-एडमिन पेयर-डिवाइस कॉलर केवल अपने स्वयं के डिवाइस टोकन को रोटेट कर सकता है और लक्षित स्कोप सेट कॉलर के अपने ऑपरेटर स्कोप के भीतर रहना चाहिए; रोटेशन कॉलर के पास पहले से मौजूद टोकन से अधिक व्यापक टोकन न तो जारी कर सकता है, न बनाए रख सकता है।

रोटेशन मेटाडेटा JSON के रूप में लौटाता है। यदि कॉलर उस डिवाइस टोकन से प्रमाणित रहते हुए अपना टोकन रोटेट करता है, तो प्रतिक्रिया में प्रतिस्थापन टोकन शामिल होता है, ताकि क्लाइंट पुनः कनेक्ट करने से पहले उसे बनाए रख सके। साझा/एडमिन रोटेशन कभी भी बेयरर टोकन वापस नहीं दिखाते।

openclaw devices revoke --device <id> --role <role>

किसी भूमिका के लिए डिवाइस टोकन निरस्त करें।

openclaw devices revoke --device <deviceId> --role node

गैर-एडमिन पेयर-डिवाइस कॉलर केवल अपने स्वयं के डिवाइस टोकन को निरस्त कर सकता है। किसी अन्य डिवाइस का टोकन निरस्त करने के लिए operator.admin आवश्यक है। लक्षित स्कोप सेट भी कॉलर के अपने ऑपरेटर स्कोप के भीतर होना चाहिए; केवल पेयरिंग की अनुमति वाले कॉलर एडमिन/लेखन ऑपरेटर टोकन निरस्त नहीं कर सकते।

टिप्पणियाँ

• इन कमांड के लिए operator.pairing (या operator.admin) स्कोप आवश्यक है। गैर-ऑपरेटर डिवाइस भूमिकाओं के लिए हमेशा operator.admin आवश्यक है; ऑपरेटर स्कोप देखें।
• टोकन रोटेशन और निरस्तीकरण डिवाइस के स्वीकृत पेयरिंग भूमिका सेट और स्कोप आधार-रेखा के भीतर रहते हैं। कोई असंबद्ध कैश किया हुआ टोकन रिकॉर्ड टोकन-प्रबंधन लक्ष्य प्रदान नहीं करता।
• पेयर-डिवाइस टोकन सत्रों के लिए, विभिन्न डिवाइसों का प्रबंधन (remove, rename, rotate, revoke) केवल स्वयं तक सीमित है, जब तक कॉलर के पास operator.admin न हो।
• टोकन रोटेशन नया टोकन (संवेदनशील) लौटाता है — इसे गुप्त जानकारी की तरह संभालें।
• यदि स्थानीय लूपबैक पर पेयरिंग स्कोप उपलब्ध नहीं है और कोई स्पष्ट --url नहीं दिया गया है, तो list/approve स्थानीय पेयरिंग स्थिति पर फ़ॉलबैक कर सकते हैं।

टोकन विचलन पुनर्प्राप्ति चेकलिस्ट

इसका उपयोग तब करें, जब Control UI या अन्य क्लाइंट AUTH_TOKEN_MISMATCH, AUTH_DEVICE_TOKEN_MISMATCH या AUTH_SCOPE_MISMATCH के साथ लगातार विफल हो रहे हों।

1. वर्तमान Gateway टोकन स्रोत की पुष्टि करें:

   openclaw config get gateway.auth.token

2. पेयर किए गए डिवाइसों की सूची दिखाएँ और प्रभावित डिवाइस id पहचानें:

   openclaw devices list

3. प्रभावित डिवाइस के लिए ऑपरेटर टोकन रोटेट करें:

   openclaw devices rotate --device <deviceId> --role operator

4. यदि रोटेशन पर्याप्त नहीं है, तो पुरानी पेयरिंग हटाएँ और दोबारा स्वीकृत करें:

   openclaw devices remove <deviceId>openclaw devices listopenclaw devices approve <requestId>

5. वर्तमान साझा टोकन/पासवर्ड के साथ क्लाइंट कनेक्शन का पुनः प्रयास करें।

टिप्पणियाँ:

• सामान्य पुनः कनेक्शन प्रमाणीकरण प्राथमिकता: पहले स्पष्ट साझा टोकन/पासवर्ड, फिर स्पष्ट deviceToken, फिर संग्रहीत डिवाइस टोकन और अंत में बूटस्ट्रैप टोकन।
• विश्वसनीय AUTH_TOKEN_MISMATCH पुनर्प्राप्ति एक सीमित पुनः प्रयास के लिए साझा टोकन और संग्रहीत डिवाइस टोकन, दोनों को अस्थायी रूप से एक साथ भेज सकती है।
• AUTH_SCOPE_MISMATCH का अर्थ है कि डिवाइस टोकन पहचाना गया था, लेकिन उसमें अनुरोधित स्कोप सेट नहीं है; साझा Gateway प्रमाणीकरण बदलने से पहले पेयरिंग/स्कोप स्वीकृति अनुबंध ठीक करें।

संबंधित:

• डैशबोर्ड प्रमाणीकरण समस्या निवारण
• Gateway समस्या निवारण

Paperclip / openclaw_gateway की प्रथम-रन स्वीकृति

openclaw_gateway अडैप्टर के माध्यम से कनेक्ट होने वाले Paperclip एजेंट भी किसी अन्य नए क्लाइंट की तरह प्रथम-रन डिवाइस पेयरिंग स्वीकृति से गुजरते हैं। यदि Paperclip openclaw_gateway_pairing_required रिपोर्ट करता है, तो लंबित डिवाइस स्वीकृत करें और पुनः प्रयास करें।

openclaw devices approve --latest

पूर्वावलोकन सटीक openclaw devices approve <requestId> कमांड दिखाता है; विवरण सत्यापित करें, फिर अनुरोध ID के साथ वही कमांड दोबारा चलाकर उसे स्वीकृत करें। दूरस्थ Gateway या स्पष्ट क्रेडेंशियल के लिए, पूर्वावलोकन और स्वीकृति के दौरान समान विकल्प दें:

openclaw devices approve --latest --url <gateway-ws-url> --token <gateway-token>

हर पुनः आरंभ के बाद दोबारा स्वीकृति से बचने के लिए, Paperclip में स्थायी adapterConfig.devicePrivateKeyPem कॉन्फ़िगर करें, बजाय इसके कि वह हर रन में नई अल्पकालिक डिवाइस पहचान बनाए:

{  "adapterConfig": {    "devicePrivateKeyPem": "<ed25519-private-key-pkcs8-pem>"  }}

यदि स्वीकृति लगातार विफल होती है, तो लंबित अनुरोध मौजूद होने की पुष्टि करने के लिए पहले openclaw devices list चलाएँ।

संबंधित

• CLI संदर्भ
• नोड