Claude Code एक समय में एक ही लॉगिन रखता है। कई खाते चलाने का तरीका यह है।

जो लोग Claude Code को नौकरी के काम और अपने निजी प्रोजेक्ट, दोनों के लिए इस्तेमाल करते हैं, उनमें से ज़्यादातर के साथ एक पल ऐसा आता है। आप ऑफ़िस का एक सत्र ख़त्म करते हैं, किसी साइड प्रोजेक्ट पर जाते हैं, और तब समझ आता है कि एजेंट अब भी उसी खाते से साइन इन है जिसका पैसा आपका नियोक्ता देता है। तो आप लॉग आउट करते हैं, अपने खाते से दोबारा लॉगिन करते हैं, और आधे घंटे बाद यही सब उल्टा करना पड़ता है।

यह चक्र कोई ग़ायब फ़ीचर नहीं है। यह इस बात का नतीजा है कि Claude Code अपना लॉगिन कहाँ रखता है, और एक बार यह पता चल जाए तो कई खाते साथ-साथ चलाना काम करने के तरीक़े की समस्या नहीं, बस कॉन्फ़िगरेशन की एक बारीकी रह जाता है।

कौन सा खाता सक्रिय है, यह एक ही एनवायरनमेंट वेरिएबल तय करता है

Claude Code में प्रोफ़ाइल नहीं होतीं। वह सब कुछ एक ही डायरेक्टरी से जोड़ता है: सत्र का मेटाडेटा, हर प्रोजेक्ट का इतिहास और लॉगिन। Linux और Windows पर लॉगिन उस डायरेक्टरी में एक .credentials.json फ़ाइल है; macOS पर वह कीचेन (Keychain) का एक आइटम है जिसका नाम डायरेक्टरी के पाथ से बनता है, इसलिए कौन सा खाता मिलेगा, यह अब भी डायरेक्टरी ही तय करती है।

वह डायरेक्टरी वही है जिसकी ओर CLAUDE_CONFIG_DIR इशारा करता है। अगर आप इसे कभी सेट नहीं करते, तो यह ~/.claude होती है।

पूरा तंत्र बस इतना ही है, और इसका एक काम का गुण है: चूँकि खाता कोई ग्लोबल सेटिंग नहीं बल्कि एक डायरेक्टरी है, दो खाते होने का मतलब है दो डायरेक्टरी होना। उनके बीच कुछ भी साझा नहीं होता। दोनों अनिश्चित काल तक साइन इन बने रहते हैं, और किसी को पता ही नहीं चलता कि दूसरा मौजूद है।

तो सीधा-सादा तरीक़ा काम कर जाता है:

# निजी
CLAUDE_CONFIG_DIR=~/.claude claude

# ऑफ़िस
CLAUDE_CONFIG_DIR=~/.claude-work claude

दूसरे वाले के अंदर एक बार /login चलाइए, और एक ही मशीन पर आपके पास दो सक्रिय खाते हो जाएँगे।

shell वाला तरीक़ा कहाँ जाकर चुभने लगता है

ऊपर वाला दो लाइन का तरीक़ा सचमुच ठीक है, बशर्ते आप एक बार में एक ही टर्मिनल खोलें और अनुशासित रहें। यह तीन वजहों से ठीक रहना बंद कर देता है, और ये तीनों एक-दूसरे पर चढ़ती जाती हैं।

वेरिएबल हर प्रोसेस के लिए अलग होता है, पूरी मशीन के लिए एक नहीं। हर नया टर्मिनल, हर नया पैन, एडिटर में जुड़ा हर shell आपकी प्रोफ़ाइल की डिफ़ॉल्ट वैल्यू से शुरू होता है। इसे .zshrc में export कर दीजिए और आपने समस्या को बस खिसका दिया है: अब दूसरा खाता वह है जिसे आप बार-बार भूलते हैं।

कौन सा खाता सक्रिय है, यह स्क्रीन पर आपको कुछ भी नहीं बताता। Claude Code अपने प्रॉम्प्ट में खाता नहीं दिखाता। आप पूछ सकते हैं, claude auth status --text से (यह उस डायरेक्टरी का लॉगिन तरीक़ा, संगठन और ईमेल दिखाता है जिसकी ओर मौजूदा shell इशारा करता है), लेकिन हर प्रॉम्प्ट से पहले इसे कोई नहीं चलाता। अगर दो टर्मिनल खुले हों और उनमें से एक ऑफ़िस के खाते पर चल रहा हो, तो दोनों एक जैसे ही दिखते हैं। पता आमतौर पर उसी वक़्त चलता है जब आप बिलिंग देखते हैं।

यह समानांतर काम में टिकता नहीं। दिलचस्प सेटअप वे होते हैं जिनमें कई प्रोजेक्ट पर एक साथ कई एजेंट चलते हैं। एक साथ चलने वाले दो सत्रों से आगे बढ़ते ही, कौन सा पैन किस वेरिएबल के साथ शुरू हुआ था यह याद रखना अनुशासन की समस्या नहीं रह जाती, वह डिज़ाइन की समस्या बन जाती है।

इसका हल और shell नहीं है। हल यह है कि फ़ैसला लॉन्च के वक़्त लेना बंद करें और खाते को उस चीज़ से जोड़ दें जो असल में उसे तय करती है: प्रोजेक्ट।

खाते को टर्मिनल से नहीं, प्रोजेक्ट से जोड़िए

आपको आमतौर पर एक नियम चाहिए होता है, कोई कमांड नहीं। कुछ इस तरह: इस क्लाइंट की रिपॉज़िटरी हमेशा इसी क्लाइंट के खाते पर चलती है। यह नियम एक बार बन जाए, फिर किसी को कुछ याद रखने की ज़रूरत नहीं रहती।

इसे ठीक से करने का मतलब है खाते को एक तय क्रम में हल करना, क्योंकि नियम को अपवाद चाहिए होते हैं। पूरे प्रोजेक्ट पर लागू डिफ़ॉल्ट ज़्यादातर मौक़ों पर सही रहता है, लेकिन कोई एक ख़ास एजेंट कहीं और चलाना पड़ सकता है: टेस्ट खाते पर एक फेंक देने लायक़ प्रयोग, या बड़े कोटा वाली सीट पर चलने वाला रिव्यू एजेंट।

ऊपर से पढ़िए: जो पहला नियम मेल खाता है, वही जीतता है। एजेंट का ओवरराइड प्रोजेक्ट की पिन को हरा देता है। प्रोजेक्ट की पिन उस सामान्य डिफ़ॉल्ट को हरा देती है जो आपने तय किया है। अगर कहीं कुछ भी कॉन्फ़िगर न हो, तो आप ~/.claude पर पहुँचते हैं, यानी वही जो एक नया इंस्टॉल पहले से करता है। यह आख़िरी फ़ॉलबैक मायने रखता है: इसका मतलब है कि मौजूदा सेटअप में इसे जोड़ने से तब तक कुछ नहीं बदलता जब तक आप ख़ुद कुछ पिन न करें।

AgentsRoom यही मॉडल लागू करता है। हर खाता एक मैनेज्ड डायरेक्टरी है, साइन इन shell के बजाय ऐप के अंदर होता है, और ऊपर बताया गया क्रम तब चलता है जब कोई एजेंट शुरू होता है, और CLAUDE_CONFIG_DIR सिर्फ़ उसी प्रोसेस पर सेट होता है। अगर आप पहले से CCS जैसा कोई थर्ड-पार्टी स्विचर इस्तेमाल करते हैं, तो दोबारा साइन इन करने के बजाय किसी खाते को मौजूदा प्रोफ़ाइल डायरेक्टरी की ओर इशारा करा सकते हैं।

यही समस्या Codex पर भी है, बस वेरिएबल अलग है

अगर आप एक से ज़्यादा प्रोवाइडर चलाते हैं, तो यह दिक़्क़त दो बार आएगी। ढाँचा एक जैसा है, वेरिएबल नहीं, इसलिए एक के लिए बना स्विचर दूसरे को कवर नहीं करता। Codex वाले पहलू का दस्तावेज़ हम अलग रखते हैं, Codex के लिए कई खाते में, साथ में यह भी कि साइन इन के तरीक़े में क्या फ़र्क़ है।

आम बात एक बार कह देना ठीक रहेगा: खातों का अलगाव हर प्रोवाइडर का अपना तंत्र है। जो भी टूल इसे एक साथ सबके लिए संभालने का दावा करे, वह या तो हर प्रोवाइडर को अलग-अलग लपेट रहा है, या सिर्फ़ एक को ही सपोर्ट करता है।

असल में टोकन कौन सा खाता जला रहा है, यह जानिए

खाते अलग करना इसकी सिर्फ़ आधी वजह है। बाक़ी आधी वजह यह जानना है कि खपत किसके हिस्से में जा रही है, ख़ासकर जब पैसा कोई क्लाइंट दे रहा हो।

shell वाले तरीक़े में यही हिस्सा चुपचाप टूटता है। जो उपयोग रीडर सिर्फ़ ~/.claude को देखते हैं, वे किसी एजेंट के कहीं और चलते ही कम गिनती दिखाने लगते हैं, और आँकड़े इतने भरोसेमंद लगते हैं कि हफ़्तों तक किसी को पता नहीं चलता। खातों को समझने वाले रीडर को हर कॉन्फ़िगर की गई डायरेक्टरी पर घूमना पड़ता है, सिर्फ़ डिफ़ॉल्ट वाली पर नहीं।

अगर आपको हर खाते और हर सत्र के आँकड़े चाहिए, तो मापने वाला पहलू हमने Claude Code टोकन उपयोग कैसे जांचें में कवर किया है, और लाइव व्यू टोकन उपयोग पेज पर है।

यह किस काम के लिए नहीं है

एक स्पष्टीकरण, क्योंकि यह सवाल उठता है और चुप्पी के बजाय इसका सीधा जवाब बनता है।

ऊपर जो कुछ भी है, वह उन खातों को अलग रखने के बारे में है जो पहले से जायज़ तौर पर मौजूद हैं। आपका नियोक्ता जिस सीट का पैसा देता है और जिस निजी सदस्यता का पैसा आप देते हैं, वे दो अलग व्यावसायिक रिश्ते हैं, और उन्हें एक ही मशीन पर बिना आपसी घालमेल के रखना एक असली, आम ज़रूरत है। किसी क्लाइंट के टोकन उसी क्लाइंट को बिल करना भी ऐसी ही ज़रूरत है, और किसी प्रयोगात्मक खाते को प्रोडक्शन खाते से दूर रखना भी।

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

लोग असल में जो सवाल पूछते हैं

क्या मैं एक ही कंप्यूटर पर दो Claude Code खाते इस्तेमाल कर सकता हूँ?

हाँ। Claude Code अपना लॉगिन, सत्र का मेटाडेटा और प्रोजेक्ट का इतिहास उसी डायरेक्टरी से जोड़ता है जिसकी ओर CLAUDE_CONFIG_DIR इशारा करता है, और डिफ़ॉल्ट रूप से वह ~/.claude होती है। इस वेरिएबल को किसी दूसरी डायरेक्टरी की ओर मोड़िए और वहाँ लॉगिन कीजिए, फिर एक ही मशीन पर आपके पास दो स्वतंत्र खाते हो जाते हैं। दोनों डायरेक्टरी के बीच कुछ भी साझा नहीं होता, इसलिए दोनों एक ही समय पर साइन इन बने रहते हैं।

लॉग आउट किए बिना Claude Code का खाता कैसे बदलूँ?

आप लॉग आउट करते ही नहीं। लॉग आउट करके दोबारा लॉगिन करने पर वही डायरेक्टरी फिर से इस्तेमाल होती है, यानी दूसरा सत्र पाने के लिए आप पहला गँवा देते हैं। इसके बजाय हर खाते को उसकी अपनी कॉन्फ़िग डायरेक्टरी दीजिए और CLI शुरू करते वक़्त CLAUDE_CONFIG_DIR सेट करके उनमें से चुनिए। दोनों के क्रेडेंशियल डिस्क पर वैध बने रहते हैं, और बदलने की कोई क़ीमत नहीं लगती।

Claude Code अपना लॉगिन कहाँ रखता है?

यह सिस्टम पर निर्भर करता है, लेकिन वह हमेशा उसी डायरेक्टरी से जुड़ा होता है जिसकी ओर CLAUDE_CONFIG_DIR इशारा करता है, और जब तक आप उसे बदलें नहीं, वह ~/.claude होती है। Linux और Windows पर क्रेडेंशियल उसी डायरेक्टरी के अंदर एक .credentials.json फ़ाइल में जाते हैं, सत्र के मेटाडेटा और हर प्रोजेक्ट के इतिहास के बग़ल में। macOS पर वे इसके बजाय लॉगिन कीचेन (login Keychain) में जाते हैं, एक ऐसे आइटम में जिसका नाम उसी डायरेक्टरी के आधार पर रखा जाता है: ~/.claude के लिए Claude Code-credentials, और किसी भी दूसरी डायरेक्टरी के लिए Claude Code-credentials- के बाद आठ हेक्साडेसिमल अक्षर। दोनों ही सूरतों में एक डायरेक्टरी यानी एक खाता, और इसीलिए उसे बदल देना कोई जुगाड़ नहीं, एक साफ़-सुथरा स्विच बन जाता है।

क्या दो एजेंट एक ही समय पर दो अलग Claude खातों पर चल सकते हैं?

हाँ, बशर्ते हर एजेंट प्रोसेस को अपने एनवायरनमेंट में अपना CLAUDE_CONFIG_DIR मिले। यह वेरिएबल ग्लोबल रूप से नहीं, बल्कि लॉन्च के वक़्त हर प्रोसेस के लिए अलग पढ़ा जाता है, इसलिए दो अलग वैल्यू के साथ शुरू किए गए दो एजेंट समानांतर में दो अलग खातों पर चलते हैं। इसी वजह से ऑफ़िस का प्रोजेक्ट और निजी प्रोजेक्ट एक ही विंडो में इस्तेमाल करने लायक़ बनते हैं।

कैसे पता करूँ कि Claude Code किस खाते में लॉगिन है?

टर्मिनल में claude auth status --text चलाइए। यह खाते का लॉगिन तरीक़ा, संगठन और ईमेल दिखाता है, उस डायरेक्टरी के लिए जिसकी ओर उस shell में CLAUDE_CONFIG_DIR इशारा करता है (Claude Code 2.1.299 पर जाँचा गया; --text के बिना यही जानकारी JSON में आती है, साथ में प्लान और कॉन्फ़िग डायरेक्टरी भी)। दूसरा खाता जाँचने के लिए कमांड के आगे वेरिएबल लगाइए: CLAUDE_CONFIG_DIR=~/.claude-work claude auth status --text। अगर जवाब Not logged in आए, तो उस डायरेक्टरी में अभी तक किसी ने साइन इन नहीं किया है, या वहाँ से खाता लॉग आउट कर दिया गया है।

एक से ज़्यादा Claude खाते रखना क्या Anthropic की शर्तों के ख़िलाफ़ है?

अलग-अलग कामों के लिए अलग-अलग खाते रखना आम बात है: आपका नियोक्ता जिस सीट का पैसा देता है और जिस निजी सदस्यता का पैसा आप देते हैं, वे दो अलग व्यावसायिक रिश्ते हैं। उपयोग नीतियाँ जिस चीज़ को निशाना बनाती हैं वह है, आप जिस प्लान पर हैं उसकी क्षमता सीमाओं से बचने के लिए खाते बनाना। अगर आपका दूसरा खाता इसलिए मौजूद है क्योंकि उसका पैसा कोई और देता है, तो आप सुरक्षित ज़मीन पर हैं। अगर वह किसी दर सीमा को रीसेट करने के लिए मौजूद है, तो नहीं। Anthropic की उपयोग नीतियाँ ही संदर्भ हैं।

संक्षेप में

Claude Code किसी खाते को एक डायरेक्टरी के रूप में रखता है, और कौन सी सक्रिय है यह CLAUDE_CONFIG_DIR तय करता है। दो डायरेक्टरी का मतलब है दो खाते, हमेशा साइन इन, और उनके बीच कुछ भी साझा नहीं।

इसका shell वाला रूप तब तक काम करता है जब तक एक से ज़्यादा टर्मिनल खुले न हों। उसके बाद आप यही चाहेंगे कि खाता प्रोजेक्ट की एक विशेषता बन जाए, अपवादों के लिए हर एजेंट पर ओवरराइड के साथ, ताकि एजेंट के शुरू होते ही सही क्रेडेंशियल जुड़ जाएँ और किसी को कुछ याद न रखना पड़े।