---
read_when:
    - DM एक्सेस नियंत्रण सेट अप करना
    - नए iOS/Android Node को पेयर करना
    - OpenClaw की सुरक्षा स्थिति की समीक्षा करना
summary: 'पेयरिंग अवलोकन: मंज़ूरी दें कि कौन आपको DM कर सकता है + कौन-से नोड जुड़ सकते हैं'
title: पेयरिंग
x-i18n:
    generated_at: "2026-06-28T22:38:44Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 92870489b62aeec710f49ec92908f4b83c7d9ee2ce34174b42e283839748e549
    source_path: channels/pairing.md
    workflow: 16
---

"पेयरिंग" OpenClaw का स्पष्ट एक्सेस अनुमोदन चरण है।
इसका उपयोग दो जगहों पर होता है:

1. **DM पेयरिंग** (किसे बॉट से बात करने की अनुमति है)
2. **Node पेयरिंग** (किन डिवाइस/नोड को gateway नेटवर्क से जुड़ने की अनुमति है)

सुरक्षा संदर्भ: [सुरक्षा](/hi/gateway/security)

## 1) DM पेयरिंग (इनबाउंड चैट एक्सेस)

जब कोई चैनल DM नीति `pairing` के साथ कॉन्फ़िगर होता है, तो अज्ञात प्रेषकों को एक छोटा कोड मिलता है और उनका संदेश तब तक **प्रोसेस नहीं किया जाता** जब तक आप अनुमोदन नहीं देते।

डिफ़ॉल्ट DM नीतियां यहां दस्तावेज़ित हैं: [सुरक्षा](/hi/gateway/security)

`dmPolicy: "open"` केवल तब सार्वजनिक होता है जब प्रभावी DM अनुमति-सूची में `"*"` शामिल हो।
सार्वजनिक-ओपन कॉन्फ़िग के लिए सेटअप और सत्यापन में उस वाइल्डकार्ड की आवश्यकता होती है। यदि मौजूदा
स्टेट में ठोस `allowFrom` प्रविष्टियों के साथ `open` है, तो रनटाइम अभी भी केवल
उन प्रेषकों को स्वीकार करता है, और पेयरिंग-स्टोर अनुमोदन `open` एक्सेस को विस्तृत नहीं करते।

पेयरिंग कोड:

- 8 अक्षर, अपरकेस, कोई अस्पष्ट अक्षर नहीं (`0O1I`)।
- **1 घंटे बाद समाप्त हो जाते हैं**। बॉट पेयरिंग संदेश केवल तब भेजता है जब नया अनुरोध बनाया जाता है (लगभग हर प्रेषक के लिए प्रति घंटे एक बार)।
- लंबित DM पेयरिंग अनुरोध डिफ़ॉल्ट रूप से **प्रति चैनल 3** तक सीमित हैं; अतिरिक्त अनुरोध तब तक अनदेखे किए जाते हैं जब तक कोई समाप्त या अनुमोदित नहीं हो जाता।

### प्रेषक को अनुमोदित करें

```bash
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>
```

यदि अभी तक कोई कमांड स्वामी कॉन्फ़िगर नहीं है, तो DM पेयरिंग कोड को अनुमोदित करना
`commands.ownerAllowFrom` को अनुमोदित प्रेषक, जैसे `telegram:123456789`, से भी बूटस्ट्रैप करता है।
यह पहली बार के सेटअप को विशेषाधिकार प्राप्त कमांड और exec
अनुमोदन प्रॉम्प्ट के लिए एक स्पष्ट स्वामी देता है। स्वामी मौजूद होने के बाद, बाद के पेयरिंग अनुमोदन केवल DM
एक्सेस देते हैं; वे और स्वामी नहीं जोड़ते।

समर्थित चैनल: `discord`, `feishu`, `googlechat`, `imessage`, `irc`, `line`, `matrix`, `mattermost`, `msteams`, `nextcloud-talk`, `nostr`, `openclaw-weixin`, `signal`, `slack`, `synology-chat`, `telegram`, `twitch`, `whatsapp`, `zalo`, `zalouser`।

### पुन: उपयोग योग्य प्रेषक समूह

जब एक ही विश्वसनीय प्रेषक सेट कई संदेश चैनलों पर या DM और समूह अनुमति-सूचियों दोनों पर लागू होना चाहिए,
तो शीर्ष-स्तरीय `accessGroups` का उपयोग करें।

स्थिर समूह `type: "message.senders"` का उपयोग करते हैं और चैनल अनुमति-सूचियों से
`accessGroup:<name>` के साथ संदर्भित होते हैं:

```json5
{
  accessGroups: {
    operators: {
      type: "message.senders",
      members: {
        discord: ["discord:123456789012345678"],
        telegram: ["987654321"],
        whatsapp: ["+15551234567"],
      },
    },
  },
  channels: {
    telegram: { dmPolicy: "allowlist", allowFrom: ["accessGroup:operators"] },
    whatsapp: { groupPolicy: "allowlist", groupAllowFrom: ["accessGroup:operators"] },
  },
}
```

एक्सेस समूहों का विस्तृत दस्तावेज़ यहां है: [एक्सेस समूह](/hi/channels/access-groups)

### स्टेट कहां रहता है

`~/.openclaw/credentials/` के अंतर्गत संग्रहीत:

- लंबित अनुरोध: `<channel>-pairing.json`
- अनुमोदित अनुमति-सूची स्टोर:
  - डिफ़ॉल्ट खाता: `<channel>-allowFrom.json`
  - गैर-डिफ़ॉल्ट खाता: `<channel>-<accountId>-allowFrom.json`

खाता स्कोपिंग व्यवहार:

- गैर-डिफ़ॉल्ट खाते केवल अपनी स्कोप की गई अनुमति-सूची फ़ाइल पढ़ते/लिखते हैं।
- डिफ़ॉल्ट खाता चैनल-स्कोप वाली अनस्कोप्ड अनुमति-सूची फ़ाइल का उपयोग करता है।

इन्हें संवेदनशील मानें (ये आपके assistant तक एक्सेस को नियंत्रित करते हैं)।

<Note>
पेयरिंग अनुमति-सूची स्टोर DM एक्सेस के लिए है। समूह प्राधिकरण अलग है।
DM पेयरिंग कोड को अनुमोदित करने से वह प्रेषक अपने-आप समूह
कमांड चलाने या समूहों में बॉट को नियंत्रित करने की अनुमति नहीं पाता। पहला-स्वामी बूटस्ट्रैप अलग कॉन्फ़िग
स्टेट है `commands.ownerAllowFrom` में, और समूह चैट डिलीवरी अभी भी
चैनल की समूह अनुमति-सूचियों का पालन करती है (उदाहरण के लिए `groupAllowFrom`, `groups`, या चैनल के अनुसार प्रति-समूह
या प्रति-विषय ओवरराइड)।
</Note>

## 2) Node डिवाइस पेयरिंग (iOS/Android/macOS/headless नोड)

नोड Gateway से `role: node` वाले **डिवाइस** के रूप में जुड़ते हैं। Gateway
एक डिवाइस पेयरिंग अनुरोध बनाता है जिसे अनुमोदित किया जाना चाहिए।

### Telegram के माध्यम से पेयर करें (iOS के लिए अनुशंसित)

यदि आप `device-pair` Plugin का उपयोग करते हैं, तो आप पहली बार की डिवाइस पेयरिंग पूरी तरह Telegram से कर सकते हैं:

1. Telegram में, अपने बॉट को संदेश भेजें: `/pair`
2. बॉट दो संदेशों के साथ उत्तर देता है: एक निर्देश संदेश और एक अलग **सेटअप कोड** संदेश (Telegram में कॉपी/पेस्ट करना आसान)।
3. अपने फ़ोन पर, OpenClaw iOS ऐप खोलें → Settings → Gateway।
4. QR कोड स्कैन करें या सेटअप कोड पेस्ट करें और कनेक्ट करें।
5. फिर Telegram में: `/pair pending` (अनुरोध ID, भूमिका और दायरों की समीक्षा करें), फिर अनुमोदित करें।

सेटअप कोड एक base64-एन्कोडेड JSON पेलोड है जिसमें शामिल है:

- `url`: Gateway WebSocket URL (`ws://...` या `wss://...`)
- `bootstrapToken`: प्रारंभिक पेयरिंग हैंडशेक के लिए उपयोग किया जाने वाला अल्पकालिक सिंगल-डिवाइस बूटस्ट्रैप टोकन

वह बूटस्ट्रैप टोकन अंतर्निहित पेयरिंग बूटस्ट्रैप प्रोफ़ाइल ले जाता है:

- अंतर्निहित सेटअप प्रोफ़ाइल केवल ताज़ा QR/सेटअप-कोड बेसलाइन की अनुमति देती है:
  `node` और सीमित `operator` हैंडऑफ़
- हैंड-ऑफ़ किया गया `node` टोकन `scopes: []` ही रहता है
- हैंड-ऑफ़ किया गया `operator` टोकन `operator.approvals`,
  `operator.read`, और `operator.write` तक सीमित है
- `operator.admin` और `operator.pairing` QR/सेटअप-कोड
  बूटस्ट्रैप द्वारा नहीं दिए जाते; इनके लिए अलग से अनुमोदित operator पेयरिंग या टोकन फ़्लो चाहिए
- बाद का टोकन रोटेशन/निरस्तीकरण डिवाइस के अनुमोदित
  भूमिका अनुबंध और कॉलर सत्र के operator दायरों, दोनों से सीमित रहता है

सेटअप कोड को वैध रहने तक पासवर्ड जैसा मानें।

Tailscale, सार्वजनिक, या अन्य रिमोट मोबाइल पेयरिंग के लिए, Tailscale Serve/Funnel
या किसी अन्य `wss://` Gateway URL का उपयोग करें। प्लेनटेक्स्ट `ws://` सेटअप कोड केवल
loopback, निजी LAN पतों, `.local` Bonjour होस्ट, और Android
emulator होस्ट के लिए स्वीकार किए जाते हैं। Tailnet CGNAT पते, `.ts.net` नाम, और सार्वजनिक होस्ट अभी भी
QR/सेटअप-कोड जारी होने से पहले fail closed होते हैं।

### Node डिवाइस को अनुमोदित करें

```bash
openclaw devices list
openclaw devices approve <requestId>
openclaw devices reject <requestId>
```

जब स्पष्ट अनुमोदन इसलिए अस्वीकार होता है क्योंकि अनुमोदन देने वाला paired-device सत्र
pairing-only दायरे के साथ खोला गया था, तो CLI उसी अनुरोध को
`operator.admin` के साथ फिर से आज़माता है। इससे मौजूदा admin-सक्षम paired device,
`devices/paired.json` को हाथ से संपादित किए बिना, नई Control UI/ब्राउज़र पेयरिंग को पुनर्प्राप्त कर सकता है।
Gateway फिर भी पुनः आज़माए गए कनेक्शन को सत्यापित करता है; जो टोकन
`operator.admin` के साथ प्रमाणित नहीं हो सकते, वे अवरुद्ध रहते हैं।

यदि वही डिवाइस अलग auth विवरणों के साथ फिर कोशिश करता है (उदाहरण के लिए अलग
भूमिका/दायरे/public key), तो पिछला लंबित अनुरोध प्रतिस्थापित हो जाता है और नया
`requestId` बनाया जाता है।

<Note>
पहले से paired डिवाइस को चुपचाप व्यापक एक्सेस नहीं मिलता। यदि वह अधिक दायरों या व्यापक भूमिका के लिए फिर से कनेक्ट करता है, तो OpenClaw मौजूदा अनुमोदन को जैसा है वैसा रखता है और एक नया लंबित अपग्रेड अनुरोध बनाता है। अनुमोदन देने से पहले वर्तमान में अनुमोदित एक्सेस की नए अनुरोधित एक्सेस से तुलना करने के लिए `openclaw devices list` का उपयोग करें।
</Note>

### वैकल्पिक trusted-CIDR Node auto-approve

डिवाइस पेयरिंग डिफ़ॉल्ट रूप से मैनुअल रहती है। कड़ाई से नियंत्रित नोड नेटवर्क के लिए,
आप स्पष्ट CIDR या सटीक IP के साथ पहली बार के नोड auto-approval में opt in कर सकते हैं:

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

यह केवल ताज़ा `role: node` पेयरिंग अनुरोधों पर लागू होता है जिनमें कोई अनुरोधित
दायरे नहीं होते। Operator, ब्राउज़र, Control UI, और WebChat क्लाइंट को अभी भी मैनुअल
अनुमोदन चाहिए। भूमिका, दायरा, मेटाडेटा, और public-key बदलावों को अभी भी मैनुअल
अनुमोदन चाहिए।

### Node पेयरिंग स्टेट स्टोरेज

`~/.openclaw/devices/` के अंतर्गत संग्रहीत:

- `pending.json` (अल्पकालिक; लंबित अनुरोध समाप्त हो जाते हैं)
- `paired.json` (paired डिवाइस + टोकन)

### नोट्स

- legacy `node.pair.*` API (CLI: `openclaw nodes pending|approve|reject|remove|rename`) एक
  अलग gateway-स्वामित्व वाला पेयरिंग स्टोर है। WS नोड को अभी भी डिवाइस पेयरिंग चाहिए।
- पेयरिंग रिकॉर्ड अनुमोदित भूमिकाओं के लिए टिकाऊ सत्य स्रोत है। Active
  डिवाइस टोकन उसी अनुमोदित भूमिका सेट तक सीमित रहते हैं; अनुमोदित भूमिकाओं के बाहर
  कोई इधर-उधर की टोकन प्रविष्टि नया एक्सेस नहीं बनाती।

## संबंधित दस्तावेज़

- सुरक्षा मॉडल + prompt injection: [सुरक्षा](/hi/gateway/security)
- सुरक्षित रूप से अपडेट करना (doctor चलाएं): [अपडेट करना](/hi/install/updating)
- चैनल कॉन्फ़िग:
  - Telegram: [Telegram](/hi/channels/telegram)
  - WhatsApp: [WhatsApp](/hi/channels/whatsapp)
  - Signal: [Signal](/hi/channels/signal)
  - iMessage: [iMessage](/hi/channels/imessage)
  - Discord: [Discord](/hi/channels/discord)
  - Slack: [Slack](/hi/channels/slack)