Codex मुख्य अवधारणाओं का त्वरित अवलोकन

📚 सीरीज नेविगेशन: पिछला लेख 01 · Codex का परिचय और चार प्रकार के प्रवेश द्वार आपको Codex के चार रूपों—डेस्कटॉप ऐप, कमांड लाइन, IDE एक्सटेंशन और क्लाउड से परिचित कराता है। यह लेख उससे एक कदम आगे जाता है और उन मुख्य अवधारणाओं को स्पष्ट करता है जिनका उपयोग आने वाले अध्यायों में बार-बार किया जाएगा। अगला लेख 03 · इंस्टॉलेशन और लॉगिन औपचारिक रूप से इसके इंस्टॉलेशन के बारे में है।

पहले मैं अपने द्वारा की गई एक बेवकूफी भरी बात बताता हूँ। जब मैंने Codex का उपयोग करना शुरू किया था, तो मैंने उससे कहा "मुझे इन तीन फाइलों का नाम एक साथ बदलने में मदद करें"। उसने फ़ाइलों का नाम बदल दिया, लेकिन जब मैंने देखा तो मैं दंग रह गया—उसने केवल प्रोजेक्ट डायरेक्टरी की फाइलों को बदला था, डेस्कटॉप पर मौजूद दो फाइलों को बिल्कुल नहीं छुआ। मैं उस समय सोच रहा था: जब कहा गया था कि वह कमांड चला सकता है, तो उसने ऐसा क्यों किया? बाद में दस्तावेज़ पढ़ने पर मुझे समझ आया: यह सैंडबॉक्स (Sandbox) के कारण था, जो उसे रोक रहा था। वह डिफ़ॉल्ट रूप से केवल आपके द्वारा निर्दिष्ट वर्कस्पेस में ही काम कर सकता है, और इस सीमा से बाहर जाने से पहले वह आपसे पूछता है।

उस समय मुझे समझ आया: यदि आप Codex का उपयोग करने से पहले इन अवधारणाओं को नहीं समझते हैं, तो आपको लगेगा कि यह कभी काम करता है और कभी नहीं—वास्तव में वह पूरी तरह से नियमों का पालन कर रहा था, बस आपको यह नहीं पता था कि उसके काम करने की कुछ सीमाएं हैं।

इस लेख में हम इन सीमाओं और इसके कुछ विशेष कॉन्फ़िगरेशन्स को विस्तार से समझेंगे।

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

• एक वाक्य में स्पष्टीकरण कि Codex का "एजेंट (Agent)" क्या है, और यह सामान्य चैटबॉट से कैसे अलग है
• सैंडबॉक्स और अनुमोदन के संबंध को गहराई से समझना—यह जानना कि मेरी पिछली नाम बदलने की कोशिश क्यों विफल रही और इसे कैसे अनुमति दें
• AGENTS.md का परिचय: एक प्रोजेक्ट गाइड जो आपके प्रोजेक्ट के नियमों को Codex के लिए सहेज कर रखती है
• यह जानना कि मेमोरी (Memory) और Chronicle क्या हैं, क्या ये डिफ़ॉल्ट रूप से सक्रिय हैं और क्या इनका उपयोग किया जा सकता है
• एक व्यावहारिक अभ्यास, जिससे आप सैंडबॉक्स द्वारा कार्य को रोके जाने की प्रक्रिया को लाइव देख सकें

⚠️ नीचे दी गई सभी विशिष्ट कमांड्स, कॉन्फ़िगरेशन विकल्प और डिफ़ॉल्ट व्यवहार Codex के आधिकारिक दस्तावेज़ों पर आधारित हैं; मॉडल के नाम, पैकेज और अन्य विवरण जो अपडेट हो सकते हैं, उन्हें अपने स्थानीय सिस्टम के अनुसार समझें।

---

01 एजेंट (Agent): यह खुद काम करता, केवल जवाब नहीं देता

पहले निष्कर्ष देखते हैं, एक वाक्य में: Codex OpenAI का एक "कोडिंग एजेंट (coding agent)" है, जो केवल टेक्स्ट के साथ जवाब देने के बजाय खुद कोड पढ़ सकता है, फ़ाइलों को बदल सकता है और कमांड चला सकता है। आधिकारिक शब्द हैं "OpenAI's coding agent that can read, edit, and run code"。

यहाँ "एजेंट (Agent)" एक महत्वपूर्ण शब्द है जिसे समझना आवश्यक है: एजेंट = एक ऐसा AI जो खुद कार्य को विभाजित कर सकता है, टूल्स का उपयोग कर सकता है, परिणाम देख सकता है और अगले कदम का निर्णय ले सकता है, न कि केवल सवाल-जवाब करने वाला चैट बॉक्स।

आधिकारिक रूप से Codex के काम करने के तरीके को इस प्रकार वर्णित किया गया है: "एजेंट एक लूप में टर्मिनल कमांड चलाता है। यह कोड एडिट करता है, जांच चलाता है, और अपने काम को सत्यापित करने का प्रयास करता है" (मूल: The agent runs terminal commands in a loop. It edits code, runs checks, and tries to validate its work)。

सरल शब्दों में, यह वही तीन क्रियाएं हैं—सोचो → करो → देखो:

• सोचो: संबंधित फ़ाइलें पढ़ना, एरर देखना, स्थिति को समझना
• करो: कोड बदलना, फ़ाइलें बनाना, कमांड चलाना
• देखो: टेस्ट चलाना, आउटपुट देखना, यदि सही न हो तो फिर से प्रयास करना

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

कुछ वास्तविक उदाहरण:

• जब आप पूछते हैं "यह टेस्ट क्यों फेल हो गया", तो वह खुद टेस्ट चलाता है → एरर पढ़ता है → बग खोजता है → कोड बदलता है → पुष्टि के लिए फिर से टेस्ट चलाता है, और आप बस स्क्रीन पर देखते रहते हैं।
• जब आप बिना दस्तावेज़ों वाले किसी पुराने प्रोजेक्ट के लिए कहते हैं "इसका स्ट्रक्चर समझाएं", तो वह खुद डायरेक्टरी देखता है कि कौन सी फाइलें हैं, कीवर्ड खोजता है, फाइलें पढ़ता है, और आपको स्ट्रक्चर का नक्शा बनाकर देता है—आपने उसे एक भी फ़ाइल निर्दिष्ट नहीं की थी。
• जब आप कहते हैं "इस फ़ंक्शन में कैश जोड़ें", तो वह कोड बदलने के साथ-साथ अन्य फ़ाइलों में इसके कॉल को भी ठीक कर देता है, क्योंकि वह पूरे प्रोजेक्ट को एक साथ देख सकता है।

💡 संक्षेप में: Codex एक "एजेंट" है, "चैट बॉक्स" नहीं—वह "सोचो→करो→देखो" के लूप में खुद काम पूरा करता है। यह तंत्र बिल्कुल Claude Code जैसा ही है, बस ब्रांड नाम अलग है।

---

02 सैंडबॉक्स (Sandbox): काम करने की सीमा कहाँ है

अब मुख्य बिंदु पर आते हैं। शुरुआत में मेरी फ़ाइल नाम बदलने की विफलता के पीछे यही जिम्मेदार था।

सैंडबॉक्स (Sandbox): आधिकारिक परिभाषा है "एक ऐसी सीमा (boundary) जो Codex को स्वतंत्र रूप से काम करने की अनुमति देती है, लेकिन उसे आपके पूरे कंप्यूटर पर असीमित अधिकार नहीं देती"। सरल शब्दों में, यह Codex के चारों ओर खींची गई एक लक्ष्मण रेखा है—रेखा के अंदर वह खुद काम कर सकता है, और बाहर जाने के लिए उसे आपसे अनुमति लेनी होगी。

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

यह सीमा दो चीजों को नियंत्रित करती है: वह कौन सी फ़ाइलें बदल सकता है, और क्या वह इंटरनेट से जुड़ सकता है。 आधिकारिक तौर पर सैंडबॉक्स के तीन मुख्य मोड्स हैं:

सैंडबॉक्स मोड	क्या फाइलें बदल सकता है	क्या इंटरनेट से जुड़ सकता है	कब उपयोग करें
read-only (सिर्फ पढ़ सकता है)	❌ नहीं (बदलाव के लिए अनुमति आवश्यक)	❌ नहीं	जब आप केवल कोड का विश्लेषण करवाना चाहते हैं, और नहीं चाहते कि वह आपकी फाइलों में कोई बदलाव करे
workspace-write (वर्कस्पेस संपादन)	✅ केवल निर्दिष्ट वर्कस्पेस में	❌ डिफ़ॉल्ट रूप से नहीं	दैनिक विकास के लिए सबसे उपयोगी; वर्जन कंट्रोल वाले प्रोजेक्ट्स में Codex इसे रिकमेंड करता है, और बिना वर्जन कंट्रोल वालों के लिए read-only
danger-full-access (पूर्ण पहुंच)	✅ पूरे कंप्यूटर पर	✅ हाँ	पूरी तरह से विश्वसनीय वातावरण में; इसके नाम में danger शब्द सुरक्षा कारणों से है, सावधानी से उपयोग करें

workspace-write में "केवल निर्दिष्ट वर्कस्पेस में" लिखा है—यही कारण था कि मेरे डेस्कटॉप की फ़ाइलें नहीं बदलीं。 वे उस प्रोजेक्ट डायरेक्टरी से बाहर थीं जहाँ से मैंने Codex शुरू किया था, यानी वे बाड़े के बाहर थीं। Codex ने काम से जी नहीं चुराया था, बल्कि वह सीमा से बाहर था।

एक और बात जो आधिकारिक दस्तावेज़ों में बताई गई है: सैंडबॉक्स केवल Codex के सीधे काम को नहीं, बल्कि उसके द्वारा चलाई जाने वाली अन्य कमांड्स को भी नियंत्रित करता है。 इसका मतलब है कि यदि वह git या किसी पैकेज मैनेजर को चलाता है, तो वे कमांड्स भी उसी सीमा के भीतर रहेंगी—ऐसा नहीं होगा कि मुख्य प्रोग्राम तो बंद है लेकिन उसकी सब-कमांड कंप्यूटर में कहीं भी बदलाव कर दे।

विभिन्न ऑपरेटिंग सिस्टम पर यह अलग तरह से काम करता है (विवरण के लिए लेख 03 देखें):

• macOS: सिस्टम के इनबिल्ट Seatbelt फ्रेमवर्क का उपयोग करता है, जो बिना किसी कॉन्फ़िगरेशन के सीधे काम करता है。
• Windows: विंडोज के नेटिव एनवायरनमेंट में चलता है और विंडोज नेटिव सैंडबॉक्स का उपयोग करता है (जिसमें elevated और unelevated मोड्स होते हैं); यदि WSL2 का उपयोग कर रहे हैं तो यह लिनक्स की तरह काम करता है।
• Linux / WSL2: इसके लिए कंप्यूटर में bubblewrap टूल इंस्टॉल होना आवश्यक है, ताकि सैंडबॉक्स सही से काम कर सके (यह एक अनिवार्य आवश्यकता है)。

💡 संक्षेप में: सैंडबॉक्स Codex के काम करने की पहली सीमा है—डिफ़ॉल्ट रूप से (workspace-write) यह उसे केवल वर्कस्पेस में बदलाव करने और इंटरनेट से न जुड़ने की अनुमति देता है; यदि आप अधिक पहुंच देना चाहते हैं, तो सीमा को बदलना होगा।

---

03 अनुमोदन (Approval): सीमा पर कौन निर्णय लेगा

सैंडबॉक्स ने सीमा तय कर दी, लेकिन "सीमा पार करने पर किससे अनुमति मांगनी है"—यह एक अलग प्रक्रिया है जिसे अनुमोदन (Approval) कहते हैं।

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

सादृश्य: एक्सेस कार्ड और गार्ड。 सैंडबॉक्स वह दरवाजा है जो भौतिक रूप से बंद है, और अनुमोदन द्वार पर खड़े गार्ड के स्वभाव जैसा है—कुछ गार्ड सबको जाने देते हैं (never), कुछ केवल अपरिचितों को रोकते (untrusted), और कुछ हर बार जाने से पहले आपसे पूछते हैं (on-request)。 दरवाजा फिक्स्ड है, लेकिन गार्ड की सख्ती को आप बदल सकते हैं।

आधिकारिक तौर पर तीन मुख्य अनुमोदन पॉलिसीज़ हैं:

अनुमोदन पॉलिसी	Codex का व्यवहार	सरल शब्दों में
untrusted	जो कमांड्स "विश्वसनीय सूची" में नहीं हैं, उन्हें चलाने से पहले पूछेगा	केवल अपरिचित कमांड्स को रोकना
on-request	सैंडबॉक्स के भीतर काम करेगा, और सीमा पार करने पर रुककर पूछेगा	दैनिक उपयोग के लिए सबसे संतुलित विकल्प
never	बिना किसी अनुमति के काम करता रहेगा	ऑटोमेशन के लिए उपयोगी; कमांड सीमा सैंडबॉक्स द्वारा तय होगी, इसका उपयोग पूर्ण पहुंच के साथ ही सही रहता है

ध्यान दें: ये नीतियां (untrusted / on-request / never) और सैंडबॉक्स मोड्स दो अलग-अलग कॉन्फ़िगरेशन हैं जिन्हें अलग-अलग सेट किया जाता है।

इन दोनों को कैसे जोड़ा जाए? आधिकारिक तौर पर दो मुख्य संयोजन सुझाए गए हैं:

• सुरक्षित दैनिक उपयोग (अनुशंसित): sandbox_mode = "workspace-write" के साथ approval_policy = "on-request"。 सीमा बंद रहेगी, और बाहर जाने पर पूछा जाएगा—सुरक्षित और आसान।
• पूरी छूट (सावधानी से उपयोग करें): sandbox_mode = "danger-full-access" के साथ approval_policy = "never"。 दरवाजा भी खुला है और गार्ड भी नहीं है—केवल 100% विश्वसनीय वातावरण में ही उपयोग करें。

मेरी आदत यह है: नए प्रोजेक्ट या अपरिचित कोडबेस के लिए, मैं हमेशा read-only (सिर्फ पढ़ने का मोड) रखता हूँ ताकि वह केवल विश्लेषण करे। जब मैं उसकी योजना देख लेता हूँ और सुरक्षित महसूस करता हूँ, तब मैं उसे संपादन की अनुमति देता हूँ। एक बार मैंने जल्दबाजी में पूर्ण पहुंच देकर एक बैच स्क्रिप्ट चलाई थी, और जब वह मेरी होम डायरेक्टरी में फाइलें खोजने लगा तो मुझे बहुत डर लगा—उसके बाद से मैं सावधानी से ही इसका उपयोग करता हूँ।

इन्हें बदलना आसान है। दैनिक उपयोग में कॉन्फ़िगरेशन फ़ाइल बदलने की आवश्यकता नहीं होती, आप बातचीत के दौरान /permissions लिखकर मोड बदल सकते हैं (डेस्कटॉप ऐप या IDE में इनपुट बॉक्स के बगल में एक बटन होता है)। यदि आप चाहते हैं कि हर बार शुरू होने पर एक ही मोड रहे, तो कॉन्फ़िगरेशन फ़ाइल में लिखना होगा, जिसे हम लेख 18 config.toml कॉन्फ़िगरेशन में समझेंगे।

नीचे दिया गया आरेख सैंडबॉक्स और अनुमोदन के संबंध को स्पष्ट करता है:

यह आरेख दिखाता है: Codex जब भी कोई कदम उठाता है, तो पहले यह देखा जाता है कि "क्या वह सैंडबॉक्स सीमा के अंदर है" (सैंडबॉक्स द्वारा तय), और यदि वह बाहर जाने की कोशिश करता है, तो देखा जाता है कि "क्या आपसे अनुमति मांगनी है" (अनुमोदन पॉलिसी द्वारा तय)。 दो परतें हैं जो काम करती हैं।

💡 संक्षेप में: सैंडबॉक्स तय करता है कि "क्या किया जा सकता है" और अनुमोदन तय करता है कि "क्या पूछना है", दोनों सेटिंग्स अलग-अलग काम करती हैं; सामान्य उपयोग के लिए workspace-write + on-request का संयोजन सबसे सुरक्षित है।

---

04 AGENTS.md: Codex के लिए प्रोजेक्ट गाइड

पहले तीन भागों में हमने "अनुमतियों" के बारे में बात की। इस भाग में हम एक अलग विषय पर चर्चा करेंगे: Codex को आपके प्रोजेक्ट के नियमों को कैसे याद दिलाया जाए, ताकि आपको हर बार वही बातें न बतानी पड़ें।

इसका उत्तर है AGENTS.md फ़ाइल।

सादृश्य: नए कर्मचारी के लिए ऑनबोर्डिंग बुक。 जब कोई नया व्यक्ति काम पर आता है, तो आप हर दिन उसके पीछे लगकर यह नहीं कहते कि "हम pnpm का उपयोग करते हैं, npm का नहीं" या "कमिट मैसेज हिंदी में लिखें"—आप उसे एक बुक दे देते हैं जिसे वह खुद पढ़ता है। AGENTS.md Codex के लिए वही गाइड है: इसे प्रोजेक्ट में रखें, वह काम शुरू करने से पहले इसे पढ़ेगा और नियमों का पालन करेगा।

आधिकारिक तौर पर इसे "durable project guidance" कहा जाता है—जो रिपॉजिटरी के साथ रहता है और काम शुरू होने से पहले लागू हो जाता है। एक सलाह: इसे छोटा और स्पष्ट रखें (Keep it small), बहुत लंबा दस्तावेज़ न बनाएं।

इसमें आमतौर पर ये चीजें लिखी जाती हैं (आधिकारिक उदाहरण):

• बिल्ड और टेस्ट कमांड (जैसे "टेस्ट के लिए pytest -q का उपयोग करें")
• कोड रिव्यू के नियम (जैसे "बदलाव के बाद लिंटर चलाना आवश्यक है")
• प्रोजेक्ट के विशेष नियम (जैसे फ़ाइलों का स्ट्रक्चर, नामकरण के तरीके)

इसे दो स्तरों पर रखा जा सकता, और प्रोजेक्ट डायरेक्टरी वाला नियम अधिक प्राथमिकता लेता है:

स्तर	कहाँ रखें	कार्यक्षेत्र
ग्लोबल	~/.codex/AGENTS.md	आपकी व्यक्तिगत प्राथमिकताएं (जैसे "संक्षिप्त जवाब दें"), जो सभी प्रोजेक्ट्स पर लागू होती हैं
प्रोजेक्ट	प्रोजेक्ट की रूट डायरेक्टरी या सब-डायरेक्टरी में AGENTS.md	इस प्रोजेक्ट / टीम के नियम, जिसे git में डालकर टीम के साथ साझा किया जा सकता है

इसका सबसे अच्छा उपयोग यह है—इसे एक फीडबैक लूप (feedback loop) की तरह उपयोग करना: जब Codex आपके प्रोजेक्ट के बारे में कोई गलत धारणा बनाता है, तो केवल बातचीत में सुधार करने के बजाय (क्योंकि वह अस्थायी होता है), उससे कहें कि वह उस सुधार को AGENTS.md में लिख दे。 इस तरह अगली बार नया सत्र शुरू होने पर उसे वह नियम याद रहेगा। मैंने एक Python प्रोजेक्ट पर काम करते समय इसे आजमाया, और समय के साथ वह फ़ाइल बीस लाइनों की हो गई जिसमें Codex के सुधार दर्ज थे—अब वह दोबारा वैसी गलतियाँ नहीं करता।

Codex में AGENTS.md का वही स्थान है जो Claude Code में CLAUDE.md का है—अवधारणा वही है, बस फ़ाइल का नाम अलग है।

💡 संक्षेप में: AGENTS.md Codex के लिए प्रोजेक्ट गाइड है—इसमें अपने प्रोजेक्ट के नियम लिखें और वह काम शुरू करने से पहले इसे पढ़ेगा; इसे सुधारों को दर्ज करने के लिए उपयोग करें ताकि वह गलतियाँ न दोहराए।

---

05 मेमोरी (Memory) और Chronicle: क्या वह आपको याद रख सकता है

अंतिम अवधारणाएँ इस बारे में हैं कि क्या Codex पिछली बातचीत की बातों को याद रख सकता है?

इन दोनों को अलग-अलग समझना आवश्यक है:

मेमोरी (Memory): यह Codex को पिछले सत्रों में सीखी गई उपयोगी जानकारियों को आगे के काम में ले जाने की अनुमति देती है—जैसे आपका टेक स्टैक, आदतें, एरर्स ताकि हर नए सत्र में इसे दोबारा न बताना पड़े।

सादृश्य: एक पुराना साथी。 एक नए सहायक को आपको बार-बार बताना पड़ता है कि "हम TypeScript का उपयोग करते हैं, सेमीकोलन नहीं लिखते"; जबकि तीन साल पुराने साथी को सब पता होता है क्योंकि वह आपकी आदतों को जानता है。 Memory का काम Codex को उसी पुराने साथी की तरह बनाना है।

लेकिन आपको इसके बारे में कुछ महत्वपूर्ण तथ्य जानने चाहिए, अन्यथा आपको लगेगा कि यह ठीक से काम नहीं कर रहा है:

• यह डिफ़ॉल्ट रूप से बंद रहती है (off by default)。 जब तक आप इसे चालू नहीं करेंगे, यह कुछ भी याद नहीं रखेगा। चालू करने के लिए: Codex ऐप की सेटिंग्स में जाएं, या ~/.codex/config.toml फ़ाइल में [features] के तहत memories = true लिखें।
• क्षेत्रीय सीमाएँ हैं。 आधिकारिक दस्तावेज़ों के अनुसार, शुरुआती दौर में यह यूरोपीय आर्थिक क्षेत्र, यूके और स्विट्जरलैंड में उपलब्ध नहीं है。
• यह तुरंत अपडेट नहीं होती解释。 यह सत्र के समाप्त होने और सिस्टम के खाली होने का इंतजार करती है, जिसके बाद पृष्ठभूमि में बातचीत का सारांश बनाकर मेमोरी में सहेजती है—तो तुरंत नया सत्र शुरू करने पर पुरानी बातें तुरंत याद नहीं आ सकतीं।
• यह स्थानीय स्तर पर सहेजी जाती है: डिफ़ॉल्ट रूप से ~/.codex/memories/ डायरेक्टरी में जनरेट की गई मार्काडाउन फाइलों के रूप में रहती है।
• इसे सत्र के अनुसार नियंत्रित किया जा सकता है: ऐप या CLI में /memories कमांड लिखकर तय करें कि वर्तमान सत्र में पुरानी मेमोरी का उपयोग करना है या नहीं, या इस सत्र से नई मेमोरी बनानी है या नहीं।

दस्तावेज़ों में यह भी कहा गया है: टीम के महत्वपूर्ण नियमों के लिए हमेशा AGENTS.md का उपयोग करें, मेमोरी पर निर्भर न रहें—मेमोरी केवल एक सहायक परत है, प्राथमिक नियम नहीं। मेमोरी का काम कभी-कभी सटीक नहीं भी हो सकता है, इसलिए महत्वपूर्ण नियमों को इसके भरोसे छोड़ना सही नहीं है।

💡 संक्षेप में: मेमोरी Codex को आपकी आदतों को याद रखने में मदद करती है, लेकिन यह डिफ़ॉल्ट रूप से बंद रहती है और इसके नियम AGENTS.md का विकल्प नहीं हैं; Chronicle एक प्रायोगिक स्क्रीन देखने की सुविधा है जो उपयोगी है लेकिन सुरक्षा जोखिमों के साथ आती है।

अब बात करते हैं Chronicle की:

⚠️ यह अभी प्रायोगिक चरण में है और बदल सकता है। Chronicle अभी एक "रिसर्च प्रीव्यू (opt-in research preview)", जो केवल ChatGPT Pro उपयोगकर्ताओं और केवल macOS पर उपलब्ध है (यूरोप, यूके और स्विट्जरलैंड में अभी उपलब्ध नहीं है)。

Chronicle का काम मेमोरी को "स्क्रीन की जानकारी" देना है। सामान्य मेमोरी केवल बातचीत से सीखती है; जबकि Chronicle आपकी स्क्रीन पर चल रही चीजों को देखकर यह समझता है कि आप हाल ही में क्या कर रहे हैं—आप कौन सी फ़ाइल देख रहे हैं, कौन सा PR खुला है, कौन से दस्तावेज़ पढ़ रहे हैं, ताकि आपको उसे दोबारा न समझाना पड़े।

सादृश्य: एक ऐसा साथी जो आपकी स्क्रीन देख सकता है。 सामान्य साथी केवल आपकी बात सुन सकता है; जबकि Chronicle आपकी स्क्रीन पर नज़र रखकर समझ जाता है कि "अच्छा, आप इस एरर को देख रहे हैं", और आपको उसे复述 नहीं करना पड़ता। यह बहुत उपयोगी लग सकता है, लेकिन इसके साथ कुछ जोखिम भी हैं जिनका उल्लेख आधिकारिक दस्तावेज़ों में किया गया है: यह एपीआई कोटा तेज़ी से समाप्त करता है, प्रॉम्प्ट इंजेक्शन (prompt injection) का जोखिम बढ़ाता है, और स्क्रीन की जानकारी स्थानीय सिस्टम में बिना एन्क्रिप्शन के स्टोर होती है。 इसका मतलब है कि इसके लाभ और जोखिम दोनों हैं। मेरा सुझाव: परीक्षण के लिए उपयोग कर सकते हैं, लेकिन संवेदनशील जानकारी (पासवर्ड, व्यक्तिगत चैट, क्लाइंट डेटा) स्क्रीन पर होने पर मेनू बार से "Pause Chronicle" दबाकर इसे रोक दें।

विशेषता	मेमोरी (Memory)	Chronicle
जानकारी का स्रोत	पिछली बातचीत से	आपकी स्क्रीन की सामग्री से
स्थिति	मुख्य सुविधा (डिफ़ॉल्ट रूप से बंद)	प्रायोगिक (रिसर्च प्रीव्यू)
प्लेटफॉर्म	ऐप और CLI दोनों में	केवल macOS, केवल Pro उपयोगकर्ता
सुझाव	कोडिंग को आसान बनाने के लिए चालू कर सकते हैं	परीक्षण के लिए ठीक है, संवेदनशील जानकारी के समय रोक दें

💡 संक्षेप में: मेमोरी Codex को आपकी आदतों को याद रखने में मदद करती है, लेकिन यह डिफ़ॉल्ट रूप से बंद रहती है और इसके नियम AGENTS.md का विकल्प नहीं हैं; Chronicle एक प्रायोगिक स्क्रीन देखने की सुविधा है जो उपयोगी है लेकिन सुरक्षा जोखिमों के साथ आती है।

---

ये अवधारणाएँ स्पष्ट होने के बाद, हम अभ्यास पर जाने से पहले यह समझ लें कि ये आपस में कैसे काम करती हैं:

यह आरेख दिखाता है: मुख्य एजेंट बीच में है जो "सैंडबॉक्स" की सीमा के भीतर काम करता है; यदि वह बाहर (कंप्यूटर या इंटरनेट पर) जाने की कोशिश करता है, तो उसे "अनुमोदन" की प्रक्रिया से गुजरना होगा; बाईं ओर AGENTS.md काम शुरू होने से पहले नियम प्रदान करता है; और नीचे "मेमोरी / Chronicle" पिछले अनुभवों को सहेजकर आगे उपयोग करने में मदद करता है—सभी अवधारणाएँ उस मुख्य एजेंट की सुरक्षा और दक्षता के लिए काम करती हैं。

---

06 व्यावहारिक अभ्यास: सैंडबॉक्स की सुरक्षा जांच को लाइव देखना

केवल पढ़ना पर्याप्त नहीं है। हम एक मिनट का एक छोटा अभ्यास करेंगे, और देखेंगे कि read-only (सिर्फ पढ़ने का मोड) में सैंडबॉक्स किसी बदलाव को कैसे रोकता है。 इसके लिए किसी प्रोजेक्ट की आवश्यकता नहीं है, बस एक खाली फोल्डर होना चाहिए।

पहला कदम: खाली डायरेक्टरी बनाना, Codex शुरू करना。

टर्मिनल में रन करें (विंडोज़ में PowerShell का उपयोग करें):

mkdir -p ~/codex-demo && cd ~/codex-demo
codex

यदि Codex इंस्टॉल नहीं है, तो पहले लेख 03 में इंस्टॉलेशन समझें और फिर इसे आज़माएं।

दूसरा कदम: सिर्फ पढ़ने का मोड (Read Only) सेट करना。

Codex सत्र में यह कमांड टाइप करें:

/permissions

और वहां सिर्फ पढ़ने का विकल्प (Read Only या read-only) चुनें। आप देखेंगे कि सिस्टम मोड बदलने की पुष्टि करेगा, जैसे—

Permissions updated: read-only

⚠️ नए वर्शन्स में बदलाव हो सकता है: codex-cli 0.142 के बाद, आधिकारिक तौर पर permission profiles (बीटा) का उपयोग किया जा रहा है—हो सकता है कि आपका मेनू बदल गया हो और वहां Ask for approval / Approval for me / Full access जैसी नीतियां दिखाई दे रही हों।

यदि Read Only विकल्प नहीं दिख रहा है, तो आप सत्र से बाहर आकर codex --sandbox read-only लिखकर फिर से प्रवेश कर सकते हैं; या ~/.codex/config.toml फ़ाइल में sandbox_mode = "read-only" लिख सकते हैं। यह तरीका हमेशा काम करेगा।

तीसरा चरण: फ़ाइल बनाने के लिए कहना और जांच देखना。

Codex से कहें:

帮我新建一个文件 hello.txt，里面写一行字 "hello codex"。

आप देखेंगे: वह चुपचाप फ़ाइल नहीं बनाएगा, बल्कि रुक जाएगा और आपसे अनुमति मांगेगा—क्योंकि फ़ाइल बनाना सिर्फ पढ़ने की अनुमति से बाहर है, और सुरक्षा नियमों के अनुसार उसे आपसे पूछना होगा। स्क्रीन पर संदेश कुछ ऐसा होगा:

我需要创建文件 hello.txt，这超出了当前只读模式的权限，
是否允许？(y/n)

यह रुकने की प्रक्रिया सैंडबॉक्स और अनुमोदन की संयुक्त सुरक्षा प्रणाली को दर्शाती है: सैंडबॉक्स ने तय किया कि काम सीमा से बाहर है, और अनुमोदन पॉलिसी ने अनुमति के लिए संदेश दिखाया। यह वही प्रक्रिया है जो हमने ऊपर समझी थी।

चौथा चरण: मोड बदलकर देखना。

/permissions में जाकर इसे वर्कस्पेस संपादन (workspace-write) पर सेट करें, और फिर से फ़ाइल बनाने के लिए कहें। इस बार वह बिना पूछे फ़ाइल बना देगा—क्योंकि प्रोजेक्ट डायरेक्टरी में फ़ाइल बनाना सैंडबॉक्स की सीमा के भीतर है।

已创建 hello.txt

काम पूरा होने पर /status लिखकर स्थिति देख सकते हैं:

/status

यह अंतर सैंडबॉक्स के महत्व को दर्शाता है—सिर्फ पढ़ने के मोड में काम का रुकना और वर्कस्पेस संपादन में बिना पूछे पूरा होना。 इसे खुद करके देखने से यह अवधारणा हमेशा के लिए स्पष्ट हो जाती है।

💡 संक्षेप में: इस अभ्यास से आप समझ सकते हैं कि—एक ही काम के लिए read-only में अनुमति मांगी जाती है और workspace-write में वह सीधे काम पूरा कर देता है。

---

07 सारांश

इस लेख में हमने Codex की मुख्य अवधारणाओं को समझा:

अवधारणा	एक वाक्य में भूमिका	Claude Code में समकक्ष
एजेंट (Agent)	एक ऐसा AI जो केवल जवाब देने के बजाय खुद काम पूरा करता है	एजेंटिक लूप (समान)
सैंडबॉक्स (Sandbox)	काम करने की सीमा तय करना, फ़ाइल और इंटरनेट पहुंच को नियंत्रित करना	सुरक्षा सीमा (समान अवधारणा)
अनुमोदन (Approval)	सीमा से बाहर जाने पर अनुमति मांगना	अनुमति मोड (समान अवधारणा)
AGENTS.md	प्रोजेक्ट के नियमों की गाइड जिसे वह काम से पहले पढ़ता है	CLAUDE.md (केवल नाम का अंतर)
मेमोरी / Chronicle	आपकी आदतों को याद रखना; Chronicle स्क्रीन की जानकारी लेता है (प्रायोगिक)	मेमोरी (समान अवधारणा)

अब आप समझ सकते हैं कि Codex क्यों किसी फ़ाइल को बदलने से मना कर सकता है (सैंडबॉक्स सीमा के बाहर होने पर), या अनुमति के लिए क्यों रुकता है (अनुमोदन नियम लागू होने पर), और नियमों के लिए AGENTS.md का उपयोग कैसे करना है।

मुख्य बात: Codex केवल एक टूल नहीं है, बल्कि एक सुरक्षित सीमा में काम करने वाला सहायक है—आपका काम उसे निर्देश देना, उसकी सीमाएं तय करना और आवश्यकता होने पर मार्गदर्शन करना है। इन अवधारणाओं को समझने के बाद आगे के अध्यायों को समझना आसान हो जाएगा।

---

अगला लेख 03 · इंस्टॉलेशन और लॉगिन: अब जब हम अवधारणाएं समझ चुके हैं, तो हम Codex को अपने कंप्यूटर पर इंस्टॉल करेंगे। हम Mac, Windows और Linux पर इसके इंस्टॉलेशन और लॉगिन की प्रक्रिया को चरण-दर-चरण समझेंगे, और Linux में आवश्यक bubblewrap टूल के उपयोग को भी देखेंगे।

---

अनुशंसित पठन

• Codex का परिचय और चार प्रवेश द्वार
• घरेलू मॉडल्स जैसे DeepSeek को जोड़ना
• सर्वोत्तम प्रथाएं: वास्तविक काम में उपयोगी सुझाव