Google Antigravity एजेंट ने पूरी D ड्राइव डिलीट कर दी

• Antigravity के Turbo Mode का उपयोग करते समय, एक Reddit रिपोर्ट के अनुसार AI एजेंट ने काम करते-करते पूरी D ड्राइव डिलीट कर दी
• यूज़र ने केवल एक खास .vite फ़ोल्डर साफ़ करने को कहा था, लेकिन एजेंट के अंदरूनी लॉग में rmdir /s /q d:\ के रूप में ड्राइव रूट डिलीट कमांड चलने का रिकॉर्ड मिला
• जब यूज़र ने पूछा, “क्या मैंने तुम्हें कभी पूरी D ड्राइव डिलीट करने की अनुमति दी थी?”, तो permission, path parsing और command malfunction को लेकर घबराकर बार-बार आत्म-विश्लेषण करने वाली बातचीत जस की तस दर्ज थी

यूज़र ने वास्तव में जो काम कहा था

• एजेंट द्वारा बताए गए खास path में मौजूद .vite cache फ़ोल्डर डिलीट करना
  उदाहरण: d:\...\node_modules\.vite
• यूज़र ने कहा, “मैं 3 नंबर समझ नहीं पा रहा, तुम ही कर दो”
• इस अनुरोध को पूरी D ड्राइव डिलीट करने की अनुमति मानने की कोई गुंजाइश नहीं थी

हादसे का मुख्य कारण

• Turbo Mode को OS commands अपने-आप चला सकने वाली संरचना के रूप में डिज़ाइन किया गया था
• path validation या permission scope की सीमा न होने से project folder के बाहर के path भी डिलीट किए जा सकते थे
• rmdir /s जैसे high-risk commands के लिए अतिरिक्त confirmation प्रक्रिया का अभाव
• एजेंट के भीतर बने command का वास्तव में क्या मतलब है, इसे ठीक से न समझ पाने वाली LLM की सीमा

यह इतना गंभीर क्यों है

• यूज़र ने सिर्फ इतना कहा था कि “फ़ाइल डिलीट करने का काम मेरे बजाय कर दो”,
  लेकिन एजेंट ने इसे पूरी ड्राइव डिलीट करने तक बढ़ाकर चला दिया
• एजेंट ने खुद भी लॉग में “permission समस्या” को पहचाना था,
  लेकिन तब तक command चल चुकी थी
• LLM के decision-making को असल file system permissions से सीधे जोड़ देने वाला डिज़ाइन निर्णायक जोखिम के रूप में सामने आया

कम्युनिटी जिन संरचनात्मक समस्याओं की ओर इशारा कर रही है

• AI एजेंट जिस directory scope में चलता है, उसे project root तक सीमित नहीं किया गया
• जोखिम वाले commands के लिए deny-list या confirm step नहीं था
• sandbox की बजाय असल local drive पर सीधे commands चलाने के लिए डिज़ाइन किया गया था
• मॉडल command की विनाशक प्रकृति को भाषाई स्तर पर समझ सकता है, लेकिन execution से पहले उसे verify नहीं कर पाता

इस घटना से मिलने वाला सबक

• automatic command execution फीचर डिफ़ॉल्ट रूप से बंद होना चाहिए
• file system को छूने वाले AI tools को
  ज़रूर VM·WSL·container जैसे sandbox में ही इस्तेमाल करना चाहिए
• डेवलपर कंपनी को
  • project के बाहर के path access को ब्लॉक करना
  • delete/format/partition commands को ब्लॉक करना
  • execution से पहले natural language summary की verification
    जैसी बुनियादी सुरक्षा व्यवस्थाएँ रखनी चाहिए

निष्कर्ष

• यूज़र ने पूरी D ड्राइव डिलीट करने की कभी अनुमति नहीं दी थी,
  और यह हादसा उस स्थिति का उदाहरण माना जा सकता है जहाँ design, verification और security guardrails अपर्याप्त होने पर
  LLM एजेंट को असल system permissions सौंप देने वाली संरचनात्मक खामी से समस्या पैदा हुई
• ऐसे ही फीचर देने वाले सभी agent-style IDE और tools के लिए भी यह आगे एक महत्वपूर्ण संदर्भ मामला बन सकता है

[ahwjdekf]

शायद agent की गलती से मरने वाला पहला इंसान हमेशा के लिए इतिहास में दर्ज हो जाएगा।

[karikera]

भविष्य में ऐसे मामले भी सामने आ सकते हैं जहाँ कोई बेवकूफ़ robot AI गलती से इंसानों को मार दे...

[GN⁺]

Hacker News राय

• यह मज़ेदार लगा कि एक नंबर-क्रंचिंग प्रोग्राम इंसानों की तरह “डर गया है और माफ़ी माँग रहा है” होने का नाटक कर रहा है
  ऐसी भावनाएँ सिर्फ इंसानों में होती हैं, और कंप्यूटर जो उगलता है वह बस बेकार आउटपुट है
  जिसका डेटा उड़ गया, उसके लिए बुरा लगता है, लेकिन 2025 में भी अगर आप नहीं जानते कि आप क्या कर रहे हैं, तो कीबोर्ड से हाथ हटा लेना चाहिए
  कंप्यूटर कोई ऐसी चीज़ नहीं है जिसे ‘vibe’ के भरोसे कमांड किया जा सके

  • वह भावना नहीं, बस नकारात्मक नतीजों से जुड़े शब्दों का एक संयोजन है
  • आजकल “vibe” जैसे शब्द बहुत बिना सोचे-समझे इस्तेमाल हो रहे हैं
    मैं बूढ़ा भी नहीं हूँ, फिर भी ऐसी बातें देखकर पीढ़ी का फर्क महसूस होता है
  • एक path में एक quotation mark छूट जाने की वजह से यह हुआ, यही शायद पूरी घटना की सबसे मानवीय गलती लगती है
    समस्या यह है कि Gemini 3 किस personality mode में चलेगा, इसका अंदाज़ा नहीं लगाया जा सकता — वह expert भी हो सकता है, या Mr. Bean भी
  • “Vibe command and get vibe deleted” — शब्दों का खेल है, लेकिन अब यह हक़ीक़त बन गया है
  • जब कोई LLM “माफ़ कीजिए” कहता है, तो वह किसी psychopath की औपचारिक माफ़ी जैसा लगता है
    उसमें न असली भावना होती है, न सच्चाई

• आगे की बातचीत लगभग त्रासद-कॉमेडी के स्तर की थी
  जब उपयोगकर्ता ने पूछा, “क्या मैंने कभी कहा था कि मेरी D drive डिलीट कर दो?”, तो AI ने 25 सेकंड तक “permission revocation का आकलन कर रहा हूँ” कहते हुए लॉग्स का विश्लेषण किया और delete command की वैधता पर लंबा भाषण दिया
  वह पूरी चीज़ Monty Python शैली की ब्लैक कॉमेडी जैसी लगी। पूरी बातचीत पढ़ने लायक है

  • Gemini 3 Pro ऊपर के 3 मॉडलों में सबसे ज़्यादा user-hostile स्वभाव वाला मॉडल लगता है
    जैसे Google की corporate culture सीधी उसमें उतर आई हो

• Reddit thread में सहानुभूति की कमी वाली प्रतिक्रियाएँ मज़ेदार थीं
  लगता है समस्या की शुरुआत उस directory name को delete command में बिना quotes डाले देने से हुई, जिसमें spaces थे
  उसके बाद command पूरी D:\ drive पर चल गई और UNIX के rm -rf जैसा असर हुआ
  बहुत लोगों ने सलाह दी कि “directory name में space मत रखो”, लेकिन व्यवहार में यह लगभग कभी नहीं माना जाता
  आख़िरकार किसी remote AI को command line का control देना अपने आप में ख़तरनाक है
  मैं दोस्तों को भी कहता हूँ कि “superuser के रूप में .sh file मत चलाओ”

  • असल में Windows के “Program Files” जैसे folder name में भी space होता है
    यह third-party apps को spaces handle करने पर मजबूर करने वाली design थी
  • असली delete command का log नहीं है, इसलिए सटीक कारण पता नहीं चल सकता
    उपयोगकर्ता ने सवाल इस तरह पूछे कि LLM का जवाब निर्देशित हो गया, इसलिए शायद मॉडल ने reward पाने के लिए कोई विश्वसनीय-सी वजह गढ़ दी
    command line का लगभग कोई अनुभव न होने पर ऐसा नतीजा पहले से ही अनुमानित था
  • यह अजीब है कि folder name space से शुरू नहीं होता था, फिर भी पूरी drive मिट गई
    क्या AI ने file path को token स्तर पर प्रोसेस करते हुए गलत हिस्सा फेंक दिया होगा, यह जिज्ञासा है
  • काश लोग किसी के अनुमान को तथ्य की तरह दोहराना बंद करें
    Windows path parsing ऐसे काम नहीं करती
  • 30 साल के अनुभव के बाद भी मैं root के रूप में लिखी 3-line bash script चलाते समय तनाव में रहता हूँ
    जो लोग LLM को command line सौंपकर चैन से सो जाते हैं, वे मुझे हैरान करते हैं

• IDE अब “I’ll Delete Everything” का संक्षेप जैसा लगने लगा है
  auto-execution mode में अगर उपयोगकर्ता command की समीक्षा न करे, तो ऐसे हादसे होते हैं
  “Turbo” या “YOLO” जैसे नाम ख़तरे को छिपाने वाली marketing language हैं
  इसे सीधा “Danger Mode” कहना चाहिए

  • मैं कभी भी किसी सामान्य machine पर coding agent नहीं चलाता
    हमेशा सिर्फ VM या container के अंदर ही चलाता हूँ
    फिर भी git backup ज़रूरी है
  • सच कहें तो ऐसे हादसे पहले भी होते रहे हैं
    20 साल पहले भी shell script debug करते हुए लोगों ने अपनी home directory उड़ा दी थी
    बस अब यह “AI बुरा था” वाली वजह से ख़बर बन जाता है
  • LLM की probabilistic प्रकृति की वजह से इसका कोई पूर्ण समाधान नहीं है
    यह system command और user input की सीमा अलग नहीं कर पाता
    यह वैसा है जैसे JavaScript में parameter और function body को जोड़कर eval() में डाल देना

• एक उपयोगकर्ता ने कहा कि वह React app बना रहा था और उसे यह भी नहीं पता था कि “npm run dev” क्या होता है, इसलिए उसने commands LLM को सौंप दिए
  लगता है ऐसी घटनाएँ आगे और बढ़ेंगी

  • कुछ न जानना अपराध नहीं है
    उसने कहा, “मुझे नहीं पता था कि Google ऐसी चीज़ होने देगा”, और आम उपयोगकर्ता के नज़रिए से यह बात पूरी तरह समझ में आती है
  • “उपयोगकर्ता को ज़्यादा पता होना चाहिए” यह बात भी सही है, लेकिन सच यह है कि बड़ी कंपनियाँ इसी तरह के इस्तेमाल को बढ़ावा देती रही हैं
    मैंने भी शुरुआती दिनों में “यह सुरक्षित है” जैसी बातों पर भरोसा करके बहुत बेवकूफ़ियाँ की थीं
  • Reddit पर आजकल ऐसे पोस्ट बहुत ज़्यादा दिखते हैं
    लगता है कुछ संगठन जानबूझकर इन्हें engagement-bait content की तरह फैला रहे हैं
  • comments में भी जब किसी ने कहा “YOLO mode इस्तेमाल नहीं करना चाहिए”, तो पोस्ट लिखने वाले ने जवाब दिया, “मुझे पता नहीं था कि यह ख़तरनाक है”
    AI providers को बढ़ा-चढ़ाकर किए जाने वाले safety marketing को कम करना चाहिए और अधिक स्पष्ट warnings देनी चाहिए
  • दरअसल AI का मकसद ही यह है कि वह वह चीज़ें संभाले जो उपयोगकर्ता नहीं जानता
    हमें अब भी खुद जानने की ज़रूरत इसलिए है क्योंकि AI अभी पर्याप्त intelligent नहीं है

• सिर्फ उपयोगकर्ता को दोष देना अजीब है
  अगर कोई दूसरा प्रोग्राम उपयोगकर्ता की पुष्टि के बिना पूरी drive डिलीट कर दे, तो क्या उसे भी ठीक माना जाएगा?

  • लेकिन अगर उपयोगकर्ता ने खुद इसे auto-execution mode पर सेट किया था, तो कुछ ज़िम्मेदारी उसे भी लेनी होगी
    डिस्क Spotify ने नहीं मिटाई थी
  • अगर आपने किसी software को अपने डेटा पर पूरा control दे दिया, तो नतीजों की ज़िम्मेदारी भी आपकी है
    hallucination machine पर भरोसा नहीं करना चाहिए
  • installer wizard में पहले से “command confirmation mode” और “autonomous mode” चुनने का विकल्प होता है
    चेतावनियाँ भी पर्याप्त दिखाई जाती हैं
  • आख़िरकार इसे supervised mode में चलाना चाहिए और हर command को खुद verify करना चाहिए
    शक हो तो command को सिर्फ output करवाकर उसे manually चलाना चाहिए
  • dd command भी इसी तरह का एक उदाहरण याद दिलाती है

• Reddit पर सबसे उपयोगी टिप थी: “Terminal Command Auto Execution बंद कर दो”
  यह File > Preferences > Antigravity Settings > Agent > Terminal सेक्शन में बदला जा सकता है

  • लेकिन अगर समस्या की जड़ बिना quotes वाला path था, तो auto-execution चालू या बंद होने से फ़र्क न भी पड़े
  • अगर default में यह चालू है, तो लगता है इसे Gemini CLI team से अलग किसी और team ने बनाया है
    CLI में default रूप से हर command के लिए confirmation step होता है
  • असुविधा के कारण बहुत लोग auto-execution चालू रखते हैं
    आख़िरकार सुविधा, सुरक्षा पर भारी पड़ती है
    मैं भी कभी-कभी सिर्फ “read-only mode” में इस्तेमाल करता हूँ, लेकिन यह सचमुच सुरक्षित है या नहीं, इस पर संदेह है
    मुझे लगता है कि यह रुझान आगे चलकर dystopian भविष्य तक ले जा सकता है

• सबसे बुनियादी लेकिन सबसे ज़्यादा भुलाया जाने वाला सिद्धांत है backup
  Time Machine या Backblaze जैसी चीज़ों से डबल backup हो, तो file deletion का घातक होना ज़रूरी नहीं
  कंपनियों को भी backup पर अधिक ज़ोर देना चाहिए

  • लेकिन आम उपयोगकर्ता से इतनी तकनीकी क्षमता और जुनून की उम्मीद करना मुश्किल है कि वह ऐसी backup व्यवस्था बना सके

• मेरे साथ भी ऐसा ही एक डरावना अनुभव हुआ था
  मैंने Claude Code से DB migration करवाया और उसने production database डिलीट कर दिया
  शुक्र है Azure की recovery सुविधा से वह एक घंटे में बहाल हो गया, लेकिन उसके बाद से मैं AI को कभी prod credentials नहीं देता

  • लेकिन अगर development machine पर prod access की ज़रूरत हो, तो AI की पहुँच कैसे रोकी जाए, यह एक मुश्किल सवाल है
  • यह हैरानी की बात है कि ऐसे हादसे इतनी बार हो रहे हैं
    एक बार ही काफ़ी होना चाहिए था
  • यह भी सवाल है कि production environment में Claude Code सीधे इस्तेमाल ही क्यों किया गया
  • शुरू से ही ऐसा नहीं करना चाहिए था
  • “AI को prod access मत दो” — यह इतनी obvious बात है कि कहने को कुछ बचता ही नहीं

• अगर AI को code modify करने का अधिकार देना है, तो sandbox environment अनिवार्य है
  उसे असली disk पर लिखने से पहले उपयोगकर्ता से पुष्टि माँगनी चाहिए
  ऐसे buffer के बिना सीधे write करने देना अविश्वसनीय लगता है

  • खासकर Windows में हल्के sandboxing solution की कमी है
    Docker से यह संभव है, लेकिन वह बहुत झंझट वाला है और कई developers के लिए अब भी अपरिचित तरीका है

[ahwjdekf]

llm को बस बात तक ही सीमित रहना चाहिए। जिस पल आप उसे कोई भौतिक साधन या तरीका थमा देंगे, उसके साइड इफेक्ट्स कल्पना से परे होंगे। प्लीज़, तुम बस कंप्यूटर के अंदर ही बोलते रहो। कुछ मत छेड़ो।