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

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

पेयर किए गए डिवाइसों के प्रदर्शन नाम इस प्राथमिकता क्रम का उपयोग करते हैं: ऑपरेटर लेबल (devices rename से operatorLabel), फिर क्लाइंट 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 Node होस्ट से 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 संदर्भ
• Nodes