सामान्य समस्याओं का निवारण: इंस्टॉलेशन, लॉगिन और फ़ाइल संपादन त्रुटियों को एक-एक करके हल करना

📚 सीरीज़ नेविगेशन: पिछला लेख 36 सर्वश्रेष्ठ अभ्यास आपको कोडिंग की अच्छी आदतों को अपनाने के बारे में बताता है। यह लेख इसके विपरीत काम करेगा — यह समस्याओं के निवारण पर केंद्रित है: जब Codex इंस्टॉल न हो, लॉगिन न हो, फ़ाइलों को संशोधित करने से मना कर दे, या काम करते समय असामान्य व्यवहार दिखाए... इन सभी समस्याओं को एक-एक करके हल किया जाएगा। अगला लेख 38 शब्दावली पूरे Codex अध्याय की शब्दावली मार्गदर्शिका है, जहां आप किसी भी कठिन शब्द का अर्थ देख सकते हैं।

"भाई, मैंने npm install पूरा कर लिया है, लेकिन codex टाइप करने पर command not found कह रहा है, क्या करूँ?"

"लॉगिन प्रक्रिया पूरी नहीं हो रही है, ब्राउज़र नहीं खुल रहा है, क्या मुझे VPN/प्रॉक्सी की आवश्यकता है?"

"वह मेरा कोड तो पढ़ पा रहा है, लेकिन फ़ाइलें बदलते समय सैंडबॉक्स त्रुटि दिखा रहा है — मैंने तो ऐसा कोई नियम सेट नहीं किया था?"

ये पिछले दो वर्षों में मुझसे सबसे अधिक पूछे गए प्रश्न हैं, जो लोग रोज़ अनुभव करते हैं। सच कहूँ तो, 90% Codex समस्याएं बग्स नहीं हैं, बल्कि उनके डिफ़ॉल्ट व्यवहार को न समझना है — या तो प्रमाणीकरण (authentication) समाप्त हो गया है, या अनुमतियाँ सख्त हैं, या संदर्भ सीमा (context window) समाप्त हो गई है। इस लेख में हम सिद्धांतों के बजाय व्यावहारिक रूप से अक्सर आने वाली समस्याओं को एक-एक करके हल करेंगे, और उनका कारण व समाधान जानेंगे ताकि आप स्वयं समस्या का समाधान कर सकें।

इस लेख को पूरा पढ़ने के बाद, आपको मिलेगा:

• अक्सर आने वाली दस प्रमुख समस्याओं के कारण और समाधान, जिन्हें अनुभव के आधार पर क्रमबद्ध किया गया है
• इंस्टॉलेशन, लॉगिन और नेटवर्क समस्याओं के समाधान
• "वह फ़ाइलें संशोधित क्यों नहीं कर रहा" के पीछे का सच, और अनुमतियाँ बदलने का तरीका
• संदर्भ सीमा समाप्त होने पर क्या निर्णय लें: /compact या /new
• एक "तीन-सूत्रीय त्वरित जांच सूची," जिससे आप किसी भी नई समस्या का समाधान स्वयं कर सकें

⚠️ नीचे दिए गए सभी विशिष्ट कमांड, कॉन्फ़िगरेशन विकल्प और डिफ़ॉल्ट व्यवहार Codex के आधिकारिक दस्तावेज़ पर आधारित हैं; मॉडल के नाम और संस्करण आपके पास उपलब्ध संस्करण के अनुसार भिन्न हो सकते हैं, हमेशा अपने स्थानीय codex --version और /model पैनल के वास्तविक व्यवहार को आधार मानें। अनुमतियों से संबंधित जानकारी आधिकारिक दस्तावेज़ों पर आधारित है, लेकिन अनुमति प्रोफ़ाइल (permission profiles) अभी Beta चरण में हैं और इनमें बदलाव हो सकता है।

---

01 त्वरित जांच का मूल नियम: पहले इन तीन चीज़ों की जांच करें

निष्कर्ष यह है: जब भी कोई समस्या आए, तो सीधे रीइंस्टॉल करने के बजाय पहले इन तीन चीज़ों की जांच करें — संस्करण (version), लॉगिन और अनुमतियां (permissions)। 80% समस्याओं का कारण यही तीन होते हैं।

सादृश्य: डॉक्टर द्वारा जांच। जब आप क्लिनिक जाते हैं, तो डॉक्टर सीधे स्कैन नहीं करता, बल्कि पहले आपका तापमान, रक्तचाप और समस्या पूछता है — ये तीन बुनियादी जांच अधिकांश बड़ी समस्याओं का पता लगा देती हैं। Codex के लिए भी इन तीन चीज़ों की जांच करें:

# 1. संस्करण की जांच करें
codex --version

# 2. लॉगिन स्थिति की जांच करें
codex login status

# 3. वर्तमान सत्र की अनुमतियां देखें (TUI में टाइप करें)
/status

पहला कमांड बताएगा कि इंस्टॉलेशन सही है या नहीं; दूसरा कमांड लॉगिन स्थिति बताएगा; और तीसरा कमांड सैंडबॉक्स स्तर और अनुमति नीति बताएगा।

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

💡 संक्षेप में: किसी भी समस्या में पहले संस्करण, लॉगिन स्थिति और अनुमतियों की जांच करें, यह समस्या निवारण का सबसे आसान तरीका है।

---

02 इंस्टॉलेशन में समस्या, कमांड न मिलना

यह नए उपयोगकर्ताओं के सामने आने वाली पहली और सबसे आम समस्या है।

लक्षण: npm install के बाद codex चलाने पर टर्मिनल command not found: codex त्रुटि दिखाता है; या इंस्टॉलेशन के बीच में लाल रंग की त्रुटियां दिखाई देती हैं।

कारण: आमतौर पर यह Codex की समस्या नहीं होती, बल्कि आपके सिस्टम वातावरण की समस्या होती है। तीन मुख्य कारण हो सकते हैं: npm की वैश्विक बाइनरी निर्देशिका (global bin directory) आपके सिस्टम के PATH में शामिल नहीं है, Node.js का संस्करण बहुत पुराना है, या npm के पास वैश्विक रूप से इंस्टॉल करने की अनुमति नहीं है।

समाधान (नीचे दिए गए तरीकों को एक-एक करके आज़माएं):

• पहले Node.js संस्करण की जांच करें: node --version चलाएं, यदि यह बहुत पुराना है तो इसे अपडेट करें, क्योंकि पुराने संस्करणों पर नए टूल्स इंस्टॉल नहीं होते।
• command not found का मतलब आमतौर पर PATH की समस्या है: npm config get prefix चलाकर देखें कि वैश्विक निर्देशिका कहाँ है, और पुष्टि करें कि उसका bin फ़ोल्डर आपके सिस्टम के PATH में शामिल है या नहीं।
• यदि इंस्टॉलेशन के दौरान EACCES जैसी अनुमतियों की त्रुटि आती है, तो इसका मतलब है कि आपके पास सिस्टम फ़ोल्डर में लिखने का अधिकार नहीं है। कभी भी sudo npm install -g का उपयोग न करें — इससे भविष्य में अधिकारों से संबंधित कई समस्याएं हो सकती हैं। इसका सही समाधान npm की वैश्विक निर्देशिका को किसी ऐसे फ़ोल्डर में बदलना है जहां आपके पास अधिकार हों, या Node.js के लिए किसी संस्करण प्रबंधक (जैसे nvm) का उपयोग करना है।
• यदि आप npm का उपयोग नहीं करना चाहते, तो Codex आधिकारिक रूप से अन्य इंस्टॉलेशन विधियां भी प्रदान करता है। अपने प्लेटफ़ॉर्म के अनुसार इंस्टॉलेशन दस्तावेज़ देखें। मैंने स्वयं एक नए Mac पर अनुमतियों की समस्या आने पर आधिकारिक रूप से सुझाई गई दूसरी विधि का उपयोग किया और यह तीन मिनट में हो गया।

प्लेटफ़ॉर्म अंतर: Windows उपयोगकर्ताओं के लिए इंस्टॉलेशन से संबंधित कुछ अलग चुनौतियाँ हो सकती हैं (जैसे WSL की आवश्यकता, पाथ अंतर आदि), जिनके बारे में विस्तार से 33 Windows उपयोग के महत्वपूर्ण बिंदु में बताया गया है।

💡 संक्षेप में: command not found का मुख्य कारण PATH में npm global bin का न होना है, और अनुमतियों की समस्या होने पर sudo का उपयोग करने से बचें।

---

03 लॉगिन विफलता, प्रमाणीकरण (Authentication) समाप्त होना

इंस्टॉलेशन के बाद लॉगिन की समस्या आ सकती है।

लक्षण: codex login चलाने पर ब्राउज़र नहीं खुलता, या ब्राउज़र में लॉगिन करने के बाद टर्मिनल पर कोई प्रतिक्रिया नहीं होती और वह घूमता रहता है; या काम करते समय अचानक "अनधिकृत (unauthorized)" या "सत्र समाप्त (session expired)" होने का संदेश दिखाई देता है।

कारण: Codex लॉगिन डिफ़ॉल्ट रूप से ब्राउज़र रीडायरेक्ट का उपयोग करता है — वह लॉगिन टोकन प्राप्त करने के लिए स्थानीय स्तर पर localhost:1455 पर एक अस्थायी सेवा चलाता है। यह तीन स्थितियों में विफल हो सकता है: रिमोट या बिना GUI वाले सर्वर पर ब्राउज़र का न होना, नेटवर्क द्वारा उस पोर्ट को ब्लॉक किया जाना, या प्रमाणीकरण कैश का दूषित होना।

समाधान:

• यदि सब कुछ सामान्य है लेकिन टर्मिनल आगे नहीं बढ़ रहा है, तो पुष्टि करें कि ब्राउज़र में लॉगिन प्रक्रिया पूरी हो गई है और localhost:1455 पोर्ट किसी अन्य सेवा द्वारा उपयोग नहीं किया जा रहा है या फ़ायरवॉल द्वारा ब्लॉक नहीं है।
• यदि आप बिना ब्राउज़र वाले वातावरण (जैसे सर्वर, Docker, या SSH) में हैं, तो सबसे अच्छा तरीका "डिवाइस कोड लॉगिन" (device code) का उपयोग करना है:

codex login --device-auth

यह आपको एक लिंक और एक अस्थायी कोड देगा। आप किसी भी ब्राउज़र वाली मशीन पर वह लिंक खोलकर कोड दर्ज करें और पुष्टि करें, जिसके बाद आपका टर्मिनल प्रमाणित हो जाएगा। यह रिमोट सर्वर पर लॉगिन करने का सबसे आसान तरीका है।

• यदि डिवाइस कोड भी काम न करे, तो एक पारंपरिक तरीका यह है: जिस कंप्यूटर पर Codex लॉगिन काम कर रहा है, वहां से ~/.codex/auth.json फ़ाइल को कॉपी करके प्रभावित कंप्यूटर पर उसी पाथ पर रख दें। ध्यान दें: इस फ़ाइल में आपका टोकन (पासवर्ड के समान) होता है, इसे कभी भी Git में न जोड़ें और न ही किसी को भेजें।
• यदि काम करते समय बार-बार लॉगिन समाप्त हो जाता है: सामान्यतः Codex का लॉगिन टोकन समाप्त होने से पहले स्वतः अपडेट हो जाता है। यदि ऐसा बार-बार हो रहा है, तो पहले codex login status से जांचें, और आवश्यकता होने पर codex logout करके दोबारा codex login करें। लॉगिन के विवरण codex-login.log में दर्ज होते हैं, आप वहां भी देख सकते हैं।

वातावरण	अनुशंसित लॉगिन तरीका
ब्राउज़र उपलब्ध होने पर	सीधे codex login चलाएं और ब्राउज़र का उपयोग करें
रिमोट / सर्वर / बिना GUI के	codex login --device-auth (डिवाइस कोड)
डिवाइस कोड भी काम न करने पर	अन्य मशीन पर लॉगिन करके ~/.codex/auth.json फ़ाइल कॉपी करें
कॉर्पोरेट TLS प्रॉक्सी / निजी CA	CODEX_CA_CERTIFICATE सेट करने के बाद लॉगिन करें

पिछले साल एक बिना डेस्कटॉप वाले सर्वर पर काम करते समय मैं codex login चलाकर ब्राउज़र खुलने की प्रतीक्षा कर रहा था, और मुझे बाद में एहसास हुआ कि वहां कोई ब्राउज़र ही नहीं था। तब मैंने codex login --device-auth का उपयोग किया और यह बहुत आसानी से हो गया। रिमोट सर्वर पर हमेशा डिवाइस कोड का उपयोग करें।

💡 संक्षेप में: रिमोट मशीन पर लॉगिन करने के लिए ब्राउज़र के बजाय codex login --device-auth (डिवाइस कोड) का उपयोग करें।

---

04 नेटवर्क त्रुटियाँ, प्रॉक्सी की आवश्यकता

लक्षण: लॉगिन करते समय, बातचीत करते समय, या टास्क चलाते समय टर्मिनल घूमता रहता है और अंत में टाइमआउट या कनेक्शन विफलता की त्रुटि दिखाता है।

कारण: Codex के मॉडल OpenAI सर्वर पर चलते हैं, जिन्हें कुछ क्षेत्रों में बिना प्रॉक्सी/VPN के सीधे एक्सेस नहीं किया जा सकता। इसके अतिरिक्त, कॉर्पोरेट नेटवर्क के TLS प्रॉक्सी या निजी CA प्रमाणपत्र भी कनेक्शन को ब्लॉक कर सकते हैं।

समाधान:

• यदि आवश्यक हो तो VPN/प्रॉक्सी का उपयोग करें: सुनिश्चित करें कि आपका प्रॉक्सी वैश्विक (global) मोड में या संबंधित डोमेन के लिए सक्षम हो। केवल ब्राउज़र एक्सटेंशन चालू रखने और टर्मिनल में प्रॉक्सी न होने पर कनेक्शन विफल रहेगा।
• पुष्टि करें कि टर्मिनल में प्रॉक्सी सक्षम है: अक्सर ब्राउज़र में इंटरनेट काम करता है लेकिन टर्मिनल में नहीं। टर्मिनल में HTTP_PROXY या HTTPS_PROXY पर्यावरण चर (environment variables) सेट करें या वैश्विक प्रॉक्सी टूल का उपयोग करें।
• यदि कॉर्पोरेट नेटवर्क निजी CA का उपयोग करता है, तो कनेक्शन विफलता से बचने के लिए अपने PEM प्रमाणपत्र का पाथ सेट करें:

export CODEX_CA_CERTIFICATE=/path/to/corporate-root-ca.pem
codex login

यदि CODEX_CA_CERTIFICATE सेट नहीं है, तो यह SSL_CERT_FILE का उपयोग करेगा। यह सेटिंग लॉगिन, सामान्य HTTPS अनुरोधों और सुरक्षित WebSocket कनेक्शनों के लिए काम करेगी।

एक बार मैं कंपनी के नेटवर्क में था और मेरा ब्राउज़र तो काम कर रहा था लेकिन Codex कनेक्ट नहीं हो रहा था। बाद में मुझे पता चला कि कंपनी की TLS प्रॉक्सी प्रमाणपत्रों को बदल रही थी। जब मैंने CODEX_CA_CERTIFICATE को IT विभाग द्वारा दिए गए प्रमाणपत्र पाथ पर सेट किया, तो यह तुरंत काम करने लगा। यह हमेशा याद रखें: "ब्राउज़र में इंटरनेट चलने का मतलब यह नहीं है कि टर्मिनल में भी Codex काम करेगा।"

💡 संक्षेप में: आवश्यक होने पर टर्मिनल में प्रॉक्सी सक्षम करें, और कॉर्पोरेट CA समस्याओं के लिए CODEX_CA_CERTIFICATE का उपयोग करें।

---

05 मॉडल विकल्प न मिलना, विशिष्ट मॉडल का न होना

लक्षण: TUI में /model पैनल में कोई विशिष्ट मॉडल दिखाई नहीं देता; या किसी मॉडल का उपयोग करने पर "मॉडल अनुपलब्ध/अमान्य" होने की त्रुटि आती है।

कारण: उपलब्ध मॉडल इस बात पर निर्भर करते हैं कि आपने लॉगिन कैसे किया है (ChatGPT सदस्यता बनाम API की) और आपके पैकेज पर; कुछ मॉडल प्रायोगिक (preview) होते हैं और केवल विशिष्ट ग्राहकों के लिए होते हैं; और कुछ पुराने मॉडलों को अब बंद कर दिया गया है।

समाधान:

• हमेशा TUI में /model पैनल में सूचीबद्ध मॉडलों को ही आधार मानें: वर्तमान में प्रमुख मॉडल gpt-5.5 है, और उप-एजेंटों के लिए हल्का मॉडल gpt-5.4-mini है। ये दोनों अधिकांश खातों के लिए उपलब्ध होते हैं।
• gpt-5.3-codex-spark का दिखाई न देना सामान्य है — यह केवल ChatGPT Pro ग्राहकों के लिए एक शोध पूर्वावलोकन मॉडल है।
• यदि कॉन्फ़िगरेशन में प्रयुक्त मॉडल काम नहीं कर रहा है, तो अपने ~/.codex/config.toml और codex exec --model की जांच करें कि वहां पुराने/असमर्थित नाम (जैसे gpt-5.2 या gpt-5.3-codex) तो नहीं लिखे हैं। इन्हें बदल लें।
• यह जांचने के लिए कि वर्तमान में कौन सा मॉडल उपयोग हो रहा है, सत्र में /status चलाएं।

मॉडलों के नाम और उपलब्धता संस्करण व सदस्यता के अनुसार बदल सकते हैं, TUI में /model चलाकर वास्तविक स्थिति देखें।

💡 संक्षेप में: मॉडलों की उपलब्धता आपके पैकेज पर निर्भर करती है, TUI में /model पैनल से पुष्टि करें।

---

06 अनुमतियों की सीमा, सैंडबॉक्स द्वारा फ़ाइल संपादन रोकना

यह फ़ाइलों में बदलाव करने से जुड़ी सबसे आम समस्या है।

लक्षण: Codex कोड पढ़ सकता है और विश्लेषण दे सकता है, लेकिन फ़ाइलों में बदलाव करने या कोई कमांड चलाने पर सैंडबॉक्स त्रुटि दिखाता है, या हर बार आपसे अनुमति मांगता है।

कारण: यह कोई बग नहीं है, बल्कि एक सुरक्षा फ़ीचर है। Codex आपके कंप्यूटर पर फ़ाइलों में सीधे बदलाव नहीं कर सकता — वह एक सैंडबॉक्स वातावरण में चलता है जहां लिखने के अधिकार सीमित होते हैं; जब वह वर्कस्पेस से बाहर जाता है या इंटरनेट का उपयोग करने का प्रयास करता है, तो वह आपसे पूछता है। यह सुरक्षा व्यवस्था डिफ़ॉल्ट रूप से चालू रहती है।

सादृश्य: किराए का घर। मकान मालिक (Codex की डिफ़ॉल्ट सेटिंग) आपको केवल रहने की अनुमति देता है, दीवारों को तोड़ने या फर्नीचर बदलने की नहीं; यदि आप कोई बदलाव करना चाहते हैं, तो आपको पहले मकान मालिक से अनुमति लेनी होगी। यह सुरक्षा के लिए किया जाता है ताकि आपके सिस्टम को कोई नुकसान न हो।

समाधान (दो तरीके हैं):

• अस्थायी रूप से अनुमति देने के लिए: कमांड-लाइन फ़्लैग का उपयोग करें। सैंडबॉक्स के लिए --sandbox (-s) और अनुमति नीति के लिए --ask-for-approval (-a) का उपयोग करें। यदि आप चाहते हैं कि वह प्रोजेक्ट के भीतर बदलाव कर सके और आवश्यकता होने पर ही आपसे पूछे, तो इस संयोजन का उपयोग करें:

  codex --sandbox workspace-write --ask-for-approval on-request

  विवरण के लिए 15 अनुमतियां, सैंडबॉक्स और स्वीकृति देखें।

• स्थायी रूप से अनुमति देने के लिए: ~/.codex/config.toml में अनुमति प्रोफ़ाइल (permission profiles, Beta) सेट करें। इसके तीन स्तर हैं:

प्रोफ़ाइल	अधिकार	उपयुक्त परिदृश्य
:read-only	केवल-पठन, कोई फ़ाइल नहीं बदल सकता	केवल विश्लेषण करने और कोड पढ़ने के लिए
:workspace	वर्कस्पेस और अस्थायी निर्देशिका में लिखने की अनुमति	सामान्य विकास कार्य, फ़ाइलें बदलने के लिए
:danger-full-access	सैंडबॉक्स की सभी सीमाएं हटा दी जाती हैं	केवल पृथक कंटेनर में उपयोग करें, अपनी मशीन पर न चलाएं

अपनी कॉन्फ़िगरेशन फ़ाइल में default_permissions को वांछित स्तर पर सेट करें। एक महत्वपूर्ण बात का ध्यान रखें: नई अनुमति प्रोफ़ाइल और पुराने sandbox_mode का एक साथ उपयोग नहीं किया जा सकता — यदि कॉन्फ़िगरेशन में sandbox_mode या --sandbox फ़्लैग का उपयोग किया गया है, तो पुरानी व्यवस्था लागू होगी और नई प्रोफ़ाइल काम नहीं करेगी। दोनों में से किसी एक को ही चुनें।

एक बार मैंने अस्थायी फ़ोल्डर में Codex से पुरानी फाइलें साफ़ करने को कहा और उसे पूर्ण अधिकार (danger-full-access) दे दिए, जिससे उसने मेरे होम फ़ोल्डर की फ़ाइलें भी प्रभावित करना शुरू कर दिया था। इसलिए इस स्तर का उपयोग केवल पृथक कंटेनरों (isolated containers) में ही करें, इसे अपनी मशीन पर डिफ़ॉल्ट न बनाएं।

💡 संक्षेप में: फ़ाइल संपादन ब्लॉक होना सुरक्षा कारणों से है; अस्थायी अनुमति के लिए -s/-a और स्थायी सेटिंग के लिए config.toml का उपयोग करें, और पुरानी व नई अनुमति सेटिंग्स को एक साथ न मिलाएं।

---

07 MCP कनेक्ट न होना

लक्षण: आपने MCP (Model Context Protocol) सर्वर कॉन्फ़िगर किया है, लेकिन Codex में उसके टूल्स दिखाई नहीं दे रहे हैं, या कनेक्शन विफल होने की त्रुटि आ रही है।

कारण: MCP सर्वर एक स्वतंत्र प्रोसेस के रूप में चलता है। कनेक्शन न होने के कई कारण हो सकते हैं: गलत कमांड, आवश्यक निर्भरता (dependencies) का न होना, आवश्यक API की या पर्यावरण चर की कमी, या फ़ायरवॉल द्वारा कनेक्शन ब्लॉक किया जाना।

समाधान:

• पहले MCP सर्वर को स्वतंत्र रूप से चलाएं: Codex के बिना उसे टर्मिनल में चलाकर देखें कि क्या वह बिना किसी त्रुटि के चल रहा है। अधिकांश मामलों में समस्या यहीं पता चल जाती है — जैसे पाथ की गलती या आवश्यक फ़ाइलों का न होना।
• config.toml में अपनी MCP कॉन्फ़िगरेशन की जांच करें: पाथ, कमांड और पर्यावरण चरों (environment variables) को ध्यान से देखें। एक छोटा सा टाइपो भी कनेक्शन विफल कर सकता है।
• यदि MCP सर्वर को इंटरनेट की आवश्यकता है, तो सुनिश्चित करें कि सैंडबॉक्स में इसकी अनुमति हो: डिफ़ॉल्ट रूप से सैंडबॉक्स में इंटरनेट एक्सेस बंद होता है।
• यदि फिर भी समस्या हल न हो, तो Codex के लॉग फ़ाइलों में देखें कि क्या त्रुटि दर्ज है।

मैंने जब पहली बार MCP कॉन्फ़िगर किया था, तो मैं एक पर्यावरण चर भूल गया था। Codex के बिना स्वतंत्र रूप से सर्वर चलाकर देखना समस्या का पता लगाने का सबसे तेज़ तरीका है।

💡 संक्षेप में: MCP की समस्या होने पर, पहले Codex के बिना स्वतंत्र रूप से सर्वर चलाकर देखें कि क्या वह सही काम कर रहा है।

---

08 संदर्भ सीमा (Context Window) समाप्त होना, खराब प्रतिक्रियाएं

लक्षण: सत्र लंबा होने पर Codex पुरानी बातें भूलने लगता है — जैसे वह पहले तय किए गए नियमों को भूल जाता है या गलत उत्तर देने लगता है।

कारण: प्रत्येक सत्र की एक संदर्भ सीमा (context window) होती है, जो उसकी "अल्पकालिक याददाश्त" की क्षमता है। जब बातचीत बहुत लंबी हो जाती है, तो पुराना संदर्भ हट जाता है, जिससे वह बातें भूलने लगता है।

सादृश्य: एक छोटा व्हाइटबोर्ड। जब बोर्ड भर जाता है, तो नई बातें लिखने के लिए पुरानी बातों को मिटाना पड़ता है। यह उसकी क्षमता की सीमा के कारण होता है।

समाधान (स्थिति के अनुसार निर्णय लें):

• यदि काम जारी रखना है लेकिन सत्र बहुत लंबा हो गया है: TUI में /compact चलाएं। यह बातचीत को संक्षेप में संपीड़ित (compress) कर देगा ताकि संदर्भ सीमा में जगह बन सके, जबकि महत्वपूर्ण नियम बने रहेंगे।
• यदि आप एक नया काम शुरू कर रहे हैं और पुराने संदर्भ की आवश्यकता नहीं है: TUI में /new चलाकर नया सत्र शुरू करें, या टर्मिनल को पूरी तरह साफ़ करने के लिए /clear का उपयोग करें। /new पुराना इतिहास स्क्रीन पर बनाए रखता है ताकि आप ऊपर देख सकें, जबकि /clear सब कुछ साफ़ कर देता है।
• सत्र के दौरान बची हुई क्षमता देखने के लिए /status का उपयोग करें: यह आपको सचेत करेगा ताकि आप समय पर /compact का उपयोग कर सकें।

स्थिति	अनुशंसित कमांड
वर्तमान काम जारी रखना है लेकिन संदर्भ बचाना है	/compact (बातचीत संपीड़ित करें)
नया काम शुरू करना है	/new (नया सत्र शुरू करें)
स्क्रीन और सत्र दोनों साफ़ करने हैं	/clear (सब कुछ साफ़ करें)
बची हुई सीमा देखनी है	/status (स्थिति देखें)

💡 संक्षेप में: संदर्भ सीमा समाप्त होने पर Codex असामान्य व्यवहार कर सकता है; काम जारी रखने के लिए /compact और नया काम शुरू करने के लिए /new का उपयोग करें।

---

09 लागत और कोटा समाप्त होना

लक्षण: सदस्यता पैकेज में कोटा समाप्त होने या लिमिट लागू होने का संदेश आता है; या API की का उपयोग करने पर बिल बहुत अधिक आता है।

कारण: दोनों योजनाओं की计费 (billing) अलग होती है — ChatGPT सदस्यता में एक निश्चित कोटा मिलता है जिसके समाप्त होने पर गति धीमी हो जाती है; API की में उपयोग के आधार पर भुगतान करना होता है, जहां बड़े मॉडल और अधिक सोचने की क्षमता (model_reasoning_effort) का उपयोग करने पर अधिक खर्च होता है।

समाधान:

• यदि सदस्यता का कोटा समाप्त हो गया है: आपको कोटा रीसेट होने की प्रतीक्षा करनी होगी या योजना बदलनी होगी। भविष्य में कोटा बचाने के लिए सरल कामों के लिए gpt-5.4-mini और कम सोचने की क्षमता का उपयोग करें, और प्रमुख मॉडल को केवल कठिन कार्यों के लिए रखें (जैसा कि 30 मॉडल चयन में बताया गया है)।
• यदि API का बिल अधिक आ रहा है: जांचें कि क्या आपने बहुत बड़े मॉडल या उच्चतम सोचने की क्षमता (model_reasoning_effort) को डिफ़ॉल्ट रूप से चालू रखा है। एक साधारण टाइपो सुधारने के लिए xhigh का उपयोग करना बहुत खर्चीला हो सकता है। कार्य की जटिलता के अनुसार सोचने की क्षमता बदलें (minimal/low/medium/high/xhigh)। आप स्थायी सेटिंग के लिए ~/.codex/config.toml में model_reasoning_effort = "medium" सेट कर सकते हैं या कमांड चलाते समय -c model_reasoning_effort=medium का उपयोग कर सकते हैं।
• सरल और बैच कार्यों के लिए हल्के मॉडल (mini) का उपयोग करें: इससे आपका खर्च काफी कम हो जाएगा और काम भी तेज़ी से होगा।

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

💡 संक्षेप में: कोटा या बजट बचाने के लिए सरल कार्यों के लिए छोटे मॉडल और संतुलित सोचने की क्षमता का उपयोग करें।

---

10 Windows विशिष्ट समस्याएं और "बदलाव कैसे वापस लें"

अंत में, प्लेटफ़ॉर्म और सामान्य बदलावों से जुड़े दो महत्वपूर्ण बिंदु।

Windows विशिष्ट समस्याएं

लक्षण: पाथ से जुड़ी त्रुटियां, सैंडबॉक्स का अलग व्यवहार, या कुछ फ़ीचर्स का काम न करना।

कारण: Windows पर Codex का सैंडबॉक्स मॉडल macOS और Linux से थोड़ा भिन्न होता है, जिससे पाथ और अधिकारों में अंतर आ सकता है।

समाधान: Windows पर सबसे अच्छा अनुभव प्राप्त करने के लिए आधिकारिक तौर पर WSL (Windows Subsystem for Linux) का उपयोग करने की सलाह दी जाती है। Windows से जुड़ी समस्याओं और समाधानों के लिए 33 Windows उपयोग के महत्वपूर्ण बिंदु देखें।

किए गए बदलावों को वापस कैसे लें (Undo)

लक्षण: Codex द्वारा किए गए बदलावों के कारण कोड खराब हो गया है और आप पुराने कोड पर वापस जाना चाहते हैं।

कारण: Codex आपकी वास्तविक फ़ाइलों में बदलाव करता है और स्वतः कोई बैकअप नहीं बनाता।

समाधान (विश्वसनीयता के अनुसार क्रमबद्ध):

• Git का उपयोग करें (सर्वोत्तम तरीका): हमेशा काम शुरू करने से पहले git commit करके कोड सुरक्षित रखें। यदि कोड खराब होता है, तो git diff से बदलाव देखें और git restore (या git checkout) करके उसे वापस पुरानी स्थिति में लाएं।
• यदि Git उपलब्ध नहीं है: तो कोई आसान तरीका नहीं है — इसलिए काम शुरू करने से पहले हमेशा बैकअप या कमिट बनाना आवश्यक है।
• अनुमतियां सख्त रखें: यदि आपको Codex पर पूरा विश्वास नहीं है, तो पहले :read-only प्रोफ़ाइल का उपयोग करके योजना देखें, और संतुष्ट होने पर ही उसे लिखने का अधिकार दें।

एक बार मैंने बिना Git कमिट किए Codex को बड़ा बदलाव करने दिया, जिससे कई फ़ाइलें प्रभावित हुईं और मुझे उन्हें एक-एक करके ठीक करना पड़ा। काम शुरू करने से पहले git commit करना सबसे सुरक्षित तरीका है।

💡 संक्षेप में: Windows समस्याओं के लिए [33 Windows] देखें; और किए गए बदलावों को आसानी से वापस लेने के लिए हमेशा काम से पहले git commit चलाएं।

---

निष्कर्ष

इस लेख में हमने Codex के उपयोग के दौरान आने वाली समस्याओं और उनके समाधानों को समझा:

• त्वरित जांच: हमेशा पहले codex --version, codex login status और /status से जांच करें।
• शुरुआती समस्याएं: command not found का कारण npm global bin का पाथ में न होना है; रिमोट सर्वर पर codex login --device-auth का उपयोग करें; और नेटवर्क समस्याओं के लिए प्रॉक्सी का उपयोग करें।
• फ़ाइल संपादन त्रुटि: यह डिफ़ॉल्ट सुरक्षा सैंडबॉक्स के कारण होता है। अस्थाई समाधान के लिए -s/-a और स्थाई समाधान के लिए config.toml का उपयोग करें।
• संदर्भ सीमा: बातचीत लंबी होने पर संदर्भ सीमित करने के लिए /compact और नया काम शुरू करने के लिए /new का उपयोग करें।
• लागत: बजट बचाने के लिए सरल कार्यों के लिए छोटे मॉडल और संतुलित सोचने की क्षमता का उपयोग करें; और बदलावों को वापस लेने के लिए Git का उपयोग करें।

अब आप सक्षम हैं: समस्याओं के आने पर शांत रहकर उन्हें व्यवस्थित तरीके से हल करने में। इन समाधानों को ध्यान में रखें ताकि आप आसानी से कोडिंग कर सकें।

---

अगला लेख 38 शब्दावली Codex श्रृंखला का समापन लेख होगा। यह पूरे अध्याय में प्रयुक्त सभी महत्वपूर्ण शब्दों (सैंडबॉक्स, अनुमति नीति, सोचने की क्षमता, MCP, उप-एजेंट, codex exec...) की एक संदर्भ मार्गदर्शिका है, जहां आप किसी भी समय शब्दों का अर्थ देख सकते हैं। जाने से पहले सोचें: काम शुरू करने से पहले सुरक्षा और बैकअप सुनिश्चित करने वाले कौन से महत्वपूर्ण कदम हैं?

---

अनुशंसित पठन

• सर्वश्रेष्ठ अभ्यास: वास्तव में काम आने वाले कुछ नियम
• Codex का परिचय और चार प्रकार के प्रवेश द्वार
• चार प्रकार के कार्यप्रवाह: शोध, बग फिक्स, रिफैक्टर और परीक्षण