अनुमतियाँ, सैंडबॉक्स और अनुमोदन: कितना ढीला छोड़ें, कितना कसें, खुद तय करें

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

मुझे पिछले सर्दियों की अपनी एक बेवकूफी याद है। उस समय मैंने Codex को अभी-अभी कॉन्फ़िगर करना सीखा था, और आसानी के लिए मैंने ~/.codex/config.toml में sandbox_mode को हमेशा के लिए danger-full-access पर सेट कर दिया था, यह सोचकर कि "बार-बार पॉप-अप देखना परेशान करता है"। परिणाम यह हुआ कि एक दिन जब मैं एक अस्थायी निर्देशिका (Temporary Directory) में था जहाँ Git इनिशियलाइज़ नहीं था, मैंने इसे "बेकार फाइलों को साफ़ करने" के लिए कहा। यह वास्तव में मेरी पूरी होम डायरेक्टरी में फाइलों को ढूँढने लगा—क्योंकि फुल एक्सेस मोड में इसके लिए "वर्कस्पेस" जैसी कोई सीमा नहीं थी। मैंने घबराकर इसे रोकने के लिए Esc दबाया, और उस समय मैं सच में डर गया था।

बाद में समीक्षा करने पर, समस्या Codex की नहीं थी, बल्कि मेरी थी: मैंने एक खतरनाक कॉन्फ़िगरेशन, जिसे एक अलग कंटेनर (Isolated Container) में इस्तेमाल किया जाना चाहिए था, उसे ग्लोबल डिफ़ॉल्ट बना दिया। इसने कोई गड़बड़ी नहीं की, बल्कि मैंने ही लगाम उस जगह पर ढीली छोड़ दी थी जहाँ नहीं छोड़नी चाहिए थी।

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

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

• तीन सैंडबॉक्स मोड (read-only / workspace-write / danger-full-access) और तीन अनुमोदन नीतियां (untrusted / on-request / never) कैसे एक-दूसरे के साथ मिलती हैं, इसकी एक आसान तालिका।
• कमांड लाइन पर --sandbox / --ask-for-approval का उपयोग करके अस्थायी रूप से कैसे बदलें, और config.toml में डिफ़ॉल्ट के रूप में स्थायी रूप से लिखने के तरीके के लिए टेम्प्लेट।
• Codex शुरू होते समय आपको डिफ़ॉल्ट रूप से कौन सा मोड मिलता है (यह इस बात पर निर्भर करता है कि आपके फ़ोल्डर में Git है या नहीं), और क्यों।
• workspace-write मोड में नेटवर्क डिफ़ॉल्ट रूप से बंद रहता है, और .git रीड-ओनली सुरक्षित रहता है—ये कुछ ऐसे डिफ़ॉल्ट मान हैं जहाँ गलतियाँ हो सकती हैं।
• --yolo (पूरी स्वतंत्रता) की सीमा कहाँ है, और स्थानीय मशीन (Local Machine) तथा प्रोडक्शन मशीन (Production Machine) पर इसका उपयोग क्यों बिल्कुल नहीं किया जाना चाहिए।

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

---

01 पहले स्पष्ट करें: आप "दो स्वतंत्र नियंत्रणों" को सेट कर रहे हैं

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

लेख 02 में हमने इसका उदाहरण दिया था, यहाँ हम केवल इतना जोड़ेंगे कि इन्हें कॉन्फ़िगरेशन में कैसे लागू किया जाए—ये config.toml में दो अलग-अलग कुंजियाँ (Keys) हैं, और कमांड लाइन में दो अलग-अलग पैरामीटर (Parameters) हैं:

नियंत्रण	क्या नियंत्रित करता है	कॉन्फ़िगरेशन कुंजी	कमांड लाइन पैरामीटर	संक्षिप्त रूप
सैंडबॉक्स मोड (sandbox mode, फ़ाइल सिस्टम और नेटवर्क एक्सेस सीमा)	कितना बड़ा बदलाव कर सकता है	sandbox_mode	--sandbox	-s
अनुमोदन नीति (approval policy, क्या हर कदम पर रुककर मानव पुष्टि की आवश्यकता है)	आपसे पूछता है या नहीं	approval_policy	--ask-for-approval	-a

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

तुलना: कार के "गियर" और "स्पीड लिमिट" से। सैंडबॉक्स कार के गियर की तरह है—P गियर (read-only) में कार बिल्कुल नहीं चलती, D गियर (workspace-write) में सड़क पर चल सकती है, और ऑफ-रोड गियर (danger-full-access) में गड्ढों में भी जा सकती है; अनुमोदन आपके द्वारा सेट की गई स्पीड लिमिट चेतावनी की तरह है—यह "केवल गति सीमा पार होने पर बीप" (on-request), "किसी अजनबी को देखकर बीप" (untrusted), या "चेतावनी बंद करके बिना किसी सूचना के ड्राइव करना" (never) हो सकता है। गियर तय करता है कि कार कहाँ जा सकती है, और स्पीड लिमिट तय करती है कि आपको कब सचेत किया जाए—दोनों एक-दूसरे की जगह नहीं ले सकते।

कुछ वास्तविक परिदृश्य जिनका आप सामना कर सकते हैं, आपको इन दोनों के अलग होने का अनुभव कराएंगे:

• आप चाहते हैं कि यह केवल कोड पढ़े और एक विश्लेषण रिपोर्ट लिखे: सैंडबॉक्स को read-only पर सेट करें, अनुमोदन कुछ भी हो—चूँकि यह कुछ लिख नहीं सकता, इसलिए पॉप-अप आने या न आने से कोई फ़र्क नहीं पड़ता।
• आप चाहते हैं कि यह प्रोजेक्ट के भीतर खुलकर काम करे, लेकिन प्रोजेक्ट से बाहर जाने पर आपसे पूछे: सैंडबॉक्स workspace-write + अनुमोदन on-request, यह दैनिक उपयोग के लिए सबसे बेहतरीन संयोजन है।
• आप एक अलग कंटेनर में बड़े काम चला रहे हैं और बिल्कुल भी परेशान नहीं होना चाहते: सैंडबॉक्स danger-full-access + अनुमोदन never, दोनों नियंत्रणों को पूरी तरह खोल दें—लेकिन केवल कंटेनर के भीतर, जैसा कि नीचे बार-बार जोर दिया जाएगा।

💡 संक्षेप में: सैंडबॉक्स (--sandbox) यह नियंत्रित करता है कि "कितना बड़ा बदलाव किया जा सकता है", और अनुमोदन (--ask-for-approval) यह नियंत्रित करता है कि "आपसे पूछा जाए या नहीं", ये दो स्वतंत्र नियंत्रण हैं और कॉन्फ़िगरेशन में भी दो अलग-अलग कुंजियाँ हैं; जो नियंत्रण आप अनुभव करते हैं, वह इन दोनों का संयोजन है।

यह आरेख दोनों नियंत्रणों को एक टू-डायमेंशनल टेबल में दिखाता है: क्षैतिज अक्ष (Horizontal Axis) सैंडबॉक्स मोड है (कठोर read-only से लेकर उदार danger-full-access तक), और ऊर्ध्वाधर अक्ष (Vertical Axis) अनुमोदन नीति है (सबसे सतर्क untrusted से लेकर बिना रुकावट वाले never तक)। प्रत्येक क्रॉसिंग पॉइंट वास्तविक स्तर को दर्शाता है—नीला बॉक्स workspace-write + on-request दैनिक उपयोग के लिए सबसे बेहतरीन है, जबकि निचले दाएं कोने में लाल बॉक्स danger-full-access + never (यानी --yolo) का उपयोग केवल अलग कंटेनर में ही किया जाना चाहिए।

---

02 तीन सैंडबॉक्स मोड: कितना बड़ा बदलाव कर सकते हैं, यह तय करता है

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

सैंडबॉक्स मोड	फ़ाइल बदल सकता है?	नेटवर्क एक्सेस?	सबसे उपयुक्त कार्य
read-only (केवल पढ़ने के लिए)	❌ नहीं (बदलाव के लिए अनुमोदन चाहिए)	❌	कोड की समीक्षा, समाधान तैयार करना, योजना बनाना, "मेरी फाइलों को मत छुओ"
workspace-write (वर्कस्पेस लिखने योग्य)	✅ केवल वर्कस्पेस के भीतर	❌ डिफ़ॉल्ट रूप से बंद, मैन्युअल रूप से खोलना होगा	दैनिक विकास के लिए डिफ़ॉल्ट स्तर, कम रुकावट वाला
danger-full-access (पूर्ण एक्सेस)	✅ पूरी मशीन	✅	पृथक कंटेनर / VM, इसके नाम में danger केवल डराने के लिए नहीं है

कुछ सबसे आम गलतफहमियां जिन्हें स्पष्ट किया जाना चाहिए:

पहला, workspace-write मोड में नेटवर्क डिफ़ॉल्ट रूप से बंद रहता है। यह थोड़ा अलग लग सकता है—आप सोच सकते हैं कि "चूँकि यह फाइलें लिख सकता है, तो इसे डिपेंडेंसी इंस्टॉल करने के लिए नेटवर्क एक्सेस भी मिलना चाहिए", लेकिन ऐसा नहीं है। आधिकारिक दस्तावेज़ स्पष्ट रूप से कहता है: डिफ़ॉल्ट रूप से workspace-write नेटवर्क एक्सेस को बंद रखता है, नेटवर्क का उपयोग करने के लिए इसे कॉन्फ़िगरेशन में मैन्युअल रूप से सक्षम करना होगा। नेटवर्क सक्षम करने के लिए, config.toml में यह जोड़ें:

[sandbox_workspace_write]
network_access = true

पहली बार जब मैंने Codex को workspace-write के तहत npm install चलाने के लिए कहा, तो यह अटक गया और नेटवर्क एरर दिखाने लगा। मुझे लगा कि यह प्रॉक्सी की समस्या है, लेकिन काफी समय बाद मुझे याद आया—सैंडबॉक्स ने इसे डिफ़ॉल्ट रूप से नेटवर्क एक्सेस की अनुमति नहीं दी थी। इसे याद रखने से आपका काफी समय बच सकता है।

दूसरा, वर्कस्पेस का मतलब केवल "वर्तमान निर्देशिका" नहीं है। आधिकारिक दस्तावेज़ के अनुसार, वर्कस्पेस में अस्थायी निर्देशिकाएं (जैसे /tmp) भी स्वचालित रूप से शामिल होती हैं। वर्कस्पेस में कौन सी निर्देशिकाएं शामिल हैं, यह देखने के लिए सेशन में /status चलाएं। इसका आउटपुट कुछ इस तरह दिखेगा:

Sandbox: workspace-write
Approval: on-request
Workspace directories:
  /Users/you/myproject
  /tmp

Sandbox और Approval लाइनें वर्तमान स्तर दिखाती हैं; Workspace directories उन डायरेक्टरी की सूची दिखाती है जिन्हें यह लिख सकता है।

तीसरा, workspace-write चालू होने पर भी, कुछ निर्देशिकाएं हमेशा "रीड-ओनली सुरक्षित" रहती हैं। यह Codex द्वारा सुरक्षा के लिए बनाई गई एक सीमा है—लिखने योग्य वर्कस्पेस में भी, निम्नलिखित पथों (Paths) में कोई बदलाव नहीं किया जा सकता:

सुरक्षित पथ	सुरक्षा का कारण
<Workspace Root>/.git	Git इतिहास में गलती से बदलाव होने या रिपोजिटरी के खराब होने से बचाने के लिए
<Workspace Root>/.agents	इसे अपने स्वयं के एजेंट कॉन्फ़िगरेशन को चुपके से बदलने से रोकने के लिए
<Workspace Root>/.codex	ऊपर की तरह ही, Codex की अपनी कॉन्फ़िगरेशन निर्देशिका

इसके अलावा, यह सुरक्षा रिकर्सिव (Recursive) है—इन निर्देशिकाओं के तहत सब कुछ रीड-ओनली हो जाता है। इसलिए आपको यह चिंता करने की आवश्यकता नहीं है कि "लिखने की अनुमति देने पर यह आपके .git को बदल देगा", Codex डिफ़ॉल्ट रूप से इन संवेदनशील निर्देशिकाओं को लॉक रखता है।

चौथा, सैंडबॉक्स न केवल Codex के अपने रीड/राइट को नियंत्रित करता है, बल्कि इसके द्वारा चलाए गए कमांड्स को भी सीमित करता है। इस बिंदु का उल्लेख लेख 02 में किया गया था, यहाँ हम इसके व्यावहारिक महत्व पर फिर से जोर देते हैं: भले ही Codex git, npm या परीक्षण स्क्रिप्ट चलाए, ये उप-कमांड (Sub-commands) भी उसी सीमा के भीतर रहेंगे—इसलिए ऐसा नहीं होगा कि मुख्य प्रोसेस सीमित है लेकिन उप-कमांड बाहर जाकर अन्य फाइलों को बदल दें।

💡 संक्षेप में: तीन सैंडबॉक्स मोड में workspace-write दैनिक डिफ़ॉल्ट है, लेकिन याद रखें कि नेटवर्क डिफ़ॉल्ट रूप से बंद रहता है, और .git / .agents / .codex हमेशा रीड-ओनली रहते हैं; नेटवर्क चालू करने के लिए मैन्युअल रूप से network_access सक्षम करना होगा, और वर्कस्पेस की सीमा देखने के लिए /status चलाएं।

---

03 तीन अनुमोदन नीतियां: आपसे पूछता है या नहीं, यह तय करता है

अनुमोदन नियंत्रण में भी तीन स्तर होते हैं। सैंडबॉक्स सीमा तय करता है, और सीमा पर "क्या रुककर आपसे पूछना चाहिए" यह अनुमोदन द्वारा नियंत्रित होता है:

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

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

एक और उन्नत स्तर भी है जिसे आपको जानना चाहिए: never को किसी भी सैंडबॉक्स मोड के साथ जोड़ा जा सकता है। बहुत से लोग सोचते हैं कि never (न पूछना) का मतलब "पूरी छूट" है, यह गलत है। आधिकारिक तौर पर कहा गया है कि --ask-for-approval never को किसी भी --sandbox मोड के साथ कॉन्फ़िगर किया जा सकता है—आप पूरी तरह से read-only + never का उपयोग कर सकते हैं, जिसका अर्थ है "इसे केवल पढ़ने की अनुमति दें, और पढ़ते समय एक बार भी न पूछें", जो CI में रीड-ओनली विश्लेषण के लिए मानक कॉन्फ़िगरेशन है और पूरी तरह सुरक्षित है। "न पूछना" और "पूर्ण अधिकार देना" दो अलग बातें हैं, लेख 01 की अवधारणा यहाँ फिर से सिद्ध होती है।

जहाँ तक "अनुमोदन कौन करेगा" का सवाल है, डिफ़ॉल्ट रूप से यह आपको स्वयं दिखाई देता है (approvals_reviewer = "user"). आधिकारिक दस्तावेज़ में auto_review (स्वचालित समीक्षा) का विकल्प भी मिलता है—जो एक समीक्षा एजेंट को आपकी जगह उन अनुरोधों की समीक्षा करने देता है जिनके लिए अनुमोदन की आवश्यकता होती है। यह एक उन्नत क्षमता है जो अभी विकसित हो रही है, 16 · सुरक्षा और जोखिम सीमा में इसके निर्णय तर्क और जोखिमों के बारे में विस्तार से बात की जाएगी, अभी के लिए केवल यह जानना पर्याप्त है कि ऐसा विकल्प मौजूद है, और दैनिक उपयोग के लिए user पर्याप्त है।

💡 संक्षेप में: अनुमोदन के तीन स्तरों में on-request दैनिक डिफ़ॉल्ट है; untrusted अधिक सख्त है (पढ़ने के लिए स्वतंत्र, कुछ बदलने पर रोकता है); never का मतलब "न पूछना" है, "अधिकार देना" नहीं, इसे किसी भी सैंडबॉक्स मोड के साथ जोड़ा जा सकता है, जैसे CI में read-only + never का उपयोग।

---

04 संयोजन कैसे करें: कमांड लाइन पर अस्थायी बदलाव, config.toml में स्थायी सेटिंग्स

सभी मोड और नीतियों को जानने के बाद, इन्हें लागू करने के दो तरीके हैं: कमांड लाइन मापदंडों का उपयोग करके अस्थायी रूप से बदलना, या कॉन्फ़िगरेशन फ़ाइल में स्थायी रूप से लिखना।

अस्थायी रूप से बदलना: कमांड लाइन पैरामीटर (केवल वर्तमान सत्र के लिए)

शुरुआत करते समय दो पैरामीटर देकर आप वर्तमान सत्र के लिए सुरक्षा स्तर निर्धारित कर सकते हैं। आधिकारिक तौर पर अनुशंसित कम जोखिम वाला दैनिक संयोजन इस प्रकार है:

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

सीमा तय है, बाहर जाने पर पूछता है, सुरक्षित और आसान। संक्षिप्त रूप में -s और -a का उपयोग करें:

codex -s read-only -a on-request "केवल इस कोड की समीक्षा करें, इसे बदलें नहीं"

सत्र शुरू होने के बाद बदलना चाहते हैं? बाहर निकलने की आवश्यकता नहीं है, सीधे स्लैश कमांड चलाएं:

/permissions

एक चयनकर्ता (Selector) खुलेगा, जहाँ आप अपनी पसंद का स्तर (Read Only / Auto / Full Access आदि) चुन सकते हैं, जो तुरंत प्रभावी हो जाएगा। मेरी अपनी आदत यह है: अपरिचित प्रोजेक्ट पर काम करते समय पहले /permissions का उपयोग करके इसे रीड-ओनली पर सेट करता हूँ ताकि यह योजना तैयार कर सके, और जब मैं आश्वस्त हो जाता हूँ तो काम करने के लिए इसे workspace-write पर बदल देता हूँ—इस आदत ने मुझे कई बार बचाया है और गलत बदलावों से बचाया है।

⚠️ नए संस्करण में मेनू अलग हो सकता है: codex-cli 0.142 से, आधिकारिक तौर पर permission profiles (Beta, बदलाव संभव) पेश किया गया है, जो पुराने प्रीसेट की जगह लेता है। आपका /permissions मेनू अब Ask for approval / Approval for me / Full access जैसी अनुमोदन नीतियों में बदल सकता है, जहाँ सीधे Read Only विकल्प नहीं होगा। रीड-ओनली पर स्विच करने के लिए कमांड लाइन पैरामीटर codex --sandbox read-only का उपयोग करें, या ~/.codex/config.toml में sandbox_mode = "read-only" लिखें (आधिकारिक तौर पर पुराने सैंडबॉक्स मोड को संगतता के लिए बनाए रखा गया है)। इस लेख में आगे जहाँ भी /permissions को रीड-ओनली पर स्विच करने की बात कही गई है, वहाँ यही बात लागू होती है।

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

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

स्थायी सेटिंग्स: config.toml को डिफ़ॉल्ट बनाना (हर बार शुरू होने पर लागू)

हर बार पैरामीटर लिखना थकाऊ हो सकता है, इसलिए अक्सर उपयोग किए जाने वाले संयोजनों को कॉन्फ़िगरेशन फ़ाइल में लिखना बेहतर होता है। फ़ाइल ~/.codex/config.toml में है, इसमें ये दो लाइनें जोड़ें:

approval_policy = "on-request"
sandbox_mode    = "workspace-write"

सबसे सुरक्षित डिफ़ॉल्ट सेटिंग चाहते हैं? आधिकारिक तौर पर अनुशंसित "हमेशा पहले पूछें" संयोजन approval_policy = "untrusted" और sandbox_mode = "read-only" है, जिसका अर्थ है कि हर बार शुरू होने पर यह सबसे सुरक्षित स्तर से शुरू होगा, और आवश्यकता पड़ने पर इसे मैन्युअल रूप से बदला जा सकता है। प्रोडक्शन प्रोजेक्ट्स या साझा मशीनों के लिए यह सबसे उपयुक्त है।

यदि आपके पास कई अक्सर उपयोग किए जाने वाले संयोजन हैं (जैसे "दैनिक उपयोग के लिए एक, CI के लिए दूसरा"), तो एक ही फ़ाइल को बार-बार बदलने के बजाय—आप आधिकारिक तौर पर समर्थित कॉन्फ़िगरेशन प्रोफ़ाइल (profile) का उपयोग कर सकते हैं, प्रत्येक को एक अलग फ़ाइल में सहेज सकते हैं और --profile का उपयोग करके चुन सकते हैं:

# ~/.codex/full_auto.config.toml
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

# ~/.codex/readonly_quiet.config.toml
approval_policy = "never"
sandbox_mode    = "read-only"

उपयोग करते समय प्रोफ़ाइल का नाम निर्दिष्ट करें:

codex --profile full_auto

⚠️ ध्यान दें कि यहाँ उल्लिखित profile (कॉन्फ़िगरेशन प्रोफ़ाइल) और धारा 05 में चर्चा की जाने वाली permission profile (अनुमति प्रोफ़ाइल) दो अलग-अलग चीजें हैं। नाम समान हैं लेकिन भ्रमित न हों: पहला "कॉन्फ़िगरेशन के समूह को नाम देना" है, जबकि दूसरा फ़ाइल सिस्टम और नेटवर्क सीमाओं को परिभाषित करने वाला एक नया Beta तंत्र है। यह वर्तमान मुख्य कॉन्फ़िगरेशन विधि sandbox_mode + approval_policy है, पहले इसे अच्छी तरह समझें।

💡 संक्षेप में: अस्थायी रूप से बदलने के लिए -s / -a या सत्र के भीतर /permissions का उपयोग करें, स्थायी रूप से बदलने के लिए ~/.codex/config.toml में sandbox_mode + approval_policy लिखें; कई संयोजनों के लिए --profile का उपयोग करें, यह वर्तमान मुख्य तरीका है, इसे पहले सीखें।

---

05 उन्नत स्तर: rules द्वारा कमांड का सटीक नियंत्रण, permission profiles द्वारा सीमाओं का बारीक निर्धारण (Beta)

धारा 04 में वर्णित "सैंडबॉक्स मोड + अनुमोदन नीति" बुनियादी सुरक्षा सेट करने के लिए है। यदि आप इसे इस स्तर तक सटीक बनाना चाहते हैं कि "यह विशिष्ट कमांड हमेशा स्वीकृत हो, और वह कमांड हमेशा प्रतिबंधित हो", तो Codex दो और बारीक उपकरण प्रदान करता है। शुरुआती लोग पहली बार में इसे छोड़ सकते हैं, और आवश्यकता पड़ने पर वापस आ सकते हैं।

rules: विशिष्ट कमांड के लिए नियम बनाना (प्रायोगिक)

⚠️ प्रायोगिक, बदलाव संभव। rules आधिकारिक तौर पर एक प्रायोगिक सुविधा है।

Codex द्वारा "विशिष्ट कमांड को सटीक रूप से नियंत्रित करने" के तंत्र को rules (नियम) कहा जाता है, ध्यान दें कि इसके निर्णय शब्द allow / prompt / forbidden हैं, न कि कुछ ट्यूटोरियल में लिखे गए ask / approve / deny—लिखने का तरीका अलग है, भ्रमित न हों।

यह इस समस्या को हल करता है: सैंडबॉक्स एक सामान्य सीमा है, लेकिन कभी-कभी आप चाहते हैं कि "gh pr view कमांड को सीमा से बाहर होने पर भी सीधे चलने दिया जाए और बार-बार न पूछा जाए" या "grep को पूरी तरह प्रतिबंधित कर दिया जाए और इसके बजाय rg का उपयोग करने के लिए बाध्य किया जाए"। ऐसे मामलों में पूरे सैंडबॉक्स को बड़ा करना असुरक्षित है, एक rule लिखना इसका सही समाधान है।

नियम ~/.codex/rules/ के तहत .rules फ़ाइलों में लिखे जाते हैं, और इनका सिंटैक्स Python जैसा होता है (वास्तव में Starlark है)। एक नियम इस प्रकार दिखता है:

prefix_rule(
    pattern = ["gh", "pr", "view"],
    decision = "prompt",
    justification = "查看 PR 允许，但要我点头",
)

decision के तीन विकल्प होते हैं, और उनकी प्राथमिकता आधिकारिक तौर पर तय है—सबसे सख्त नियम की जीत होती है (forbidden > prompt > allow):

decision	प्रभाव
allow	सैंडबॉक्स से बाहर सीधे चलाएं, बिना पूछे
prompt	हर बार मैच होने पर पहले आपसे पूछें
forbidden	सीधे ब्लॉक करें, न पूछें और न चलाएं

एक सुरक्षा डिज़ाइन बहुत उपयोगी है: यदि git add . && rm -rf / जैसी एक ही लाइन में कई कमांड लिखी हों, तो Codex सुरक्षा सुनिश्चित करने के लिए इन्हें अलग-अलग भागों में तोड़कर जाँचता है—भले ही आपने git add को allow किया हो, rm -rf / को अलग से ब्लॉक कर दिया जाएगा, इसे चुपके से नहीं चलने दिया जाएगा। नियमों को सत्यापित करने के लिए, codex execpolicy check का उपयोग करके जाँचें कि कमांड पर क्या निर्णय लिया जाएगा, इसे सीधे उत्पादन में न चलाएं।

permission profiles: फ़ाइल सिस्टम और नेटवर्क सीमाओं को एक प्रोफ़ाइल में पैक करना (Beta)

⚠️ Beta, बदलाव संभव, और पुराने सैंडबॉक्स सेटिंग्स के साथ मिलकर उपयोग नहीं किया जा सकता। इस पर आधिकारिक तौर पर जोर दिया गया है—यदि आपकी किसी कॉन्फ़िगरेशन फ़ाइल में sandbox_mode दिखाई देता है, या आप --sandbox पास करते हैं, तो Codex पुराने सैंडबॉक्स सेटिंग्स का ही उपयोग करेगा, permission profiles का नहीं। दोनों में से किसी एक को चुनें, दोनों को एक साथ कॉन्फ़िगर न करें।

यदि आपको लगता है कि "workspace-write पर्याप्त रूप से बारीक नहीं है, मैं सटीक रूप से यह तय करना चाहता हूँ कि कौन सी निर्देशिका लिखने योग्य है, कौन सी .env ब्लॉक होनी चाहिए, और किन डोमेन तक पहुँचा जा सकता है", तो permission profiles (अनुमति प्रोफ़ाइल) इसी काम के लिए हैं। यह फ़ाइल सिस्टम नियमों और नेटवर्क नियमों को एक नामित प्रोफ़ाइल में पैक करता है, और default_permissions द्वारा डिफ़ॉल्ट रूप से उपयोग की जाने वाली प्रोफ़ाइल को निर्दिष्ट करता है।

आधिकारिक तौर पर तीन बिल्ट-इन प्रोफ़ाइल शामिल हैं (ध्यान दें कि सभी में कोलन : उपसर्ग होता है):

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

एक कस्टम प्रोफ़ाइल इस प्रकार दिखती है (फ़ाइल सिस्टम स्तर पर "वर्कस्पेस लिखने योग्य है, लेकिन सभी .env ब्लॉक हैं"):

default_permissions = "project-edit"

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

फ़ाइल सिस्टम के तीन स्तर होते हैं read / write / deny, और प्राथमिकता नियमों के समान ही है—deny सबसे ऊपर है (deny > write > read), और जितना विशिष्ट पथ होगा, प्राथमिकता उतनी ही अधिक होगी। इस डिज़ाइन का लाभ यह है कि: आप "वर्कस्पेस को लिखने योग्य रख सकते हैं, लेकिन विशिष्ट .env फाइलों को ब्लॉक कर सकते हैं", इस प्रकार सामान्य और बारीक नियंत्रणों को एक साथ प्रबंधित किया जा सकता है। नेटवर्क भी "व्हाइटलिस्ट-फ़र्स्ट" है—जब तक आप allow नहीं लिखेंगे, किसी भी डोमेन तक पहुँच नहीं होगी, और deny हमेशा allow पर हावी रहेगा।

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

💡 संक्षेप में: rules कमांड उपसर्ग के आधार पर सटीक नियंत्रण प्रदान करते हैं (allow/prompt/forbidden, सबसे सख्त की जीत), जबकि permission profiles (Beta) पथ और डोमेन के आधार पर बारीक सीमाएँ तय करते हैं (deny सबसे ऊपर); दोनों उन्नत सुविधाएँ हैं, शुरुआती लोग पहले मुख्य विधि का उपयोग करें, आवश्यकता होने पर ही इनका उपयोग करें, और profiles को पुराने सैंडबॉक्स सेटिंग्स के साथ नहीं मिलाया जा सकता।

---

06 डिफ़ॉल्ट मान + डेंजर मोड सीमाएँ

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

Codex आपको डिफ़ॉल्ट रूप से कौन सा स्तर देता है

आधिकारिक निर्णय प्रक्रिया बहुत स्पष्ट है: शुरू होते समय यह जाँचता है कि क्या निर्देशिका वर्जन कंट्रोल (Git) के अंतर्गत है, और उसी के अनुसार डिफ़ॉल्ट स्तर की सिफारिश करता है:

निर्देशिका जहाँ Codex शुरू किया गया है	डिफ़ॉल्ट अनुशंसित स्तर
Git के अंतर्गत है (version-controlled)	Auto स्तर (workspace-write + on-request)
Git के अंतर्गत नहीं है (non-version-controlled)	read-only (केवल पढ़ने के लिए)

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

इसके अलावा, कुछ मामलों में Codex रीड-ओनली से शुरू हो सकता है, जब तक कि आप स्पष्ट रूप से इस निर्देशिका पर "भरोसा" नहीं करते (जैसे प्रारंभिक मार्गदर्शन संकेतों या /permissions के माध्यम से)। यदि आप देखते हैं कि यह शुरुआत में केवल पढ़ने तक सीमित है, तो घबराएं नहीं, यह केवल आपके द्वारा इस निर्देशिका पर भरोसा किए जाने की पुष्टि का इंतजार कर रहा है, यह कोई खराबी नहीं है।

नेटवर्क एक्सेस से संबंधित एक और डिफ़ॉल्ट मान याद रखें—वेब सर्च (web search) डिफ़ॉल्ट रूप से कैश (cached) का उपयोग करता है, लाइव सर्च का नहीं। आधिकारिक तौर पर एक पूर्व-अनुक्रमित (Pre-indexed) परिणाम सूची बनाए रखी जाती है, और कैश मोड इसी सूची से परिणाम देता है, न कि सीधे वेब पेजों को स्क्रैप करता है। इसका लाभ यह है कि लाइव पेजों में छिपे "प्रॉम्प्ट इंजेक्शन" हमलों के जोखिम को कम किया जा सकता है। एक बात ध्यान रखें: यदि आप पूर्ण एक्सेस चालू करते हैं (जैसे --yolo), तो वेब सर्च डिफ़ॉल्ट रूप से लाइव (live) पर स्विच हो जाएगी। लाइव सर्च को बाध्य करने के लिए --search का उपयोग करें, और इसे पूरी तरह बंद करने के लिए web_search = "disabled" सेट करें, लेकिन सुरक्षा के इन पहलुओं पर 16 · सुरक्षा और जोखिम सीमा में विस्तार से चर्चा की जाएगी।

--yolo: पूर्ण स्वतंत्रता की सीमा

अंत में वह सीमा आती है, जो मेरी शुरुआत की कहानी की मुख्य बिंदु थी—पूरी स्वतंत्रता। Codex में इसे लिखने के दो तरीके हैं:

• कॉन्फ़िगरेशन स्तर पर: sandbox_mode = "danger-full-access" और approval_policy = "never" का संयोजन
• कमांड लाइन पर: --dangerously-bypass-approvals-and-sandbox (संक्षिप्त रूप --yolo, you only live once)

--yolo नाम से ही स्पष्ट है कि "इसे बिना सोचे-समझे उपयोग न करें"। यह सैंडबॉक्स को हटा देता है और अनुमोदन को बंद कर देता है, जिसका अर्थ है कि Codex आपकी पूरी मशीन पर कुछ भी कर सकता है और एक बार भी नहीं पूछेगा। इसका उपयोग कब करना चाहिए, यह इस तालिका से समझें:

परिदृश्य	क्या --yolo / पूर्ण एक्सेस का उपयोग करना चाहिए?
पृथक कंटेनर / VM / dev container	✅ हाँ, यदि कुछ खराब होता है तो वह एक अस्थायी वातावरण है
CI में अस्थायी कार्य चलाना (कंटेनर के भीतर)	✅ हाँ, लेकिन वातावरण स्वयं पृथक होना चाहिए
दैनिक विकास के लिए आपकी अपनी मशीन	❌ नहीं, सुरक्षा के लिए अनुमोदन चालू रखें
कंपनी का कोड या महत्वपूर्ण डेटा वाली मशीन	❌ बिल्कुल नहीं, यह खतरनाक हो सकता है

इस पर आधिकारिक दृष्टिकोण बहुत स्पष्ट है: पूर्ण एक्सेस को (not recommended) (अनुशंसित नहीं) के रूप में चिह्नित किया गया है। यदि आपकी होस्ट मशीन लिनक्स सैंडबॉक्स का समर्थन नहीं करती है, या कंपनी कंटेनर-आधारित विकास का उपयोग करती है, तो सही तरीका Docker / dev container का उपयोग करके बाहरी सुरक्षा परत बनाना और कंटेनर के भीतर --yolo चलाना है—कंटेनर को सुरक्षा सीमा बनने दें, न कि अपनी स्थानीय मशीन पर सभी सुरक्षा हटा दें। आधिकारिक दस्तावेज़ में एक सुरक्षित devcontainer उदाहरण (फ़ायरवॉल आउटबाउंड नियंत्रण के साथ) भी प्रदान किया गया है, जो देखने योग्य है।

लेकिन आधिकारिक तौर पर एक चेतावनी भी दी गई है जिसे आपको ध्यान में रखना चाहिए: devcontainer में पूर्ण एक्सेस चालू करना भी पूरी तरह सुरक्षित नहीं है—एक दुर्भावनापूर्ण प्रोजेक्ट कंटेनर के भीतर से जानकारी (आपके Codex लॉगिन क्रेडेंशियल सहित) चुरा सकता है। इसलिए कंटेनर के भीतर भी, केवल विश्वसनीय कोड रिपोजिटरी के साथ ही ऐसा करें, और किसी भी उच्च-विशेषाधिकार वातावरण की तरह इसकी गतिविधियों पर नज़र रखें।

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

💡 संक्षेप में: Codex डिफ़ॉल्ट रूप से "क्या Git मौजूद है" के आधार पर सुरक्षा स्तर चुनता है (Git है → Auto, Git नहीं है → रीड-ओनली), इस सुरक्षा को न हटाएं; वेब सर्च डिफ़ॉल्ट रूप से इंजेक्शन से बचने के लिए कैश का उपयोग करता है; --yolo (पूर्ण एक्सेस) का उपयोग केवल पृथक कंटेनरों में करें, स्थानीय और प्रोडक्शन मशीनों पर कभी नहीं।

---

07 अभ्यास: 5 मिनट में तीन स्तरों को बदलें

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

चरण 1: एक खाली निर्देशिका बनाएं और उसमें Codex शुरू करें।

Mac / Linux (Windows पर PowerShell में mkdir -p की जगह mkdir का उपयोग करें):

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

codex

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

चरण 2: वर्तमान स्तर की पुष्टि करें।

सत्र में प्रवेश करने के बाद पहले यह देखें कि वर्तमान स्तर क्या है:

/status

अपेक्षित परिणाम: आप वर्तमान सैंडबॉक्स मोड, अनुमोदन नीति और वर्कस्पेस निर्देशिका सूची देख पाएंगे। इसे आधार मान लें।

चरण 3: रीड-ओनली स्तर पर एक फ़ाइल लिखने का प्रयास करें।

सुनिश्चित करें कि वर्तमान स्तर रीड-ओनली है (यदि नहीं, तो /permissions का उपयोग करके Read Only पर स्विच करें), और फिर इसे कहें:

कृपया एक नई फ़ाइल hello.txt बनाएं और उसमें "hello codex" लिखें।

अपेक्षित परिणाम: यह चुपचाप फ़ाइल नहीं बनाएगा, बल्कि रुककर आपसे अनुमति मांगेगा—क्योंकि फ़ाइल लिखना रीड-ओनली की सीमा से बाहर है, और अनुमोदन नीति के अनुसार इसे आपसे पूछना होगा, कुछ इस तरह:

मुझे hello.txt फ़ाइल बनाने की आवश्यकता है, जो वर्तमान रीड-ओनली मोड की अनुमतियों से बाहर है। क्या आप इसकी अनुमति देते हैं?

इसे रुककर पूछते हुए देखना ही वह अनुभव है जहाँ सैंडबॉक्स और अनुमोदन एक साथ काम करते हैं: सैंडबॉक्स ने तय किया कि "यह सीमा से बाहर है", और अनुमोदन नीति ने पुष्टि के लिए पॉप-अप दिखाया।

चरण 4: वर्कस्पेस लिखने योग्य स्तर पर स्विच करें और अंतर देखें।

/permissions

चयनकर्ता में Auto / Workspace Write स्तर पर स्विच करें, और इसे फिर से फ़ाइल बनाने के लिए कहें। अपेक्षित परिणाम: इस बार यह बिना पूछे सीधे फ़ाइल बना देगा—क्योंकि वर्कस्पेस में फ़ाइल लिखना सैंडबॉक्स सीमा के भीतर है, इसलिए अनुमोदन की आवश्यकता नहीं है।

hello.txt फ़ाइल बना दी गई है

चरण 5 (वैकल्पिक): अनुभव करें कि नेटवर्क डिफ़ॉल्ट रूप से बंद है।

वर्कस्पेस लिखने योग्य स्तर पर रहते हुए ही इसे कोई नेटवर्क कार्य करने के लिए कहें:

कृपया curl का उपयोग करके https://example.com पर जाएँ और परिणाम यहाँ दिखाएँ।

अपेक्षित परिणाम: चूँकि workspace-write में नेटवर्क डिफ़ॉल्ट रूप से बंद रहता है (धारा 02 में बताया गया है), यह या तो नेटवर्क एक्सेस की अनुमति मांगेगा या सीधे विफलता दिखाएगा—यह इस बात की पुष्टि करता है कि "लिखने की अनुमति होने का मतलब नेटवर्क एक्सेस होना नहीं है"। नेटवर्क सक्षम करने के लिए config.toml में network_access को सक्षम करना होगा, लेकिन इस अभ्यास के लिए इसकी आवश्यकता नहीं है।

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

💡 संक्षेप में: एक खाली निर्देशिका बनाएं, /status द्वारा स्तर देखें, रीड-ओनली मोड में फ़ाइल लिखने का प्रयास करके ब्लॉक होना देखें, लिखने योग्य मोड में स्विच करके अनुमति देखना सीखें, और नेटवर्क एक्सेस का प्रयास करके डिफ़ॉल्ट सीमा को समझें—एक बार अभ्यास करना नियमों को याद रखने से कहीं अधिक उपयोगी है।

---

08 सारांश

इस लेख में हमने Codex की अनुमतियों और सीमाओं को समझने से लेकर लागू करने तक की प्रक्रिया को देखा है—यह कितना सुरक्षित या स्वतंत्र रहेगा, यह सैंडबॉक्स और अनुमोदन के दो नियंत्रणों के संयोजन पर निर्भर करता है।

मुख्य बिंदुओं का सारांश:

आप क्या करना चाहते हैं	किसका उपयोग करें	मुख्य बिंदु
"कितना बड़ा बदलाव कर सकता है" तय करना	सैंडबॉक्स --sandbox	read-only / workspace-write / danger-full-access तीन स्तर
"आपसे पूछता है या नहीं" तय करना	अनुमोदन --ask-for-approval	untrusted / on-request / never स्तर, सैंडबॉक्स से स्वतंत्र
वर्तमान सत्र के लिए अस्थायी बदलाव	कमांड लाइन पैरामीटर / /permissions	सत्र के भीतर किसी भी समय स्विच किया जा सकता है
स्थायी डिफ़ॉल्ट सेटिंग्स	config.toml	sandbox_mode + approval_policy; कई संयोजनों के लिए --profile
कमांड या पथ का सटीक नियंत्रण	rules / permission profiles	उन्नत सुविधाएँ, शुरुआत में मुख्य विधि का उपयोग करें, और profiles को पुराने सैंडबॉक्स के साथ मिश्रित न करें
पूर्ण एक्सेस (YOLO)	--yolo	केवल पृथक कंटेनर में उपयोग करें, स्थानीय और उत्पादन मशीनों पर कभी नहीं

अब आप यह कर सकते हैं: विभिन्न कार्यों के लिए उपयुक्त सैंडबॉक्स मोड और अनुमोदन नीतियों को समझें, कमांड लाइन या config.toml में डिफ़ॉल्ट सेट करना सीखें, यह जानें कि Git की उपस्थिति के आधार पर डिफ़ॉल्ट स्तर कैसे तय होते हैं, और सैंडबॉक्स सीमाओं की सुरक्षा को समझें। यह नियंत्रण क्षमता आपको Codex का सुरक्षित रूप से उपयोग करने का विश्वास देती है।

---

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

---

अनुशंसित पठन

• क्लाउड संस्करण Codex Cloud: कार्यों को क्लाउड पर भेजें और परिणाम का इंतजार करें
• उप-एजेंट (Subagents): समानांतर रूप से कार्य विभाजित करें, लेकिन केवल आपके निर्देश पर
• सर्वोत्तम प्रथाएं: सामान्य बातों से परे, वास्तव में लागू करने योग्य व्यावहारिक नियम