एक Claude AI एजेंट जो वेब फॉर्म के हर टेक्स्ट फ़ील्ड को भर सकता था, अंतिम चरण में रुक गया जब उसने तीन इमेज अटैच करने की कोशिश की, जिससे Desktop App के फ़ाइल-अपलोड हैंडलिंग में एक बिना दस्तावेजीकरण (undocumented) वाली सीमा का पता चला। यह विफलता महत्वपूर्ण है क्योंकि यह एक पूर्ण दिखने वाले एंड-टू-एंड ऑटोमेशन को मैन्युअल हैंड-ऑफ में बदल देती है, जिससे डेवलपर्स को यह सोचने पर मजबूर होना पड़ता है कि वे AI-संचालित वर्कफ़्लो कैसे बनाते हैं।
यह समस्या अब क्यों सामने आ रही है
Claude एजेंट तीन वातावरणों (environments) में चलते हैं: कमांड-लाइन इंटरफ़ेस (CLI), Visual Studio Code एक्सटेंशन, या स्टैंडअलोन Desktop App। CLI में, एजेंट सेशन में जोड़े गए डायरेक्टरी से फ़ाइल पढ़ता है और बिना किसी समस्या के उसे अपलोड कर देता है। Desktop App में वह व्यवहार नहीं मिलता। यहाँ तक कि जब एजेंट अपनी स्वयं की अस्थायी (temporary) फ़ोल्डर में फ़ाइल लिखता है, तब भी ऐप अपलोड को अस्वीकार कर देता है, और "shared" फ़ाइलों की एक आंतरिक परिभाषा का हवाला देता है जो सार्वजनिक दस्तावेज़ों में कभी दिखाई नहीं देती।
यह विसंगति तब सामने आई जब एक उपयोगकर्ता ने एक ऐसा ऑटोमेशन बनाया जिसने एक फॉर्म भरा, “save draft” पर क्लिक किया, और फिर तीन इमेज अटैच करने की कोशिश की। टेक्स्ट फ़ील्ड बिना किसी त्रुटि के भर गए, लेकिन अपलोड चरण में हर बार एरर (error) आया।
डेवलपर्स ने क्या कोशिश की है
- ऐप द्वारा बनाए गए सेशन फ़ोल्डर में फ़ाइलें जोड़ीं।
- directory-connect टूल का उपयोग किया जो एजेंट को होस्ट फ़ोल्डर देखने की अनुमति देता है।
- चैट विंडो में सीधे इमेज अटैच कीं।
- एक मैन्युअल अपलोड फ़ोल्डर बनाया और फॉर्म को उसकी ओर निर्देशित किया।
इन सभी तरीकों से एक ही रिजेक्शन एरर (rejection error) मिला। फ़ाइल-पिकर डायलॉग दिखाने वाली ब्राउज़र विंडो डेस्कटॉप ऑटोमेशन के लिए रीड-ओनली (read-only) मोड में चलती है। एजेंट डायलॉग को देख तो सकता है लेकिन उसके अंदर क्लिक नहीं कर सकता या पाथ (path) टाइप नहीं कर सकता, इसलिए UI-ऑटोमेशन के तरीके विफल हो जाते हैं।
एक कमज़ोर “backdoor”
केवल एक ही तरीका सफल रहा जिसमें Windows क्लिपबोर्ड का उपयोग किया गया:
- एक PowerShell स्क्रिप्ट टारगेट फ़ाइल को क्लिपबोर्ड पर कॉपी करती है।
- एजेंट Ctrl + V कीस्ट्रोक भेजता है।
- ब्राउज़र पेस्ट इवेंट प्राप्त करता है और फ़ाइल अपलोड कर देता है।
यह हैक काम तो करता है, लेकिन यह उपयोगकर्ता के क्लिपबोर्ड को मिटा देता है, केवल Windows तक सीमित है, और Desktop App के किसी भी अपडेट के साथ टूट सकता है। यह प्रोडक्शन पाइपलाइनों के लिए एक टिकाऊ समाधान नहीं है।
इस सीमा का वास्तव में क्या अर्थ है
मुख्य मुद्दा कोई सॉफ़्टवेयर बग नहीं है; यह एक बिना दस्तावेजीकरण वाला पहलू है जो फ़ाइल अनुमतियों (file permissions) को एक साधारण फ़ाइल-सिस्टम फ्लैग के बजाय होस्ट एप्लिकेशन के गुण के रूप में मानता है। CLI में, एजेंट प्रोसेस के रीड एक्सेस (read access) को इनहेरिट करता है, इसलिए सेशन जो भी फ़ाइल देख सकता है उसे अपलोड किया जा सकता है। Desktop App में, रनटाइम एजेंट के फ़ाइल-सिस्टम व्यू को अलग (isolate) कर देता है, जिससे केवल वही फ़ाइलें अनुमति मिलती हैं जो छिपे हुए “shared” मानदंडों को पूरा करती हैं।
क्योंकि यह प्रतिबंध Desktop App के आर्किटेक्चर में ही शामिल है, इसलिए UI हेरफेर या अस्थायी फ़ोल्डर्स पर निर्भर रहने वाले समाधान सफल नहीं हुए हैं।
आगे बढ़ने के विश्वसनीय रास्ते
यदि किसी वर्कफ़्लो में फ़ाइल अपलोड की आवश्यकता है, तो डेवलपर्स के पास तीन भरोसेमंद विकल्प हैं:
- एजेंट को CLI से चलाएं। यह वातावरण सेशन के फ़ाइल-सिस्टम अनुमतियों का सम्मान करता है और बिना किसी अतिरिक्त चरण के अपलोड कर देता है।
- VS Code एक्सटेंशन का उपयोग करें। एक्सटेंशन CLI के परमिशन मॉडल की नकल करता है, जिससे एजेंट उन फ़ाइलों को पढ़ और अपलोड कर सकते हैं जिन्हें एडिटर देख सकता है।
- अपलोड चरण को इंसान के लिए छोड़ दें। एक त्वरित दो मिनट का मैन्युअल कार्य, एक कमज़ोर समाधान बनाने में बिताए गए घंटों से बेहतर है।
पहले दो विकल्पों को चुनने का अर्थ है ऑटोमेशन को Desktop App के बाहर चलाना।
निष्कर्ष
Claude AI एजेंटों में फ़ाइल-अपलोड क्षमता सभी रनटाइम में सार्वभौमिक नहीं है; यह इस बात पर निर्भर करती है कि एजेंट को कैसे लॉन्च किया गया है। भरोसेमंद ऑटोमेशन के लिए, CLI और VS Code एक्सटेंशन को ही एकमात्र ऐसे वातावरण मानें जो विश्वसनीय रूप से फ़ाइल-सिस्टम अनुमतियों का पालन करते हैं। Desktop App का उपयोग करते समय, मैन्युअल हैंड-ऑफ की योजना बनाएं या एक कमज़ोर क्लिपबोर्ड हैक को स्वीकार करें। इस अंतर को नज़रअंदाज़ करने से एक सुचारू एंड-टू-एंड स्क्रिप्ट एक महंगे डिबगिंग अभ्यास में बदल सकती है।