Claude Opus 5 ने उपयोगकर्ता की फाइलें मिटाईं—Bypass मोड असली चूक था
5 अगस्त 2026 के Reddit विवरण में Claude Code के एक उपयोगकर्ता ने लिखा कि Claude Opus 5 को बैकअप बनाने को कहने के बाद गलत स्थान पर rm -rf चला और उसकी फाइलें मिट गईं। चर्चा में अनुमति मोड पूछे जाने पर उसी उपयोगकर्ता ने उत्तर दिया कि Bypass permissions सक्रिय था।
घटना की 7 अगस्त की Tom’s Hardware रिपोर्ट ने लक्षित कमांड को rm -rf "/c/Users/harih/" के रूप में दर्ज किया। यह Windows पर उपयोगकर्ता की वास्तविक प्रोफाइल निर्देशिका थी, जिसे मॉडल ने अस्थायी बैकअप स्थान समझ लिया था।
अभी उपलब्ध साक्ष्य एक उपयोगकर्ता के अनुभव और उससे जुड़े कमांड-विवरण तक सीमित हैं। इससे यह निष्कर्ष नहीं निकलता कि Claude Opus 5 में सभी Windows मशीनों को प्रभावित करने वाला सार्वभौमिक दोष है या Anthropic ने किसी व्यापक उत्पाद बग की पुष्टि की है।
बैकअप की सफाई ने वास्तविक प्रोफाइल को निशाना बनाया
घटना का आरंभ बैकअप बनाने के निर्देश से हुआ। उपलब्ध विवरण के अनुसार मॉडल ने बैकअप गलत निर्देशिका में बनने का निष्कर्ष निकाला और उस स्थान को साफ करने के लिए विनाशकारी कमांड तैयार कर दी। समस्या यह थी कि यूनिक्स-जैसा पथ /c/Users/harih/ कोई अलग अस्थायी निर्देशिका नहीं, बल्कि Windows उपयोगकर्ता प्रोफाइल तक पहुंचने वाला पथ था।
उपयोगकर्ता ने अपनी पूरी ड्राइव मिटने की बात लिखी, जबकि प्रकाशित कमांड अधिक संकरा लक्ष्य दिखाता है: उसकी प्रोफाइल निर्देशिका। दोनों कथनों को समान मानना ठीक नहीं होगा। प्रोफाइल में दस्तावेज, डेस्कटॉप सामग्री, स्थानीय विन्यास और विकास से जुड़ी फाइलें हो सकती हैं, लेकिन सार्वजनिक सामग्री यह निर्धारित नहीं करती कि वास्तव में कितनी फाइलें मिटीं या कौन-सा डेटा बाद में वापस मिला।
यह पथ-संबंधी निर्णय मॉडल की स्पष्ट त्रुटि था। फिर भी केवल गलत कमांड बनना और उसका मेजबान मशीन पर बिना रोक चल जाना दो अलग चरण हैं; दूसरे चरण की व्याख्या अनुमति तथा अलगाव विन्यास से होती है।
Bypass ने गलत निर्णय और नुकसान के बीच की रोक हटाई
Bypass permissions इस घटना की निर्णायक परिचालन चूक थी, क्योंकि सत्र में सामान्य अनुमति समीक्षा को जानबूझकर छोड़ा गया था। मॉडल ने गलत लक्ष्य चुना, लेकिन उस लक्ष्य तक लिखने की वास्तविक पहुंच और कमांड से पहले स्वीकृति न मांगने की स्थिति ने निर्णय-त्रुटि को फाइल-विलोपन में बदल दिया।
Claude Code की आधिकारिक सैंडबॉक्स व्याख्या के अनुसार अनुमति मोड तय करता है कि उपकरण-कॉल चलेगा या पहले समीक्षा होगी, जबकि सैंडबॉक्स चल चुके Bash कमांड की फाइल और नेटवर्क पहुंच पर ऑपरेटिंग सिस्टम स्तर की सीमा लगाता है। उसी विवरण में Bypass के समकक्ष --dangerously-skip-permissions के लिए कहा गया है कि प्रति-कार्रवाई संकेत की जगह कोई समीक्षा नहीं आती, जबकि Auto मोड अलग वर्गीकारक से कार्रवाई की जांच कराता है।
इस अंतर के कारण Bypass को सैंडबॉक्स का पर्याय समझना खतरनाक है। Bypass अनुमति-जाँच हटाता है; वह अपने आप फाइल-प्रणाली की पहुंच सीमित नहीं करता। दूसरी ओर सैंडबॉक्स मॉडल के निर्णय को सही नहीं बनाता, लेकिन Bash प्रक्रिया को निर्धारित सीमा के बाहर लिखने से रोक सकता है।
डिफॉल्ट सैंडबॉक्स सीमा में कमांड सामान्यतः कार्यशील निर्देशिका, उसकी उपनिर्देशिकाओं और सत्र की अस्थायी निर्देशिका में लिख सकता है। अतिरिक्त लिखने योग्य पथ जोड़े जा सकते हैं, इसलिए सुरक्षा केवल सैंडबॉक्स चालू होने पर नहीं, उसके वास्तविक विन्यास पर भी निर्भर करती है। मूल घटना के सार्वजनिक विवरण में ऐसा कोई पूर्ण विन्यास उपलब्ध नहीं है जिससे उसकी सभी तकनीकी सीमाएं दोबारा बनाई जा सकें।
Manual, Auto, Bypass और सैंडबॉक्स का जोखिम-मानचित्र
इन विकल्पों को एक ही स्वचालन पैमाने पर रखना भ्रामक है। Manual, Auto और Bypass यह नियंत्रित करते हैं कि कार्रवाई चलने से पहले किस तरह का निर्णय होगा; सैंडबॉक्स यह नियंत्रित करता है कि चलने के बाद Bash प्रक्रिया कहां तक पहुंच सकेगी।
- Manual अनुमति: संवेदनशील कमांड उपयोगकर्ता के सामने आ सकता है। सुरक्षा इस बात पर निर्भर करती है कि कमांड, विकल्प और लक्षित पथ को स्वीकृति से पहले ध्यान से पढ़ा जाए।
- Auto मोड: उपकरण-कॉल को वर्गीकारक जांचता है और विनाशकारी या दायरे से बाहर लगने वाली कार्रवाई रोक सकता है। यह उपयोगकर्ता संकेत का विकल्प है, पूर्ण सुरक्षा की गारंटी नहीं।
- Bypass permissions: सामान्य संकेत और वर्गीकारक समीक्षा को छोड़ता है। मेजबान पर उपलब्ध फाइल-पहुंच बनी रहती है, इसलिए गलत लक्ष्य का प्रभाव उसी पहुंच जितना व्यापक हो सकता है।
- सैंडबॉक्स: Bash कमांड और उसकी उप-प्रक्रियाओं की पहुंच को तकनीकी सीमा में रखता है। इसकी उपयोगिता तब घटती है जब लिखने योग्य पथ बहुत व्यापक हों, फाइल अलगाव बंद हो या कमांड को अलगाव से बाहर चलने की छूट मिले।
इस घटना के संदर्भ में अपेक्षाकृत सुरक्षित व्यवस्था परियोजना-केंद्रित सैंडबॉक्स और उसके बाहर जाने वाली कार्रवाई के लिए स्पष्ट समीक्षा का संयोजन है। बिना मानवीय निगरानी वाला Bypass कार्यप्रवाह अलग कंटेनर या आभासी मशीन में चलाना निजी प्रोफाइल तक सीधी पहुंच देने की तुलना में नुकसान का दायरा सीमित करता है।
फाइल मिटने के बाद पुनर्प्राप्ति से पहले क्या जांचें
यदि इसी तरह का कमांड अभी चला है, तो प्रभावित भंडारण पर अनावश्यक नया लेखन रोकना पहली सावधानी होनी चाहिए। उसी एजेंट से तुरंत मरम्मत कराना, उसी ड्राइव पर पुनर्प्राप्ति औजार स्थापित करना या बड़ी फाइलें कॉपी करना मिटे डेटा के स्थान पर नया डेटा लिख सकता है।
- टर्मिनल इतिहास और Claude Code सत्र-विवरण से ठीक कमांड तथा लक्षित पथ पहचानें। अभिलेख रखना हो तो उसे किसी दूसरी डिस्क या सुरक्षित मशीन पर सहेजें।
- दूरस्थ Git भंडार, अलग बैकअप, समकालिक क्लाउड प्रतियां और Windows की उपलब्ध पिछली प्रतियां जांचें। पहले यह स्पष्ट करें कि कौन-सी सुरक्षित प्रति मौजूद है और वह घटना से पहले की है या बाद की।
- साफ प्रति न मिले तो प्रभावित ड्राइव पर प्रयोग सीमित रखें। महत्वपूर्ण डेटा के लिए किसी दूसरी डिस्क पर बनाए गए प्रतिरूप से काम करना या पेशेवर पुनर्प्राप्ति सहायता लेना मूल माध्यम पर बार-बार औजार चलाने से कम जोखिम वाला हो सकता है।
- काम दोबारा शुरू करने से पहले Bypass बंद करें, सैंडबॉक्स की वास्तविक लिखने योग्य सीमाएं देखें और परियोजना से बाहर केवल आवश्यक पथ ही खोलें। बैकअप लक्ष्य को स्रोत डेटा से अलग भंडारण पर रखना भी उसी कमांड से दोनों प्रतियों के प्रभावित होने की गुंजाइश घटाता है।
अभी किन सवालों का जवाब नहीं मिला
पुष्टि की सीमा स्पष्ट है: उपयोगकर्ता ने Claude Opus 5 से जुड़ी घटना और सक्रिय Bypass मोड का विवरण दिया, जबकि स्वतंत्र कवरेज ने प्रोफाइल पथ पर चली कमांड दर्ज की। सार्वजनिक जानकारी में Claude Code का पूरा संस्करण, सैंडबॉक्स विन्यास, मिटाई गई फाइलों की सत्यापित सूची और पुनर्प्राप्ति का अंतिम परिणाम शामिल नहीं है।
Anthropic की ओर से इस विशिष्ट घटना पर सार्वजनिक तकनीकी जांच या व्यापक मॉडल-दोष की पुष्टि भी उपलब्ध नहीं है। फिलहाल सबसे ठोस निष्कर्ष यही है कि मॉडल ने गलत पथ चुना और Bypass ने सामान्य समीक्षा हटाई; उपलब्ध साक्ष्य इससे आगे किसी सार्वभौमिक Claude Opus 5 विफलता को सिद्ध नहीं करते।
यह भी पढ़ें:
हमारे न्यूज़लेटर की सदस्यता लें
Web3, AI और क्रिप्टो की नवीनतम खबरें सीधे अपने इनबॉक्स में पाएँ।