Codex CLI में दो अकाउंट: वर्क और पर्सनल लॉगिन को कैसे अलग करें

पर्सनल प्रोजेक्ट्स के साथ-साथ वर्क टास्क के लिए Codex CLI का उपयोग करते समय, आपको एनवायरनमेंट और अकाउंट्स को अलग रखने का एक विश्वसनीय तरीका चाहिए होता है। --profile फ़्लैग अकाउंट स्विच करने के लिए डिज़ाइन नहीं किया गया है: बेसिक कॉन्फ़िगरेशन दस्तावेज़ के अनुसार, प्रोफाइल केवल आपके मुख्य कॉन्फ़िगरेशन के ऊपर $CODEX_HOME/<name>.config.toml को ओवरले करते हैं (जैसे मॉडल चुनना, सैंडबॉक्स स्तर या MCP सर्वर बदलना), लेकिन वे एक्टिव ऑथेंटिकेशन क्रेडेंशियल्स को नहीं बदलते हैं।

अलग-अलग अकाउंट्स का उपयोग करने के लिए, आपको CODEX_HOME एनवायरनमेंट वेरिएबल के माध्यम से स्वतंत्र डायरेक्टरी तय करनी होगी और हर डायरेक्टरी के लिए अलग से लॉगिन प्रक्रिया (codex login) पूरी करनी होगी।

सेशन फ़ाइलों को मैन्युअली कॉपी करने के जोखिम

Habr पर एक लेख में एक यूज़र वर्कअराउंड का उदाहरण दिया गया है: लेखक ने एक bash स्क्रिप्ट का उपयोग करके ऑथराइज़ेशन फ़ाइलों की अदला-बदली करके अकाउंट स्विचिंग को ऑटोमेट किया और एक अनडॉक्यूमेंटेड वेब इंटरफ़ेस एंडपॉइंट के माध्यम से बचे हुए कोटे की जानकारी ली। लेखक ने स्पष्ट रूप से इस समाधान की सबसे बड़ी खामी की ओर इशारा किया था—आंतरिक, प्राइवेट बैकएंड API पर निर्भरता, जो किसी भी समय बदल सकती है।

सेशन फ़ाइलों से सीधे छेड़छाड़ करने से टोकन लाइफसाइकिल भी खराब होने का जोखिम रहता है: जब एक जगह रिफ्रेश टोकन रोटेट होता है, तो दूसरी डायरेक्टरी में कॉपी किया गया डुप्लिकेट अमान्य हो सकता है। फ़ाइल कॉपी करने के बाद ऑथराइज़ेशन एरर का ऐसा ही एक मामला issue #15410 में दर्ज है। हालांकि यह एक अकेला रिपोर्ट यह साबित नहीं करता कि हर कॉपी की गई फ़ाइल निश्चित रूप से ख़राब हो जाएगी, लेकिन फ़ाइलों को मैन्युअली कॉपी करना अनावश्यक परिचालन जोखिम पैदा करता है। कभी भी auth.json को न पढ़ें और न ही कॉपी करें, और प्राइवेट बैकएंड API का उपयोग न करें। मानक तरीका यह है कि CLI को अलग-अलग डायरेक्टरी में स्वतंत्र रूप से सेशन मैनेज करने दें।

क्रेडेंशियल स्टोरेज और पॉलिसी की सीमाएं

अलग डायरेक्टरी सेट करने से पहले, यह समझना महत्वपूर्ण है कि ऑथेंटिकेशन डेटा कहाँ और कैसे स्टोर होता है। ऑथेंटिकेशन दस्तावेज़ के अनुसार, cli_auth_credentials_store कॉन्फ़िगरेशन सेटिंग निम्नलिखित मोड को सपोर्ट करती है:

• file — क्रेडेंशियल्स CODEX_HOME डायरेक्टरी के भीतर एक लोकल auth.json फ़ाइल में सेव होते हैं।
• keyring — क्रेडेंशियल्स सिस्टम कीरिंग (macOS पर Keychain, Linux पर Secret Service) में स्टोर होते हैं।
• auto — CLI सिस्टम कीरिंग का उपयोग करने का प्रयास करता है, और कीरिंग उपलब्ध न होने पर फ़ाइल स्टोरेज पर वापस आ जाता है।
• ephemeral — सेशन केवल वर्तमान चल रहे प्रोसेस की मेमोरी में रहता है।

एनवायरनमेंट सेपरेशन की योजना बनाते समय, इन सावधानियों और सीमाओं को ध्यान में रखें:

• यदि मशीन पर केंद्रीकृत संगठनात्मक नीतियां लागू होती हैं, तो अलग CODEX_HOME डायरेक्टरी पूर्ण अलगाव की गारंटी नहीं देती हैं (Managed configuration / requirements.toml)। यदि किसी एडमिनिस्ट्रेटर ने कोई विशिष्ट ऑथेंटिकेशन विधि या स्टोरेज प्रकार अनिवार्य किया है, तो वे नीतियां लोकल कॉन्फ़िगरेशन को ओवरराइड कर देती हैं।
• CLI सोर्स कोड में, कीरिंग सर्विस CODEX_HOME पाथ को हैश करके डायरेक्टरी में अंतर करती है (देखें storage.rs)। इसलिए यह मानना गलत है कि अलग-अलग डायरेक्टरी अपने आप कीरिंग में एक ही एंट्री शेयर करती हैं। फिर भी, यह सभी एनवायरनमेंट में पूर्ण अलगाव की गारंटी नहीं देता: वास्तविक स्टोरेज व्यवहार प्लेटफ़ॉर्म और ऑपरेटिंग सिस्टम सेटिंग्स पर निर्भर करता है, इसलिए आपको अपनी मशीन पर इसे जांचना चाहिए।
• जब तक एक्टिव स्टोरेज मोड की पुष्टि नहीं हो जाती, तब तक आप यह नहीं मान सकते कि टोकन केवल डायरेक्टरी के भीतर ही मौजूद हैं।

दो एनवायरनमेंट के लिए स्टेप-बाय-स्टेप सेटअप

हम दो स्पष्ट डायरेक्टरी सेट करेंगे: $HOME/.codex-personal और $HOME/.codex-work। आपकी मौजूदा ~/.codex डायरेक्टरी में कोई बदलाव नहीं किया जाएगा और वह सुरक्षित रहेगी।

स्टेप 1. डायरेक्टरी तैयार करें

केवल अपने यूज़र अकाउंट के लिए एक्सेस अनुमतियों को सीमित करते हुए डायरेक्टरी बनाएं:

mkdir -p "$HOME/.codex-personal" "$HOME/.codex-work"
chmod 700 "$HOME/.codex-personal" "$HOME/.codex-work"

यदि आपके संगठन की नीतियां फ़ाइल-आधारित स्टोरेज की अनुमति देती हैं, तो आप लॉगिन करने से पहले प्रत्येक डायरेक्टरी में config.toml में स्पष्ट रूप से cli_auth_credentials_store = "file" सेट कर सकते हैं:

cat << 'EOF' > "$HOME/.codex-personal/config.toml"
cli_auth_credentials_store = "file"
EOF

cat << 'EOF' > "$HOME/.codex-work/config.toml"
cli_auth_credentials_store = "file"
EOF

यदि आपके डिवाइस पर कॉर्पोरेट ऑथेंटिकेशन की अनिवार्य आवश्यकताएं लागू हैं, तो इसके बजाय एडमिनिस्ट्रेटर द्वारा स्वीकृत क्रेडेंशियल स्टोर मोड का उपयोग करें।

स्टेप 2. स्वतंत्र ऑथेंटिकेशन

ब्राउज़र-आधारित ऑथेंटिकेशन chatgpt.com पर वर्तमान में सक्रिय सेशन से जुड़ता है। ब्राउज़र प्रोफाइल मेनू केवल मौजूदा वेब सेशन दिखाता है और यह साबित नहीं करता कि किसी विशिष्ट CODEX_HOME में कौन से क्रेडेंशियल्स सेव हुए हैं। प्रत्येक ब्राउज़र लॉगिन के दौरान आपको इच्छित अकाउंट और Workspace की पुष्टि करनी होगी:

• पर्सनल एनवायरनमेंट में लॉगिन करने से पहले, ब्राउज़र में अपने पर्सनल अकाउंट पर स्विच करें।
• वर्क एनवायरनमेंट में लॉगिन करने से पहले, ब्राउज़र में संबंधित कॉर्पोरेट अकाउंट या Workspace चुनें।

प्रत्येक एनवायरनमेंट के लिए अलग-अलग लॉगिन प्रक्रिया चलाएं:

env CODEX_HOME="$HOME/.codex-personal" codex login

env CODEX_HOME="$HOME/.codex-work" codex login

प्रत्येक स्थिति में, खुलने वाली ब्राउज़र विंडो में ऑथराइज़ेशन प्रॉम्प्ट की पुष्टि करें। यदि कोई संदेह हो, तो मानक env CODEX_HOME="..." codex logout चलाएं और ब्राउज़र में एक्टिव अकाउंट की दोबारा जांच करते हुए उसी विशिष्ट डायरेक्टरी के लिए लॉगिन दोहराएं (टोकन फ़ाइलों को पढ़ने या मैन्युअली कॉपी करने की कोशिश न करें)।

स्टेप 3. लॉगिन स्टेटस की जांच

दोनों डायरेक्टरी में ऑथराइज़ेशन स्टेटस जांचें:

env CODEX_HOME="$HOME/.codex-personal" codex login status
env CODEX_HOME="$HOME/.codex-work" codex login status

codex login status कमांड केवल ऑथेंटिकेशन विधि प्रदर्शित करता है, लेकिन यह किसी विशिष्ट यूज़र अकाउंट की पहचान को साबित नहीं करता है। बिलिंग स्रोतों के अंतर को ध्यान में रखें: ChatGPT लॉगिन संबंधित प्लान और Workspace के सब्सक्रिप्शन या उसमें शामिल कोटा लिमिट पर निर्भर करता है, जबकि API-key लॉगिन का बिल OpenAI Platform के माध्यम से अलग से लिया जाता है।

यह वर्कफ़्लो दो अलग-अलग अकाउंट्स में ChatGPT लॉगिन के लिए है। यदि status में API key दिखाई देती है, तो अपेक्षित परिदृश्य पूरा नहीं हुआ है—उस डायरेक्टरी के लिए लॉगिन चरण को फिर से जांचें।

स्टेप 4. टेस्ट टास्क चलाना

वर्क एनवायरनमेंट को वेरिफ़ाई करने के लिए, read-only सैंडबॉक्स के साथ अनुमतियों को सीमित करते हुए टेस्ट वर्क रिपॉजिटरी में एक वास्तविक कार्य चलाएं:

cd /path/to/work-project
env CODEX_HOME="$HOME/.codex-work" codex exec --sandbox read-only "README.md पढ़ें और प्रोजेक्ट का उद्देश्य बताएं। फ़ाइलें न बदलें"

एक छोटा read-only टेस्ट यह पुष्टि करता है कि सेशन और सैंडबॉक्स काम कर रहे हैं। टेस्ट चलाने के बाद अपने अकाउंट या Workspace में Usage सेक्शन देखना केवल संभावित रिपोर्टिंग देरी के साथ एक अप्रत्यक्ष संकेत प्रदान करता है, पहचान का कोई सत्यापित प्रमाण नहीं। यदि कोई अनिश्चितता बनी रहती है, तो env CODEX_HOME="$HOME/.codex-work" codex logout चलाएं और अपने ब्राउज़र में सक्रिय अकाउंट की सावधानीपूर्वक जांच करते हुए लॉगिन प्रक्रिया दोहराएं।

रोज़मर्रा का उपयोग

नियमित डेवलपमेंट के लिए, आप सीधे CODEX_HOME जोड़कर कमांड चला सकते हैं, या अपनी शेल कॉन्फ़िगरेशन फ़ाइल (~/.zshrc या ~/.bashrc) में हेल्पर फ़ंक्शन परिभाषित कर सकते हैं:

codex-personal() {
  env CODEX_HOME="$HOME/.codex-personal" codex "$@"
}

codex-work() {
  env CODEX_HOME="$HOME/.codex-work" codex "$@"
}

"$@" के माध्यम से आर्ग्युमेंट्स पास करके इन हेल्पर्स को कॉल करने के उदाहरण:

codex-work login status

cd /path/to/work-project
codex-work exec --sandbox read-only "README.md पढ़ें और प्रोजेक्ट का उद्देश्य बताएं। फ़ाइलें न बदलें"

codex-personal