--- read_when: - Gateway WS क्लाइंट को लागू या अपडेट करना - प्रोटोकॉल बेमेल या कनेक्शन विफलताओं की डीबगिंग - प्रोटोकॉल स्कीमा/मॉडल पुनः जनरेट करना summary: 'Gateway WebSocket प्रोटोकॉल: हैंडशेक, फ़्रेम, संस्करण प्रबंधन' title: Gateway प्रोटोकॉल x-i18n: generated_at: "2026-07-27T19:45:19Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 32 provider: openai source_hash: 89d637a9070bc6512a182fea0fd890b56287e0080515ba4fba9b2591c6247e0d source_path: gateway/protocol.md workflow: 16 --- Gateway WS प्रोटोकॉल OpenClaw के लिए एकमात्र नियंत्रण तल और Node परिवहन है। ऑपरेटर और Node क्लाइंट (CLI, वेब UI, macOS ऐप, iOS/Android Node, हेडलेस Node) WebSocket पर कनेक्ट होते हैं और हैंडशेक के समय एक **भूमिका** और **स्कोप** घोषित करते हैं। ## npm पैकेज ये पैकेज OpenClaw रिलीज़ शृंखलाओं के साथ भेजे जाते हैं। प्रारंभिक रोलआउट के दौरान, पहला पैकेज-सहित रिलीज़ प्रकाशित होने तक npm `E404` लौटा सकता है। - [`@openclaw/gateway-protocol`](https://www.npmjs.com/package/@openclaw/gateway-protocol) स्कीमा, वैलिडेटर, TypeScript प्रकार, हल्के फ़्रेम और त्रुटि सहायक तथा संस्करण कॉन्स्टेंट प्रकाशित करता है। इसके टारबॉल में जनरेट किया गया [`protocol.schema.json`](https://unpkg.com/@openclaw/gateway-protocol/protocol.schema.json) मशीन-पठनीय अनुबंध शामिल है। - [`@openclaw/gateway-client`](https://www.npmjs.com/package/@openclaw/gateway-client) संदर्भ Node क्लाइंट और `@openclaw/gateway-client/browser` पर एक ब्राउज़र-सुरक्षित एंट्री प्रकाशित करता है। एप्लिकेशन जीवनचक्र मार्गदर्शन के लिए, [Gateway क्लाइंट बनाना](https://docs.openclaw.ai/gateway/clients) देखें। Gateway को चाइल्ड प्रोसेस के रूप में पर्यवेक्षित करने वाले ऐप्स के लिए, [OpenClaw एम्बेड करना](https://docs.openclaw.ai/gateway/embedding) देखें। ## परिवहन और फ़्रेमिंग - WebSocket, टेक्स्ट फ़्रेम, JSON पेलोड। - पहला फ़्रेम `connect` अनुरोध **होना आवश्यक है**। - कनेक्ट होने से पहले के फ़्रेम 64 KiB (`MAX_PREAUTH_PAYLOAD_BYTES`) तक सीमित हैं। हैंडशेक के बाद, `hello-ok.policy.maxPayload` और `hello-ok.policy.maxBufferedBytes` का पालन करें। डायग्नोस्टिक्स सक्षम होने पर, बहुत बड़े इनबाउंड फ़्रेम और धीमे आउटबाउंड बफ़र, Gateway द्वारा फ़्रेम बंद करने या हटाने से पहले `payload.large` इवेंट उत्सर्जित करते हैं। इन इवेंट में `surface`, बाइट आकार, सीमाएँ और एक सुरक्षित कारण कोड होते हैं; संदेश बॉडी, अटैचमेंट सामग्री, कच्चे फ़्रेम बाइट, टोकन, कुकी या सीक्रेट कभी नहीं होते। फ़्रेम संरचनाएँ: - अनुरोध: `{type:"req", id, method, params}` - प्रतिक्रिया: `{type:"res", id, ok, payload|error}` - इवेंट: `{type:"event", event, payload, seq?, stateVersion?}` प्रतिक्रिया त्रुटियाँ `{ code, message, details?, retryable?, retryAfterMs? }` का उपयोग करती हैं। क्लाइंट को `code` और `details.code` के आधार पर शाखा बनानी चाहिए; `message` मानव-पठनीय रहता है और बदल सकता है, सिवाय उन स्थानों के जहाँ संगतता नोट कुछ और कहता हो। विधि-स्तरीय प्राधिकरण विफलताएँ संरचित अनुपलब्ध-स्कोप विवरण के साथ शीर्ष-स्तरीय `code: "FORBIDDEN"` का उपयोग करती हैं: - अनुपलब्ध स्कोप: `{ code: "MISSING_SCOPE", missingScope, requiredScopes }`। `requiredScopes` अनुरोधित ऑपरेशन के लिए ज्ञात स्कोप का पूर्ण सेट है। पुराने क्लाइंट के लिए विरासती `missing scope: ` संदेश बनाए रखा गया है। क्लाइंट को पहले `details` पढ़ना चाहिए और विरासती संदेश का उपयोग केवल संगतता फ़ॉलबैक के रूप में करना चाहिए। `readMissingScopeError` और `readMissingScopeErrorDetails` `@openclaw/gateway-protocol/gateway-error-details` से एक्सपोर्ट किए जाते हैं; ब्राउज़र-सुरक्षित Gateway क्लाइंट उन्हें `@openclaw/gateway-client/browser` से फिर से एक्सपोर्ट करता है। स्कीमा `@openclaw/gateway-protocol/schema` से `GatewayErrorDetailsSchema`, `MissingScopeErrorDetailsSchema` के रूप में एक्सपोर्ट किए जाते हैं। HTTP स्कोप विफलताएँ `error.details` के अंतर्गत `MISSING_SCOPE` ऑब्जेक्ट को प्रतिबिंबित करती हैं और HTTP स्थिति `403` का उपयोग करती हैं। दुष्प्रभाव उत्पन्न करने वाली विधियों को आइडेम्पोटेंसी कुंजियों की आवश्यकता होती है (स्कीमा देखें)। ## हैंडशेक Gateway कनेक्ट होने से पहले एक चुनौती भेजता है: ```json { "type": "event", "event": "connect.challenge", "payload": { "nonce": "…", "ts": 1737264000000 } } ``` क्लाइंट `connect` से उत्तर देता है: ```json { "type": "req", "id": "…", "method": "connect", "params": { "minProtocol": 4, "maxProtocol": 4, "client": { "id": "cli", "version": "1.2.3", "platform": "macos", "mode": "operator" }, "role": "operator", "scopes": ["operator.read", "operator.write"], "caps": [], "commands": [], "permissions": {}, "auth": { "token": "…" }, "locale": "en-US", "userAgent": "openclaw-cli/1.2.3", "device": { "id": "device_fingerprint", "publicKey": "…", "signature": "…", "signedAt": 1737264000000, "nonce": "…" } } } ``` Gateway `hello-ok` से प्रतिक्रिया देता है: ```json { "type": "res", "id": "…", "ok": true, "payload": { "type": "hello-ok", "protocol": 4, "server": { "version": "…", "connId": "…" }, "features": { "methods": ["…"], "events": ["…"] }, "snapshot": { "…": "…" }, "auth": { "role": "operator", "scopes": ["operator.read", "operator.write"] }, "policy": { "maxPayload": 26214400, "maxBufferedBytes": 52428800, "tickIntervalMs": 15000 } } } ``` `server`, `features`, `snapshot`, `policy` और `auth`, सभी `HelloOkSchema` (`packages/gateway-protocol/src/schema/frames.ts`) के लिए आवश्यक हैं। `auth` डिवाइस टोकन जारी न होने पर भी तय की गई भूमिका/स्कोप की रिपोर्ट करता है (ऊपर दी गई संरचना)। `pluginSurfaceUrls` वैकल्पिक है और Plugin सतह नामों (जैसे `canvas`) को स्कोप किए गए होस्टेड URL से मैप करता है; इसकी समय-सीमा समाप्त हो सकती है, इसलिए Node नई एंट्री के लिए `{ "surface": "canvas" }` के साथ `node.pluginSurface.refresh` को कॉल करते हैं। बहिष्कृत `canvasHostUrl` / `canvasCapability` / `node.canvas.capability.refresh` पथ समर्थित नहीं है; Plugin सतहों का उपयोग करें। स्नैपशॉट का वैकल्पिक `appliedConfigHash`, सक्रिय Gateway रनटाइम द्वारा स्वीकार किया गया रिज़ॉल्व किया हुआ स्रोत-कॉन्फ़िग संशोधन है। क्लाइंट इसकी तुलना `config.get.configRevisionHash` से करके यह निर्धारित कर सकते हैं कि क्या नए सहेजे गए कॉन्फ़िग को अभी भी रीस्टार्ट की आवश्यकता है। `config.get.hash`, कॉन्फ़िग लेखन टकराव गार्ड द्वारा उपयोग किया जाने वाला कच्चा रूट-फ़ाइल संशोधन बना रहता है। जब Gateway अभी भी स्टार्टअप साइडकार को पूरा कर रहा हो, तब `connect`, `details.reason: "startup-sidecars"` और `retryAfterMs` के साथ पुनः प्रयास योग्य `UNAVAILABLE` त्रुटि लौटा सकता है। इसे अंतिम हैंडशेक विफलता मानने के बजाय अपनी कनेक्शन सीमा के भीतर पुनः प्रयास करें। डिवाइस टोकन जारी होने पर, `hello-ok.auth` उसे जोड़ता है: ```json { "auth": { "deviceToken": "…", "role": "operator", "scopes": ["operator.read", "operator.write"] } } ``` अंतर्निहित QR/सेटअप-कोड बूटस्ट्रैप एक मोबाइल हैंडऑफ़ पथ है। सफल बेसलाइन सेटअप-कोड कनेक्शन एक प्राथमिक Node टोकन और एक सीमित ऑपरेटर टोकन लौटाता है: ```json { "auth": { "deviceToken": "…", "role": "node", "scopes": [], "deviceTokens": [ { "deviceToken": "…", "role": "operator", "scopes": ["operator.approvals", "operator.read", "operator.talk.secrets", "operator.write"] } ] } } ``` इस ऑपरेटर हैंडऑफ़ को जानबूझकर सीमित रखा गया है: यह मोबाइल ऑपरेटर लूप और नेटिव सेटअप शुरू करने के लिए पर्याप्त है, जिसमें Talk कॉन्फ़िग पढ़ने के लिए `operator.talk.secrets` शामिल है, लेकिन इसमें पेयरिंग-म्यूटेशन स्कोप और `operator.admin` नहीं हैं। अधिक व्यापक पेयरिंग/एडमिन पहुँच के लिए अलग स्वीकृत पेयरिंग या टोकन प्रवाह आवश्यक है। `hello-ok.auth.deviceTokens` को केवल तभी स्थायी रूप से सहेजें जब बूटस्ट्रैप प्रमाणीकरण किसी विश्वसनीय परिवहन (`wss://` या लूपबैक/स्थानीय पेयरिंग) पर चला हो। विश्वसनीय समान-प्रोसेस बैकएंड क्लाइंट (`client.id: "gateway-client"`, `client.mode: "backend"`), साझा Gateway टोकन/पासवर्ड से प्रमाणीकरण करते समय सीधे लूपबैक कनेक्शन पर `device` को छोड़ सकते हैं। यह पथ आंतरिक नियंत्रण-तल RPC (जैसे सबएजेंट सत्र अपडेट) के लिए आरक्षित है और पुरानी CLI/डिवाइस पेयरिंग बेसलाइन को स्थानीय बैकएंड कार्य अवरुद्ध करने से रोकता है। रिमोट, ब्राउज़र-मूल, Node और स्पष्ट डिवाइस-टोकन/डिवाइस-पहचान क्लाइंट अभी भी सामान्य पेयरिंग और स्कोप-अपग्रेड जाँच से गुजरते हैं। ### वर्कर भूमिका और बंद प्रोटोकॉल क्लाउड वर्कर Gateway-स्वामित्व वाली, होस्ट-कुंजी-पिन की गई SSH टनल के माध्यम से एक समर्पित लूपबैक प्रवेश का उपयोग करते हैं। यह केवल वर्कर पहचान स्वीकार करता है और सामान्य प्रमाणीकरण, Node इवेंट, ऑपरेटर RPC या Plugin विधियों को कभी डिस्पैच नहीं करता। एक सख्त `connect`, परिवेश, बंडल हैश, स्वामी युग, RPC-सेट संस्करण, समाप्ति और एक शून्य-योग्य सत्र से बंधे, स्थिर अवस्था में हैश किए गए, अल्पकालिक क्रेडेंशियल को सत्यापित करता है; यह वर्तमान संस्करण और सुविधा सेट की अलग से जाँच करता है। सफलता पर न्यूनतम `worker-hello-ok` लौटता है; सुविधा वार्ता सामान्य प्रोटोकॉल संस्करण से स्वतंत्र है। फ़्रेम 64 KiB से कम रहते हैं, सिवाय तय किए गए `worker.inference.start` फ़्रेम के, जो 25 MiB तक हो सकता है। बंद अनुमति-सूची में `worker.heartbeat`, `worker.transcript.commit`, `worker.live-event`, `worker.inference.start` और `worker.inference.cancel` शामिल हैं। ट्रांसक्रिप्ट कमिट स्वामी-युग फ़ेंसिंग, Gateway-स्वामित्व वाली सत्र बाइंडिंग, बेस-लीफ़ कंपेयर-एंड-स्वैप और टिकाऊ अनुक्रम रीप्ले का उपयोग करते हैं; Gateway सामान्य सत्र राइटर के माध्यम से ट्रांसक्रिप्ट एंट्री और पैरेंट ID जनरेट करता है। प्रत्येक RPC पर स्वामित्व और समाप्ति की दोबारा जाँच की जाती है। ### क्लाइंट क्षमताएँ ऑपरेटर क्लाइंट `connect.params.caps` में वैकल्पिक क्षमताएँ घोषित कर सकते हैं: - `tool-events`: संरचित टूल जीवनचक्र इवेंट स्वीकार करता है। - `inline-widgets`: होस्ट किए गए इनलाइन विजेट टूल परिणाम रेंडर कर सकता है। क्लाइंट क्षमताएँ कनेक्ट किए गए क्लाइंट का वर्णन करती हैं, प्राधिकरण का नहीं। एजेंट टूल आवश्यक क्षमताएँ घोषित कर सकते हैं; जब तक प्रत्येक आवश्यकता मूल क्लाइंट के `caps` में उपस्थित न हो, Gateway उन टूल को छोड़ देता है। चैनल से शुरू किए गए रन में कोई Gateway क्लाइंट क्षमता नहीं होती, इसलिए क्षमता-नियंत्रित टूल तब भी अनुपलब्ध रहते हैं जब टूल नीति उन्हें स्पष्ट रूप से अनुमति देती है। ### Node कनेक्शन उदाहरण ```json { "type": "req", "id": "…", "method": "connect", "params": { "minProtocol": 4, "maxProtocol": 4, "client": { "id": "ios-node", "version": "1.2.3", "platform": "ios", "mode": "node" }, "role": "node", "scopes": [], "caps": ["camera", "canvas", "screen", "location", "voice"], "commands": ["camera.snap", "canvas.navigate", "screen.record", "location.get"], "permissions": { "camera.capture": true, "screen.record": false }, "auth": { "token": "…" }, "locale": "en-US", "userAgent": "openclaw-ios/1.2.3", "device": { "id": "device_fingerprint", "publicKey": "…", "signature": "…", "signedAt": 1737264000000, "nonce": "…" } } } ``` Node कनेक्ट होते समय क्षमता दावे घोषित करते हैं: - `caps`: `camera`, `canvas`, `screen`, `location`, `voice`, `talk` जैसी उच्च-स्तरीय श्रेणियाँ। - `commands`: इनवोक के लिए कमांड अनुमति-सूची। - `permissions`: विस्तृत टॉगल (जैसे `screen.record`, `camera.capture`)। Gateway इन्हें दावों के रूप में मानता है और सर्वर-साइड अनुमति-सूचियाँ लागू करता है। ## भूमिकाएँ और स्कोप संपूर्ण ऑपरेटर स्कोप मॉडल, स्वीकृति-समय जाँच और साझा-सीक्रेट अर्थविज्ञान के लिए, [ऑपरेटर स्कोप](/hi/gateway/operator-scopes) देखें। भूमिकाएँ: - `operator`: नियंत्रण-तल क्लाइंट (CLI/UI/ऑटोमेशन)। - `node`: क्षमता होस्ट (camera/screen/canvas/system.run)। - `worker`: समर्पित, बंद वर्कर प्रोटोकॉल पर क्लाउड निष्पादन होस्ट। ऑपरेटर स्कोप (`src/gateway/operator-scopes.ts`), पूर्ण बंद सेट: - `operator.read` - `operator.write` - `operator.admin` - `operator.approvals` - `operator.pairing` - `operator.talk.secrets` `includeSecrets: true` के साथ `talk.config` को `operator.talk.secrets` (या `operator.admin`) की आवश्यकता होती है। सीक्रेट शामिल होने पर, सक्रिय Talk प्रदाता क्रेडेंशियल को `talk.resolved.config.apiKey` से पढ़ें; `talk.providers..apiKey` स्रोत-आकार में बना रहता है और SecretRef ऑब्जेक्ट या संपादित स्ट्रिंग हो सकता है। Plugin-पंजीकृत Gateway RPC विधियाँ अपने ऑपरेटर स्कोप का अनुरोध कर सकती हैं, लेकिन ये आरक्षित कोर प्रीफ़िक्स हमेशा `operator.admin` (`src/shared/gateway-method-policy.ts`) में रिज़ॉल्व होते हैं: `config.*`, `exec.approvals.*`, `wizard.*`, `update.*`। विधि स्कोप केवल पहला गेट है। `chat.send` के माध्यम से पहुँचने वाले कुछ स्लैश कमांड अधिक सख्त कमांड-स्तरीय जाँच लागू करते हैं: स्थायी `/config set` और `/config unset` लेखन के लिए `operator.admin` आवश्यक है, उन Gateway क्लाइंट के लिए भी जिनके पास पहले से निम्न ऑपरेटर स्कोप है। `node.pair.approve` में आधार विधि स्कोप (`operator.pairing`) के अतिरिक्त, लंबित अनुरोध के घोषित `commands` (`src/infra/node-pairing-authz.ts`) पर आधारित एक अतिरिक्त स्वीकृति-समय स्कोप जाँच होती है: | घोषित कमांड | आवश्यक स्कोप | | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- | | कोई नहीं | `operator.pairing` | | सामान्य कमांड | `operator.pairing` + `operator.write` | | इसमें `system.run`, `system.run.prepare`, `system.which`, `browser.proxy`, `fs.listDir`, या `system.execApprovals.get/set` शामिल हैं | `operator.pairing` + `operator.admin` | ### क्षमताएँ/कमांड/अनुमतियाँ (नोड) नोड कनेक्ट होते समय क्षमता के दावे घोषित करते हैं: - `caps`: उच्च-स्तरीय क्षमता श्रेणियाँ, जैसे `camera`, `canvas`, `screen`, `location`, `voice`, और `talk`। - `commands`: इनवोक के लिए कमांड अनुमत-सूची। - `permissions`: सूक्ष्म टॉगल (उदा. `screen.record`, `camera.capture`)। Gateway इन्हें **दावे** मानता है और सर्वर-साइड अनुमत-सूचियाँ लागू करता है। कनेक्ट किए गए नोड सफल कनेक्ट या पुनः कनेक्ट के बाद `node.pluginTools.update` के साथ वैकल्पिक, एजेंट को दिखाई देने वाले Plugin या MCP टूल डिस्क्रिप्टर प्रकाशित कर सकते हैं। हेडलेस नोड होस्ट घोषणात्मक MCP इन्वेंटरी परिवर्तनों को लागू करने के लिए पुनः शुरू होते हैं। यह अपडेट विधि प्रकाशन का एकमात्र मार्ग है; Plugin टूल डिस्क्रिप्टर `connect` पैरामीटर में स्वीकार नहीं किए जाते। प्रत्येक डिस्क्रिप्टर को प्रदाता-सुरक्षित टूल `name` का उपयोग करना और नोड की वर्तमान कमांड अनुमत-सूची में मौजूद `command` का नाम देना आवश्यक है। Gateway युग्मित नोड से प्राप्त डिस्क्रिप्टर मेटाडेटा पर भरोसा करता है, स्वीकृत कमांड सतह से बाहर के डिस्क्रिप्टर फ़िल्टर करता है, नोड के डिस्कनेक्ट होने पर उन्हें हटा देता है और किसी अन्य नोड के कैटलॉग में परिवर्तन करने के ऑपरेटर प्रयासों को अस्वीकार करता है। नोड द्वारा प्रकाशित डिस्क्रिप्टर अनदेखे करने के लिए `gateway.nodes.pluginTools.enabled: false` सेट करें। कनेक्ट किए गए नोड होस्ट अपना संपूर्ण प्रतिस्थापन Skills कैटलॉग `node.skills.update` के साथ प्रकाशित करते हैं। यह नोड-भूमिका विधि नोड Skills के प्रकाशन का एकमात्र मार्ग है; Skills `connect` पैरामीटर में स्वीकार नहीं किए जाते। प्रत्येक डिस्क्रिप्टर में एक सुरक्षित नाम, विवरण और सीमित `SKILL.md` सामग्री होती है। Gateway उस सामग्री को सामान्य Skills लोडर से पार्स करता है, नोड के कनेक्ट रहने तक उसे एजेंट Skills स्नैपशॉट में शामिल करता है और डिस्कनेक्ट होने पर हटा देता है। नोड द्वारा प्रकाशित Skills अनदेखे करने के लिए `gateway.nodes.allowSkills: false` सेट करें। ## उपस्थिति - `system-presence` डिवाइस पहचान के अनुसार कुंजीबद्ध प्रविष्टियाँ लौटाता है, जिनमें `deviceId`, `roles`, और `scopes` शामिल हैं, ताकि UI प्रत्येक डिवाइस के लिए एक पंक्ति दिखा सकें, भले वह ऑपरेटर और नोड दोनों के रूप में कनेक्ट हो। - `node.list` में वैकल्पिक `lastSeenAtMs` और `lastSeenReason` शामिल होते हैं। कनेक्ट किए गए नोड `connect` कारण के साथ वर्तमान कनेक्शन समय रिपोर्ट करते हैं; युग्मित नोड किसी विश्वसनीय नोड इवेंट के माध्यम से टिकाऊ पृष्ठभूमि उपस्थिति भी रिपोर्ट कर सकते हैं। मूल macOS नोड सीमित इनपुट निष्क्रिय समय के साथ प्रमाणित `node.presence.activity` इवेंट भी भेज सकते हैं। Gateway अपनी घड़ी पर गतिविधि टाइमस्टैम्प प्राप्त करता है, `node.list` और `node.describe` के माध्यम से सबसे हाल में सक्रिय कनेक्टेड Mac को प्रदर्शित करता है और पठन-स्कोप वाले क्लाइंट को `node.presence` अपडेट प्रसारित करता है। जब उपयोगकर्ता गतिविधि साझाकरण अक्षम करता है, तो ऐप `{ "action": "clear" }` भेजता है; Gateway केवल उसी प्रमाणित नोड कनेक्शन के टाइमस्टैम्प साफ़ करता है। इस स्वीकृत क्रिया से पुराने Gateway इसे अनहैंडल्ड के रूप में लौटाते हैं, इसलिए Mac नोड एक बार पुनः कनेक्ट होता है और डिस्कनेक्ट क्लीनअप को पुरानी कनेक्शन स्थिति हटाने देता है। चयन, गोपनीयता, मॉडल संदर्भ और सूचना-रूटिंग व्यवहार के लिए [सक्रिय कंप्यूटर उपस्थिति](/hi/nodes/presence) देखें। ### नोड पृष्ठभूमि सक्रिय इवेंट नोड यह दर्ज करने के लिए `event: "node.presence.alive"` के साथ `node.event` कॉल करते हैं कि कोई युग्मित नोड पृष्ठभूमि वेक के दौरान सक्रिय था, बिना उसे कनेक्टेड चिह्नित किए: ```json { "event": "node.presence.alive", "payloadJSON": "{\"trigger\":\"silent_push\",\"sentAtMs\":1737264000000,\"displayName\":\"Peter's iPhone\",\"version\":\"2026.4.28\",\"platform\":\"iOS 18.4.0\",\"deviceFamily\":\"iPhone\",\"modelIdentifier\":\"iPhone17,1\",\"pushTransport\":\"relay\"}" } ``` `trigger` एक बंद एनम है: `background`, `silent_push`, `bg_app_refresh`, `significant_location`, `manual`, `connect`। अज्ञात मान `background` (`src/shared/node-presence.ts`) में सामान्यीकृत होते हैं। इवेंट केवल प्रमाणित नोड डिवाइस सत्रों के लिए स्थायी रहता है; डिवाइस-रहित या अयुग्मित सत्र `handled: false` लौटाते हैं। सफल Gateway एक संरचित परिणाम लौटाते हैं: ```json { "ok": true, "event": "node.presence.alive", "handled": true, "reason": "persisted" } ``` पुराने Gateway `node.event` के लिए केवल `{ "ok": true }` लौटा सकते हैं; इसे स्वीकृत RPC मानें, टिकाऊ उपस्थिति स्थायित्व नहीं। ## प्रसारण इवेंट स्कोपिंग सर्वर द्वारा पुश किए गए प्रसारण इवेंट स्कोप-गेटेड होते हैं, ताकि युग्मन-स्कोप वाले या केवल-नोड सत्र निष्क्रिय रूप से सत्र सामग्री प्राप्त न करें (`src/gateway/server-broadcast.ts`): - चैट, एजेंट और टूल-परिणाम फ़्रेम (स्ट्रीम किए गए `agent` इवेंट, टूल-परिणाम इवेंट) के लिए कम-से-कम `operator.read` आवश्यक है। इसके बिना सत्र इन फ़्रेम को पूरी तरह छोड़ देते हैं। - Plugin-परिभाषित `plugin.*` प्रसारण डिफ़ॉल्ट रूप से `operator.write` या `operator.admin` तक सीमित होते हैं; `plugin.approval.requested` / `plugin.approval.resolved` जैसी स्पष्ट प्रविष्टियाँ इसके बजाय `operator.approvals` का उपयोग करती हैं। - स्थिति/ट्रांसपोर्ट इवेंट (`heartbeat`, `presence`, `tick`, कनेक्ट/डिस्कनेक्ट जीवनचक्र) अप्रतिबंधित रहते हैं, ताकि प्रत्येक प्रमाणित सत्र को ट्रांसपोर्ट की स्थिति दिखाई दे सके। - अज्ञात प्रसारण इवेंट परिवार डिफ़ॉल्ट रूप से स्कोप-गेटेड (विफलता पर बंद) होते हैं, जब तक कोई पंजीकृत हैंडलर स्पष्ट रूप से उन्हें शिथिल न करे। प्रत्येक क्लाइंट कनेक्शन अपनी प्रति-क्लाइंट क्रम संख्या रखता है, इसलिए अलग-अलग क्लाइंट द्वारा इवेंट स्ट्रीम के अलग-अलग स्कोप-फ़िल्टर किए गए उपसमुच्चय देखने पर भी प्रसारण उस सॉकेट पर एकदिश रूप से क्रमबद्ध रहते हैं। ## RPC विधि परिवार `hello-ok.features.methods`, `src/gateway/server-methods-list.ts` और लोड किए गए Plugin/चैनल विधि निर्यातों से निर्मित एक रूढ़िवादी खोज सूची है—यह प्रत्येक विधि का जनरेट किया गया डंप नहीं है और कुछ विधियाँ (उदाहरण के लिए `push.test`, `web.login.start`, `web.login.wait`, `sessions.usage`) वास्तविक, कॉल करने योग्य विधियाँ होने के बावजूद जानबूझकर खोज से बाहर रखी जाती हैं। इसे सुविधा खोज मानें, `src/gateway/server-methods/*.ts` की पूर्ण गणना नहीं। - `health` कैश किया हुआ या नए सिरे से जाँचा गया Gateway स्वास्थ्य स्नैपशॉट लौटाता है। - `diagnostics.stability` हाल का सीमित नैदानिक स्थिरता रिकॉर्डर लौटाता है: इवेंट नाम, गणनाएँ, बाइट आकार, मेमोरी रीडिंग, क्यू/सत्र स्थिति, चैनल/Plugin नाम, सत्र आईडी। कोई चैट टेक्स्ट, Webhook बॉडी, टूल आउटपुट, रॉ अनुरोध/प्रतिक्रिया बॉडी, टोकन, कुकी या सीक्रेट नहीं। `operator.read` आवश्यक है। - `status`, `/status`-शैली का Gateway सारांश लौटाता है; संवेदनशील फ़ील्ड केवल एडमिन-स्कोप वाले ऑपरेटर क्लाइंट के लिए। - `gateway.identity.get` रिले और युग्मन प्रवाहों द्वारा उपयोग की जाने वाली Gateway डिवाइस पहचान लौटाता है। - `system-presence` कनेक्ट किए गए ऑपरेटर/नोड डिवाइसों के लिए वर्तमान उपस्थिति स्नैपशॉट लौटाता है। - `system-event` एक सिस्टम इवेंट जोड़ता है और उपस्थिति संदर्भ को अपडेट/प्रसारित कर सकता है। - `last-heartbeat` नवीनतम स्थायी Heartbeat इवेंट लौटाता है। - `set-heartbeats` Gateway पर Heartbeat प्रोसेसिंग टॉगल करता है। - `gateway.suspend.prepare` केवल तभी एक छोटी सहयोगात्मक-निलंबन लीज़ बनाता है, जब ट्रैक किया गया Gateway कार्य निष्क्रिय हो। `gateway.suspend.status` उस लीज़ की जाँच करता है और `gateway.suspend.resume` थॉ के बाद या निरस्त होस्ट ऑपरेशन के पश्चात उसे जारी करता है। - `models.list` रनटाइम-अनुमत मॉडल कैटलॉग लौटाता है। नीचे "`models.list` दृश्य" देखें। - `usage.status` प्रदाता उपयोग विंडो/शेष कोटा सारांश लौटाता है। - `usage.cost` किसी दिनांक सीमा के लिए समेकित लागत-उपयोग सारांश लौटाता है। एक एजेंट के लिए `agentId` पास करें या कॉन्फ़िगर किए गए एजेंटों को समेकित करने के लिए `agentScope: "all"` पास करें। - `doctor.memory.status` सक्रिय डिफ़ॉल्ट एजेंट वर्कस्पेस के लिए वेक्टर-मेमोरी / कैश किए गए एम्बेडिंग की तत्परता लौटाता है। केवल स्पष्ट लाइव एम्बेडिंग प्रदाता पिंग के लिए `{ "probe": true }` या `{ "deep": true }` पास करें। Dreaming स्टोर आँकड़ों को एक एजेंट वर्कस्पेस तक सीमित करने के लिए `{ "agentId": "agent-id" }` पास करें; इसे छोड़ने पर कॉन्फ़िगर किए गए Dreaming वर्कस्पेस समेकित होते हैं। - `doctor.memory.dreamDiary`, `doctor.memory.backfillDreamDiary`, `doctor.memory.resetDreamDiary`, `doctor.memory.resetGroundedShortTerm`, `doctor.memory.repairDreamingArtifacts`, और `doctor.memory.dedupeDreamDiary` वैकल्पिक `{ "agentId": "agent-id" }` स्वीकार करते हैं; इसे छोड़ने पर वे कॉन्फ़िगर किए गए डिफ़ॉल्ट एजेंट वर्कस्पेस पर काम करते हैं। - `doctor.memory.remHarness` रिमोट कंट्रोल-प्लेन क्लाइंट के लिए सीमित, केवल-पठन REM हार्नेस पूर्वावलोकन लौटाता है, जिसमें वर्कस्पेस पथ, मेमोरी अंश, रेंडर किया गया आधारयुक्त Markdown और गहन प्रोमोशन उम्मीदवार शामिल हैं। `operator.read` आवश्यक है। - `sessions.usage` प्रति-सत्र उपयोग सारांश लौटाता है। एक एजेंट के लिए `agentId` पास करें या कॉन्फ़िगर किए गए एजेंटों को एक साथ सूचीबद्ध करने के लिए `agentScope: "all"` पास करें। दोनों उपयोग विधियाँ DST-जागरूक कैलेंडर-दिन सीमाओं और बकेट के लिए IANA `timeZone` सहित `mode: "specific"` स्वीकार करती हैं। पुराने क्लाइंट के लिए और जब Gateway रनटाइम अनुरोधित ज़ोन को नहीं पहचानता, तब फ़ॉलबैक के रूप में `utcOffset` समर्थित रहता है। - `sessions.usage.timeseries` एक सत्र के लिए समय-श्रृंखला उपयोग लौटाता है। - `sessions.usage.logs` एक सत्र के लिए उपयोग लॉग प्रविष्टियाँ लौटाता है। - `channels.status` अंतर्निहित + बंडल किए गए चैनल/Plugin स्थिति सारांश लौटाता है। - `channels.logout` जहाँ चैनल इसका समर्थन करता है, वहाँ किसी विशिष्ट चैनल/खाते को लॉग आउट करता है। - `web.login.start` वर्तमान QR-सक्षम वेब चैनल प्रदाता के लिए QR/वेब लॉगिन प्रवाह शुरू करता है। - `web.login.wait` उस प्रवाह के पूरा होने की प्रतीक्षा करता है और सफलता पर चैनल शुरू करता है। - `push.test` पंजीकृत iOS नोड को एक परीक्षण APNs पुश भेजता है। - `voicewake.get` संग्रहीत वेक-वर्ड ट्रिगर लौटाता है। - `voicewake.set` वेक-वर्ड ट्रिगर अपडेट करता है और परिवर्तन प्रसारित करता है। - `plugins.list` (`operator.read`) इंस्टॉल किए गए Plugin की सूची के साथ स्थानीय रूप से चयनित आधिकारिक विकल्प, निदान, और यह जानकारी लौटाता है कि वर्तमान इंस्टॉल मोड बदलावों की अनुमति देता है या नहीं। - `plugins.search` (`operator.read`) इंस्टॉल किए जा सकने वाले ClawHub कोड-Plugin और बंडल-Plugin समूहों को खोजता है। 1 से 100 तक गैर-रिक्त `query` और वैकल्पिक `limit` पास करें। - `plugins.install` (`operator.admin`) या तो `{ source: "official", pluginId }` वाली आधिकारिक कैटलॉग प्रविष्टि या `{ source: "clawhub", packageName, version?, acknowledgeClawHubRisk? }` वाला ClawHub पैकेज इंस्टॉल करता है। ClawHub इंस्टॉल Gateway के विश्वास, अखंडता और इंस्टॉल-नीति जाँचों को बनाए रखते हैं। सफल इंस्टॉल के लिए Gateway पुनः आरंभ करना आवश्यक है। - `plugins.setEnabled` (`operator.admin`) `{ pluginId, enabled }` के साथ इंस्टॉल किए गए एक Plugin की सक्षम करने की नीति बदलता है। प्रतिक्रिया में अपडेट की गई कैटलॉग प्रविष्टि, पुनः आरंभ मेटाडेटा और स्लॉट-चयन संबंधी चेतावनियाँ शामिल होती हैं। - `plugins.uninstall` (`operator.admin`) `{ pluginId }` के साथ बाहरी रूप से इंस्टॉल किए गए एक Plugin को हटाता है: कॉन्फ़िगरेशन संदर्भ, इंस्टॉल रिकॉर्ड और प्रबंधित फ़ाइलें। बंडल किए गए Plugin अनइंस्टॉल नहीं किए जा सकते, केवल अक्षम किए जा सकते हैं। प्रतिक्रिया हटाने की कार्रवाइयों को सूचीबद्ध करती है और हमेशा Gateway पुनः आरंभ करने की आवश्यकता बताती है। - `send` चैट रनर के बाहर चैनल/खाते/थ्रेड को लक्षित करके भेजने के लिए प्रत्यक्ष आउटबाउंड-डिलीवरी RPC है। - `logs.tail` कर्सर/सीमा और अधिकतम-बाइट नियंत्रणों के साथ कॉन्फ़िगर किए गए Gateway फ़ाइल-लॉग का अंतिम भाग लौटाता है। - `terminal.open` किसी स्पष्ट `agentId` या डिफ़ॉल्ट एजेंट के लिए होस्ट PTY शुरू करता है और निर्धारित एजेंट, कार्यशील डायरेक्टरी, शेल तथा परिसीमन स्थिति लौटाता है। - `terminal.input`, `terminal.resize`, और `terminal.close` केवल कॉल करने वाले कनेक्शन के स्वामित्व वाले सत्रों पर काम करते हैं। - `terminal.upload` अधिकतम 16 MiB की एक base64 फ़ाइल स्वीकार करता है, उसे सत्र के Gateway या युग्मित-Node होस्ट पर निजी 24-घंटे की अस्थायी डायरेक्टरी में रखता है और निरपेक्ष पथ लौटाता है। कॉलर को अभी भी उस पथ को पेस्ट करना या किसी अन्य प्रकार से उपयोग करना होगा; RPC कभी भी टर्मिनल इनपुट नहीं लिखता या कोई कमांड निष्पादित नहीं करता। - `terminal.data` और `terminal.exit` ईवेंट केवल सत्र के स्वामी कनेक्शन पर स्ट्रीम होते हैं। - जिन सत्रों का कनेक्शन टूट जाता है उन्हें समाप्त नहीं, बल्कि अलग किया जाता है: वे `gateway.terminal.detachedSessionTimeoutSeconds` (डिफ़ॉल्ट 300; `0` कनेक्शन टूटने पर समाप्त करने की व्यवस्था पुनर्स्थापित करता है) तक पुनः संलग्न किए जा सकते हैं, जबकि हालिया आउटपुट सीमित सर्वर-साइड बफ़र में एकत्र होता रहता है। - `terminal.list` संलग्न किए जा सकने वाले सत्र लौटाता है; `terminal.attach` किसी सक्रिय या अलग किए गए सत्र को कॉल करने वाले कनेक्शन से पुनः बाँधता है और पुनर्चालन बफ़र लौटाता है (tmux-शैली अधिग्रहण—पिछले सक्रिय स्वामी को कारण `detached` के साथ `terminal.exit` प्राप्त होता है); `terminal.text` बिना संलग्न किए बफ़र को सादे टेक्स्ट के रूप में पढ़ता है। - प्रत्येक टर्मिनल विधि के लिए `operator.admin` आवश्यक है; `gateway.terminal.enabled` स्पष्ट रूप से true होना चाहिए। पूर्णतः सैंडबॉक्स किए गए एजेंट अस्वीकार कर दिए जाते हैं और एजेंट नीति में बदलाव मौजूदा तथा प्रक्रियाधीन PTY को बंद कर देता है, जिसमें अलग किए गए PTY भी शामिल हैं। - `talk.catalog` वाक्, स्ट्रीमिंग ट्रांसक्रिप्शन और रीयलटाइम वॉइस के लिए केवल-पढ़ने योग्य Talk प्रदाता कैटलॉग लौटाता है: प्रामाणिक प्रदाता आईडी, रजिस्ट्री उपनाम, लेबल, कॉन्फ़िगर की गई स्थिति, वैकल्पिक समूह-स्तरीय `ready` परिणाम, उपलब्ध मॉडल/वॉइस आईडी, प्रामाणिक मोड, ट्रांसपोर्ट, ब्रेन रणनीतियाँ और रीयलटाइम ऑडियो/क्षमता फ़्लैग; यह प्रदाता सीक्रेट लौटाए या वैश्विक कॉन्फ़िगरेशन बदले बिना ऐसा करता है। वर्तमान Gateway रनटाइम प्रदाता चयन लागू करने के बाद `ready` सेट करते हैं; पुराने Gateway पर इसकी अनुपस्थिति को असत्यापित मानें। - `talk.config` प्रभावी Talk कॉन्फ़िगरेशन पेलोड लौटाता है; `includeSecrets` के लिए `operator.talk.secrets` (या `operator.admin`) आवश्यक है। - `talk.session.create` `realtime/gateway-relay`, `transcription/gateway-relay`, या `stt-tts/managed-room` के लिए Gateway के स्वामित्व वाला Talk सत्र बनाता है। `stt-tts/managed-room` के लिए, `sessionKey` पास करने वाले `operator.write` कॉलर को सीमित सत्र-कुंजी दृश्यता के लिए `spawnedBy` भी पास करना होगा; बिना सीमांकन वाला `sessionKey` निर्माण और `brain: "direct-tools"` के लिए `operator.admin` आवश्यक है। - `talk.session.join` प्रबंधित-कक्ष सत्र टोकन को सत्यापित करता है, आवश्यकतानुसार `session.ready` या `session.replaced` उत्सर्जित करता है और कक्ष/सत्र मेटाडेटा के साथ हालिया Talk ईवेंट लौटाता है, लेकिन कभी भी प्लेनटेक्स्ट टोकन या उसका हैश नहीं लौटाता। - `talk.session.appendAudio` Gateway के स्वामित्व वाले रीयलटाइम रिले और ट्रांसक्रिप्शन सत्रों में base64 PCM इनपुट ऑडियो जोड़ता है। - `talk.session.startTurn`, `talk.session.endTurn`, और `talk.session.cancelTurn` स्थिति साफ़ होने से पहले पुराने टर्न को अस्वीकार करते हुए प्रबंधित-कक्ष टर्न जीवनचक्र संचालित करते हैं। - `talk.session.cancelOutput` सहायक का ऑडियो आउटपुट रोकता है, मुख्यतः Gateway रिले सत्रों में VAD-नियंत्रित बीच में बोलने के लिए। - `talk.session.submitToolResult` Gateway के स्वामित्व वाले रीयलटाइम रिले सत्र द्वारा उत्सर्जित प्रदाता टूल कॉल को पूरा करता है। अनुरोध प्रदाता ब्रिज द्वारा उपलब्ध कराए गए किसी भी अतुल्यकालिक पूर्णता संकेत की प्रतीक्षा करता है; विफल सबमिशन संबद्ध रन को सक्रिय रखते हैं और सफल टूल-परिणाम ईवेंट उत्सर्जित नहीं करते। अंतरिम टूल आउटपुट के लिए `options: { willContinue: true }` पास करें या जब प्रदाता ब्रिज दमन समर्थन घोषित करता हो और परिणाम से दूसरी प्रतिक्रिया शुरू नहीं होनी चाहिए, तब `options: { suppressResponse: true }` पास करें। - `talk.session.steer` Gateway के स्वामित्व वाले एजेंट-समर्थित Talk सत्र में सक्रिय-रन वॉइस नियंत्रण भेजता है: `{ sessionId, text, mode? }`, जहाँ `mode`, `status`, `steer`, `cancel`, या `followup` है; छोड़े गए मोड को बोले गए टेक्स्ट से वर्गीकृत किया जाता है। - `talk.session.close` Gateway के स्वामित्व वाले रिले, ट्रांसक्रिप्शन या प्रबंधित-कक्ष सत्र को बंद करता है और अंतिम Talk ईवेंट उत्सर्जित करता है। - `talk.mode` WebChat/Control UI क्लाइंट के लिए वर्तमान Talk मोड स्थिति सेट/प्रसारित करता है। - `talk.client.create` `webrtc` या `provider-websocket` का उपयोग करके क्लाइंट के स्वामित्व वाला रीयलटाइम प्रदाता सत्र बनाता या फिर से शुरू करता है, जबकि Gateway क्रेडेंशियल, निर्देश, टूल नीति और लौटाए गए `voiceSessionId` का स्वामित्व रखता है। क्लाइंट `sessionKey` पास करते हैं और एक कॉल के दौरान प्रदाता ट्रांसपोर्ट बदलते समय `voiceSessionId` का पुनः उपयोग करते हैं। - `talk.client.transcript` सामान्य एजेंट सत्र में एक अंतिम रूप दिया गया `{ role, text }` आइटम जोड़ता है। आवश्यक `entryId`, `voiceSessionId` के भीतर इडेम्पोटेंट है; पुनः प्रयास ट्रांसक्रिप्ट संदेशों की प्रतिलिपि नहीं बनाते। - `talk.client.close` लंबित ट्रांसक्रिप्ट लेखन के बाद तार्किक वॉइस सत्र बंद करता है। बंद करना इडेम्पोटेंट है और यह सत्र के अंतिम गैर-WebChat चैनल पर केवल-म्यूटेशन कॉल सारांश पहुँचा सकता है। - `talk.client.toolCall` क्लाइंट के स्वामित्व वाले रीयलटाइम ट्रांसपोर्ट को प्रदाता टूल कॉल Gateway नीति तक अग्रेषित करने देता है। पहला समर्थित टूल `openclaw_agent_consult` है; क्लाइंट को एक रन आईडी मिलती है और वे प्रदाता-विशिष्ट टूल परिणाम सबमिट करने से पहले सामान्य चैट जीवनचक्र ईवेंट की प्रतीक्षा करते हैं। वॉइस-बाउंड उच्च-प्रभाव वाली कार्रवाइयाँ तब तक `VOICE_CONFIRMATION_REQUIRED:` लौटाती हैं, जब तक बाद का अंतिम रूप दिया गया उपयोगकर्ता कथन उस सटीक कार्रवाई की स्पष्ट रूप से पुष्टि नहीं करता और अगला परामर्श `confirmationId` प्रदान नहीं करता। - `talk.client.steer` क्लाइंट के स्वामित्व वाले रीयलटाइम ट्रांसपोर्ट के लिए सक्रिय-रन वॉइस नियंत्रण भेजता है। Gateway `sessionKey` से सक्रिय एम्बेडेड रन निर्धारित करता है और निर्देशन को चुपचाप छोड़ने के बजाय संरचित स्वीकृत/अस्वीकृत परिणाम लौटाता है। - `talk.event` रीयलटाइम, ट्रांसक्रिप्शन, STT/TTS, प्रबंधित-कक्ष, टेलीफ़ोनी और मीटिंग एडाप्टर के लिए एकल Talk ईवेंट चैनल है। - `talk.speak` सक्रिय Talk वाक् प्रदाता के माध्यम से वाक् संश्लेषित करता है। - `tts.status` TTS सक्षम स्थिति, सक्रिय प्रदाता, फ़ॉलबैक प्रदाता और प्रदाता कॉन्फ़िगरेशन स्थिति लौटाता है। - `tts.providers` दृश्यमान TTS प्रदाता सूची लौटाता है। - `tts.enable` और `tts.disable` TTS प्राथमिकता स्थिति को टॉगल करते हैं। - `tts.setProvider` पसंदीदा TTS प्रदाता को अपडेट करता है। - `tts.convert` एकबारगी टेक्स्ट-से-वाक् रूपांतरण चलाता है। - `tts.speak` (`operator.write`) कॉन्फ़िगर की गई सामान्य TTS प्रदाता शृंखला के साथ गैर-रिक्त `text` रेंडर करता है और एक संपूर्ण क्लिप को इनलाइन `audioBase64` के रूप में लौटाता है, साथ ही `provider` और वैकल्पिक `outputFormat`, `mimeType`, तथा `fileExtension` मेटाडेटा भी लौटाता है। `tts.convert` के विपरीत, यह Gateway-स्थानीय पथ नहीं लौटाता; `talk.speak` के विपरीत, इसे Talk प्रदाता की आवश्यकता नहीं होती। `tts.maxTextLength` से अधिक टेक्स्ट `INVALID_REQUEST` लौटाता है; संश्लेषण विफलताएँ `UNAVAILABLE` लौटाती हैं। - `secrets.reload` सक्रिय SecretRefs को फिर से रिज़ॉल्व करता है और स्वामी-जागरूक रनटाइम स्थिति को परमाण्विक रूप से प्रकाशित करता है। पात्र स्वामी विफलताएँ `warningCount` के साथ कोल्ड या स्टेल डिग्रेडेशन के रूप में प्रकाशित हो सकती हैं; सख्त या अमैप्ड विफलताएँ रीलोड को अस्वीकार करती हैं और सक्रिय स्नैपशॉट को सुरक्षित रखती हैं। - `secrets.resolve` किसी विशिष्ट कमांड/लक्ष्य सेट के लिए कमांड-लक्ष्य सीक्रेट असाइनमेंट रिज़ॉल्व करता है। - `config.get` वर्तमान ऑन-डिस्क कॉन्फ़िगरेशन स्नैपशॉट, रॉ रूट-फ़ाइल `hash`, रिज़ॉल्व किया गया `configRevisionHash`, और सक्रिय Gateway रनटाइम द्वारा स्वीकार किए गए रिज़ॉल्व किए गए संशोधन के लिए वैकल्पिक `appliedConfigHash` लौटाता है। - `config.set` सत्यापित कॉन्फ़िगरेशन पेलोड लिखता है। - `config.patch` आंशिक कॉन्फ़िगरेशन अपडेट को मर्ज करता है। विनाशकारी ऐरे प्रतिस्थापन के लिए प्रभावित पथ का `replacePaths` में होना आवश्यक है; ऐरे प्रविष्टियों के अंतर्गत नेस्टेड ऐरे `agents.entries.*.skills` जैसे `[]` पथों का उपयोग करते हैं। - `config.apply` पूर्ण कॉन्फ़िगरेशन पेलोड को सत्यापित करके प्रतिस्थापित करता है। - `config.schema` Control UI और CLI टूलिंग द्वारा उपयोग किया जाने वाला लाइव कॉन्फ़िगरेशन स्कीमा पेलोड लौटाता है: स्कीमा, `uiHints`, संस्करण, जनरेशन मेटाडेटा, और लोड किए जा सकने पर Plugin + चैनल स्कीमा मेटाडेटा। इसमें UI के समान लेबल/सहायता टेक्स्ट से `title` / `description` मेटाडेटा शामिल होता है, जिसमें मेल खाने वाला फ़ील्ड दस्तावेज़ उपलब्ध होने पर नेस्टेड ऑब्जेक्ट, वाइल्डकार्ड, ऐरे-आइटम और `anyOf` / `oneOf` / `allOf` संयोजन शाखाएँ शामिल हैं। - `config.schema.lookup` एक कॉन्फ़िगरेशन पथ के लिए पथ-स्कोप्ड लुकअप पेलोड लौटाता है: सामान्यीकृत पथ, एक शैलो स्कीमा नोड, मेल खाने वाला संकेत + `hintPath`, वैकल्पिक `reloadKind`, और UI/CLI ड्रिल-डाउन के लिए निकटतम चाइल्ड सारांश। `reloadKind`, `restart`, `hot`, या `none` (`src/config/schema.ts`) में से एक है और अनुरोधित पथ के लिए Gateway कॉन्फ़िगरेशन रीलोड प्लानर को प्रतिबिंबित करता है। लुकअप स्कीमा नोड उपयोगकर्ता-दृश्य दस्तावेज़ और सामान्य सत्यापन फ़ील्ड (`title`, `description`, `type`, `enum`, `const`, `format`, `pattern`, संख्यात्मक/स्ट्रिंग/ऐरे/ऑब्जेक्ट सीमाएँ, `additionalProperties`, `deprecated`, `readOnly`, `writeOnly`) बनाए रखते हैं। चाइल्ड सारांश `key`, सामान्यीकृत `path`, `type`, `required`, `hasChildren`, वैकल्पिक `reloadKind`, और मेल खाने वाला `hint` / `hintPath` प्रदर्शित करते हैं। - `update.run` Gateway अपडेट प्रवाह चलाता है और केवल अपडेट सफल होने पर पुनरारंभ शेड्यूल करता है; सत्र वाले कॉलर `continuationMessage` शामिल कर सकते हैं, ताकि स्टार्टअप पुनरारंभ निरंतरता कतार के माध्यम से एजेंट का एक अनुवर्ती टर्न फिर से शुरू करे। कंट्रोल प्लेन से पैकेज-मैनेजर अपडेट और पर्यवेक्षित git-checkout अपडेट, लाइव Gateway के भीतर पैकेज ट्री को प्रतिस्थापित करने या checkout/build आउटपुट को बदलने के बजाय एक अलग किए गए प्रबंधित-सेवा हैंडऑफ़ का उपयोग करते हैं। आरंभ किया गया हैंडऑफ़ `result.reason: "managed-service-handoff-started"` और `handoff.status: "started"` के साथ `ok: true` लौटाता है। उसी Gateway प्रक्रिया द्वारा संभाला गया दूसरा समवर्ती `update.run`, `result.reason: "managed-service-handoff-already-running"` और `handoff.status: "already-running"` के साथ `ok: false` लौटाता है; उसकी निरंतरता स्वीकार नहीं की जाती, इसलिए सक्रिय अपडेट पूरा होने के बाद कॉलर पुनः प्रयास कर सकता है। स्टैंडअलोन CLI अपडेटर और प्रतिस्थापन Gateway प्रक्रियाएँ इस प्रक्रिया-स्थानीय गार्ड के बाहर हैं। अनुपलब्ध या विफल हैंडऑफ़ `managed-service-handoff-unavailable` या `managed-service-handoff-failed` के साथ `ok: false`, तथा मैन्युअल शेल अपडेट आवश्यक होने पर `handoff.command` लौटाते हैं। अनुपलब्ध का अर्थ है कि OpenClaw में सुरक्षित सुपरवाइज़र सीमा या स्थायी सेवा पहचान का अभाव है, जैसे systemd के लिए `OPENCLAW_SYSTEMD_UNIT`। आरंभ किए गए हैंडऑफ़ के दौरान पुनरारंभ सेंटिनल थोड़े समय के लिए `stats.reason: "restart-health-pending"` रिपोर्ट कर सकता है; निरंतरता तब तक विलंबित रहती है, जब तक CLI पुनरारंभ किए गए Gateway को सत्यापित करके अंतिम `ok` सेंटिनल नहीं लिख देता। - `update.status` नवीनतम अपडेट पुनरारंभ सेंटिनल को रीफ़्रेश करके लौटाता है, जिसमें उपलब्ध होने पर पुनरारंभ के बाद चल रहा संस्करण शामिल होता है। - `wizard.start`, `wizard.next`, `wizard.status`, और `wizard.cancel` ऑनबोर्डिंग विज़ार्ड को WS RPC के माध्यम से उपलब्ध कराते हैं। - `agents.list` Gateway को दिखाई देने वाली एजेंट प्रविष्टियाँ लौटाता है, जिनमें प्रभावी मॉडल/रनटाइम मेटाडेटा और वैकल्पिक अर्थगत `kind` (`agent` या `system`) शामिल हैं। पूर्ण टाइप्ड रोस्टर प्राप्त करने के लिए क्लाइंट `agent-kind` हैंडशेक क्षमता घोषित करते हैं; इसके बिना क्लाइंट सिस्टम पंक्तियों से रहित पुराना, सिलेक्टर-सुरक्षित रोस्टर बनाए रखते हैं। प्रकार-जागरूक क्लाइंट सामान्य सिलेक्टरों से `system` पंक्तियाँ बाहर रखते हैं, जबकि उन्हें डायग्नोस्टिक दृश्यों में बनाए रखते हैं। पुराने v4 Gateway `kind` के बिना पंक्तियाँ लौटा सकते हैं। - `agents.create`, `agents.update`, और `agents.delete` एजेंट रिकॉर्ड और कार्यक्षेत्र वायरिंग का प्रबंधन करते हैं। - `agents.files.list`, `agents.files.get`, और `agents.files.set` किसी एजेंट के लिए उपलब्ध कराई गई बूटस्ट्रैप कार्यक्षेत्र फ़ाइलों का प्रबंधन करते हैं। - `audit.activity.list` संस्करणयुक्त, केवल-मेटाडेटा गतिविधि लेजर लौटाता है; `audit.list` संगतता-सुरक्षित रन/टूल RPC बना रहता है। - `agents.workspace.list` और `agents.workspace.get` (`operator.read`), [ऑपरेटर स्कोप](/hi/gateway/operator-scopes) में वर्णित विश्वसनीय ऑपरेटर डोमेन के क्लाइंट के लिए एजेंट की कार्यक्षेत्र डायरेक्टरी की केवल-पढ़ने योग्य, पृष्ठांकित ब्राउज़िंग उपलब्ध कराते हैं। अनुरोध केवल कार्यक्षेत्र-सापेक्ष पथ स्वीकार करते हैं; रीड वास्तविक पथ में बदले गए कार्यक्षेत्र रूट तक सीमित रहते हैं (सिमलिंक और हार्डलिंक एस्केप अस्वीकार किए जाते हैं), आकार-सीमित होते हैं, और UTF-8 टेक्स्ट तथा सामान्य इमेज प्रकारों (base64) तक सीमित रहते हैं। प्रतिक्रियाएँ होस्ट कार्यक्षेत्र पथ प्रदर्शित नहीं करतीं। इस नेमस्पेस में कोई लेखन ऑपरेशन नहीं है। - `tasks.list`, `tasks.get`, और `tasks.cancel` SDK और ऑपरेटर क्लाइंट के लिए Gateway टास्क लेजर उपलब्ध कराते हैं। नीचे [टास्क लेजर RPC](#task-ledger-rpcs) देखें। - `artifacts.list`, `artifacts.get`, और `artifacts.download` स्पष्ट `sessionKey`, `runId`, या `taskId` स्कोप के लिए ट्रांसक्रिप्ट से प्राप्त आर्टिफ़ैक्ट सारांश और डाउनलोड उपलब्ध कराते हैं। रन और टास्क क्वेरी स्वामी सत्र को सर्वर-साइड पर रिज़ॉल्व करती हैं और केवल मेल खाने वाले उद्गम वाला ट्रांसक्रिप्ट मीडिया लौटाती हैं; असुरक्षित या स्थानीय URL स्रोतों को सर्वर-साइड पर फ़ेच करने के बजाय असमर्थित डाउनलोड लौटाए जाते हैं। - `environments.list` और `environments.status` Gateway-स्थानीय और Node परिवेश खोज को बनाए रखते हैं। कॉन्फ़िगर किए गए क्लाउड वर्कर और पुराने प्रोफ़ाइल द्वारा छोड़े गए स्थायी रिकॉर्ड, `providerId`, वैकल्पिक `leaseId`, `state`, `ageMs`, वैकल्पिक `idleMs`, और `attachedSessionIds` के साथ `worker` मेटाडेटा जोड़ते हैं। वर्कर जीवनचक्र स्थितियाँ `requested`, `provisioning`, `bootstrapping`, `ready`, `attached`, `idle`, `draining`, `destroying`, `destroyed`, `failed`, और `orphaned` हैं। - `environments.create` (`{ profileId, idempotencyKey }`) कॉन्फ़िगर की गई Plugin प्रदाता प्रोफ़ाइल से एक वर्कर प्रोविज़न करता है; समान कुंजी वाले पुनः प्रयास स्थायी ऑपरेशन का पुनः उपयोग करते हैं। `environments.destroy` (`{ environmentId }`) स्थायी वर्कर परिवेश को इडेम्पोटेंट रूप से हटाने का अनुरोध करता है। दोनों को `operator.admin` आवश्यक है, दोनों कंट्रोल-प्लेन लेखन हैं, और दोनों स्थिति प्रतिक्रियाओं में प्रयुक्त समान परिवेश सारांश संरचना लौटाते हैं। - `agent.identity.get` किसी एजेंट या सत्र के लिए प्रभावी सहायक पहचान लौटाता है। - `agent.wait` रन समाप्त होने की प्रतीक्षा करता है और उपलब्ध होने पर अंतिम स्नैपशॉट लौटाता है। - `sessions.list` वर्तमान सत्र अनुक्रमणिका लौटाता है, जिसमें एजेंट रनटाइम बैकएंड कॉन्फ़िगर होने पर प्रत्येक पंक्ति का `agentRuntime` मेटाडेटा शामिल होता है। क्लाउड-वर्कर प्लेसमेंट सक्षम होने या टिकाऊ पुनर्प्राप्ति स्थिति मौजूद होने पर, सत्र पंक्तियों में एक बंद `placement` स्थिति (`local`, `requested`, `provisioning`, `syncing`, `starting`, `active`, `draining`, `reconciling`, `reclaimed`, या `failed`) के साथ स्थिति-विशिष्ट परिवेश, स्वामी-युग, कार्यक्षेत्र, बंडल, ACK-कर्सर या पुनर्प्राप्ति फ़ील्ड भी शामिल होते हैं। - `sessions.subscribe` और `sessions.unsubscribe` वर्तमान WS क्लाइंट के लिए सत्र परिवर्तन इवेंट सदस्यताओं को चालू या बंद करते हैं। - `sessions.messages.subscribe` और `sessions.messages.unsubscribe` किसी एक सत्र के लिए ट्रांसक्रिप्ट/संदेश इवेंट सदस्यताओं को चालू या बंद करते हैं। उन अनुमोदनों के लिए सैनिटाइज़ किए गए `session.approval` जीवनचक्र इवेंट भी प्राप्त करने हेतु `includeApprovals: true` पास करें, जिनके स्थायी ऑडियंस में वही सटीक सत्र शामिल है और जिनकी समीक्षक बाइंडिंग सदस्यता लेने वाले क्लाइंट को अधिकृत करती है। तब सदस्यता प्रतिक्रिया में एक सीमित लंबित `approvalReplay` शामिल होता है; `truncated` के false होने पर यह प्रामाणिक होता है। ऑप्ट-इन प्रत्येक सदस्यता कॉल के लिए होता है, स्थायी नहीं: उसी सत्र की `includeApprovals: true` के बिना दोबारा सदस्यता लेने पर मौजूदा अनुमोदन सदस्यता हट जाती है। सामान्य सत्र-पठन प्राधिकार के अतिरिक्त, इस ऑप्ट-इन के लिए `operator.admin`, या युग्मित डिवाइस पर `operator.approvals` आवश्यक है। - `sessions.preview` विशिष्ट सत्र कुंजियों के लिए सीमित ट्रांसक्रिप्ट पूर्वावलोकन लौटाता है। - `sessions.describe` किसी सटीक सत्र कुंजी के लिए एक Gateway सत्र पंक्ति लौटाता है। - `sessions.resolve` किसी सत्र लक्ष्य को हल या कैनॉनिकलाइज़ करता है। - `sessions.create` एक नई सत्र प्रविष्टि बनाता है। वैकल्पिक `model` और `thinkingLevel` मान प्रारंभिक मॉडल और रीजनिंग ओवरराइड को परमाण्विक रूप से स्थायी करते हैं। `worktree: true` एक प्रबंधित वर्कट्री का प्रावधान करता है; वैकल्पिक `worktreeBaseRef`/`worktreeName` आधार रेफ़ और शाखा नाम चुनते हैं, और `execNode` (`operator.admin`) सत्र निष्पादन को किसी Node होस्ट से बाँधता है। बनाया गया वर्कट्री परिणाम में दोहराया जाता है और सत्र पंक्ति (`worktree: { id, branch, repoRoot }`) पर स्थायी किया जाता है। जब प्रविष्टि बन जाती है लेकिन उसका नेस्टेड प्रारंभिक `chat.send` अस्वीकार हो जाता है, तो सफल परिणाम में `runStarted: false` और `runError` शामिल होते हैं; क्लाइंट प्रॉम्प्ट को बनाए रखकर लौटाई गई सत्र कुंजी के विरुद्ध पुनः प्रयास कर सकते हैं। `emitCommandHooks: true` के साथ `parentSessionKey` पास करने वाले कॉलर को किसी अलग चाइल्ड की जीवनचक्र व्यवस्था भी घोषित करनी चाहिए: `succeedsParent: true`, `session_end` के साथ पैरेंट को समाप्त करता है, जबकि `false` पैरेंट को सक्रिय रखता है और केवल चाइल्ड का `session_start` उत्सर्जित करता है। `succeedsParent` को छोड़ देने पर मौजूदा क्लाइंट के लिए विरासती पैरेंट-रोलओवर व्यवहार बना रहता है। इस व्यवस्था के लिए पैरेंट लिंकेज और कमांड हुक, दोनों आवश्यक हैं; कोई फ़ोर्क अपने पैरेंट को सफल नहीं कर सकता। मुख्य सत्र का उसी स्थान पर रीसेट होने का व्यवहार अपरिवर्तित रहता है, क्योंकि कोई अलग चाइल्ड नहीं बनाया जाता। नई पंक्तियों पर विश्वसनीय निर्माण सीम से केवल-एक-बार लिखी जाने वाली निर्माण उत्पत्ति (`createdVia`, `createdActor`, `createdAt`) अंकित की जाती है; किसी मौजूदा कुंजी को अपनाने पर इसे दोबारा अंकित नहीं किया जाता। मानव प्रोफ़ाइल अभिनेताओं के लिए, पंक्ति को प्रक्षेपित करते समय `createdActor.label` को वर्तमान उपयोगकर्ता प्रोफ़ाइल से हल किया जाता है और इसे सत्र प्रविष्टि पर कभी संग्रहीत नहीं किया जाता, इसलिए प्रोफ़ाइल का नाम बदलने पर विचलन नहीं होता। सत्र पंक्तियों में `parentSessionKey` (नेविगेशन पैरेंट, स्थायी), `controlOwnerSessionKey` (लाइव होने पर रनटाइम नियंत्रक), `forkSource` (फ़ोर्क के लिए सटीक स्रोत कुंजी + ट्रांसक्रिप्ट जनरेशन), और `previousSessionId` (उसी कुंजी के अंतर्गत पिछला ट्रांसक्रिप्ट जनरेशन) भी होते हैं। - `sessions.dispatch` (`operator.admin`) किसी सत्र-स्वामित्व वाले प्रबंधित वर्कट्री सहित मौजूदा स्थानीय OpenClaw सत्र को कॉन्फ़िगर किए गए क्लाउड-वर्कर प्रोफ़ाइल में ले जाता है। `{ key, profileId, agentId? }` पास करें। कोई वर्कर प्रोफ़ाइल कॉन्फ़िगर न होने पर यह विधि अनुपस्थित रहती है, सक्रिय कार्य को समाप्त होने देने से पहले स्थानीय टर्न प्रवेश बंद करती है, और प्लेसमेंट के `active` वर्कर स्वामित्व तक पहुँचने के बाद ही लौटती है। डिस्पैच एकतरफ़ा है; वर्कर से स्थानीय में वापस खींचना इस RPC का भाग नहीं है। - `sessions.groups.list`, `sessions.groups.put`, `sessions.groups.rename`, और `sessions.groups.delete` Gateway-स्वामित्व वाली कस्टम सत्र समूह सूची (नाम + प्रदर्शन क्रम) को प्रबंधित करते हैं। सदस्यता प्रत्येक सत्र के `category` फ़ील्ड पर रहती है; नाम बदलने और हटाने पर सर्वर की ओर से सदस्य सत्र अपडेट होते हैं। - `sessions.send` किसी मौजूदा सत्र में संदेश भेजता है। - `sessions.steer` सक्रिय सत्र के लिए बाधित-करें-और-दिशा-दें प्रकार है। - `sessions.abort` किसी सत्र का सक्रिय कार्य रद्द करता है। `key` के साथ वैकल्पिक `runId` पास करें, या उन सक्रिय रन के लिए केवल `runId` पास करें जिन्हें Gateway किसी सत्र से संबद्ध कर सकता है। `runId` देने पर रद्दीकरण उसी रन तक सीमित रहता है। केवल-कुंजी वाले गैर-ग्लोबल अनुरोध पर `clearQueued: true` सेट करने से उस सत्र के स्वामित्व वाली फ़ॉलोअप और लेन कतारें भी हटा दी जाती हैं। `clearQueued` को छोड़ने वाले मौजूदा कॉलर उन कतारों को बनाए रखते हैं। शाब्दिक `global` कुंजी मौजूदा एजेंट-योग्य `chat.abort` स्वामित्व नियम बनाए रखती है और गैर-ग्लोबल फ़ॉलोअप या लेन सफ़ाई नहीं करती। - `sessions.patch` सत्र मेटाडेटा/ओवरराइड अपडेट करता है और हल किया गया कैनॉनिकल मॉडल तथा प्रभावी `agentRuntime` रिपोर्ट करता है। स्पॉन वंशावली (`spawnedBy`, `spawnedWorkspaceDir`, `spawnedCwd`, `spawnDepth`, `subagentRole`, `subagentControlScope`) अब सार्वजनिक रूप से पैच नहीं की जा सकती; ये तथ्य विश्वसनीय निर्माण पथों द्वारा केवल एक बार लिखे जाते हैं, और इन्हें अब भी भेजने वाले अनुरोध अस्वीकार कर दिए जाते हैं। - `sessions.reset`, `sessions.delete`, और `sessions.compact` सत्र रखरखाव करते हैं। - `sessions.get` पूर्ण संग्रहीत सत्र पंक्ति लौटाता है। - चैट निष्पादन अब भी `chat.history`, `chat.send`, `chat.abort`, और `chat.inject` का उपयोग करता है। UI क्लाइंट के लिए `chat.history` को प्रदर्शन हेतु सामान्यीकृत किया जाता है: दृश्यमान टेक्स्ट से इनलाइन डायरेक्टिव टैग हटा दिए जाते हैं, सादे-टेक्स्ट वाले टूल-कॉल XML पेलोड (`...`, `...`, `...`, `...`, और काटे गए टूल-कॉल ब्लॉक) तथा लीक हुए ASCII/पूर्ण-चौड़ाई मॉडल नियंत्रण टोकन हटा दिए जाते हैं, पूर्णतः मौन-टोकन सहायक पंक्तियाँ (सटीक `NO_REPLY` / `no_reply`) छोड़ दी जाती हैं, और बहुत बड़ी पंक्तियों को प्लेसहोल्डर से बदला जा सकता है। - `chat.message.get` किसी एक दृश्यमान ट्रांसक्रिप्ट प्रविष्टि के लिए योगात्मक, सीमित पूर्ण-संदेश रीडर है। `sessionKey`, सत्र चयन के एजेंट-स्कोप्ड होने पर वैकल्पिक `agentId`, और पहले `chat.history` के माध्यम से सामने आया ट्रांसक्रिप्ट `messageId` पास करें; यदि संग्रहीत प्रविष्टि अब भी उपलब्ध है और बहुत बड़ी नहीं है, तो Gateway हल्की हिस्ट्री की काट-छाँट सीमा के बिना वही प्रदर्शन-सामान्यीकृत प्रक्षेपण लौटाता है। - `chat.toolTitles` Control UI में रेंडर किए गए टूल कॉल के लिए छोटे उद्देश्य शीर्षक लौटाता है (बैच में, सीमित इनपुट के साथ अधिकतम 24 आइटम)। यह सुविधा `gateway.controlUi.toolTitles` के माध्यम से ऑप्ट-इन है (डिफ़ॉल्ट रूप से बंद); अक्षम Gateway बिना मॉडल कॉल के `{ titles: {}, disabled: true }` का उत्तर देते हैं, ताकि क्लाइंट पूछना बंद कर दें। सक्षम होने पर, शीर्षक मानक यूटिलिटी-मॉडल रूटिंग का उपयोग करते हैं: स्पष्ट रूप से कॉन्फ़िगर किया गया `utilityModel` (एक ऑपरेटर निर्णय, जो सभी यूटिलिटी कार्यों की तरह सीमित कार्य सामग्री चुने गए प्रदाता को भेज सकता है), अन्यथा सत्र प्रदाता का घोषित छोटा-मॉडल डिफ़ॉल्ट, ताकि कोई नया निर्गमन गंतव्य अप्रत्यक्ष रूप से न दिखाई दे; खाली `utilityModel` इन्हें पूरी तरह अक्षम कर देता है। शीर्षक कभी भी प्राथमिक मॉडल पर फ़ॉलबैक नहीं करते। परिणामों को टूल नाम + इनपुट के आधार पर प्रत्येक एजेंट की स्थिति डेटाबेस में कैश किया जाता है, इसलिए बार-बार देखने पर समान कॉल का दोबारा शुल्क नहीं लगता। - `chat.send` स्वचालित कटऑफ़ से पहले शुरू हुए मॉडल कॉल के लिए फ़ास्ट मोड उपयोग करने हेतु एक-टर्न `fastMode: "auto"` स्वीकार करता है, फिर बाद के पुनः प्रयास, फ़ॉलबैक, टूल-परिणाम या निरंतरता कॉल को फ़ास्ट मोड के बिना शुरू करता है। कटऑफ़ डिफ़ॉल्ट रूप से 60 सेकंड (`DEFAULT_FAST_MODE_AUTO_ON_SECONDS`) होता है और इसे `agents.defaults.models["/"].params.fastAutoOnSeconds` से प्रत्येक मॉडल के लिए कॉन्फ़िगर किया जा सकता है। कोई `chat.send` कॉलर उस अनुरोध के लिए कटऑफ़ ओवरराइड करने हेतु एक-टर्न `fastAutoOnSeconds` पास कर सकता है। केवल इस अनुरोध के लिए संग्रहीत कतार मोड ओवरराइड करने हेतु `queueMode` (`steer`, `followup`, `collect`, या `interrupt`) पास करें; स्पष्ट Control UI दिशा-परिवर्तन क्रियाएँ `queueMode: "steer"` का उपयोग करती हैं। इंटरैक्टिव क्लाइंट अपने द्वारा प्रदर्शित सक्रिय ट्रांसक्रिप्ट-शाखा लीफ़ के साथ `expectedLeafEntryId`, या प्रामाणिक खाली ट्रांसक्रिप्ट के लिए `null` पास कर सकते हैं; यदि किसी अन्य क्लाइंट ने पहले शाखा बदल दी हो, तो Gateway `details.reason: "active-leaf-changed"` के साथ भेजना अस्वीकार कर देता है। - `device.pair.list` लंबित और अनुमोदित युग्मित डिवाइस लौटाता है। - `device.pair.setupCode` एक मोबाइल सेटअप कोड और, डिफ़ॉल्ट रूप से, PNG QR डेटा URL बनाता है। इसके लिए `operator.admin` आवश्यक है और इसे जानबूझकर विज्ञापित खोज से बाहर रखा गया है। परिणाम में `setupCode`, वैकल्पिक `qrDataUrl`, `gatewayUrl`, गैर-गोपनीय `auth` लेबल, और `urlSource` शामिल होते हैं। - `device.pair.approve`, `device.pair.reject`, और `device.pair.remove` डिवाइस-युग्मन रिकॉर्ड प्रबंधित करते हैं। - `device.pair.rename` एक ऑपरेटर लेबल (`{ deviceId, label }`) निर्दिष्ट करता है, जिसे क्लाइंट द्वारा रिपोर्ट किए गए प्रदर्शन नाम पर वरीयता दी जाती है और जो डिवाइस की मरम्मत या पुनः अनुमोदन के बाद भी बना रहता है। - `device.token.rotate` किसी युग्मित डिवाइस टोकन को उसकी अनुमोदित भूमिका और कॉलर स्कोप की सीमाओं के भीतर रोटेट करता है। - `device.token.revoke` किसी युग्मित डिवाइस टोकन को उसकी अनुमोदित भूमिका और कॉलर स्कोप की सीमाओं के भीतर निरस्त करता है। सेटअप कोड में अल्पकालिक बूटस्ट्रैप क्रेडेंशियल अंतर्निहित होता है। क्लाइंट को युग्मन प्रवाह के बाद इसे लॉग या स्थायी नहीं करना चाहिए। - `node.pair.list`, `node.pair.approve`, `node.pair.reject`, और `node.pair.remove` Node क्षमता अनुमोदनों को कवर करते हैं। `node.pair.request` और `node.pair.verify` को स्वतंत्र Node युग्मन स्टोर के साथ 2026.7 में हटा दिया गया था; लंबित अनुरोध Node कनेक्ट होने के दौरान Gateway द्वारा बनाए जाते हैं। - `node.list` और `node.describe` ज्ञात/कनेक्टेड Node स्थिति लौटाते हैं। - `node.rename` किसी युग्मित Node लेबल को अपडेट करता है। - `node.invoke` किसी कनेक्टेड Node को कमांड अग्रेषित करता है। - `node.invoke.result` किसी आह्वान अनुरोध का परिणाम लौटाता है। - `mcp.tools.call.v1` किसी कॉन्फ़िगर किए गए Node-स्थानीय MCP टूल को कॉल करने के लिए हेडलेस Node-होस्ट कमांड है। इसे `node.invoke` के माध्यम से ले जाया जाता है, इसके लिए Node द्वारा कमांड घोषित करना आवश्यक है, और यह युग्मन अनुमोदन तथा `gateway.nodes.commands.deny` के अधीन रहता है। - `node.event` Node से उत्पन्न इवेंट को वापस Gateway में ले जाता है। - `node.pluginTools.update` कनेक्टेड Node के एजेंट-दृश्यमान Plugin/MCP टूल विवरणकों को बदलने का एकमात्र प्रकाशन पथ है; `connect` पैरामीटर उन्हें नहीं ले जाते। - `node.pending.pull` और `node.pending.ack` कनेक्टेड-Node कतार API हैं। - `node.pending.enqueue` और `node.pending.drain` ऑफ़लाइन/डिस्कनेक्टेड Node के लिए टिकाऊ लंबित कार्य प्रबंधित करते हैं। - `approval.history` exec, plugin और system-agent अनुरोधों (दायरा `operator.approvals`) के लिए 30 दिनों तक रखे गए नवीनतम-प्रथम अंतिम अनुमोदन लौटाता है। यह कर्सर पृष्ठांकन के साथ वैकल्पिक प्रकार फ़िल्टर का समर्थन करता है; लंबित अनुमोदन इतिहास की पंक्तियाँ नहीं हैं। - `approval.get` और `approval.resolve` प्रकार-निरपेक्ष टिकाऊ अनुमोदन विधियाँ हैं (दायरा `operator.approvals`)। `approval.get` स्थिर `urlPath` के साथ स्वच्छ किया गया लंबित या रखा गया अंतिम प्रक्षेपण लौटाता है; `approval.resolve` विहित अनुमोदन आईडी, स्पष्ट `kind` और निर्णय स्वीकार करता है, पहले उत्तर को अंतिम मानने वाला समाधान लागू करता है और हमेशा दर्ज किया गया विहित परिणाम लौटाता है। - `exec.approval.request`, `exec.approval.get`, `exec.approval.list` और `exec.approval.resolve` एकबारगी exec अनुमोदन अनुरोधों के साथ लंबित अनुमोदन खोज/पुनर्चालन को कवर करते हैं। वे उसी टिकाऊ अनुमोदन रजिस्ट्री पर प्रोटोकॉल-सीमा अडैप्टर हैं। - `exec.approval.waitDecision` एक लंबित exec अनुमोदन की प्रतीक्षा करता है और अंतिम निर्णय (या टाइमआउट होने पर `null`) लौटाता है। - `exec.approvals.get` और `exec.approvals.set` Gateway की exec अनुमोदन नीति के स्नैपशॉट प्रबंधित करते हैं। - `exec.approvals.node.get` और `exec.approvals.node.set` Node रिले कमांड के माध्यम से Node-स्थानीय exec अनुमोदन नीति प्रबंधित करते हैं। - `plugin.approval.request`, `plugin.approval.list`, `plugin.approval.waitDecision` और `plugin.approval.resolve` Plugin द्वारा परिभाषित अनुमोदन प्रवाहों को कवर करते हैं। - `ui.command`, `operator.write` कॉलर को उन कनेक्टेड Control UI क्लाइंट को टाइपयुक्त लेआउट और नेविगेशन कमांड भेजने देता है जो `ui-commands` क्षमता घोषित करते हैं। - कमांड पेन विभाजन/बंद करना/फ़ोकस, साइडबार दृश्यता, टर्मिनल/ब्राउज़र पैनल की दृश्यता और डॉक तथा सत्र नेविगेशन को कवर करते हैं। - प्रोटोकॉल v1 जानबूझकर प्रत्येक कनेक्टेड और सक्षम Control UI तक प्रसारित होता है। यदि कोई कनेक्टेड नहीं है, तो लेआउट बदलने का दिखावा करने के बजाय अनुरोध `UNAVAILABLE` के साथ विफल होता है। - स्वचालन: `wake` तत्काल या अगले Heartbeat पर सक्रियण-पाठ अंतःक्षेप निर्धारित करता है; `cron.get`, `cron.list`, `cron.status`, `cron.add`, `cron.update`, `cron.remove`, `cron.run`, `cron.runs` निर्धारित कार्य प्रबंधित करते हैं। - `cron.run` मैन्युअल संचालनों के लिए कतारबद्ध करने की शैली वाला RPC बना रहता है। जिन क्लाइंट को पूर्णता संबंधी अर्थविज्ञान चाहिए, उन्हें लौटाया गया `runId` पढ़ना और `cron.runs` को पोल करना चाहिए। - `cron.runs` वैकल्पिक गैर-रिक्त `runId` फ़िल्टर स्वीकार करता है, ताकि क्लाइंट उसी जॉब की अन्य इतिहास प्रविष्टियों से होड़ किए बिना कतारबद्ध मैन्युअल संचालन का अनुसरण कर सकें। - Skills और उपकरण: `commands.list`, `skills.*`, `tools.catalog`, `tools.effective`, `tools.invoke`। नीचे [ऑपरेटर सहायक विधियाँ](#operator-helper-methods) देखें। ### सामान्य इवेंट समूह - `chat`: UI चैट अपडेट, जैसे `chat.inject` और अन्य केवल-प्रतिलेख चैट इवेंट। प्रोटोकॉल v4 में, डेल्टा पेलोड `deltaText` रखते हैं; `message` संचयी सहायक स्नैपशॉट बना रहता है। गैर-उपसर्ग प्रतिस्थापन `replace=true` सेट करते हैं और प्रतिस्थापन पाठ के रूप में `deltaText` का उपयोग करते हैं। - `session.message`, `session.operation`, `session.tool`: सदस्यता लिए गए सत्र के लिए प्रतिलेख, प्रगति में चल रहा सत्र संचालन और इवेंट-स्ट्रीम अपडेट। - `session.approval`: स्पष्ट रूप से सहमति देने वाले सटीक-सत्र सदस्य के लिए स्वच्छ किया गया लंबित और अंतिम अनुमोदन सत्य। चाइल्ड अनुमोदन स्थायी पूर्वज ऑडियंस का उपयोग करते हैं; इवेंट कभी भी प्रतिलेख परिवर्तित नहीं करते या एजेंट को सक्रिय नहीं करते। - `sessions.changed`: सत्र इंडेक्स या मेटाडेटा बदला। - `presence`: सिस्टम उपस्थिति स्नैपशॉट अपडेट। - `tick`: आवधिक कीपअलाइव/सक्रियता इवेंट। - `health`: Gateway स्वास्थ्य स्नैपशॉट अपडेट। - `heartbeat`: Heartbeat इवेंट स्ट्रीम अपडेट। - `cron`: Cron संचालन/जॉब परिवर्तन इवेंट। - `shutdown`: Gateway शटडाउन सूचना। - `node.pair.requested` / `node.pair.resolved`: Node पेयरिंग जीवनचक्र। - `node.invoke.request`: Node इनवोक अनुरोध प्रसारण। - `device.pair.requested` / `device.pair.resolved`: पेयर किए गए डिवाइस का जीवनचक्र। - `voicewake.changed`: वेक-वर्ड ट्रिगर कॉन्फ़िगरेशन बदला। - `config.changed`: कॉन्फ़िगरेशन लेखन स्थायी हुआ (पेलोड में कॉन्फ़िगरेशन पथ, नया स्नैपशॉट हैश और टाइमस्टैम्प होता है—कॉन्फ़िगरेशन सामग्री कभी नहीं)। ऑपरेटर-पठन दायरे वाला; क्लाइंट `config.get` के माध्यम से रीफ़्रेश करते हैं। - `exec.approval.requested` / `exec.approval.resolved`: exec अनुमोदन जीवनचक्र। - `plugin.approval.requested` / `plugin.approval.resolved`: Plugin अनुमोदन जीवनचक्र। ### Node सहायक विधियाँ स्वतः-अनुमति जाँच के लिए कौशल निष्पादनयोग्य फ़ाइलों की वर्तमान सूची प्राप्त करने हेतु Node, `skills.bins` को कॉल कर सकते हैं। ## ऑडिट लेजर RPC `audit.activity.list` ऑपरेटर क्लाइंट को एजेंट संचालन, उपकरण क्रिया और सहमति-आधारित संदेश जीवनचक्र मेटाडेटा का स्थिर नवीनतम-प्रथम दृश्य देता है। इसके लिए `operator.read` आवश्यक है। क्वेरी 30 दिनों से पुराने रिकॉर्ड बाहर रखती हैं और साझा SQLite लेजर की सीमा 100,000 रिकॉर्ड है। समय-सीमा समाप्त पंक्तियाँ Gateway स्टार्टअप, प्रति घंटे रखरखाव और बाद के लेखनों के दौरान हटाई जाती हैं। डेटा मॉडल और गोपनीयता अर्थविज्ञान के लिए [ऑडिट इतिहास](/hi/gateway/audit) देखें। - पैरामीटर: वैकल्पिक सटीक `agentId`, `sessionKey` या `runId`; वैकल्पिक `kind` (`"agent_run"`, `"tool_action"` या `"message"`); वैकल्पिक `status` (`"started"`, `"succeeded"`, `"failed"`, `"cancelled"`, `"timed_out"`, `"blocked"` या `"unknown"`); वैकल्पिक संदेश `direction` (`"inbound"` या `"outbound"`) और सटीक `channel`; वैकल्पिक समावेशी `after` / `before` यूनिक्स-मिलीसेकंड सीमाएँ; `1` से `500` तक वैकल्पिक `limit`; और पिछले पृष्ठ का वैकल्पिक स्ट्रिंग `cursor`। - परिणाम: `{ "events": AuditActivityEventV1[], "nextCursor"?: string }`। नामित V1 परिणाम यूनियन में एजेंट-संचालन, उपकरण-क्रिया, इनबाउंड-संदेश और आउटबाउंड-संदेश के लिए अलग-अलग स्कीमा हैं। `eventType` डिस्क्रिमिनेटर क्रमशः `agent_run`, `tool_action`, `inbound_message` या `outbound_message` है; `kind` और संदेश `direction` फ़िल्टरिंग और प्रदर्शन के लिए उपलब्ध रहते हैं। प्रत्येक इवेंट में पूर्णांक `schemaVersion: 1` होता है। संदेश पहचान संदर्भ सटीक `hmac-sha256:v1:<32 hex key id>:<64 hex digest>` प्रारूप का उपयोग करते हैं; चैनल-प्रेषक अभिनेता आईडी भी इसी प्रारूप का उपयोग करती है। सभी वेरिएंट के लिए `eventType`, `schemaVersion`, `eventId`, `sequence`, `sourceSequence`, `occurredAt`, `kind`, `action`, `status`, `actor` और `redaction` आवश्यक हैं। वेरिएंट फ़ील्ड ये हैं: | `eventType` | आवश्यक फ़ील्ड | वैकल्पिक फ़ील्ड | | ------------------ | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | `agent_run` | `agentId`, `runId`; `kind: "agent_run"` | `sessionKey`, `sessionId`, `errorCode` | | `tool_action` | `agentId`, `runId`; `kind: "tool_action"` | `sessionKey`, `sessionId`, `toolCallId`, `toolName`, `errorCode` | | `inbound_message` | `direction: "inbound"`, `channel`, `conversationKind`, `outcome` | `agentId`, `runId`, `durationMs`, `resultCount`, पहचान संदर्भ, `reasonCode`, `errorCode` | | `outbound_message` | `direction: "outbound"`, `channel`, `conversationKind`, `outcome` | `agentId`, `runId`, `durationMs`, `resultCount`, पहचान संदर्भ, `reasonCode`, `deliveryKind`, `failureStage`, `errorCode` | बंद संदेश एनम ये हैं: - `conversationKind`: `direct`, `group`, `channel` या `unknown`। - इनबाउंड `outcome`: `completed`, `skipped` या `failed`; वैकल्पिक `reasonCode`: `duplicate`, `reply_operation_active`, `reply_operation_aborted`, `fast_abort`, `plugin_bound_handled`, `plugin_bound_unavailable`, `plugin_bound_declined`, `plugin_bound_error`, `before_dispatch_handled`, `acp_dispatch_completed`, `acp_dispatch_failed`, `acp_dispatch_empty` या `acp_dispatch_aborted`। - आउटबाउंड `outcome`: `sent`, `suppressed`, `failed` या `unknown`; वैकल्पिक `reasonCode`: `cancelled_by_message_sending_hook`, `cancelled_by_reply_payload_sending_hook`, `empty_after_message_sending_hook`, `empty_after_reply_payload_sending_hook` या `no_visible_payload`। जो अडैप्टर कोई प्लेटफ़ॉर्म पहचान नहीं लौटाता, वह `unknown` है, क्योंकि बाहरी दुष्प्रभाव को असत्य सिद्ध नहीं किया जा सकता। - `deliveryKind`: `text`, `media` या `other`; `failureStage`: `platform_send`, `queue` या `unknown`। अंतिम फ़ील्ड सहसंबद्ध हैं, स्वतंत्र रूप से वैकल्पिक नहीं: | वेरिएंट | अंतिम मैपिंग | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | एजेंट संचालन | `started` में `errorCode` नहीं होता; प्रत्येक गैर-सफल पूर्ण स्थिति के लिए उसका मेल खाता `run_*` कोड आवश्यक है। | | उपकरण क्रिया | `started` और सफल स्थिति में `errorCode` नहीं होता; प्रत्येक अन्य पूर्ण स्थिति के लिए उसका मेल खाता `tool_*` कोड आवश्यक है। | | इनबाउंड संदेश | सफल = `completed`; अवरुद्ध = `skipped`; विफल = `failed` के साथ `message_processing_failed`। `reasonCode`, मौजूद होने पर, उसी अंतिम समूह से संबंधित होना चाहिए। | | आउटबाउंड संदेश | सफल = `sent`; अवरुद्ध = `suppressed` के साथ `reasonCode`; विफल = `failed` के साथ `errorCode` और `failureStage`; अज्ञात = `unknown` के साथ `failureStage`। | प्रत्येक गतिविधि इवेंट में स्थिर इवेंट आईडी, एकदिश बढ़ता लेजर अनुक्रम, स्रोत इवेंट अनुक्रम, टाइमस्टैम्प, अभिनेता, क्रिया, स्थिति, पूर्णांक `schemaVersion: 1` और `redaction: "metadata_only"` शामिल हैं। संचालन और उपकरण रिकॉर्ड के लिए एजेंट और संचालन उद्गम आवश्यक हैं तथा उनमें सत्र उद्गम शामिल हो सकता है। संदेश रिकॉर्ड में एजेंट और संचालन आईडी शामिल हो सकती हैं, लेकिन जानबूझकर कभी भी `sessionKey` या `sessionId` शामिल नहीं होते; इसलिए `sessionKey` क्वेरी फ़िल्टर केवल संचालन और उपकरण पंक्तियों पर लागू होता है। उपकरण इवेंट में उपकरण कॉल आईडी और उपकरण नाम शामिल हो सकते हैं। संदेश रिकॉर्ड `message.inbound.processed` या `message.outbound.finished` का उपयोग करते हैं और दिशा, चैनल, वार्तालाप प्रकार, सामान्यीकृत परिणाम, तथा वैकल्पिक वितरण प्रकार, विफलता चरण, अवधि, परिणाम संख्या, कारण कोड, और इंस्टॉलेशन-स्थानीय कुंजीयुक्त खाता/वार्तालाप/संदेश/लक्ष्य छद्मनाम जोड़ते हैं। ये छद्मनाम सहसंबंध में सहायता करते हैं, लेकिन अनामिकीकरण नहीं हैं: स्थिति डेटाबेस में उनकी कुंजी होती है, जबकि RPC और CLI निर्यातों में नहीं। लेजर प्रॉम्प्ट, संदेश मुख्य भाग, टूल तर्क, टूल परिणाम, कमांड आउटपुट या अपरिष्कृत त्रुटि टेक्स्ट संग्रहीत नहीं करता। रन/टूल `sessionKey` मान अपरिष्कृत सहसंबंध मेटाडेटा बने रहते हैं और उनमें प्लेटफ़ॉर्म खाता या पीयर आईडी समाहित हो सकती हैं; संदेश रिकॉर्ड में सत्र कुंजियाँ शामिल नहीं होतीं। इनबाउंड पंक्तियों के लिए, `durationMs` कोर डिस्पैच से उसके समापन तक का मापन करता है और `resultCount` अंतिम रूप दिए गए कतारबद्ध टूल, ब्लॉक और उत्तर पेलोड की गणना करता है। आउटबाउंड पंक्तियों के लिए, `durationMs` वितरण स्वामित्व से अभिस्वीकृति, डेड लेटर या समाधान तक (कतारबद्ध प्रतीक्षा समय सहित) की अवधि को समेटता है, और `resultCount` पहचाने गए वास्तविक प्लेटफ़ॉर्म प्रेषणों की गणना करता है। `deliveryKind`, मौजूद होने पर, हुक और रेंडरिंग के बाद प्रभावी पेलोड का वर्णन करता है; दबाई गई या क्रैश-संदिग्ध पंक्तियों में यह शामिल नहीं होता। वर्तमान संदेश कवरेज में कोर डिस्पैच तक पहुँचने वाले स्वीकृत इनबाउंड संदेश शामिल हैं, जिनमें कोर डुप्लिकेट/समापन परिणाम भी शामिल हैं। आउटबाउंड कवरेज साझा टिकाऊ वितरण तक पहुँचने वाले प्रत्येक मूल तार्किक उत्तर पेलोड के लिए एक समापन पंक्ति लिखता है; खंडन और अडैप्टर फ़ैन-आउट को `resultCount` में समेकित किया जाता है। कतारबद्ध पुनः प्रयास योग्य या संदिग्ध प्रेषण केवल अभिस्वीकृति, डेड लेटर या समाधान के बाद रिकॉर्ड किए जाते हैं। उन साझा सीमाओं को दरकिनार करने वाले Plugin-स्थानीय और प्रत्यक्ष-प्रेषण पथ अभी कवर नहीं किए गए हैं। सीमित वर्कर कतार सर्वोत्तम-प्रयास आधारित है और विफलता या संतृप्ति पर रिकॉर्ड छोड़ सकती है, इसलिए यह सतह हानिरहित अनुपालन संग्रह नहीं है। रिकॉर्डिंग डिफ़ॉल्ट रूप से चालू होती है और [`audit.enabled`](/hi/gateway/configuration-reference#audit) द्वारा नियंत्रित होती है। संदेश रिकॉर्डिंग अलग से `audit.messages` द्वारा नियंत्रित होती है और डिफ़ॉल्ट रूप से `"off"` होती है। जब रिकॉर्डिंग अक्षम होती है, तब `audit.activity.list` पहले लिखे गए रिकॉर्ड की समाप्ति तक उन्हें प्रस्तुत करता रहता है। जारी किए गए `audit.list` अनुरोध, परिणाम और `AuditEvent` स्कीमा अपरिवर्तित रहते हैं और केवल एजेंट-रन तथा टूल-क्रिया रिकॉर्ड लौटाते हैं। नए ऑपरेटर क्लाइंट को `audit.activity.list` कॉल करना चाहिए, जब Gateway इसका विज्ञापन करे। पुराने Gateway या तो `unknown method: audit.activity.list` रिपोर्ट कर सकते हैं या, क्योंकि जारी किए गए संस्करणों में प्राधिकरण विधि खोज से पहले होता था, पठन-स्कोप वाले अनुरोध को `missing scope: operator.admin` रिपोर्ट कर सकते हैं। बाद वाले को विधि की अनुपस्थिति केवल तभी मानें, जब विधि का विज्ञापन नहीं किया गया था। इसके बाद क्लाइंट `audit.list` का पुनः प्रयास केवल तभी कर सकता है, जब उसके फ़िल्टर को संदेश प्रकार, दिशा या चैनल समर्थन की आवश्यकता न हो। टेक्स्ट क्वेरी और सीमित JSON निर्यातों के लिए [`openclaw audit`](/hi/cli/audit) का उपयोग करें। ## कार्य लेजर RPC ऑपरेटर क्लाइंट कार्य लेजर RPC (`packages/gateway-protocol/src/schema/tasks.ts`) के माध्यम से Gateway पृष्ठभूमि कार्य रिकॉर्ड का निरीक्षण और निरस्तीकरण करते हैं। ये साफ़ किए गए कार्य सारांश लौटाते हैं, अपरिष्कृत रनटाइम स्थिति नहीं। - `tasks.list` के लिए `operator.read` आवश्यक है। - पैरामीटर: वैकल्पिक `status` (`"queued"`, `"running"`, `"completed"`, `"failed"`, `"cancelled"` या `"timed_out"`) या उन स्थितियों की एक सरणी, वैकल्पिक `agentId`, वैकल्पिक `sessionKey`, `1` से `500` तक वैकल्पिक `limit`, और वैकल्पिक स्ट्रिंग `cursor`। - परिणाम: `{ "tasks": TaskSummary[], "nextCursor"?: string }`। - `tasks.get` के लिए `operator.read` आवश्यक है। - पैरामीटर: `{ "taskId": string }`। - परिणाम: `{ "task": TaskSummary }`। - अनुपलब्ध कार्य आईडी Gateway की नॉट-फाउंड त्रुटि संरचना लौटाती हैं। - `tasks.cancel` के लिए `operator.write` आवश्यक है। - पैरामीटर: `{ "taskId": string, "reason"?: string }`। - परिणाम: `{ "found": boolean, "cancelled": boolean, "reason"?: string, "task"?: TaskSummary }`। - `found` बताता है कि लेजर में मेल खाता कार्य था या नहीं। `cancelled` बताता है कि रनटाइम ने निरस्तीकरण स्वीकार किया या रिकॉर्ड किया अथवा नहीं। `TaskSummary` में `id`, `status` और वैकल्पिक मेटाडेटा शामिल हैं: `kind`, `runtime`, `title`, `agentId`, `sessionKey`, `childSessionKey`, `ownerKey`, `runId`, `taskId`, `flowId`, `parentTaskId`, `sourceId`, टाइमस्टैम्प, प्रगति, समापन सारांश और साफ़ किया गया त्रुटि टेक्स्ट। `agentId` कार्य निष्पादित करने वाले एजेंट की पहचान करता है; `sessionKey` और `ownerKey` अनुरोधकर्ता और नियंत्रण संदर्भ को बनाए रखते हैं। ## ऑपरेटर सहायक विधियाँ - `commands.list` (`operator.read`) किसी एजेंट के लिए रनटाइम कमांड सूची प्राप्त करता है। - `agentId` वैकल्पिक है; डिफ़ॉल्ट एजेंट कार्यस्थान पढ़ने के लिए इसे छोड़ दें। - `scope` नियंत्रित करता है कि प्राथमिक `name` किस सतह को लक्षित करता है: `text` प्रारंभिक `/` के बिना प्राथमिक टेक्स्ट कमांड टोकन लौटाता है; `native` और डिफ़ॉल्ट `both` पथ उपलब्ध होने पर प्रदाता-सजग नेटिव नाम लौटाते हैं। - `textAliases` `/model` और `/m` जैसे हूबहू स्लैश उपनाम रखता है। - `nativeName` मौजूद होने पर प्रदाता-सजग नेटिव कमांड नाम रखता है। - `provider` वैकल्पिक है और केवल नेटिव नामकरण तथा नेटिव Plugin कमांड उपलब्धता को प्रभावित करता है। - `includeArgs=false` प्रतिक्रिया से क्रमबद्ध तर्क मेटाडेटा हटा देता है। - `tools.catalog` (`operator.read`) किसी एजेंट के लिए रनटाइम टूल कैटलॉग प्राप्त करता है। प्रतिक्रिया में समूहित टूल और उद्गम मेटाडेटा शामिल होते हैं: - `source`: `core` या `plugin` - `pluginId`: `source="plugin"` होने पर Plugin स्वामी - `optional`: क्या Plugin टूल वैकल्पिक है - `tools.effective` (`operator.read`) किसी सत्र के लिए रनटाइम-प्रभावी टूल सूची प्राप्त करता है। - `sessionKey` आवश्यक है। - Gateway कॉलर द्वारा दी गई प्रमाणीकरण या वितरण प्रसंग को स्वीकार करने के बजाय सर्वर-साइड सत्र से विश्वसनीय रनटाइम प्रसंग प्राप्त करता है। - प्रतिक्रिया सक्रिय सूची का सत्र-स्कोप वाला, सर्वर-व्युत्पन्न प्रक्षेपण है, जिसमें कोर, Plugin, चैनल और पहले से खोजे गए MCP सर्वर टूल शामिल हैं। - `tools.effective` MCP के लिए केवल-पठन है: यह अंतिम टूल नीति के माध्यम से किसी सक्रिय सत्र MCP कैटलॉग को प्रक्षेपित कर सकता है, लेकिन MCP रनटाइम नहीं बनाता, ट्रांसपोर्ट कनेक्ट नहीं करता, या `tools/list` जारी नहीं करता। यदि कोई मेल खाता सक्रिय कैटलॉग मौजूद नहीं है, तो प्रतिक्रिया में `mcp-not-yet-connected`, `mcp-not-yet-listed` या `mcp-stale-catalog` जैसी सूचना शामिल हो सकती है। - प्रभावी टूल प्रविष्टियाँ `source="core"`, `source="plugin"`, `source="channel"` या `source="mcp"` का उपयोग करती हैं। - `tools.invoke` (`operator.write`) `/tools/invoke` के समान Gateway नीति पथ के माध्यम से एक उपलब्ध टूल का आह्वान करता है। - `name` आवश्यक है। `args`, `sessionKey`, `agentId`, `confirm` और `idempotencyKey` वैकल्पिक हैं। - यदि `sessionKey` और `agentId` दोनों मौजूद हैं, तो समाधान किया गया सत्र एजेंट `agentId` से मेल खाना चाहिए। - केवल-स्वामी कोर रैपर, जैसे `cron`, `gateway` और `nodes`, के लिए स्वामी/व्यवस्थापक पहचान (`operator.admin`) आवश्यक है, भले ही `tools.invoke` स्वयं `operator.write` हो। - प्रतिक्रिया SDK-उन्मुख आवरण है, जिसमें `ok`, `toolName`, वैकल्पिक `output` और टाइप किए गए `error` फ़ील्ड होते हैं। अनुमोदन या नीति अस्वीकृतियाँ Gateway टूल नीति पाइपलाइन को दरकिनार करने के बजाय पेलोड में `ok:false` लौटाती हैं। - `skills.status` (`operator.read`) किसी एजेंट के लिए दृश्यमान Skills सूची प्राप्त करता है। - `agentId` वैकल्पिक है; डिफ़ॉल्ट एजेंट कार्यस्थान पढ़ने के लिए इसे छोड़ दें। - प्रतिक्रिया में अपरिष्कृत गुप्त मानों को उजागर किए बिना पात्रता, अनुपलब्ध आवश्यकताएँ, कॉन्फ़िगरेशन जाँच और साफ़ किए गए इंस्टॉल विकल्प शामिल होते हैं। - `skills.search` और `skills.detail` (`operator.read`) ClawHub खोज मेटाडेटा लौटाते हैं। - `skills.upload.begin`, `skills.upload.chunk` और `skills.upload.commit` (`operator.admin`) किसी निजी Skill संग्रह को इंस्टॉल करने से पहले तैयार करते हैं। यह विश्वसनीय क्लाइंट के लिए एक अलग व्यवस्थापक अपलोड पथ है, सामान्य ClawHub Skill इंस्टॉल प्रवाह नहीं, और डिफ़ॉल्ट रूप से तब तक अक्षम रहता है जब तक `skills.install.allowUploadedArchives` सक्षम न हो। - `skills.upload.begin({ kind: "skill-archive", slug, sizeBytes, sha256?, force?, idempotencyKey? })` उस स्लग और फ़ोर्स मान से बँधा अपलोड बनाता है। - `skills.upload.chunk({ uploadId, offset, dataBase64 })` सटीक डिकोड किए गए ऑफ़सेट पर बाइट जोड़ता है। - `skills.upload.commit({ uploadId, sha256? })` अंतिम आकार और SHA-256 सत्यापित करता है। कमिट केवल अपलोड को अंतिम रूप देता है; यह Skill इंस्टॉल नहीं करता। - अपलोड किए गए Skill संग्रह ऐसे zip संग्रह होते हैं जिनमें `SKILL.md` रूट होता है। संग्रह का आंतरिक डायरेक्टरी नाम कभी भी इंस्टॉल लक्ष्य नहीं चुनता। - `skills.install` (`operator.admin`) के तीन मोड हैं: - ClawHub मोड: `{ source: "clawhub", slug, version?, force? }` डिफ़ॉल्ट एजेंट कार्यस्थान की `skills/` डायरेक्टरी में एक Skill फ़ोल्डर इंस्टॉल करता है। - अपलोड मोड: `{ source: "upload", uploadId, slug, force?, sha256?, timeoutMs? }` प्रतिबद्ध अपलोड को डिफ़ॉल्ट एजेंट कार्यस्थान की `skills/` डायरेक्टरी में इंस्टॉल करता है। स्लग और फ़ोर्स मान मूल `skills.upload.begin` अनुरोध से मेल खाने चाहिए। जब तक `skills.install.allowUploadedArchives` सक्षम न हो, इसे अस्वीकार किया जाता है; यह सेटिंग ClawHub इंस्टॉल को प्रभावित नहीं करती। - Gateway इंस्टॉलर मोड: `{ name, installId, timeoutMs? }` Gateway होस्ट पर घोषित `metadata.openclaw.install` क्रिया चलाता है। पुराने क्लाइंट अभी भी `dangerouslyForceUnsafeInstall` भेज सकते हैं; यह फ़ील्ड पदावनत है, केवल प्रोटोकॉल संगतता के लिए स्वीकार किया जाता है और अनदेखा किया जाता है। ऑपरेटर-स्वामित्व वाले इंस्टॉल निर्णयों के लिए `security.installPolicy` का उपयोग करें। - `skills.update` (`operator.admin`) के दो मोड हैं: - ClawHub मोड डिफ़ॉल्ट एजेंट कार्यस्थान में एक ट्रैक किए गए स्लग या सभी ट्रैक किए गए ClawHub इंस्टॉल को अपडेट करता है। - कॉन्फ़िगरेशन मोड `skills.entries.` मानों, जैसे `enabled`, `apiKey` और `env`, को पैच करता है। ### `models.list` दृश्य `models.list` एक वैकल्पिक `view` पैरामीटर (`src/agents/model-catalog-visibility.ts`) स्वीकार करता है: - छोड़ा गया या `"default"`: यदि `agents.defaults.modelPolicy.allow` कॉन्फ़िगर किया गया है, तो प्रतिक्रिया अनुमत कैटलॉग होती है, जिसमें `provider/*` प्रविष्टियों के लिए गतिशील रूप से खोजे गए मॉडल शामिल होते हैं। अन्यथा प्रतिक्रिया पूर्ण Gateway कैटलॉग होती है। - `"configured"`: पिकर-आकार का व्यवहार। यदि `agents.defaults.modelPolicy.allow` कॉन्फ़िगर किया गया है, तो उसे फिर भी प्राथमिकता मिलती है, जिसमें `provider/*` प्रविष्टियों के लिए प्रदाता-स्कोप वाली खोज शामिल है। अनुमति-सूची के बिना, प्रतिक्रिया स्पष्ट `models.providers..models` प्रविष्टियों का उपयोग करती है और केवल तब पूर्ण कैटलॉग पर वापस जाती है, जब कोई कॉन्फ़िगर की गई मॉडल पंक्ति मौजूद न हो। - `"provider-config"`: स्रोत-निर्मित `models.providers.*.models` सूची, पिकर अनुमति-सूचियों से स्वतंत्र। पंक्तियों में सार्वजनिक मॉडल क्षमताएँ और रूट-सजग उपलब्धता शामिल होती हैं, लेकिन प्रदाता एंडपॉइंट, प्रमाणीकरण सामग्री और रनटाइम अनुरोध कॉन्फ़िगरेशन शामिल नहीं होते। - `"all"`: पूर्ण Gateway कैटलॉग, `agents.defaults.modelPolicy.allow` को दरकिनार करते हुए। इसका उपयोग निदान/खोज UI के लिए करें, सामान्य मॉडल पिकर के लिए नहीं। ## निष्पादन अनुमोदन - जब किसी exec अनुरोध को अनुमोदन की आवश्यकता होती है, तो Gateway `exec.approval.requested` प्रसारित करता है। - ऑपरेटर क्लाइंट `exec.approval.resolve` को कॉल करके समाधान करते हैं (इसके लिए `operator.approvals` आवश्यक है)। - `host=node` के लिए, `exec.approval.request` में `systemRunPlan` (कैनोनिकल `argv`/`cwd`/`rawCommand`/सत्र मेटाडेटा) शामिल होना चाहिए। जिन अनुरोधों में `systemRunPlan` नहीं होता, उन्हें अस्वीकार कर दिया जाता है। - अनुमोदन के बाद, अग्रेषित `node.invoke system.run` कॉल उसी कैनोनिकल `systemRunPlan` को आधिकारिक कमांड/cwd/सत्र संदर्भ के रूप में पुनः उपयोग करती हैं। - यदि कोई कॉलर तैयार करने और अंतिम अनुमोदित `system.run` अग्रेषण के बीच `command`, `rawCommand`, `cwd`, `agentId`, या `sessionKey` में बदलाव करता है, तो Gateway बदले हुए पेलोड पर भरोसा करने के बजाय रन को अस्वीकार कर देता है। ## एजेंट डिलीवरी फ़ॉलबैक - `agent` अनुरोधों में आउटबाउंड डिलीवरी का अनुरोध करने के लिए `deliver=true` शामिल हो सकता है। - `bestEffortDeliver=false` (डिफ़ॉल्ट) सख्त व्यवहार बनाए रखता है: अनसुलझे या केवल-आंतरिक डिलीवरी लक्ष्य `INVALID_REQUEST` लौटाते हैं। - जब कोई बाहरी डिलीवरी-योग्य रूट हल नहीं किया जा सकता (उदाहरण के लिए आंतरिक/webchat सत्र या अस्पष्ट मल्टी-चैनल कॉन्फ़िगरेशन), तब `bestEffortDeliver=true` केवल-सत्र निष्पादन पर फ़ॉलबैक की अनुमति देता है। - यदि डिलीवरी का अनुरोध किया गया था, तो अंतिम `agent` परिणामों में `result.deliveryStatus` शामिल हो सकता है, जिसमें [`openclaw agent --json --deliver`](/hi/cli/agent#json-delivery-status) के लिए दस्तावेज़ित वही `sent`, `suppressed`, `partial_failed`, और `failed` स्थितियाँ उपयोग की जाती हैं। ## संस्करण निर्धारण - `PROTOCOL_VERSION`, `MIN_CLIENT_PROTOCOL_VERSION`, `MIN_NODE_PROTOCOL_VERSION`, और `MIN_PROBE_PROTOCOL_VERSION` `packages/gateway-protocol/src/version.ts` में मौजूद हैं। - क्लाइंट `minProtocol` + `maxProtocol` भेजते हैं। ऑपरेटर और UI क्लाइंट को उस सीमा में वर्तमान प्रोटोकॉल शामिल करना आवश्यक है; वर्तमान क्लाइंट और सर्वर प्रोटोकॉल v4 चलाते हैं। - `role: "node"` और `client.mode: "node"` दोनों वाले प्रमाणित क्लाइंट N-1 Node प्रोटोकॉल (वर्तमान में v3) का उपयोग कर सकते हैं। हल्के रीस्टार्ट प्रोब समान N-1 विंडो का उपयोग करते हैं। इस संगतता विंडो से डिवाइस प्रमाणीकरण, पेयरिंग, स्कोप, कमांड नीति और exec अनुमोदन अपरिवर्तित रहते हैं। Plugin-स्वामित्व वाली Node क्षमताएँ और कमांड तब तक उपलब्ध नहीं कराए जाते, जब तक Node वर्तमान प्रोटोकॉल पर अपग्रेड नहीं हो जाता, क्योंकि उनकी होस्ट की गई सतहें N-1 अनुबंध का हिस्सा नहीं हैं। - स्कीमा और मॉडल TypeBox परिभाषाओं से जनरेट किए जाते हैं: - `pnpm protocol:gen` - `pnpm protocol:gen:swift` - `pnpm protocol:check` ### क्लाइंट स्थिरांक संदर्भ क्लाइंट कार्यान्वयन `packages/gateway-client/src/` में मौजूद है (OpenClaw इसे पतले `src/gateway/client.ts` फ़साड के माध्यम से रैप करता है)। ये डिफ़ॉल्ट प्रोटोकॉल v4 में स्थिर हैं और तृतीय-पक्ष क्लाइंट के लिए अपेक्षित आधार-रेखा हैं। | स्थिरांक | डिफ़ॉल्ट | स्रोत | | ----------------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | `PROTOCOL_VERSION` | `4` | `packages/gateway-protocol/src/version.ts` | | `MIN_CLIENT_PROTOCOL_VERSION` | `4` | `packages/gateway-protocol/src/version.ts` | | `MIN_NODE_PROTOCOL_VERSION` | `3` | `packages/gateway-protocol/src/version.ts` | | `MIN_PROBE_PROTOCOL_VERSION` | `3` | `packages/gateway-protocol/src/version.ts` | | अनुरोध टाइमआउट (प्रति RPC) | `30_000` ms | `packages/gateway-client/src/client.ts` (`requestTimeoutMs`) | | प्रीऑथ / कनेक्ट-चैलेंज टाइमआउट | `15_000` ms | `packages/gateway-client/src/timeouts.ts` (`OPENCLAW_HANDSHAKE_TIMEOUT_MS` env युग्मित सर्वर/क्लाइंट बजट बढ़ा सकता है) | | प्रारंभिक पुनःकनेक्ट बैकऑफ़ | `1_000` ms | `packages/gateway-client/src/client.ts` (`GATEWAY_RECONNECT_POLICY`) | | अधिकतम पुनःकनेक्ट बैकऑफ़ | `30_000` ms | `packages/gateway-client/src/client.ts` (`GATEWAY_RECONNECT_POLICY`) | | डिवाइस-टोकन बंद होने के बाद तेज़-पुनःप्रयास क्लैंप | `250` ms | `packages/gateway-client/src/client.ts` | | `terminate()` से पहले बलपूर्वक-रोकने की छूट | `250` ms | `FORCE_STOP_TERMINATE_GRACE_MS` | | `stopAndWait()` डिफ़ॉल्ट टाइमआउट | `1_000` ms | `STOP_AND_WAIT_TIMEOUT_MS` | | डिफ़ॉल्ट टिक अंतराल (`hello-ok` से पहले) | `30_000` ms | `packages/gateway-client/src/client.ts` | | टिक-टाइमआउट क्लोज़ | जब मौन `tickIntervalMs * 2` से अधिक हो, तब कोड `4000` | `packages/gateway-client/src/client.ts` | | `MAX_PAYLOAD_BYTES` | `25 * 1024 * 1024` (25 MB) | `src/gateway/server-constants.ts` | सर्वर प्रभावी `policy.tickIntervalMs`, `policy.maxPayload`, और `policy.maxBufferedBytes` को `hello-ok` में घोषित करता है; क्लाइंट को प्री-हैंडशेक डिफ़ॉल्ट के बजाय उन मानों का पालन करना चाहिए। जब प्रत्येक लंबित अनुरोध की अपनी समय-सीमा होती है, तो संदर्भ क्लाइंट सीमित अनुरोधों को उनकी कॉन्फ़िगर की गई समय-सीमा नियंत्रित करने देता है। सीमित `timeoutMs` के बिना कोई `expectFinal` अनुरोध, `timeoutMs: null` वाला कोई भी अनुरोध, या सीमित और असीमित अनुरोधों का मिश्रण टिक वॉचडॉग को सक्रिय रखता है। यदि इनबाउंड ईवेंट और प्रतिक्रियाएँ टिक-टाइमआउट सीमा के बाद भी मौन रहती हैं, तो क्लाइंट कोड `4000` के साथ सॉकेट बंद करता है, प्रत्येक लंबित अनुरोध को अस्वीकार करता है और पुनः कनेक्ट करता है। यह पुनः कनेक्ट होने के बाद अस्वीकृत अनुरोधों को दोबारा नहीं चलाता। ## प्रमाणीकरण - साझा-सीक्रेट Gateway प्रमाणीकरण कॉन्फ़िगर किए गए `gateway.auth.mode` (`"none" | "token" | "password" | "trusted-proxy"`) के आधार पर `connect.params.auth.token` या `connect.params.auth.password` का उपयोग करता है। - Tailscale Serve (`gateway.auth.allowTailscale: true`) या गैर-लूपबैक `gateway.auth.mode: "trusted-proxy"` जैसे पहचान-युक्त मोड, `connect.params.auth.*` के बजाय अनुरोध हेडर से कनेक्ट प्रमाणीकरण जाँच पूरी करते हैं। - निजी-इनग्रेस `gateway.auth.mode: "none"` साझा-सीक्रेट कनेक्ट प्रमाणीकरण को पूरी तरह छोड़ देता है; उस मोड को सार्वजनिक/अविश्वसनीय इनग्रेस पर उजागर न करें। - पेयरिंग के बाद, Gateway कनेक्शन की भूमिका + स्कोप तक सीमित एक डिवाइस टोकन जारी करता है, जो `hello-ok.auth.deviceToken` में लौटाया जाता है। क्लाइंट को प्रत्येक सफल कनेक्ट के बाद इसे स्थायी रूप से सहेजना चाहिए। - उस संग्रहीत डिवाइस टोकन से पुनः कनेक्ट करते समय उस टोकन के लिए संग्रहीत स्वीकृत स्कोप सेट का भी पुनः उपयोग किया जाना चाहिए। इससे पहले से दी गई रीड/प्रोब/स्टेटस पहुँच सुरक्षित रहती है और पुनः कनेक्शन चुपचाप किसी अधिक सीमित, अंतर्निहित केवल-एडमिन स्कोप में सिमटने से बचते हैं। - क्लाइंट-साइड कनेक्ट प्रमाणीकरण संयोजन (`packages/gateway-client/src/client.ts` में `selectConnectAuth`): - `auth.password` स्वतंत्र है और सेट होने पर हमेशा अग्रेषित किया जाता है। - `auth.token` को प्राथमिकता क्रम में भरा जाता है: पहले स्पष्ट साझा टोकन, फिर स्पष्ट `deviceToken`, और फिर संग्रहीत प्रति-डिवाइस टोकन (`deviceId` + `role` द्वारा कुंजीबद्ध)। - `auth.bootstrapToken` केवल तभी भेजा जाता है, जब उपरोक्त में से किसी ने भी `auth.token` का समाधान न किया हो। साझा टोकन या कोई भी हल किया गया डिवाइस टोकन इसे रोक देता है। - एकल-प्रयास `AUTH_TOKEN_MISMATCH` पुनः प्रयास पर संग्रहीत डिवाइस टोकन का स्वतः-प्रोमोशन केवल विश्वसनीय एंडपॉइंट तक सीमित है: लूपबैक, या पिन किए गए `tlsFingerprint` वाला `wss://`। पिनिंग के बिना सार्वजनिक `wss://` योग्य नहीं है। - अंतर्निहित सेटअप-कोड बूटस्ट्रैप विश्वसनीय मोबाइल हैंडऑफ़ के लिए प्राथमिक Node `hello-ok.auth.deviceToken` के साथ `hello-ok.auth.deviceTokens` में एक सीमित ऑपरेटर टोकन लौटाता है। ऑपरेटर टोकन में नेटिव Talk कॉन्फ़िगरेशन रीड के लिए `operator.talk.secrets` शामिल है, लेकिन पेयरिंग-म्यूटेशन स्कोप और `operator.admin` शामिल नहीं हैं। - जब कोई गैर-बेसलाइन सेटअप-कोड बूटस्ट्रैप स्वीकृति की प्रतीक्षा करता है, `PAIRING_REQUIRED` विवरण में `recommendedNextStep: "wait_then_retry"`, `retryable: true`, और `pauseReconnect: false` शामिल होते हैं। अनुरोध स्वीकृत होने या टोकन अमान्य होने तक उसी बूटस्ट्रैप टोकन से पुनः कनेक्ट करते रहें। - `hello-ok.auth.deviceTokens` को केवल तभी स्थायी रूप से सहेजें, जब कनेक्ट ने `wss://` या लूपबैक/स्थानीय पेयरिंग जैसे विश्वसनीय ट्रांसपोर्ट पर बूटस्ट्रैप प्रमाणीकरण का उपयोग किया हो। - यदि कोई क्लाइंट स्पष्ट `deviceToken` या स्पष्ट `scopes` देता है, तो कॉलर द्वारा अनुरोधित वह स्कोप सेट प्रामाणिक बना रहता है; कैश किए गए स्कोप का पुनः उपयोग केवल तब होता है, जब क्लाइंट संग्रहीत प्रति-डिवाइस टोकन का पुनः उपयोग कर रहा हो। - डिवाइस टोकन को `device.token.rotate` और `device.token.revoke` के माध्यम से रोटेट/निरस्त किया जा सकता है (`operator.pairing` आवश्यक है)। किसी Node या अन्य गैर-ऑपरेटर भूमिका को रोटेट या निरस्त करने के लिए `operator.admin` भी आवश्यक है। - `device.token.rotate` रोटेशन मेटाडेटा लौटाता है। यह प्रतिस्थापन बेयरर टोकन केवल उसी डिवाइस की उन कॉल के लिए दोहराता है, जो पहले से उस डिवाइस टोकन से प्रमाणित हैं, ताकि केवल-टोकन क्लाइंट पुनः कनेक्ट करने से पहले अपना प्रतिस्थापन सहेज सकें। साझा/एडमिन रोटेशन बेयरर टोकन नहीं दोहराते। - टोकन जारी करना, रोटेशन और निरसन उस डिवाइस की पेयरिंग प्रविष्टि में दर्ज स्वीकृत भूमिका सेट तक सीमित रहते हैं; टोकन म्यूटेशन उस डिवाइस भूमिका का विस्तार या उसे लक्षित नहीं कर सकता, जिसे पेयरिंग स्वीकृति ने कभी प्रदान नहीं किया। - पेयर किए गए डिवाइस टोकन सत्रों के लिए, डिवाइस प्रबंधन स्वयं तक सीमित रहता है, जब तक कॉलर के पास `operator.admin` भी न हो: गैर-एडमिन कॉलर केवल अपनी डिवाइस प्रविष्टि का ऑपरेटर टोकन प्रबंधित कर सकते हैं। Node और अन्य गैर-ऑपरेटर टोकन का प्रबंधन केवल एडमिन कर सकता है, भले ही वह कॉलर का अपना डिवाइस हो। - `device.token.rotate` और `device.token.revoke` लक्षित ऑपरेटर टोकन स्कोप सेट की जाँच कॉलर के वर्तमान सत्र स्कोप से भी करते हैं। गैर-एडमिन कॉलर अपने पास पहले से मौजूद ऑपरेटर टोकन से अधिक व्यापक टोकन को रोटेट या निरस्त नहीं कर सकते। - प्रमाणीकरण विफलताओं में `error.details.code` और पुनर्प्राप्ति संकेत शामिल हैं: - `error.details.canRetryWithDeviceToken` (बूलियन) - `error.details.recommendedNextStep`: `retry_with_device_token`, `update_auth_configuration`, `update_auth_credentials`, `wait_then_retry`, `review_auth_configuration` (`packages/gateway-protocol/src/connect-error-details.ts`) में से एक। - `AUTH_TOKEN_MISMATCH` के लिए क्लाइंट व्यवहार: - विश्वसनीय क्लाइंट कैश किए गए प्रति-डिवाइस टोकन के साथ एक सीमित पुनः प्रयास कर सकते हैं। - यदि वह पुनः प्रयास विफल हो जाए, तो स्वचालित पुनः कनेक्ट लूप रोकें और ऑपरेटर कार्रवाई संबंधी मार्गदर्शन दिखाएँ। - `AUTH_SCOPE_MISMATCH` का अर्थ है कि डिवाइस टोकन पहचाना गया था, लेकिन वह अनुरोधित भूमिका/स्कोप को कवर नहीं करता। इसे खराब टोकन के रूप में प्रस्तुत न करें; ऑपरेटर को पुनः पेयर करने या अधिक सीमित/व्यापक स्कोप अनुबंध स्वीकृत करने के लिए कहें। ## डिवाइस पहचान और पेयरिंग - Nodes को कीपेयर फ़िंगरप्रिंट से प्राप्त एक स्थिर डिवाइस पहचान (`device.id`) शामिल करनी चाहिए। - Gateways प्रति डिवाइस + भूमिका टोकन जारी करते हैं। - नई डिवाइस ID के लिए पेयरिंग स्वीकृति आवश्यक है, जब तक स्थानीय स्वतः-स्वीकृति सक्षम न हो। - पेयरिंग स्वतः-स्वीकृति सीधे स्थानीय लूपबैक कनेक्ट पर केंद्रित है। - OpenClaw में विश्वसनीय साझा-सीक्रेट सहायक प्रवाहों के लिए एक सीमित बैकएंड/कंटेनर-स्थानीय स्व-कनेक्ट पथ भी है। - समान-होस्ट टेलनेट या LAN कनेक्ट को पेयरिंग के लिए अब भी रिमोट माना जाता है और इनके लिए स्वीकृति आवश्यक है। - WS क्लाइंट सामान्यतः `connect` के दौरान `device` पहचान शामिल करते हैं (ऑपरेटर + Node)। बिना डिवाइस वाले ऑपरेटर के एकमात्र अपवाद स्पष्ट विश्वास पथ हैं: - सफल `gateway.auth.mode: "trusted-proxy"` ऑपरेटर Control UI प्रमाणीकरण। - आरक्षित आंतरिक सहायक पथ पर सीधे-लूपबैक `gateway-client` बैकएंड RPC। - डिवाइस पहचान छोड़ने से स्कोप पर प्रभाव पड़ता है। जब किसी स्पष्ट विश्वास पथ से बिना डिवाइस वाले ऑपरेटर कनेक्शन की अनुमति दी जाती है, तब भी OpenClaw स्वयं-घोषित स्कोप को खाली सेट में साफ़ कर देता है, जब तक उस पथ के लिए नामित स्कोप-संरक्षण अपवाद न हो। इसके बाद स्कोप-गेटेड विधियाँ `missing scope` के साथ विफल हो जाती हैं। - आरक्षित सीधे-लूपबैक `gateway-client` बैकएंड सहायक पथ केवल आंतरिक स्थानीय कंट्रोल-प्लेन RPC के लिए स्कोप सुरक्षित रखता है; कस्टम बैकएंड ID को यह अपवाद नहीं मिलता। - सभी कनेक्शन को सर्वर द्वारा दिए गए `connect.challenge` नॉन्स पर हस्ताक्षर करना आवश्यक है। ### डिवाइस प्रमाणीकरण माइग्रेशन निदान उन पुराने क्लाइंट के लिए, जो अभी भी प्री-चैलेंज हस्ताक्षर व्यवहार का उपयोग करते हैं, `connect`, `error.details.code` के अंतर्गत स्थिर `error.details.reason` के साथ `DEVICE_AUTH_*` विवरण कोड लौटाता है। सामान्य माइग्रेशन विफलताएँ: | संदेश | details.code | details.reason | अर्थ | | --------------------------- | -------------------------------- | ------------------------ | -------------------------------------------------- | | `device nonce required` | `DEVICE_AUTH_NONCE_REQUIRED` | `device-nonce-missing` | क्लाइंट ने `device.nonce` छोड़ दिया (या रिक्त भेजा)। | | `device nonce mismatch` | `DEVICE_AUTH_NONCE_MISMATCH` | `device-nonce-mismatch` | क्लाइंट ने पुराने/गलत नॉन्स से हस्ताक्षर किए। | | `device signature invalid` | `DEVICE_AUTH_SIGNATURE_INVALID` | `device-signature` | हस्ताक्षर पेलोड v2 पेलोड से मेल नहीं खाता। | | `device signature expired` | `DEVICE_AUTH_SIGNATURE_EXPIRED` | `device-signature-stale` | हस्ताक्षरित टाइमस्टैम्प अनुमत अंतर से बाहर है। | | `device identity mismatch` | `DEVICE_AUTH_DEVICE_ID_MISMATCH` | `device-id-mismatch` | `device.id` सार्वजनिक कुंजी फ़िंगरप्रिंट से मेल नहीं खाता। | | `device public key invalid` | `DEVICE_AUTH_PUBLIC_KEY_INVALID` | `device-public-key` | सार्वजनिक कुंजी प्रारूप/कैनॉनिकलाइज़ेशन विफल रहा। | माइग्रेशन लक्ष्य: - हमेशा `connect.challenge` की प्रतीक्षा करें। - सर्वर नॉन्स शामिल करने वाले v2 पेलोड पर हस्ताक्षर करें। - `connect.params.device.nonce` में वही नॉन्स भेजें। - वरीय हस्ताक्षर पेलोड `v3` (`packages/gateway-client/src/device-auth.ts` में `buildDeviceAuthPayloadV3`) है, जो डिवाइस/क्लाइंट/भूमिका/स्कोप/टोकन/नॉन्स फ़ील्ड के अतिरिक्त `platform` और `deviceFamily` को भी बाँधता है। - संगतता के लिए पुराने `v2` हस्ताक्षर अभी भी स्वीकार किए जाते हैं, लेकिन पेयर किए गए डिवाइस की मेटाडेटा पिनिंग पुनः कनेक्ट होने पर भी कमांड नीति नियंत्रित करती है। ## TLS और पिनिंग - WS कनेक्शन के लिए TLS समर्थित है (`gateway.tls` कॉन्फ़िगरेशन)। - क्लाइंट वैकल्पिक रूप से `gateway.remote.tlsFingerprint` या CLI `--tls-fingerprint` के माध्यम से Gateway प्रमाणपत्र फ़िंगरप्रिंट पिन कर सकते हैं। ## दायरा यह प्रोटोकॉल संपूर्ण Gateway API उपलब्ध कराता है: स्टेटस, चैनल, मॉडल, चैट, एजेंट, सत्र, Nodes, स्वीकृतियाँ और बहुत कुछ। सटीक सतह `packages/gateway-protocol/src/schema.ts` से पुनः निर्यात किए गए TypeBox स्कीमा द्वारा परिभाषित होती है। ## संबंधित - [Gateway क्लाइंट बनाना](https://docs.openclaw.ai/gateway/clients) - [OpenClaw एम्बेड करना](https://docs.openclaw.ai/gateway/embedding) - [ब्रिज प्रोटोकॉल](/hi/gateway/bridge-protocol) - [Gateway रनबुक](/hi/gateway)