हार्नेस के भीतर: टर्न-सीमित अनुमतियाँ एजेंट रनटाइम की मूल इकाई बन रही हैं

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

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

मुख्य बातें - टर्न-सीमित अनुमतियों का मतलब है कि रनटाइम टर्न शुरू होने पर मंजूरी नीति, सैंडबॉक्स नीति और अनुमति प्रोफ़ाइल का स्नैपशॉट लेता है, और उस टर्न का हर टूल कॉल उसी स्नैपशॉट के विरुद्ध चलता है। - खतरा मॉडल दुर्भावनापूर्ण उपयोगकर्ता नहीं है। यह सक्षम एजेंट है जो शत्रुतापूर्ण निर्देश, यानी प्रॉम्प्ट इंजेक्शन, मान ले या काम से भटक जाए, और आपकी मशीन पर आपके क्रेडेंशियल के साथ चल रहा हो। - Codex सीमा को तीन स्वतंत्र नियंत्रणों के रूप में लागू करता है: मंजूरी नीति, यानी क्या पूछना है; सैंडबॉक्स मोड, यानी कमांड क्या छू सकते हैं; और अनुमति प्रोफ़ाइल, यानी सूक्ष्म फ़ाइल-सिस्टम और नेटवर्क नियम। प्रवर्तन मॉडल नहीं, ऑपरेटिंग सिस्टम करता है। - प्रवर्तन मॉडल से नीचे होता है: macOS पर Seatbelt, Linux पर bubblewrap और seccomp, Windows पर समर्पित सैंडबॉक्स। जहाँ नीति लागू नहीं की जा सकती, Codex कमांड चलाने से मना कर देता है। - अभी अनसुलझी सीमा बीच टर्न परिवर्तन है: आज स्नैपशॉट पूरे टर्न के जीवनकाल में अपरिवर्तनीय है, जो सुरक्षित है और कभी-कभी बेहद परेशान करने वाला।

क्या हुआ

जुलाई के अंत और अगस्त की शुरुआत तक Codex की अनुमति सतह दो मोटी सेटिंग से बढ़कर नीति इंजन जैसी हो गई, और दस्तावेज़ भी उसके साथ आ गए। पुराना मॉडल config.toml में दो नियंत्रण था: sandbox_mode (read-only, workspace-write, danger-full-access) और approval_policy (untrusted, on-request, never)। नया मॉडल अनुमति प्रोफ़ाइल जोड़ता है, अभी बीटा में: नामित, संयोज्य नीतियाँ जो फ़ाइल-सिस्टम नियम, हर पथ पर read, write, deny, जिसमें अस्वीकार जीतता है, और नेटवर्क नियम, स्थानीय प्रॉक्सी से लागू डोमेन अनुमति सूची, जोड़ती हैं। रनटाइम के साथ तीन अंतर्निहित प्रोफ़ाइल आती हैं: :read-only, :workspace और :danger-full-access, और आप शून्य से शुरू करने के बजाय इन्हें बढ़ाते हैं।

कॉन्फ़िगरेशन सतह के साथ बातचीत मॉडल भी अधिक टर्न-केंद्रित हुआ। /permissions चल रहे सत्र के भीतर मोड बदलता है। सूक्ष्म मंजूरी नीति कुछ प्रॉम्प्ट श्रेणियों, सैंडबॉक्स उन्नयन और MCP elicitations, को बातचीत योग्य रख सकती है जबकि अन्य को अपने-आप अस्वीकार कर सकती है, जिसमें अलग request_permissions श्रेणी शामिल है, यानी एजेंट खुद काम के बीच अधिक पहुँच माँग रहा है। और OpenAI के मंजूरियाँ और सुरक्षा दस्तावेज़ के अनुसार मंजूरियाँ ऐसे स्वचालित समीक्षक एजेंट को भेजी जा सकती हैं जो मानव तक पहुँचने से पहले डेटा बाहर भेजने, क्रेडेंशियल टटोलने और विनाशकारी कार्रवाई के लिए अनुरोध जाँचता है।

यह कोई एक घोषणा नहीं है। यह रनटाइम वास्तविकता से टकराकर अनुमति परत उगा रहा है, ठीक वैसे ही जैसे ऑपरेटिंग सिस्टम ने अनिच्छा से उपयोगकर्ता खाते विकसित किए थे।

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

"टर्न-सीमित" का असली मतलब

मेरी सबसे साफ़ परिभाषा: एजेंट क्या कर सकता है उसकी सीमा एकल टर्न के जीवनकाल से बँधी होती है, टर्न शुरू होने पर पकड़ी जाती है, और सिद्धांततः टर्न खत्म होने पर छोड़ी जा सकती है। उपयोगकर्ता से नहीं, जो एजेंट काम करते समय एक घंटे के लिए दूर हो सकता है; मशीन से नहीं, जो अलग-अलग जोखिम वाले अनेक टर्न चलाती है; और सत्र से भी नहीं, जो सुबह कोड समीक्षा करे और दोपहर में निर्भरताएँ स्थापित करे।

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

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

Codex अनुमतियों को टर्न-आरंभ स्नैपशॉट से बाँधता है: जुलाई 2026 का मुद्दा दर्ज करता है कि बीच टर्न पहुँच मोड बदलने से चल रहा टर्न प्रभावित नहीं होता, और सक्रिय टर्न में नई मंजूरी नीति, सैंडबॉक्स नीति तथा अनुमति प्रोफ़ाइल पहुँचाने का प्रस्ताव देता है, साथ ही पुनरारंभ और सौंपे टर्न नया संदर्भ बनाए रखें।

यह किस खतरा मॉडल का जवाब है

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

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

भटकाव और सीमा से बाहर जाना शांत खतरा है। वैध काम करता सक्षम एजेंट फिर भी भटकेगा: कुछ स्थापित कर देगा, निर्भरता ले आएगा, "मदद" के नाम पर निर्देशिका साफ़ कर देगा। सैंडबॉक्स इसके लिए एजेंट को दुर्भावनापूर्ण मानने की जरूरत नहीं रखता, इसीलिए सीमा मॉडल के अच्छे निर्णय पर नहीं बल्कि OS पर लागू होती है, macOS पर Seatbelt, Linux पर bubblewrap और seccomp, Windows पर मूल सैंडबॉक्स। जहाँ प्लेटफ़ॉर्म माँगी नीति लागू नहीं कर सकता, Codex कमांड को बिना सैंडबॉक्स चलाने के बजाय मना करता है। सुरक्षित विफलता, आशावादी विफलता नहीं।

क्रेडेंशियल उजागर होना गुणक है। दस्तावेज़ की devcontainer मार्गदर्शिका साफ़ कहती है: कंटेनर के भीतर पूर्ण पहुँच के साथ Codex चलाएँ और दुर्भावनापूर्ण परियोजना कंटेनर की कोई भी चीज़ बाहर भेज सकती है, Codex क्रेडेंशियल सहित। इसीलिए नए मूल नियम रहस्यों को लेकर इतने विशिष्ट हैं: "**/*.env" = "deny" ग्लॉब जो लिखने योग्य कार्यक्षेत्र से क्रेडेंशियल फ़ाइलें बाहर रखते हैं, लिखने योग्य मूल पथों में .git, .codex और .agents को केवल-पढ़ने योग्य बनाना, और DNS रीबाइंडिंग से बचाव के लिए डिफ़ॉल्ट रूप से स्थानीय तथा निजी गंतव्यों को रोकने वाला नेटवर्क प्रॉक्सी। आपके स्थानीय डेमन तक पहुँच वाला सैंडबॉक्स एजेंट वास्तव में सैंडबॉक्स नहीं है। व्यापक एजेंटिक AI आर्किटेक्चर की संरचना भी यही है: प्रस्ताव मॉडल देता है, निर्णय हार्नेस लागू करता है, और रहस्य हार्नेस के पास रहने चाहिए।

OpenAI के सुरक्षा दस्तावेज़ के अनुसार Codex का दस्तावेज़ित खतरा मॉडल प्रॉम्प्ट इंजेक्शन पर केंद्रित है, नेटवर्क डिफ़ॉल्ट रूप से बंद और शत्रुतापूर्ण लाइव सामग्री का जोखिम घटाने के लिए कैश्ड वेब खोज; एजेंट भटकाव पर, OS-प्रवर्तित सैंडबॉक्स जो लागू न कर सकने वाले कमांड से मना करते हैं; और क्रेडेंशियल जोखिम पर, .env फ़ाइलों के लिए अस्वीकार ग्लॉब, .git तथा .codex पथ केवल-पढ़ने योग्य, और स्थानीय नेटवर्क अवरोध।

कार्यान्वयन वास्तव में कैसे जुड़ता है

अपने रनटाइम के लिए सोचते समय तीन कार्यान्वयन विवरण चुराने लायक हैं।

समान विशिष्टता पर deny, लेखन को हराता है, और write, पठन को। अनुमति प्रोफ़ाइल आपको पहले व्यापक पहुँच देने और फिर अपवाद काटने देती है: कार्यक्षेत्र लिखने योग्य, **/*.env निषिद्ध, .devcontainer केवल-पढ़ने योग्य। अधिक विशिष्ट पथ व्यापक नियमों को बदलते हैं, और निषिद्ध उपपथ लिखने योग्य मूल के भीतर भी निषिद्ध रहता है। व्यापक अस्वीकार के भीतर संकीर्ण उपवृक्ष फिर खोल सकते हैं, जैसे ~/Documents निषिद्ध लेकिन ~/Documents/codex लिखने योग्य। यह सही प्राथमिकता मॉडल है क्योंकि यह न्यूनतम-अधिकार को लिखने की अनुमति में जोड़ने वाला बनाता है, याददाश्त पर निर्भर होकर घटाने वाला नहीं।

नेटवर्क पहुँच और नेटवर्क फ़िल्टरिंग अलग स्विच हैं। network.enabled = true कमांड को नेटवर्क तक पहुँच देता है; features.network_proxy = true ही आपके डोमेन नियम स्थानीय प्रॉक्सी के जरिए वास्तव में लागू करता है। एक को दूसरे के बिना चालू करना अप्रतिबंधित आउटबाउंड पहुँच देता है और शासन का झूठा भरोसा भी। डोमेन नियम अनुमति-सूची से शुरू होते हैं, अस्वीकार जीतता है, और localhost तथा संबंधित पते डिफ़ॉल्ट रूप से रोके जाते हैं जब तक आप स्पष्ट अनुमति न दें, क्योंकि स्थानीय सेवाओं तक पहुँच वाला सैंडबॉक्स एजेंट अर्थपूर्ण रूप से सैंडबॉक्स नहीं है।

पुरानी और नई प्रणालियाँ साथ नहीं जुड़तीं। प्रोफ़ाइल और पुराने sandbox_mode नियम परस्पर अनन्य हैं; किसी भी लोड किए गए कॉन्फ़िगरेशन में sandbox_mode सेट हो तो प्रोफ़ाइल अनदेखी हो जाती हैं। एंटरप्राइज़ प्रशासक प्रबंधित allowed_permission_profiles अनुमति-सूची से नया मॉडल अनिवार्य कर सकते हैं, जो सूची से बाहर अंतर्निहित प्रोफ़ाइल भी निषिद्ध कर देती है। पूरे डिज़ाइन से एक परिचालन सबक लें: दो अनुमति प्रणालियाँ जो "दोनों लागू" हों, वहीं आप यह सोचते रह जाते हैं कि कुछ रोका है जबकि नहीं रोका। एक चुनें, /permissions और /status से सत्यापित करें, फिर विस्तार करें।

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

अनुमति दस्तावेज़ के अनुसार Codex अनुमति प्रोफ़ाइल deny-over-write-over-read प्राथमिकता और विशिष्टता ओवरराइड इस्तेमाल करती हैं, नेटवर्क सक्षम करना और प्रॉक्सी डोमेन प्रवर्तन अलग रखती हैं, और अस्पष्टता से बचने के लिए पुराने सैंडबॉक्स नियमों के साथ नहीं जुड़तीं; प्रशासक प्रबंधित अनुमति-सूचियों से प्रोफ़ाइल अनिवार्य कर सकते हैं।

अभी क्या करें

1. आज: अगले Codex सत्र में /permissions और /status चलाएँ और देखें कि वास्तव में क्या लागू है, न कि आपको क्या लगता है। यदि किसी कॉन्फ़िगरेशन परत में अभी भी sandbox_mode है, तो आपने चुपचाप अनुमति प्रोफ़ाइल से बाहर होने का चुनाव किया है। तय करें कि आप किस प्रणाली पर हैं।

2. इस सप्ताह: एक कस्टम प्रोफ़ाइल लिखें जो :workspace बढ़ाती हो, **/*.env निषिद्ध करे और केवल वास्तव में उपयोग किए API डोमेन की अनुमति दे, network_proxy चालू रखते हुए। भरोसा करने से पहले इसे codex debug, यानी सैंडबॉक्स कमांड, से जाँचें। यदि तीसरे पक्ष का कोड समीक्षा करते हैं, तो उन परियोजनाओं को उनकी परियोजना कॉन्फ़िगरेशन में :read-only से बनी प्रोफ़ाइल पर बाँधें।

3. इस महीने: यदि एजेंट रनटाइम बना रहे हैं या किसी को लपेट रहे हैं, तो टर्न को अनुमति इकाई बनाएँ: टर्न शुरू होते समय स्नैपशॉट, टर्न खत्म होते समय समाप्ति, रहस्य मॉडल संदर्भ के बाहर, और ऐसा प्रवर्तन जो सुरक्षित रूप से विफल हो। फिर उस खुले सवाल का अपना जवाब लिखें जिसे Codex खुद अभी हल नहीं कर पाया: बीच टर्न अनुमतियाँ बदलें तो क्या होना चाहिए? "अगले टर्न तक कुछ नहीं" सुरक्षित है, लेकिन उपयोगकर्ता उम्मीद करेंगे कि UI जो कहता है वही सच हो।

अक्सर पूछे जाने वाले सवाल

टर्न-सीमित अनुमतियाँ क्या हैं?

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

यह एजेंट को प्रतिबंधित OS उपयोगकर्ता के रूप में चलाने से कैसे अलग है?

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

क्या प्रॉम्प्ट इंजेक्शन Codex की अनुमतियाँ बदल सकता है?

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

क्या अनुमति प्रोफ़ाइल भरोसे लायक स्थिर हैं?

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

निष्कर्ष

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

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

स्रोत

• OpenAI Developers, "Codex अनुमतियाँ": https://developers.openai.com/codex/permissions (देखा 2026-08-29)

• OpenAI Developers, "एजेंट मंजूरियाँ और सुरक्षा": https://developers.openai.com/codex/agent-approvals-security (देखा 2026-08-29)

• GitHub, openai/codex मुद्दा #32612, "चल रहे टर्न पर पहुँच-नियंत्रण बदलाव लागू करें": https://github.com/openai/codex/issues/32612 (दर्ज 2026-07-12, देखा 2026-08-29)

• GitHub, openai/codex मुद्दा #23626, "Codex CLI /permissions WSL2 में केवल-पढ़ने योग्य विकल्प छोड़ देता है लेकिन Windows PowerShell में दिखाता है": https://github.com/openai/codex/issues/23626 (दर्ज 2026-05-20, देखा 2026-08-29)

• OpenAI Codex रिपॉजिटरी: https://github.com/openai/codex (देखा 2026-08-29)