Skip to main content
OpenClaw उन प्रदाताओं के लिए OAuth (“सब्सक्रिप्शन प्रमाणीकरण”) का समर्थन करता है जो इसे उपलब्ध कराते हैं, विशेष रूप से OpenAI Codex (ChatGPT OAuth) और Anthropic Claude CLI का पुनः उपयोग। Anthropic के लिए व्यावहारिक विभाजन यह है:
  • Anthropic API कुंजी: सामान्य Anthropic API बिलिंग।
  • OpenClaw के भीतर Anthropic Claude CLI / सब्सक्रिप्शन प्रमाणीकरण: Anthropic के कर्मचारियों ने हमें बताया कि इस उपयोग की फिर से अनुमति है, इसलिए OpenClaw इस एकीकरण के लिए Claude CLI के पुनः उपयोग और claude -p के उपयोग को तब तक स्वीकृत मानता है, जब तक Anthropic कोई नई नीति प्रकाशित नहीं करता। उत्पादन में Anthropic के लिए API कुंजी प्रमाणीकरण अब भी अधिक सुरक्षित अनुशंसित मार्ग है।
OpenClaw, OpenAI API-कुंजी प्रमाणीकरण और ChatGPT/Codex OAuth दोनों को कैनोनिकल प्रदाता आईडी openai के अंतर्गत संग्रहीत करता है। पुराने openai-codex:* प्रोफ़ाइल आईडी और auth.order.openai-codex प्रविष्टियाँ पुरानी स्थिति हैं, जिन्हें openclaw doctor --fix सुधारता है; नए कॉन्फ़िगरेशन के लिए openai:* प्रोफ़ाइल आईडी और auth.order.openai का उपयोग करें। इस पृष्ठ में शामिल हैं:
  • OAuth टोकन एक्सचेंज कैसे काम करता है (PKCE)
  • टोकन कहाँ संग्रहीत होते हैं (और क्यों)
  • एकाधिक खातों को कैसे संभालें (प्रोफ़ाइल + प्रति-सत्र ओवरराइड)
अपने स्वयं के OAuth या API-कुंजी प्रवाह के साथ आने वाले प्रदाता Plugin उसी प्रवेश बिंदु के माध्यम से चलते हैं:

​
टोकन सिंक (यह क्यों मौजूद है)

OAuth प्रदाता सामान्यतः प्रत्येक लॉगिन/रीफ़्रेश पर एक नया रीफ़्रेश टोकन बनाते हैं। कुछ प्रदाता उसी उपयोगकर्ता/ऐप के लिए नया रीफ़्रेश टोकन जारी होने पर पिछले रीफ़्रेश टोकन को अमान्य कर देते हैं। व्यावहारिक लक्षण: OpenClaw और Claude Code / Codex CLI के माध्यम से लॉगिन करने पर, उनमें से कोई एक बाद में अचानक लॉग आउट हो जाता है। इसे कम करने के लिए, OpenClaw प्रमाणीकरण प्रोफ़ाइल स्टोर को टोकन सिंक मानता है:
  • रनटाइम प्रत्येक एजेंट के लिए एक ही स्थान से क्रेडेंशियल पढ़ता है
  • एकाधिक प्रोफ़ाइल साथ-साथ रह सकती हैं और निर्धारक ढंग से रूट हो सकती हैं
  • बाहरी CLI का पुनः उपयोग प्रदाता-विशिष्ट है: किसी प्रदाता के लिए स्थानीय OAuth प्रोफ़ाइल का स्वामित्व OpenClaw के पास आने के बाद, स्थानीय रीफ़्रेश टोकन कैनोनिकल होता है। यदि वह स्थानीय रीफ़्रेश टोकन अस्वीकार हो जाता है, तो OpenClaw बाहरी CLI टोकन सामग्री पर वापस जाने के बजाय पुनः प्रमाणीकरण के लिए प्रोफ़ाइल की सूचना देता है। Codex CLI बूटस्ट्रैप का दायरा और भी सीमित है: यह केवल तब एक खाली openai:default-शैली की प्रोफ़ाइल को प्रारंभिक सामग्री दे सकता है, जब उस प्रदाता के OAuth का स्वामित्व OpenClaw के पास न आया हो; उसके बाद OpenClaw के स्वामित्व वाले रीफ़्रेश कैनोनिकल रहते हैं
  • स्थिति/स्टार्टअप पथ बाहरी CLI की खोज को पहले से कॉन्फ़िगर किए गए प्रदाता समूह तक सीमित रखते हैं, ताकि एकल-प्रदाता सेटअप में किसी असंबंधित CLI लॉगिन स्टोर की जाँच न हो

​
संग्रहण (टोकन कहाँ रहते हैं)

सीक्रेट प्रत्येक एजेंट के लिए अलग-अलग रहते हैं और तार्किक नाम auth-profiles.json से संबद्ध होते हैं ( अंतर्निहित स्टोर एजेंट का SQLite डेटाबेस है; JSON नाम को संगतता और टूलिंग प्रदर्शन के लिए बनाए रखा गया है):
  • प्रमाणीकरण प्रोफ़ाइल (OAuth + API कुंजियाँ + वैकल्पिक मान-स्तरीय संदर्भ): ~/.openclaw/agents/<agentId>/agent/auth-profiles.json
  • पुरानी संगतता फ़ाइल: ~/.openclaw/agents/<agentId>/agent/auth.json (स्थिर api_key प्रविष्टियाँ मिलने पर साफ़ कर दी जाती हैं)
केवल पुराने आयात के लिए फ़ाइल (अब भी समर्थित, लेकिन मुख्य स्टोर नहीं):
  • ~/.openclaw/credentials/oauth.json (पहली बार उपयोग करने पर प्रमाणीकरण प्रोफ़ाइल स्टोर में आयात की जाती है)
उपरोक्त सभी $OPENCLAW_STATE_DIR (स्थिति निर्देशिका ओवरराइड) का भी पालन करते हैं। पूर्ण संदर्भ: /gateway/configuration-reference#auth-storage स्थिर सीक्रेट संदर्भों और रनटाइम स्नैपशॉट सक्रियण व्यवहार के लिए, सीक्रेट प्रबंधन देखें। जब किसी द्वितीयक एजेंट के पास कोई स्थानीय प्रमाणीकरण प्रोफ़ाइल नहीं होती, तो OpenClaw डिफ़ॉल्ट/मुख्य एजेंट स्टोर से रीड-थ्रू इनहेरिटेंस का उपयोग करता है; वह पढ़ते समय मुख्य एजेंट के स्टोर की प्रतिलिपि नहीं बनाता। OAuth रीफ़्रेश टोकन विशेष रूप से संवेदनशील होते हैं: सामान्य प्रतिलिपि प्रवाह उन्हें डिफ़ॉल्ट रूप से छोड़ देते हैं, क्योंकि कुछ प्रदाता उपयोग के बाद रीफ़्रेश टोकन को बदल देते हैं या अमान्य कर देते हैं। जब किसी एजेंट को स्वतंत्र खाते की आवश्यकता हो, तो उसके लिए अलग OAuth लॉगिन कॉन्फ़िगर करें।

​
Anthropic Claude CLI का पुनः उपयोग

OpenClaw एक स्वीकृत प्रमाणीकरण मार्ग के रूप में Anthropic Claude CLI के पुनः उपयोग और claude -p का समर्थन करता है। यदि होस्ट पर पहले से कोई स्थानीय Claude लॉगिन मौजूद है, तो ऑनबोर्डिंग/कॉन्फ़िगरेशन उसका सीधे पुनः उपयोग कर सकता है। Anthropic सेटअप-टोकन एक समर्थित टोकन-प्रमाणीकरण मार्ग के रूप में उपलब्ध रहता है, लेकिन उपलब्ध होने पर OpenClaw Claude CLI के पुनः उपयोग को प्राथमिकता देता है।
Anthropic के सार्वजनिक Claude Code दस्तावेज़ कहते हैं कि Claude Code का प्रत्यक्ष उपयोग Claude सब्सक्रिप्शन सीमाओं के भीतर रहता है, और Anthropic के कर्मचारियों ने हमें बताया कि OpenClaw-शैली के Claude CLI उपयोग की फिर से अनुमति है। इसलिए OpenClaw इस एकीकरण के लिए Claude CLI के पुनः उपयोग और claude -p के उपयोग को तब तक स्वीकृत मानता है, जब तक Anthropic कोई नई नीति प्रकाशित नहीं करता।Anthropic के वर्तमान प्रत्यक्ष-Claude-Code प्लान दस्तावेज़ों के लिए, अपने Pro या Max प्लान के साथ Claude Code का उपयोग और अपने Team या Enterprise प्लान के साथ Claude Code का उपयोग देखें।यदि आपको OpenClaw में अन्य सब्सक्रिप्शन-शैली के विकल्प चाहिए, तो OpenAI Codex, Qwen Cloud Coding Plan, MiniMax Coding Plan, और Z.AI / GLM Coding Plan देखें।

​
OAuth एक्सचेंज (लॉगिन कैसे काम करता है)

OpenClaw के इंटरैक्टिव लॉगिन प्रवाह openclaw/plugin-sdk/llm.ts में लागू किए गए हैं और विज़ार्ड/कमांड से जुड़े हैं।

​
Anthropic सेटअप-टोकन

प्रवाह की संरचना:
  1. Claude Code वाली किसी भी मशीन पर claude setup-token चलाकर टोकन बनाएँ, फिर OpenClaw से Anthropic सेटअप-टोकन या पेस्ट-टोकन शुरू करें
  2. OpenClaw परिणामी Anthropic क्रेडेंशियल को एक प्रमाणीकरण प्रोफ़ाइल में संग्रहीत करता है
  3. मॉडल चयन anthropic/... पर बना रहता है
  4. मौजूदा Anthropic प्रमाणीकरण प्रोफ़ाइल रोलबैक/क्रम नियंत्रण के लिए उपलब्ध रहती हैं

​
OpenAI Codex (ChatGPT OAuth)

OpenAI Codex OAuth को Codex CLI के बाहर उपयोग करने के लिए स्पष्ट रूप से समर्थन प्राप्त है, जिसमें OpenClaw कार्यप्रवाह भी शामिल हैं। लॉगिन कमांड कैनोनिकल OpenAI प्रदाता आईडी का उपयोग करता है:
एक एजेंट में एकाधिक ChatGPT/Codex OAuth खातों के लिए --profile-id openai:<name> का उपयोग करें। नई प्रोफ़ाइल के लिए openai-codex:<name> का उपयोग न करें। Doctor उस पुराने उपसर्ग को टकराव-मुक्त openai:* प्रोफ़ाइल आईडी में माइग्रेट करता है; सुधार के बाद प्रोफ़ाइल आईडी को auth.order या /model ...@<profileId> में कॉपी करने से पहले openclaw models auth list --provider openai चलाएँ। प्रवाह की संरचना (PKCE):
  1. एक PKCE सत्यापनकर्ता/चुनौती और एक यादृच्छिक state बनाएँ
  2. https://auth.openai.com/oauth/authorize?... खोलें (स्कोप openid profile email offline_access)
  3. http://localhost:1455/auth/callback पर कॉलबैक कैप्चर करने का प्रयास करें ( कॉलबैक होस्ट डिफ़ॉल्ट रूप से localhost होता है और केवल लूपबैक होस्ट स्वीकार करता है; OPENCLAW_OAUTH_CALLBACK_HOST से ओवरराइड करें)
  4. यदि कॉलबैक आने से पहले आप कोई कोड पेस्ट कर सकते हैं (या आप रिमोट/हेडलेस हैं और कॉलबैक बाइंड नहीं हो सकता), तो इसके बजाय रीडायरेक्ट URL/कोड पेस्ट करें - मैन्युअल पेस्ट ब्राउज़र कॉलबैक के साथ प्रतिस्पर्धा करता है और जो भी पहले पूरा होता है वही प्रभावी होता है
  5. https://auth.openai.com/oauth/token पर कोड का एक्सचेंज करें
  6. एक्सेस टोकन से accountId निकालें और { access, refresh, expires, accountId } संग्रहीत करें
विज़ार्ड पथ openclaw onboard → प्रमाणीकरण विकल्प openai है।

​
रीफ़्रेश + समाप्ति

प्रोफ़ाइल एक expires टाइमस्टैम्प संग्रहीत करती हैं। रनटाइम पर:
  • यदि expires भविष्य में है, तो संग्रहीत एक्सेस टोकन का उपयोग करें
  • यदि समाप्त हो चुका है, तो रीफ़्रेश करें (फ़ाइल लॉक के अंतर्गत) और संग्रहीत क्रेडेंशियल को अधिलेखित करें
  • यदि कोई द्वितीयक एजेंट इनहेरिट की गई मुख्य-एजेंट OAuth प्रोफ़ाइल पढ़ता है, तो रीफ़्रेश, रीफ़्रेश टोकन को द्वितीयक एजेंट स्टोर में कॉपी करने के बजाय मुख्य एजेंट स्टोर में वापस लिखा जाता है
  • बाहरी रूप से प्रबंधित CLI क्रेडेंशियल (Claude CLI, सीमित Codex CLI बूटस्ट्रैप; टोकन सिंक देखें) की प्रतिलिपि बनाए गए रीफ़्रेश टोकन को खर्च करने के बजाय उन्हें फिर से पढ़ा जाता है। यदि प्रबंधित रीफ़्रेश विफल होता है, तो OpenClaw बाहरी CLI टोकन सामग्री लौटाने के बजाय प्रभावित प्रोफ़ाइल की पुनः प्रमाणीकरण के लिए सूचना देता है।
रीफ़्रेश प्रवाह स्वचालित है; सामान्यतः आपको टोकन मैन्युअल रूप से प्रबंधित करने की आवश्यकता नहीं होती।

​
एकाधिक खाते (प्रोफ़ाइल) + रूटिंग

दो तरीके:

​
1) पसंदीदा: अलग एजेंट

यदि आप चाहते हैं कि “व्यक्तिगत” और “कार्य” कभी परस्पर संपर्क न करें, तो पृथक एजेंट (अलग सत्र + क्रेडेंशियल + कार्यस्थान) का उपयोग करें:
फिर प्रत्येक एजेंट के लिए प्रमाणीकरण (विज़ार्ड) कॉन्फ़िगर करें और चैट को सही एजेंट तक रूट करें।

​
2) उन्नत: एक एजेंट में एकाधिक प्रोफ़ाइल

प्रमाणीकरण प्रोफ़ाइल स्टोर समान प्रदाता के लिए एकाधिक प्रोफ़ाइल आईडी का समर्थन करता है। उपयोग की जाने वाली प्रोफ़ाइल चुनें:
  • कॉन्फ़िगरेशन क्रम (auth.order) के माध्यम से वैश्विक रूप से
  • /model ...@<profileId> के माध्यम से प्रति-सत्र
उदाहरण (सत्र ओवरराइड):
  • /model Opus@anthropic:work
मौजूदा प्रोफ़ाइल आईडी सूचीबद्ध करने के लिए:
संबंधित दस्तावेज़:

​
संबंधित