openclaw node

एक हेडलेस Node होस्ट चलाएँ जो Gateway WebSocket से कनेक्ट होता है और इस मशीन पर system.run / system.which उपलब्ध कराता है।

macOS पर, मेनू बार ऐप पहले से ही इस Node-होस्ट रनटाइम को अपने Node कनेक्शन में एम्बेड करता है और मूल Mac क्षमताएँ जोड़ता है। Mac पर openclaw node run का उपयोग केवल तभी करें, जब आप जानबूझकर ऐप के बिना एक हेडलेस Node चाहते हों। दोनों को चलाने से एक ही मशीन के लिए दो Node पहचान बनती हैं।

Node होस्ट का उपयोग क्यों करें?

जब आप अपने नेटवर्क में एजेंटों से अन्य मशीनों पर कमांड चलवाना चाहते हैं, लेकिन वहाँ पूरा macOS सहयोगी ऐप इंस्टॉल नहीं करना चाहते, तब Node होस्ट का उपयोग करें।

सामान्य उपयोग के मामले:

• दूरस्थ Linux/Windows मशीनों (बिल्ड सर्वर, लैब मशीनें, NAS) पर कमांड चलाएँ।
• Gateway पर exec को सैंडबॉक्स में रखें, लेकिन स्वीकृत रन अन्य होस्ट को सौंपें।
• ऑटोमेशन या CI Node के लिए एक हल्का, हेडलेस निष्पादन लक्ष्य उपलब्ध कराएँ।

निष्पादन अब भी Node होस्ट पर exec अनुमोदनों और प्रति-एजेंट अनुमत-सूचियों द्वारा सुरक्षित रहता है, इसलिए आप कमांड एक्सेस को सीमित और स्पष्ट रख सकते हैं।

openclaw node run कनेक्ट होने के बाद Plugin या MCP-समर्थित टूल प्रकाशित कर सकता है। Gateway डिफ़ॉल्ट रूप से युग्मित Node से प्राप्त डिस्क्रिप्टर पर भरोसा करता है, साथ ही यह आवश्यक करता है कि प्रत्येक डिस्क्रिप्टर का कमांड Node की स्वीकृत कमांड सतह में रहे। एजेंट प्रत्येक स्वीकृत डिस्क्रिप्टर को सामान्य Plugin टूल के रूप में देखता है, लेकिन निष्पादन अब भी node.invoke से होकर जाता है, इसलिए Node को डिस्कनेक्ट करने पर नए एजेंट रन से टूल हट जाता है। Gateway संचालक gateway.nodes.pluginTools.enabled: false के साथ प्रकाशन अक्षम कर सकते हैं।

घोषणात्मक MCP टूल के लिए, Node मशीन पर openclaw.json में nodeHost.mcp.servers के अंतर्गत सामान्य MCP सर्वर संरचना जोड़ें, फिर Node होस्ट को पुनः आरंभ करें। Node अनुमोदन-नियंत्रित mcp.tools.call.v1 कमांड परिवार घोषित करता है और कनेक्ट होने के बाद सूचीबद्ध टूल प्रकाशित करता है; बाद में सर्वर सूची बदलने के लिए फिर से युग्मित करने की आवश्यकता नहीं होती। देखें Node पर होस्ट किए गए MCP सर्वर।

ब्राउज़र प्रॉक्सी (बिना कॉन्फ़िगरेशन)

यदि Node पर browser.enabled अक्षम नहीं है, तो Node होस्ट स्वचालित रूप से ब्राउज़र प्रॉक्सी का विज्ञापन करते हैं। इससे एजेंट बिना अतिरिक्त कॉन्फ़िगरेशन के उस Node पर ब्राउज़र ऑटोमेशन का उपयोग कर सकता है।

डिफ़ॉल्ट रूप से, प्रॉक्सी Node की सामान्य ब्राउज़र प्रोफ़ाइल सतह उपलब्ध कराता है। यदि आप nodeHost.browserProxy.allowProfiles सेट करते हैं, तो प्रॉक्सी प्रतिबंधात्मक हो जाता है: अनुमत-सूची में शामिल न की गई प्रोफ़ाइल को लक्षित करने के अनुरोध अस्वीकार कर दिए जाते हैं और स्थायी प्रोफ़ाइल बनाने/हटाने के रूट प्रॉक्सी के माध्यम से अवरुद्ध कर दिए जाते हैं।

आवश्यक होने पर इसे Node पर अक्षम करें:

{  nodeHost: {    browserProxy: {      enabled: false,    },  },}

चलाएँ (फ़ोरग्राउंड)

openclaw node run --host <gateway-host> --port 18789

विकल्प:

• --host <host>: Gateway WebSocket होस्ट (डिफ़ॉल्ट: 127.0.0.1)
• --port <port>: Gateway WebSocket पोर्ट (डिफ़ॉल्ट: 18789)
• --context-path <path>: Gateway WebSocket संदर्भ पथ (उदा. /openclaw-gw)। WebSocket URL में जोड़ा जाता है।
• --tls: Gateway कनेक्शन के लिए TLS का उपयोग करें
• --no-tls: स्थानीय Gateway कॉन्फ़िगरेशन में TLS सक्षम होने पर भी प्लेनटेक्स्ट Gateway कनेक्शन को बाध्य करें
• --tls-fingerprint <sha256>: अपेक्षित TLS प्रमाणपत्र फ़िंगरप्रिंट (sha256)
• --node-id <id>: साझा SQLite स्थिति में संग्रहीत क्लाइंट इंस्टेंस ID को ओवरराइड करें (युग्मन रीसेट नहीं करता)
• --display-name <name>: Node के प्रदर्शन नाम को ओवरराइड करें

Node होस्ट के लिए Gateway प्रमाणीकरण

openclaw node run और openclaw node install कॉन्फ़िगरेशन/पर्यावरण से Gateway प्रमाणीकरण निर्धारित करते हैं (Node कमांड पर कोई --token/--password फ़्लैग नहीं):

• पहले OPENCLAW_GATEWAY_TOKEN / OPENCLAW_GATEWAY_PASSWORD की जाँच की जाती है।
• फिर स्थानीय कॉन्फ़िगरेशन फ़ॉलबैक: gateway.auth.token / gateway.auth.password।
• स्थानीय मोड में, Node होस्ट जानबूझकर gateway.remote.token / gateway.remote.password इनहेरिट नहीं करता।
• यदि gateway.auth.token / gateway.auth.password को SecretRef के माध्यम से स्पष्ट रूप से कॉन्फ़िगर किया गया है और वह समाधान नहीं हो पाता, तो Node प्रमाणीकरण निर्धारण बंद-सुरक्षित ढंग से विफल होता है (दूरस्थ फ़ॉलबैक इसे छिपाता नहीं है)।
• gateway.mode=remote में, दूरस्थ क्लाइंट फ़ील्ड (gateway.remote.token / gateway.remote.password) भी दूरस्थ प्राथमिकता नियमों के अनुसार पात्र होते हैं।
• Node होस्ट प्रमाणीकरण निर्धारण केवल OPENCLAW_GATEWAY_* पर्यावरण चरों को स्वीकार करता है।

प्लेनटेक्स्ट ws:// Gateway से कनेक्ट होने वाले Node के लिए, लूपबैक, निजी IP लिटरल, .local, और Tailnet *.ts.net होस्ट स्वीकार किए जाते हैं। अन्य विश्वसनीय निजी-DNS नामों के लिए, OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1 सेट करें; इसके बिना Node स्टार्टअप बंद-सुरक्षित ढंग से विफल होता है और आपसे wss://, SSH टनल, या Tailscale का उपयोग करने को कहता है। यह प्रक्रिया-पर्यावरण का ऑप्ट-इन है, न कि openclaw.json कॉन्फ़िगरेशन कुंजी। इंस्टॉल कमांड के पर्यावरण में मौजूद होने पर openclaw node install इसे पर्यवेक्षित Node सेवा में स्थायी रूप से सहेजता है।

सेवा (बैकग्राउंड)

हेडलेस Node होस्ट को उपयोगकर्ता सेवा के रूप में इंस्टॉल करें (macOS पर launchd, Linux पर systemd, Windows पर Windows Task Scheduler)।

openclaw node install --host <gateway-host> --port 18789

विकल्प:

• --host <host>: Gateway WebSocket होस्ट (डिफ़ॉल्ट: 127.0.0.1)
• --port <port>: Gateway WebSocket पोर्ट (डिफ़ॉल्ट: 18789)
• --context-path <path>: Gateway WebSocket संदर्भ पथ (उदा. /openclaw-gw)। WebSocket URL में जोड़ा जाता है।
• --tls: Gateway कनेक्शन के लिए TLS का उपयोग करें
• --tls-fingerprint <sha256>: अपेक्षित TLS प्रमाणपत्र फ़िंगरप्रिंट (sha256)
• --node-id <id>: साझा SQLite स्थिति में संग्रहीत क्लाइंट इंस्टेंस ID को ओवरराइड करें (युग्मन रीसेट नहीं करता)
• --display-name <name>: Node के प्रदर्शन नाम को ओवरराइड करें
• --runtime <runtime>: सेवा रनटाइम (node)
• --force: पहले से इंस्टॉल होने पर पुनः इंस्टॉल/ओवरराइट करें

सेवा प्रबंधित करें:

openclaw node statusopenclaw node startopenclaw node stopopenclaw node restartopenclaw node uninstall

फ़ोरग्राउंड Node होस्ट (सेवा के बिना) के लिए openclaw node run का उपयोग करें।

सेवा कमांड मशीन द्वारा पठनीय आउटपुट के लिए --json स्वीकार करते हैं।

Node होस्ट प्रक्रिया के भीतर Gateway के पुनः आरंभ और नेटवर्क कनेक्शन बंद होने पर फिर से प्रयास करता है। यदि Gateway टर्मिनल टोकन/पासवर्ड/बूटस्ट्रैप प्रमाणीकरण विराम की रिपोर्ट करता है, तो Node होस्ट कनेक्शन बंद होने का विवरण लॉग करता है और गैर-शून्य स्थिति के साथ बाहर निकलता है, ताकि launchd/systemd/Task Scheduler उसे नए कॉन्फ़िगरेशन और क्रेडेंशियल के साथ पुनः आरंभ कर सके। युग्मन-आवश्यक विराम फ़ोरग्राउंड प्रवाह में बने रहते हैं, ताकि लंबित अनुरोध को स्वीकृत किया जा सके।

युग्मन

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

जब Gateway होस्ट Node होस्ट से गैर-इंटरैक्टिव तरीके से SSH कर सकता है (समान उपयोगकर्ता, विश्वसनीय होस्ट कुंजी), तो लंबित अनुरोध स्वचालित रूप से स्वीकृत हो जाता है: Gateway SSH के माध्यम से Node होस्ट पर openclaw node identity --json चलाता है और डिवाइस कुंजी के सटीक मिलान पर स्वीकृति देता है। यह डिफ़ॉल्ट रूप से चालू है; आवश्यकताओं और इसे अक्षम करने के तरीके (gateway.nodes.pairing.sshVerify: false) के लिए SSH-सत्यापित डिवाइस स्वतः-अनुमोदन देखें।

अन्यथा निम्न के माध्यम से मैन्युअल रूप से स्वीकृत करें:

openclaw devices listopenclaw devices approve <requestId>

Gateway जिस स्थानीय Node पहचान का सत्यापन करता है, उसका निरीक्षण करें:

openclaw node identity --json

यह state/openclaw.sqlite में primary पंक्ति से डिवाइस ID और सार्वजनिक कुंजी प्रिंट करता है तथा कभी भी डेटाबेस या नई पहचान नहीं बनाता।

कड़े नियंत्रण वाले Node नेटवर्क पर, Gateway संचालक विश्वसनीय CIDR से पहली बार होने वाले Node युग्मन को स्वतः स्वीकृत करने के लिए स्पष्ट रूप से ऑप्ट-इन कर सकता है:

{  gateway: {    nodes: {      pairing: {        autoApproveCidrs: ["192.168.1.0/24"],      },    },  },}

यह डिफ़ॉल्ट रूप से अक्षम है (autoApproveCidrs सेट नहीं है)। यह केवल बिना अनुरोधित स्कोप वाले नए role: node युग्मन पर, ऐसे क्लाइंट IP से लागू होता है जिस पर Gateway भरोसा करता है। संचालक/ब्राउज़र क्लाइंट, Control UI, WebChat, और भूमिका, स्कोप, मेटाडेटा या सार्वजनिक-कुंजी अपग्रेड के लिए अब भी मैन्युअल स्वीकृति आवश्यक है।

यदि Node बदले हुए प्रमाणीकरण विवरण (भूमिका/स्कोप/सार्वजनिक कुंजी) के साथ युग्मन का पुनः प्रयास करता है, तो पिछले लंबित अनुरोध को प्रतिस्थापित कर दिया जाता है और नया requestId बनाया जाता है। स्वीकृति से पहले openclaw devices list फिर से चलाएँ।

पहचान और युग्मन स्थिति

हेडलेस Node अपने क्लाइंट इंस्टेंस ID को उस हस्ताक्षरित डिवाइस पहचान से अलग रखता है जिसका उपयोग Gateway युग्मन और रूटिंग के लिए करता है। यह स्थिति OpenClaw स्थिति निर्देशिका में रहती है (डिफ़ॉल्ट रूप से ~/.openclaw, या सेट होने पर $OPENCLAW_STATE_DIR):

--node-id साझा SQLite स्थिति में केवल क्लाइंट इंस्टेंस ID बदलता है। यह क्रिप्टोग्राफ़िक डिवाइस ID नहीं बदलता या युग्मन प्रमाणीकरण साफ़ नहीं करता। openclaw doctor --fix के साथ अप्रचलित node.json माइग्रेट करने से भी युग्मन रीसेट नहीं होता। किसी Node को निरस्त करके फिर से युग्मित करने के लिए:

1. Gateway पर, openclaw nodes remove --node <id|name|ip> चलाएँ।
2. Node पर, इंस्टॉल की गई सेवा को openclaw node restart के साथ पुनः आरंभ करें, या फ़ोरग्राउंड openclaw node run कमांड को रोककर फिर से चलाएँ। इससे डिवाइस-युग्मन प्रवाह आरंभ होता है। यदि openclaw devices list कोई अनुरोध नहीं दिखाता और Node AUTH_DEVICE_TOKEN_MISMATCH की रिपोर्ट करता है, तो उसे एक बार और पुनः आरंभ करें या फिर से चलाएँ। अस्वीकृत प्रयास अब निरस्त हो चुके स्थानीय टोकन को साफ़ कर देता है; अगला प्रयास युग्मन का अनुरोध कर सकता है।
3. Gateway पर, openclaw devices list, फिर openclaw devices approve <deviceRequestId> चलाएँ।
4. Node को फिर से पुनः आरंभ करें या चलाएँ। युग्मन के लिए रोका गया क्लाइंट स्वीकृति के बाद स्वचालित रूप से फिर से शुरू नहीं होता; यह पुनः कनेक्शन अलग कमांड-सतह अनुरोध बनाता है।
5. Gateway पर, openclaw nodes pending, फिर openclaw nodes approve <nodeRequestId> चलाएँ।

दोनों अनुरोध ID अलग-अलग हैं। लागू विश्वसनीय-CIDR नीति पहली बार के डिवाइस-युग्मन चरण को स्वतः स्वीकृत कर सकती है; कमांड-सतह स्वीकृति एक अलग जाँच बनी रहती है।

OpenClaw के पुराने रिलीज़ में Node-होस्ट स्थिति node.json में और हस्ताक्षरित पहचान identity/device.json में संग्रहीत होती थी। Node होस्ट को रोकें और openclaw doctor --fix एक बार चलाएँ; Doctor प्रत्येक अप्रचलित स्रोत पर अधिकार लेता है, उसका सत्यापन करता है, विहित SQLite पंक्ति आयात करके सत्यापित करता है, फिर पुरानी फ़ाइल हटा देता है। जब तक कोई अप्रचलित फ़ाइल या बाधित Doctor दावा मौजूद रहता है, सामान्य Node कमांड इस सुधार निर्देश के साथ बंद-सुरक्षित ढंग से विफल होते हैं। state/openclaw.sqlite और identity/device-auth.json को निजी रखें; इनमें डिवाइस कुंजी-युग्म और प्रमाणीकरण टोकन होते हैं। डिवाइस प्रमाणीकरण एक अलग संग्रह बना रहता है और पहचान माइग्रेशन द्वारा दोबारा नहीं लिखा जाता।

Exec अनुमोदन

system.run स्थानीय exec अनुमोदनों द्वारा नियंत्रित है:

• $OPENCLAW_STATE_DIR/exec-approvals.json, या चर सेट न होने पर ~/.openclaw/exec-approvals.json
• Exec अनुमोदन
• openclaw approvals --node <id|name|ip> (Gateway से संपादित करें)

स्वीकृत एसिंक्रोनस Node exec के लिए, OpenClaw संकेत देने से पहले एक विहित systemRunPlan तैयार करता है। बाद में स्वीकृत system.run फ़ॉरवर्ड उसी संग्रहीत योजना का पुनः उपयोग करता है, इसलिए स्वीकृति अनुरोध बनाए जाने के बाद कमांड/cwd/सत्र फ़ील्ड में किए गए संपादन अस्वीकार कर दिए जाते हैं, न कि Node द्वारा निष्पादित सामग्री को बदलते हैं।

संबंधित

• CLI संदर्भ
• Nodes