आप किसी मौजूदा प्रोजेक्ट की संरचना या बग की जाँच करना चाहते हैं, लेकिन उसका कोड बदलवाना, सेटिंग बदलवाना या सॉफ़्टवेयर इंस्टॉल करवाना नहीं चाहते। इसके लिए जाँच का निर्देश और बदलावों को सीमित करने वाली अनुमतियाँ, दोनों तैयार करें। Codex का केवल पढ़ने वाला सैंडबॉक्स और Claude Code का Plan मोड मिलते-जुलते उद्देश्यों के लिए हैं, लेकिन इनके काम करने का तरीका अलग है।
पढ़ें → प्रमाण दिखाएँ → सुझाव प्राप्त करें
Codex
read-only और मंज़ूरी नीति जाँचेंऐप और IDE में सेटिंग तथा बातचीत में दिखाई गई अनुमतियाँ जाँचें। CLI में स्थानीय कमांड के लिखने की क्षमता सीमित करने के लिए स्टार्टअप विकल्प इस्तेमाल करें।
Claude Code
Plan से शुरू करें; ज़रूरत हो तो टूल सीमित करेंजाँच और योजना बनाएँ; आम तौर पर सोर्स कोड में बदलाव ब्लॉक होते हैं। जाँचें कि शुरुआत में बाइपास उपलब्ध है या नहीं और कौन-सी कमांड तथा बाहरी टूल अब भी उपलब्ध हैं।
9 अक्टूबर 2026 को OpenAI और Anthropic के आधिकारिक दस्तावेज़ों से पुष्टि की गई। इस लेख के स्टार्टअप उदाहरण किसी वास्तविक कंप्यूटर पर चलाकर नहीं जाँचे गए हैं। हमने दस्तावेज़ों में बताए गए व्यवहार को उन स्थितियों से अलग रखा है जिन्हें आपको अपने परिवेश में जाँचना होगा।
सेटिंग स्क्रीन और साझा कॉन्फ़िगरेशन जाँचें। मंज़ूरी मेनू के साथ फ़ाइलों में लिखने की पाबंदियाँ भी जाँचें।
इंटरफ़ेस में Plan चुनें। अलग से जाँचें कि नई बातचीत भी Plan में शुरू होती है या नहीं।
देखें: Codex CLI, Claude Code CLI या वेब और मोबाइल पर Claude। यह भी जाँचें कि काम वास्तव में कहाँ चल रहा है।
1. निर्देश और अनुमति की पाबंदियाँ
“लॉगिन प्रक्रिया की समस्याओं की जाँच करो” जैसे अनुरोध में अस्पष्टता रहती है: एजेंट मिली समस्या ठीक करे या रिपोर्ट देकर रुक जाए? “कोई बदलाव मत करो” आपकी मंशा बताता है, लेकिन इससे एडिटिंग टूल या शेल की लिखने की क्षमता हटती नहीं है।
काम की मंशा और उसे रोकने वाले नियंत्रण अलग रखें
निर्देश
आप उससे क्या करवाना चाहते हैंस्पष्ट करें: “केवल जाँच और सुझाव दो। लागू मत करो।” रिपोर्ट का प्रारूप और काम पूरा होने की शर्त तय करें।
उत्पाद की अनुमतियाँ
वह कौन-से टूल इस्तेमाल कर सकता हैलागू करने वाली कार्रवाइयों को Plan या टूल की पाबंदियों से सीमित करें। जाँचें कि मंज़ूरी या मोड बदलने से यह दायरा कब बढ़ सकता है।
काम चलने का परिवेश
लिखने के स्थानों की सुरक्षा कैसे होती हैवास्तविक लेखन को सीमित करने के लिए सैंडबॉक्स या ऑपरेटिंग सिस्टम की अनुमतियाँ इस्तेमाल करें। जाँचें कि किन प्रक्रियाओं पर ये लागू हैं और क्या अपवाद हैं।
Claude Code के दस्तावेज़ बताते हैं कि निर्देश और CLAUDE.md यह प्रभावित करते हैं कि मॉडल क्या करने की कोशिश करता है, जबकि अनुमति प्रणाली तय करती है कि कौन-सी कार्रवाइयाँ अनुमत हैं। Codex की AGENTS.md में मनाही लिखने पर भी निर्देशों और वास्तविक अनुमतियों के बीच यही अंतर रखें। स्रोत: Claude Code की अनुमतियाँ।
2. Codex: ऐप, IDE और CLI की सेटिंग
Desktop: Settings में लिखने की पाबंदियाँ जाँचें
डेस्कटॉप ऐप के मेनू से Settings → Configuration खोलें। Windows पर सेटिंग का शॉर्टकट Ctrl+, और macOS पर Cmd+, है। आधिकारिक Configuration स्क्रीन पर Approval policy और Sandbox settings अलग-अलग दिखाए जाते हैं। भाषा और संस्करण के अनुसार नाम बदल सकते हैं।
मंज़ूरी और लिखने की अनुमति अलग-अलग जाँचें
यदि Sandbox settings में Workspace write दिखता है, तो वर्कस्पेस में लिखना अनुमत है। केवल जाँच के लिए read-only जैसी पाबंदियाँ लागू हैं या नहीं, यह देखें।
Approval policy तय करती है कि पाबंदियों के बाहर काम चलाने की माँग कैसे संभाली जाती है। केवल मंज़ूरी माँगना वर्कस्पेस के भीतर बदलाव करने पर रोक नहीं लगाता।
अनुरोध भेजने से पहले इनपुट बॉक्स के नीचे अनुमति नियंत्रण और सक्रिय सेटिंग जाँचें। पहले से कोई काम चल रहा हो तो उसे पहले रोकें।
स्रोत: आधिकारिक Configuration स्क्रीन, सेटिंग खोलना, इनपुट बॉक्स के नीचे अनुमति नियंत्रण।
इंटरफ़ेस स्पष्ट न हो तो Open config.toml इस्तेमाल करें
कॉन्फ़िगरेशन फ़ाइल खोलने के लिए Settings → Configuration → Open config.toml चुनें। उपयोगकर्ता की सेटिंग आम तौर पर ~/.codex/config.toml में होती हैं। पुराने सैंडबॉक्स सेटिंग तरीके में ये मान केवल पढ़ने की पहुँच और अतिरिक्त मंज़ूरी न माँगने वाली नीति चुनते हैं। यह कॉन्फ़िगरेशन का उदाहरण है; लेख पढ़ने से आपकी सेटिंग नहीं बदलती।
sandbox_mode = "read-only"
approval_policy = "never"उपयोगकर्ता की सेटिंग उसी कॉन्फ़िगरेशन को पढ़ने वाले ऐप, IDE एक्सटेंशन और CLI को भी प्रभावित करती हैं। विश्वसनीय प्रोजेक्ट की .codex/config.toml में मौजूद सेटिंग, स्टार्टअप विकल्प और प्रबंधित नीतियाँ भी लागू हो सकती हैं। इसलिए केवल ये दो पंक्तियाँ मिल जाने से साबित नहीं होता कि वे सक्रिय हैं। CLI में /status और /debug-config काम चलने की शर्तें और सेटिंग का स्रोत दिखा सकते हैं। स्थायी सेटिंग बदले बिना एक सत्र के लिए जाँच करनी हो तो नीचे दिया CLI उदाहरण इस्तेमाल करें।
नया Permission profiles फ़ीचर बीटा में है और कॉन्फ़िगरेशन का एक और तरीका देता है, जिसमें अंतर्निहित :read-only प्रोफ़ाइल भी है। इसे पुराने sandbox_mode या --sandbox सेटिंग के साथ मिलाने पर पुरानी सेटिंग को प्राथमिकता मिल सकती है; प्रबंधित नीतियों के भी अपवाद हैं। दोनों जोड़ने से पहले जाँचें कि आप कौन-सा तरीका इस्तेमाल कर रहे हैं। स्रोत: कॉन्फ़िगरेशन फ़ाइल खोलना, कॉन्फ़िगरेशन की प्राथमिकता, Permission profiles।
Ask for approval बदलाव करने पर रोक नहीं लगाता
इनपुट बॉक्स के नीचे Ask for approval चुनने से अनुमत वर्कस्पेस में अपने-आप काम करने की अनुमति रहती है। Approve for me उपयुक्त मंज़ूरी अनुरोधों को स्वचालित समीक्षा में भेजता है। इनमें से किसी को चुनने से वर्कस्पेस केवल पढ़ने योग्य नहीं बनता। Full access भी केवल जाँच की पाबंदी के लिए उपयुक्त नहीं है।
Codex में /plan भी है, जिससे लागू करने से पहले योजना माँग सकते हैं। लेकिन योजना माँगने और फ़ाइल में लिखने की पाबंदियों को अलग-अलग जाँचें। केवल नाम समान होने के कारण यह न मानें कि Claude Code के Plan की एडिटिंग पाबंदियाँ या अपवाद Codex पर भी लागू हैं। स्रोत: Codex /plan।
IDE एक्सटेंशन: गियर आइकन से Codex Settings खोलें
Codex साइडबार के ऊपर गियर आइकन → Codex Settings से साझा सेटिंग जाँचें और विस्तार के लिए Open config.toml खोलें। इनपुट बॉक्स के नीचे अनुमति नियंत्रण भी जाँचें। एडिटर की एक्सटेंशन सेटिंग उस config.toml से अलग हैं जिसे एजेंट पढ़ता है। IDE context बंद करने से, जो खुली फ़ाइलें उपलब्ध कराता है, एजेंट की फ़ाइल पढ़ने की अनुमति रद्द नहीं होती। स्रोत: हर क्लाइंट की डेवलपर सेटिंग।
CLI: इस सत्र के लिए विकल्प तय करें
यदि Codex CLI पहले से उपलब्ध है, तो जिस फ़ोल्डर की जाँच करनी है उसमें टर्मिनल खोलकर ऐसे शुरू करें। कॉन्फ़िगरेशन फ़ाइल को स्थायी रूप से बदलने की ज़रूरत नहीं है। आपकी संस्था की प्रबंधित नीतियों और CLI संस्करण की क्षमताओं को तब भी प्राथमिकता मिलेगी।
codex --sandbox read-only --ask-for-approval never--sandbox read-only
लिखने की पाबंदियाँ चुनेंउपलब्ध फ़ाइलें पढ़ें और केवल पढ़ने वाले सैंडबॉक्स के भीतर कमांड चलाएँ।
--ask-for-approval never
पाबंदियों के भीतर बिना पूछे काम करेंअतिरिक्त मंज़ूरी न माँगें। पाबंदियाँ बढ़ाकर आगे बढ़ने के बजाय एजेंट से वे कार्रवाइयाँ बताने को कहें जो वह नहीं कर सकता।
never का मतलब पूरी पहुँच नहीं है। सैंडबॉक्स का प्रकार और मंज़ूरी नीति अलग सेटिंग हैं। OpenAI की आधिकारिक संयोजन तालिका में इन पाबंदियों के भीतर फ़ाइलें पढ़ने और कमांड चलाने के लिए read-only के साथ never शामिल है। स्रोत: एजेंट की मंज़ूरी और सुरक्षा।
on-request से अंतर
विकल्प --ask-for-approval on-request के साथ एजेंट ऐसी कार्रवाई की मंज़ूरी माँग सकता है जिसे सैंडबॉक्स के बाहर चलाना हो। केवल पढ़ने की पहुँच से शुरुआत करने पर भी ऐसे निष्पादन की मंज़ूरी मूल सीमा बदल देती है। “ज़रूरत हो तो बदलाव से पहले पूछो” और “इस बार कोई बदलाव मत करो” अलग नीतियाँ हैं।
जाँच के दौरान किन कार्रवाइयों से बचें
केवल किसी त्रुटि को दूर करने के लिए Full access न चुनें, लिखने की अनुमति वाला प्रोफ़ाइल न चुनें और पाबंदियों के बाहर निष्पादन मंज़ूर न करें। केवल जाँच वाले काम में किसी जाँच को न किया गया बताना उपयुक्त नतीजा हो सकता है।
Web, Cloud और Remote: देखने वाले डिवाइस और निष्पादन परिवेश में अंतर रखें
वेब पर काम एक प्रबंधित निष्पादन परिवेश में चलता है और आपकी स्थानीय Codex कॉन्फ़िगरेशन फ़ाइल नहीं पढ़ता। अपने PC पर ऊपर की दो पंक्तियाँ जोड़ने से अकेले Cloud का निष्पादन केवल पढ़ने योग्य नहीं बनता। Cloud इंटरफ़ेस और वर्कस्पेस के नियंत्रण जाँचें। हमने पूरे Cloud को केवल पढ़ने योग्य बनाने वाले समान स्टार्टअप तरीके की पुष्टि नहीं की है।
Remote से किसी दूसरे इंटरफ़ेस पर PC में चल रहा काम देखने पर, उस मशीन की सेटिंग मायने रखती हैं जो वास्तव में कमांड चला रही है। केवल देखने वाले डिवाइस की पाबंदियों पर भरोसा न करें। देखें: Codex को स्थानीय रूप से, Remote से या Cloud में कब इस्तेमाल करें। स्रोत: वेब और स्थानीय सेटिंग का अंतर।
3. Claude Code से केवल जाँच और योजना बनवाएँ
Claude Desktop: Code टैब में भेजने के बटन के पास Plan चुनें
ये निर्देश Claude Desktop के Code टैब के लिए हैं। Chat और Cowork की सेटिंग, Claude Code के अनुमति मोड जैसी नहीं हैं। नीचे मोड के नाम आधिकारिक अंग्रेज़ी दस्तावेज़ों के अनुसार दिए गए हैं; इंटरफ़ेस में दिखने वाले नाम प्रदर्शन की भाषा और संस्करण के अनुसार अलग हो सकते हैं।
भेजने से पहले निष्पादन परिवेश और Plan जाँचें
जाँचें कि Environment में Local, Cloud, SSH या WSL में से क्या चुना है और Project folder वही फ़ोल्डर है जिसकी जाँच करना चाहते हैं।
Manual में मंज़ूरी के बाद बदलाव किए जा सकते हैं; Accept edits बदलावों को अपने-आप मंज़ूर करता है। केवल जाँच के लिए Plan चुनें।
नीचे दिया निर्देश भेजें, योजना पढ़ें और रुक जाएँ। आगे जाँच करते समय भी Plan चुना रहने दें।
चयन नियंत्रण में चुना गया Plan केवल उसी सत्र पर लागू होता है। दूसरे मोड का चुनाव हर फ़ोल्डर के लिए याद रखा जाता है और सेटिंग फ़ाइल के permissions.defaultMode पर प्राथमिकता पाता है। यदि नई बातचीत भी केवल जाँच के लिए होनी चाहिए, तो हर बार Plan दिखना जाँचें। CLI जैसी सेटिंग फ़ाइल पढ़ने का मतलब यह नहीं है कि बातचीत का मोड अगले सत्र में भी बना रहेगा। स्रोत: Desktop के अनुमति मोड और चुनाव का बने रहना।
VS Code: इनपुट बॉक्स के नीचे मोड संकेतक से Plan चुनें
Claude Code का चैट पैनल खोलें और इनपुट बॉक्स के नीचे मोड संकेतक → Plan चुनें। v2.1.280 से पैनल में /plan भेजकर भी मोड बदल सकते हैं। यदि योजना Markdown दस्तावेज़ के रूप में खुलती है, तो उसे जाँच का परिणाम समझकर पढ़ें और लागू करने की मंज़ूरी न दें।
नई बातचीत भी Plan में शुरू करने के लिए
- VS Code की सेटिंग खोलें (Windows/Linux पर Ctrl+,; macOS पर Cmd+,)
- Extensions → Claude Code में उपयोगकर्ता की यह सेटिंग जाँचें:
claudeCode.initialPermissionMode - यदि शुरुआत Plan से करना चाहते हैं, तो उपयोगकर्ता की इस सेटिंग का मान
planकरें - नई बातचीत खोलें और जाँचें कि उसमें वास्तव में Plan दिखता है
वर्तमान आधिकारिक विनिर्देश के अनुसार, वर्कस्पेस की claudeCode.initialPermissionMode सेटिंग को अनदेखा किया जाता है। यह v2.1.225 से पहले के व्यवहार से अलग है। चैट में Plan चुनने का असर भी केवल उसी बातचीत पर होता है। यह न मानें कि प्रोजेक्ट की permissions.defaultMode सेटिंग को .claude/settings.json में रखने से VS Code का शुरुआती मोड ज़रूर बदल जाएगा। एक्सटेंशन के शुरुआती मोड की सेटिंग, पिछले चुने गए सामान्य मोड, प्रबंधित सेटिंग, उपयोगकर्ता की सेटिंग और अन्य लागू कॉन्फ़िगरेशन के बीच प्राथमिकता जाँचें।
बिना सहेजी गई फ़ाइलों का भी ध्यान रखें। एक्सटेंशन की claudeCode.autosave सेटिंग Claude के पढ़ने या लिखने से पहले एडिटर के बदलाव सहेजती है। AI द्वारा सोर्स में किए गए बदलाव और एडिटर द्वारा सहेजी गई फ़ाइलों में अंतर रखें। खुली फ़ाइलों को अपने-आप जोड़ना भी फ़ाइल पहुँच की पाबंदी से अलग है। स्रोत: VS Code के मोड नियंत्रण, एक्सटेंशन सेटिंग और प्राथमिकता।
वेब, मोबाइल और JetBrains के नियंत्रण
इनपुट बॉक्स के पास मोड मेनू से Plan चुनें। Cloud में Accept edits और Plan उपलब्ध हैं। Auto के लिए संस्था की अनुमति और समर्थित मॉडल चाहिए; Bypass permissions उपलब्ध नहीं है।
Claude Code की बातचीत में इनपुट बॉक्स के “+” → Permission से मोड चुनें। Remote Control में इससे आपकी स्थानीय मशीन पर सक्रिय सत्र की अनुमतियाँ भी बदलती हैं।
प्लगइन IDE के टर्मिनल में CLI इस्तेमाल करता है। नीचे दिए CLI उदाहरण और Shift+Tab इस्तेमाल करें; VS Code की विशिष्ट सेटिंग के नाम यहाँ न दोहराएँ।
Cloud में सामान्य फ़ाइल बदलाव पहले से मंज़ूर होते हैं, इसलिए उसे Manual जैसा न समझें। जाँच के लिए स्पष्ट रूप से Plan चुनें और एजेंट को लागू करने के बजाय रिपोर्ट देकर रुकने का निर्देश दें। Cloud में बदलावों की मंज़ूरी का तरीका यह नहीं बताता कि Plan में सोर्स फ़ाइलें बिना किसी शर्त के दोबारा लिखी जा सकती हैं। स्रोत: इंटरफ़ेस के अनुसार मोड बदलना, Cloud के मोड।
CLI: Plan से शुरू करें और लागू करने की मंज़ूरी न दें
इस विकल्प से Claude Code CLI को Plan मोड में शुरू करें। सामान्य Plan फ़ाइलें पढ़ता है, संरचना और समस्याओं की जाँच करता है और प्रस्तावित बदलावों की योजना बनाता है। सोर्स एडिटिंग टूल से बदलाव आम तौर पर ब्लॉक होते हैं, लेकिन योजना की फ़ाइलें बनती हैं।
claude --permission-mode planजाँच के परिणाम मिलने पर रुक जाएँ
इंटरैक्टिव टर्मिनल में Shift+Tab से मोड बदलते हैं। यह भी जाँचें कि स्टार्टअप कॉन्फ़िगरेशन में बाइपास उपलब्ध है या नहीं।
काम का अंत लक्षित फ़ाइलों और पंक्ति संख्याओं वाली रिपोर्ट से तय करें, एडिटिंग या बिल्ड से नहीं।
योजना पढ़ें या जाँच जारी रखने के लिए No, keep planning चुनें। Yes वाले विकल्प Plan से बाहर जाकर लागू करने की प्रक्रिया शुरू कर सकते हैं।
Plan में शेल कमांड हमेशा केवल पढ़ने वाली कमांड तक सीमित नहीं होतीं। यदि auto मोड उपलब्ध है और useAutoModeDuringPlan चालू है, तो एक वर्गीकरण प्रणाली उनकी समीक्षा कर उन्हें अनुमति दे सकती है। auto उपलब्ध न होने जैसी स्थितियों में, अंतर्निहित केवल पढ़ने वाली कमांड के समूह से बाहर की कमांड के लिए मंज़ूरी चाहिए। स्रोत: Permission modes में Plan।
कुछ शर्तों में Plan में भी एडिटिंग की रोक लागू नहीं होती
आधिकारिक दस्तावेज़ों के अनुसार, Plan की एडिटिंग और कमांड वाली पाबंदियाँ बाइपास उपलब्ध होने वाले इंटरैक्टिव टर्मिनल सत्रों में लागू नहीं होतीं। इंटरफ़ेस में Plan दिखने पर भी बदलाव के प्रयास या कमांड चल सकती हैं। केवल Plan संकेतक पर भरोसा करने के बजाय बाइपास सक्षम करने वाले स्टार्टअप विकल्प और सेटिंग जाँचें। -p, SDK और VS Code चैट पैनल के लिए अलग विवरण हैं; इस अपवाद को हर इंटरफ़ेस पर लागू न मानें। स्रोत: bypassPermissions।
यदि शेल कमांड और एडिटिंग टूल, दोनों नहीं चाहिए
यदि कोड पढ़ना और संरचना की जाँच करना काफ़ी है, तो अंतर्निहित टूल सीमित करने के लिए --tools इस्तेमाल करें। यह उदाहरण फ़ाइल जाँच के टूल Read, Glob और Grep तक सीमित करता है और MCP टूल भी रोकता है। बातचीत समाप्त करने के लिए EndConversation उपलब्ध रहता है। इससे सामान्य Plan की तुलना में जाँच की क्षमता कम हो जाती है: कमांड चलाने वाली जाँच उपलब्ध नहीं रहतीं।
claude --permission-mode plan --tools "Read,Glob,Grep" --disallowedTools "mcp__*"यहाँ इसकी जगह --allowedTools इस्तेमाल न करें। वह विकल्प बिना पुष्टि वाले टूल तय करता है; उपलब्ध टूल को केवल उस सूची तक सीमित नहीं करता। साथ ही, अकेले --tools से MCP सीमित नहीं होता, इसलिए अलग विकल्प चाहिए। स्रोत: CLI संदर्भ।
Desktop में CLI के --allowedTools या --disallowedTools जैसे सत्र-स्तर के UI नियंत्रण नहीं हैं। सेटिंग फ़ाइलों में अनुमति नियम लागू होते हैं, लेकिन केवल Plan बटन इस टूल-सीमित उदाहरण जैसी पाबंदियाँ नहीं बनाता। स्रोत: Desktop और CLI की क्षमताएँ।
यह उदाहरण आपके पूरे PC को केवल पढ़ने योग्य नहीं बनाता, जिसमें ऐप का सहेजा डेटा या लोड की गई सेटिंग और हुक भी शामिल हैं। अनजान प्रोजेक्ट खोलते समय मौजूदा हुक, प्लगइन और बाहरी कनेक्शन अलग से जाँचें। अधिक सख़्त उपयोग के लिए --restricted, जो v2.1.248 से उपलब्ध है, टूल के अलावा और चीज़ें भी बदलता है: उदाहरण के लिए, कौन-सी सेटिंग लोड होगी। यह सामान्य परिवेश को बिना बदले इस्तेमाल करने वाले Plan का दूसरा नाम नहीं है।
टूल की अनुमतियों के नियमित प्रबंधन के लिए देखें: Claude Code की allow, ask और deny सेटिंग। Bash को अलग परिवेश में रखने के लिए देखें: सैंडबॉक्स कॉन्फ़िगरेशन और उसकी सीमाएँ। ऐसी अलगाव व्यवस्था जिसमें वर्कस्पेस में लिखना पहले से अनुमत है, केवल जाँच वाले उपयोग से अलग उद्देश्य पूरा करती है।
4. सीधे इस्तेमाल करने योग्य जाँच का निर्देश
अनुमतियाँ तय करने के बाद एजेंट को रिपोर्ट देकर रुकने के लिए कहें। “इसे ठीक करो” या “इसे बेहतर बनाओ” से अधिक स्पष्ट रूप से जाँच का दायरा और काम पूरा करने वाला परिणाम तय करने से लागू करने तक ले जाने वाली गलतफ़हमियाँ कम होती हैं।
इस काम में केवल वर्तमान स्थिति की जाँच करो और सुझाव दो। कुछ लागू मत करो।
दायरा: इस प्रोजेक्ट की लॉगिन प्रक्रिया और प्राधिकरण की सीमाएँ।
अनुमत: उपलब्ध सोर्स फ़ाइलें पढ़ना और संरचना तथा समस्याएँ समझाना।
मनाही: फ़ाइलें बनाना, बदलना या हटाना; सेटिंग बदलना; निर्भरताएँ जोड़ना;
बिल्ड, परीक्षण, डेटाबेस कार्रवाइयाँ, कमिट, पुश, डिप्लॉयमेंट
या बाहरी सेवाओं में बदलाव।
हुक या स्क्रिप्ट चलाने के लिए अनुमतियाँ न बढ़ाओ।
देने वाले परिणाम:
1. जाँच की गई फ़ाइलों और पंक्ति संख्याओं के साथ प्रक्रिया का प्रवाह
2. हर संभावित समस्या के प्रमाण, प्रभाव और प्राथमिकता
3. बिना लागू किए सुधार के सुझाव और लागू करने से पहले आवश्यक जाँच
4. ऐसे सवाल जो केवल पढ़कर हल नहीं हो सकते और ऐसी जाँच जो नहीं की गई
बदलाव आवश्यक हो तब भी सुझाव देकर रुक जाओ; उसे लागू मत करो।
जाँच की रिपोर्ट देने के बाद काम समाप्त करो।“सहेजी गई जानकारी गायब होने की संभावित वजहों की जाँच, सेव करने, लोड करने और अपवाद सँभालने का कोड पढ़कर करो।” यदि लॉग में गोपनीय जानकारी है, तो पहले तय करें कि क्या साझा कर सकते हैं।
“मॉड्यूल की निर्भरताएँ समझाओ और मिलती-जुलती ज़िम्मेदारियाँ पहचानो।” परिणामों में वास्तविक रीफ़ैक्टरिंग शामिल न करें।
“स्वामित्व की जाँच, प्रमाणीकरण, प्राधिकरण और इनपुट सत्यापन पढ़ो।” आक्रमण वाला कोड चलाना या प्रोडक्शन पर अनुरोध भेजना अलग काम मानें।
सुझाए गए सुधार से सहमत होने पर भी जाँच वाली बातचीत में कह सकते हैं: “इसे संभावित तरीका मानकर रखो। लागू मत करो।” आगे बढ़ने के लिए बदलाव, परीक्षण और प्रकाशन के नए दायरे तय करके अलग विकास वाली बातचीत शुरू करें। इससे जाँच की पाबंदियाँ काम के उद्देश्य के अनुरूप रहती हैं।
5. जाँच से पहले और बाद में क्या देखें
“मॉडल ने कहा कि उसने कुछ नहीं बदला” पर सत्यापन समाप्त न करें। फ़ाइलों में बदलाव न हुआ हो, यह जाँचने के लिए सुरक्षित रखने वाले सोर्स में लिखने की कोशिश करने की भी ज़रूरत नहीं है। इंटरफ़ेस, कॉन्फ़िगरेशन के विवरण और मौजूदा अंतर से शुरू करें और बाकी अनिश्चितताएँ दर्ज करें।
पहले: उद्देश्य और निष्पादन की शर्तें मिलाएँ
- लक्षित फ़ोल्डर और एजेंट की पढ़ सकने वाली जानकारी जाँचें
- Codex में फ़ाइल की अनुमतियाँ और मंज़ूरी नीति; Claude Code में Plan और बाइपास की स्टार्टअप शर्तें जाँचें
- जाँचें कि नई बातचीत में वही मोड रहता है या नहीं और साझा सेटिंग दूसरे क्लाइंट को प्रभावित करती हैं या नहीं
- जाँच के दौरान अनुमत कार्रवाइयाँ तय करें, जिनमें शेल, MCP, ब्राउज़र और बाहरी ऐप शामिल हैं
- अपने पहले से मौजूद बिना कमिट वाले बदलाव और अनट्रैक की गई फ़ाइलें पहचानें और तुलना के लिए शुरुआती स्थिति दर्ज करें
- रिपोर्ट देना काम पूरा होने की शर्त बनाएँ और अनुमति से ब्लॉक हुई जाँच को न किया गया बताना आवश्यक करें
प्रोजेक्ट में Git हो तो अंतर की तुलना करें
उदाहरण के लिए, ये कमांड बदली फ़ाइलें तथा स्टेज किए और बिना स्टेज किए अंतर का सारांश दिखाती हैं। जाँच से पहले और बाद में दोनों देखें, ताकि आप अपने पुराने बदलावों को AI के बदलाव न समझ लें। इस उदाहरण में माना गया है कि लक्षित रिपॉज़िटरी पहले से Git इस्तेमाल करती है।
git status --short
git diff --stat
git diff --cached --statये कमांड यह साबित नहीं करतीं कि कहीं भी कुछ नहीं बदला। git diff अनट्रैक की गई फ़ाइलें नहीं दिखाता और ये जाँच सभी अनदेखी फ़ाइलों, वर्कस्पेस से बाहर के स्थानों, डेटाबेस या बाहरी सेवाओं को नहीं देखतीं। आख़िरी अंतर से ऐसी कार्रवाई भी नहीं दिखती जिसमें बदलाव करके उसे वापस बहाल कर दिया गया हो। रिपोर्ट में जाँचे गए और न जाँचे गए दायरे अलग रखें। आधिकारिक Git दस्तावेज़: git status, git diff।
बाद में: रिपोर्ट को निष्कर्ष मानकर पढ़ें, लागू किए गए सुधार नहीं
- क्या हर संभावित समस्या में फ़ाइलें, पंक्ति संख्याएँ और कोड से प्रमाण हैं?
- क्या स्थिर कोड पढ़कर निकले निष्कर्ष, वास्तव में समस्या दोहराने या परीक्षण के परिणामों से अलग हैं?
- क्या जाँच से पहले और बाद के अंतर में कोई अस्पष्ट बदलाव है?
- क्या अपर्याप्त अनुमति या निष्पादन की मनाही से रुकी जाँच स्पष्ट रूप से सूचीबद्ध है?
- क्या अगले कदम अब भी सुझाव हैं और अपने-आप शुरू नहीं हुए हैं?
6. जो जाँच नहीं चला सकते और बाकी जोखिम
परीक्षण और बिल्ड भी फ़ाइलें लिख सकते हैं
कोड बदले बिना भी परीक्षण अस्थायी फ़ाइलें या स्नैपशॉट लिख सकते हैं, बिल्ड आउटपुट बना सकते हैं और पैकेज मैनेजर कैश या निर्भरताएँ लिख सकते हैं। यह न मानें कि “केवल परीक्षण चलाने” से कुछ नहीं बदलता। केवल पढ़ने की पाबंदियों में विफलता बग के बजाय उन पाबंदियों का अपेक्षित परिणाम हो सकती है।
यदि रिपोर्ट बताती है कि कुछ परिस्थितियों में प्राधिकरण को बाइपास किया जा सकता है, तो अगला कदम अलग सत्यापन परिवेश में समस्या दोहराने की योजना हो सकता है। जाँच बेहतर बनाने के लिए प्रोडक्शन डेटाबेस या गोपनीय जानकारी वाले कंप्यूटर पर तुरंत लिखने की अनुमति देना ज़रूरी नहीं है। स्थिर जाँच से साबित होने वाली बातों को निष्पादन माँगने वाली बातों से अलग करना रिपोर्ट को निर्णय लेने के लिए अधिक उपयोगी बनाता है।
केवल सोर्स में लिखने की रोक इन हिस्सों की सुरक्षा नहीं करती
एजेंट जिस जानकारी को पढ़ सकता है, वह उसकी जाँच में इस्तेमाल हो सकती है। केवल पढ़ने की पहुँच और गोपनीय फ़ाइलों को पढ़ने से रोकना अलग नियंत्रण हैं।
MCP या जुड़े ऐप टिकट, रिपॉज़िटरी और दूसरे संसाधन बदल सकने की क्षमता रख सकते हैं। केवल स्थानीय पाबंदियों से साबित नहीं होता कि हर रास्ता बंद है।
बातचीत और योजनाएँ सहेजना, लक्षित सोर्स फ़ाइलों को बदलने से अलग है। ये स्टार्टअप उदाहरण PC पर हर लेखन समाप्त नहीं करते।
Codex की नेटवर्क पाबंदियाँ भी सैंडबॉक्स वाली कमांड के संचार को मॉडल, प्रमाणीकरण और दूसरे उद्देश्यों के सेवा ट्रैफ़िक से अलग रखती हैं। केवल पढ़ने की पहुँच से शुरुआत यह गारंटी नहीं देती कि पढ़ी गई जानकारी मॉडल को नहीं भेजी जाएगी या प्रशिक्षण में इस्तेमाल नहीं होगी। स्रोत: Permissions का दायरा। गोपनीय जानकारी पढ़ने से रोकने के लिए देखें: Codex में गोपनीय फ़ाइलें और अनुमतियाँ। प्रशिक्षण और डेटा रखने की सेटिंग के लिए देखें: ChatGPT और Codex में प्रशिक्षण का उपयोग और गोपनीयता।
जब पाबंदियाँ उम्मीद के अनुसार काम न करें
- सेटिंग नहीं मिलती: अपना उत्पाद, संस्करण, निष्पादन परिवेश और संस्था की प्रबंधित पाबंदियाँ जाँचें। ऐसी सेटिंग न चुनें जो इन पाबंदियों को बाइपास करती हों।
- परीक्षण विफल होता है: ज़रूरी लेखन और कोड की समस्या में अंतर करें। न की गई जाँच रिपोर्ट में रखें।
- आपने बीच में पाबंदियाँ जोड़ीं: पहले से किए गए बदलाव वापस नहीं होते। चल रहा काम रोकें, अंतर जाँचें और फिर जाँच वाली नई बातचीत शुरू करें।
सारांश
Codex में read-only और मंज़ूरी नीति तय करें। Claude Code में Plan की स्टार्टअप शर्तें जाँचें और ज़रूरत हो तो उपलब्ध टूल सीमित करें। फिर ऐसा निर्देश दें जिसमें रिपोर्ट देने पर काम समाप्त हो जाए। दोनों टूल में जाँच और बदलाव लागू करना अलग रखा जा सकता है।
यदि सख़्त पाबंदियों में कुछ सवाल हल नहीं होते, तो आसानी से पूरी पहुँच चुनने के बजाय न की गई जाँच की सूची और आगे सत्यापन का प्रस्ताव स्वीकार करें। पढ़ने योग्य जानकारी, बाहरी टूल और ऐप के सहेजे डेटा के नियंत्रण, सोर्स बदलने की मनाही से अलग तय करने होते हैं।
अक्सर पूछे जाने वाले सवाल
क्या “केवल जाँच करो” कहने से एजेंट केवल पढ़ने तक सीमित हो जाता है?
इससे उद्देश्य पता चलता है, लेकिन वास्तविक एडिटिंग क्षमता या कमांड की अनुमतियाँ नहीं बदलतीं। निर्देश के साथ Codex का सैंडबॉक्स या Claude Code का Plan और टूल की पाबंदियाँ इस्तेमाल करें और जाँचें कि वे वास्तव में क्या सीमित करती हैं।
क्या Claude Code का Plan गारंटी देता है कि कोई फ़ाइल नहीं बदलेगी?
नहीं। आम तौर पर वह सोर्स में बदलाव रोकता है, लेकिन योजना की फ़ाइलें बनाता है। आधिकारिक दस्तावेज़ यह भी बताते हैं कि बाइपास उपलब्ध वाले इंटरैक्टिव टर्मिनल सत्रों में Plan की पाबंदियाँ लागू नहीं होतीं। यह PC पर हर लेखन रोकने वाला मोड नहीं है।
क्या Codex की “never” मंज़ूरी नीति का मतलब बिना पाबंदी की पहुँच है?
इसका मतलब मंज़ूरी अनुरोध न करना है; यह सैंडबॉक्स बंद नहीं करती। read-only के साथ एजेंट उन पाबंदियों के भीतर जाँच करता है। इसे पूरी पहुँच के साथ शुरू करने से अलग समझें।
क्या केवल पढ़ने वाली जाँच से सुरक्षा समीक्षा पूरी हो जाती है?
नहीं। सोर्स पढ़कर मिली संभावित समस्याएँ, वास्तव में चलाकर दोहराए गए परिणामों से अलग हैं। यदि कॉन्फ़िगरेशन, रनटाइम परिवेश या निर्भर सेवाएँ नहीं जाँच सकते, तो निष्कर्ष सीमित रहेंगे। प्रमाण और अज्ञात बातें बताएँ तथा आवश्यक प्रदर्शन की योजना अलग सत्यापन परिवेश में बनाएँ।
क्या Codex ऐप में Ask for approval एडिटिंग रोकता है?
अकेले नहीं। मंज़ूरी नीति और फ़ाइल में लिखने की पाबंदियाँ अलग हैं। Configuration और सक्रिय अनुमतियाँ जाँचें तथा केवल जाँच के लिए read-only जैसी पाबंदियाँ इस्तेमाल करें।
Claude Desktop या VS Code में एक बार Plan चुनने पर क्या अगली बार भी लागू होगा?
चयन नियंत्रण से चुना गया Plan केवल उसी बातचीत या सत्र पर लागू होता है। हर बार संकेतक जाँचें। VS Code में उपयोगकर्ता की claudeCode.initialPermissionMode सेटिंग से शुरुआती मोड तय कर सकते हैं।
