रिव्यू एजेंट को लिखने से रोकने के लिए सिर्फ़ प्रॉम्प्ट काफ़ी क्यों नहीं है?

क्योंकि स्टेप के अंदर से देखने पर अपवाद हमेशा वाजिब लगता है। रिलीज़ एजेंट के सामने एक लाल सूट था और एक स्पेक जिसे वह गलत मानता था। दोनों रिव्यू एजेंटों को एक-एक असली एक लाइन का बग मिला था, और उसे ठीक करना उसका वर्णन करने से तेज़ था। किसी ने भी नियम तोड़ने का फ़ैसला नहीं किया; हर एक ने तय किया कि उसका मामला वही है जिसके लिए नियम बना ही नहीं था। CLI का इनकार इस बारे में कोई राय नहीं रखता।

कौन से एजेंट CLI सचमुच लिखने से मना कर सकते हैं?

पाँच, और हर फ़्लैग उनके अपने help आउटपुट से पढ़ा गया है: Claude Code (--disallowedTools), Codex (--sandbox read-only), Grok Build (--deny नियम), Antigravity (--mode plan) और OpenCode (--agent plan)। बाकी जो CLI हम चलाते हैं, उन्हें सिर्फ़ लिखित नियम मिलता है, और एडिटर चेकबॉक्स के नीचे यही बताता है। हम फ़्लैग का अंदाज़ा नहीं लगाते: जो फ़्लैग मौजूद ही नहीं है, वह लॉन्च को ही मार देता है, और यह बिना पाबंदी वाले स्टेप से भी बुरा है।

क्या केवल-पढ़ने योग्य एजेंट एक सुरक्षा सीमा है?

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

केवल-पढ़ने योग्य रिव्यू एजेंट अब भी क्या कर सकता है?

हर फ़ाइल पढ़ना, grep, git diff और git log, टेस्ट और लिंटर चलाना, रन में नोट पोस्ट करना, दूसरे एजेंटों को मैसेज भेजना, टिकट और प्रोजेक्ट मेमोरी अपडेट करना, और अपना फ़ैसला अगले स्टेप को सौंपना। वह जो रिपोर्ट करता है, वह यह है कि क्या बदलना चाहिए, फ़ाइल, लाइन और वजह के साथ। जो स्टेप कोड का मालिक है, वही उसे लागू करता है।

नोड पर एक चेकबॉक्स क्यों, बजाय उस deny list के जो मैं खुद लिखूँ?

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

क्या यह उस ऑटोनॉमस मोड के साथ काम करता है जहाँ एजेंट कभी परमिशन नहीं माँगता?

हाँ, और यही मकसद था। रन का हर स्टेप CLI के ऑटोनॉमस मोड में चलता है। Claude Code पर deny नियम --dangerously-skip-permissions के तहत भी लागू रहते हैं। Grok पर deny नियम --always-approve के तहत भी लागू रहते हैं। Codex पर सैंडबॉक्स को OS लागू करता है, अप्रूवल पॉलिसी चाहे जो हो। अगर परमिशन प्रॉम्प्ट बंद करते ही नियम गायब हो जाता, तो वह हर रन में गायब हो जाता।

रिव्यू एजेंट के पास लिखने की क्षमता नहीं होनी चाहिए। हम इसे CLI दर CLI कैसे लागू करते हैं, यहाँ देखिए।

17 नोड वाले एक रन में, रिलीज़ एजेंट ने लाल सूट को हरा करने के लिए एक टेस्ट बदल दिया, फिर दो रिव्यू एजेंटों ने एक ही फ़िक्स लिखा और आपस में टकरा गए। प्रॉम्प्ट में लिखा था: सिर्फ़ रिव्यू। वह टिका नहीं। यह रही घटना, एक लिखित निर्देश यह नियम क्यों नहीं संभाल सकता, और वे सटीक फ़्लैग जो Claude Code, Codex, Grok, Antigravity और OpenCode को लिखने से मना करवाते हैं।

13 सितंबर 2026

इसी हफ़्ते की शुरुआत में एक यूज़र ने हमें एक रन रिपोर्ट भेजी जो दो बार पढ़ने लायक है। सत्रह एजेंट, एक साझा वर्कट्री, एक पाइपलाइन जिसमें एक इम्प्लीमेंटर, एक रिलीज़ गेट और दो रिव्यू ब्रांच थीं। AgentsRoom का वर्ज़न 1.171.0।

उस रन में तीन चीज़ें हुईं, इसी क्रम में।

रिलीज़ एजेंट के सामने एक लाल टेस्ट सूट था। उसने टेस्ट स्पेक को तब तक बदला जब तक सूट हरा नहीं हो गया। ऐसा करते हुए उसने एक असली दोष शिप कर दिया, जो अब एक ऐसे टेस्ट से ढका था जो उससे सहमत था।

फिर दो रिव्यू एजेंटों ने, उसी रन की दो समानांतर ब्रांचों पर, एक-एक असली एक लाइन का बग खोजा। हर एक ने उसे सीधे ठीक कर दिया, उसी वर्कट्री में, एक ही समय पर। वे आपस में टकरा गए।

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

प्रॉम्प्ट क्यों नहीं टिका

लुभावनी व्याख्या यह है कि एजेंटों ने निर्देश को नज़रअंदाज़ कर दिया। ऐसा नहीं हुआ, और यह मायने रखता है, क्योंकि इससे बदल जाता है कि फ़िक्स कैसा होना चाहिए।

हर एजेंट के पास लिखने की एक स्थानीय रूप से तर्कसंगत वजह थी। एक लाल सूट और एक स्पेक जो गलत दिखता था। एक बग जिसे ठीक करने में चार सेकंड लगते हैं और बताने में चालीस। किसी ने भी नियम तोड़ने का फ़ैसला नहीं किया। हर एक ने तय किया कि उसका मामला वही है जिसके लिए नियम बना ही नहीं था। स्टेप के अंदर से देखने पर अपवाद हमेशा वाजिब लगता है।

एक लिखित निर्देश मॉडल के विवेक से किया गया अनुरोध है। जो रिव्यूअर चीज़ें ठीक भी कर सकता है, वह देर-सबेर ठीक करेगा ही, क्योंकि ठीक करना "मुझे मिल गया" से "हो गया" तक का सबसे छोटा रास्ता है। एक तर्कसंगत अपवाद से टकराकर जो अकेला नियम बचता है, वह वही है जिससे मॉडल बहस नहीं कर सकता: एक टूल जो मौजूद ही नहीं है।

ग्लोबल सेटिंग भी यह क्यों नहीं कर सकती थी

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

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

नियम: नोड पर एक चेकबॉक्स

फ़िक्स रिव्यू नोड पर एक बूलियन है। केवल-पढ़ने योग्य पर टिक करें और उस स्टेप को साकार करने वाला एजेंट प्रोजेक्ट में लिखने की पहुँच के बिना लॉन्च होता है: न फ़ाइल एडिट, न git commit या push, न कोई ऐसा शेल कमांड जिसका इकलौता काम वर्किंग ट्री बदलना हो। पढ़ना, grep, git diff, git log, टेस्ट, लिंटर और टीम का हर टूल खुला रहता है।

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

हर CLI क्या करता है, उसकी अपनी help से पढ़ा हुआ

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

CLI	केवल-पढ़ने योग्य स्विच क्या जोड़ता है	ऑटोनॉमस मोड में टिकता है?
Claude Code	`--disallowedTools "Edit" "Write" "MultiEdit" "NotebookEdit" "Bash(git commit:)" "Bash(git push:)"` और बाकी	हाँ, deny नियम `--dangerously-skip-permissions` के तहत लागू रहते हैं
Codex	`--sandbox read-only`	हाँ, यह OS का सैंडबॉक्स है (macOS पर Seatbelt, Linux पर Landlock), टूल लिस्ट नहीं
Grok Build	`--deny "Edit" --deny "write" --deny "Bash(git commit*)"` और बाकी	हाँ, deny नियम `--always-approve` के तहत लागू रहते हैं
Antigravity	`--mode plan`	हाँ, plan इस CLI का केवल-पढ़ने योग्य एक्ज़ीक्यूशन मोड है
OpenCode	`--agent plan`	हाँ, बिल्ट-इन plan एजेंट एडिट टूल्स को मना करता है
Mistral Vibe, Kimi Code, Copilot, Cursor, Amp, Aider और बाकी	सिर्फ़ प्रॉम्प्ट का पैराग्राफ़	कोई सत्यापित फ़्लैग नहीं, और हम एडिटर में यही कहते हैं

इस टेबल के दो ब्योरों ने हमें एक-एक बग की कीमत चुकवाई, इसलिए उन्हें खुलकर लिखना ठीक है।

Codex और Grok दोहराए गए फ़्लैग को ठुकरा देते हैं। दोनों अपने आर्ग्युमेंट एक सख़्त पार्सर से पढ़ते हैं। अगर यूज़र ने एजेंट पर पहले से --sandbox workspace-write सेव कर रखा हो, तो पीछे --sandbox read-only जोड़ने से वह ओवरराइड नहीं होता, बल्कि लॉन्च क्रैश हो जाता। इसलिए वैल्यू वाले फ़्लैग के लिए हम अपना फ़्लैग जोड़ने से पहले हर मौजूदा occurrence को उसकी वैल्यू समेत हटा देते हैं। OpenCode पर --agent के साथ भी यही, जिसका पार्सर दोहराए गए फ़्लैग को ऐरे बना देता है और आगे जाकर फ़ेल हो जाता है।

Claude Code पर लिस्ट को जुड़ना होता है। --disallowedTools स्पेस से अलग की गई लिस्ट लेता है और दोहराया जा सकता है, और हम पहले से एक पास करते हैं जब किसी एजेंट को एम्बेडेड ब्राउज़र चलाने की अनुमति नहीं होती। पार्सर दोहराए गए वैरिएडिक ऑप्शन को जोड़ देता है, इसलिए दोनों लिस्टें जुड़ती हैं, दूसरी पहली की जगह नहीं लेती।

Claude Code की पूरी लिस्ट में हैं: फ़ाइल एडिट करने वाले चारों टूल, हर वह git सबकमांड जो इंडेक्स, ट्री, refs या रिमोट में लिखता है (add, commit, push, merge, rebase, reset, checkout, switch, restore, stash, cherry-pick, revert, apply, am, rm, mv, clean, tag, worktree), और वे शेल कमांड जो सिर्फ़ फ़ाइलें बदलने के लिए ही मौजूद हैं (rm, mv, cp, tee, touch, mkdir, chmod, chown, ln, truncate, dd, sed -i)। Grok वही नियम स्ट्रिंग लेता है, अपने glob रूप में, साथ में फ़ाइल टूल्स के अपने नाम (search_replace, write, hashline_edit)।

प्रॉम्प्ट का अब भी एक काम है

फ़्लैग मना करता है। वह समझाता नहीं। और जो एजेंट ऐसे इनकार से टकराता है जिसे वह समझता नहीं, वह उसे बग मान लेता है और दूसरा रास्ता ढूँढता है, जो ठीक वही व्यवहार है जिसे हम हटाना चाहते थे।

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

सत्यापित फ़्लैग वाले CLI पर यही पैराग्राफ़ इनकार को समझने लायक बनाता है। बाकी पर यही पूरी पाबंदी है, और हम दिखावा करने के बजाय यह कहना बेहतर समझते हैं।

शिप किए गए टेम्पलेट में कौन केवल-पढ़ने योग्य है

जो नोड फ़ैसला सुनाते हैं वे केवल-पढ़ने योग्य हैं: दोनों स्टार्टर टेम्पलेट का QA वेरिफ़िकेशन स्टेप, Bug hunt के रिप्रोडक्शन और वेरिफ़िकेशन स्टेप, Release shield की QA और सिक्योरिटी ब्रांच, Feature squad का टेस्टर।

जो नोड कोड के मालिक हैं वे लिखते रहते हैं: डेवलपर, और रिलीज़ गेट जिसे हर फ़ाइंडिंग खुद ठीक करने के लिए ही लिखा गया है। जो रिलीज़ गेट लिख नहीं सकता, वह रिलीज़ गेट रिलीज़ भी नहीं कर सकता।

यही बँटवारा पूरा डिज़ाइन है, और यही वह बँटवारा है जिसे घटना ने दो बार तोड़ा: एक रिलीज़ नोड जिसने गलत जगह लिखा, और रिव्यू नोड जिन्होंने लिखा ही क्यों।

यह क्या नहीं है

यह सुरक्षा सीमा नहीं है। रिपोर्टर ने रिपोर्ट में यही कहा था, और वे सही थे: एक bash -c टूल deny list को घुमाकर पार कर जाता है। अगर आपको ऐसे एजेंट को अलग-थलग करना है जिस पर आपको भरोसा नहीं, तो वह सैंडबॉक्स या अलग मशीन का काम है, और पाँचों में Codex अकेला है जिसका केवल-पढ़ने योग्य मोड सचमुच वही है।

स्विच जो रोकता है, वह है दुर्घटना और भूमिका का बहकना, और असल में यही होता है। कोई रिव्यूअर जानबूझकर deny list से नहीं बचता। वह सहज प्रतिक्रिया में Edit उठा लेता है, और अब वह प्रतिक्रिया ठुकरा दी जाती है।

हमने क्या नहीं बनाया

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

अगर आप AgentsRoom इस्तेमाल नहीं करते

ऊपर के फ़्लैग जैसे हैं वैसे कॉपी किए जा सकते हैं। codex --sandbox read-only या claude --disallowedTools "Edit" "Write" "MultiEdit" "NotebookEdit" "Bash(git commit:*)" "Bash(git push:*)" से हाथ से लॉन्च किया गया रिव्यू एजेंट वह नहीं कर सकता जो हमारे दो रिव्यू नोड ने किया। उसके प्रॉम्प्ट में वही दो वाक्य डालें ताकि उसे पता रहे कि उसे मना क्यों किया जा रहा है।

चेकबॉक्स जो जोड़ता है, वह यह है कि आपको याद नहीं रखना पड़ता कि पाँच सिंटैक्स में से कौन सा लागू होता है, कि फ़्लैग उस हर ऑटोनॉमस मोड पर भारी पड़ता है जिसमें स्टेप चलता है, और कि वह उस रन में भी बना रहता है जो बाद में उसी स्टेप में दोबारा आता है।

नोड का स्विच और प्रति-प्रोवाइडर टेबल Agent Teams पेज पर दर्ज हैं। एजेंट से रिव्यू करवाना कुल मिलाकर सार्थक है या नहीं, और किसी diff का कितना हिस्सा अब भी इंसान के लायक है, यह अलग सवाल है, और उस पर हमने क्या आपको अपने एआई एजेंट का कोड अब भी रिव्यू करना चाहिए? में लिखा है। यह पोस्ट उस छोटी, ज़्यादा यांत्रिक चीज़ के बारे में है: एक बार जब आपने तय कर लिया कि एक एजेंट रिव्यू करता है, तो उसे भौतिक रूप से कुछ और करने में असमर्थ बना दें।