जिस लॉग लाइन में इसका कारण लिखा था, उसे किसी के पढ़ने से पहले ही वह डायरेक्टरी गायब हो चुकी थी।
एक स्क्रैच रिपॉज़िटरी पर हम जिस एजेंट को चला रहे थे, उसे कहा गया था कि "बिल्ड आर्टिफैक्ट्स साफ़ कर दो।" उसने तर्क करते-करते rm -rf तक पहुँच बनाई, जिसमें पाथ एक ऐसे वेरिएबल से जोड़ा गया जो दो टर्न पहले चुपचाप एक खाली स्ट्रिंग में रिज़ॉल्व हो चुका था। rm -rf / इस मज़ाक का किताबी संस्करण है। असली वाला ज़्यादा शांत है: rm -rf "$BUILD_DIR/" जहाँ $BUILD_DIR है "", और अब तुम वर्किंग डायरेक्टरी से ऊपर की ओर मिटा रहे हो। हम भाग्यशाली रहे — यह एक फेंकने लायक क्लोन था, और सबसे बड़ा नुकसान एक दोपहर का था। पर मैंने इतने एजेंट ट्रांसक्रिप्ट देखे हैं कि "इसने हमें नुकसान नहीं पहुँचाया" और "यह हमें नुकसान पहुँचा ही नहीं सकता" के बीच का फर्क जानता हूँ, और कच्चे शेल वाला मॉडल मज़बूती से पहली श्रेणी में आता है।
वही घटना पूरी वजह है कि मुझे इस बात की परवाह है कि एजेंट डिस्क को कैसे छूता है। सबक यह नहीं है कि "मॉडल खतरनाक हैं।" मॉडल दुर्भावनापूर्ण नहीं होते; वे पूरे आत्मविश्वास के साथ गलत होते हैं, और rm -rf हाथ में लेकर पूरे आत्मविश्वास से गलत होना एक सुरक्षा समस्या है, चाहे किसी का इरादा नुकसान का हो या न हो। समाधान वही है जो हम पचास साल से अविश्वसनीय कोड के लिए इस्तेमाल करते आए हैं: उसे पूरी मशीन मत सौंपो। उसे एक संकरा, टाइप किया हुआ, अवलोकन योग्य इंटरफ़ेस दो, यह सीमित करो कि वह इंटरफ़ेस कहाँ तक पहुँच सकता है, और खतरनाक ऑपरेशनों को या तो असंभव बनाओ या शोरगुल वाला।
फाइलों के लिए वह इंटरफ़ेस एक फाइल सिस्टम MCP सर्वर है। यह पोस्ट Octofs के बारे में है — जिसे हम बनाते और चलाते हैं — सुरक्षा के नज़रिए से: यह असल में किसे रोकता है, किसे जानबूझकर नहीं रोकता, और इसे ऐसे कैसे कॉन्फ़िगर करें कि अगले rm -rf के पास पकड़ने को कुछ बचे ही नहीं।
खतरे का मॉडल: कच्चा शेल असल में क्या दे देता है
शुरुआत इस बात की ईमानदारी से करो कि एजेंट को bash देते वक्त तुम क्या छोड़ रहे हो।
शेल कोई "फाइल टूल" नहीं है। यह उस प्रोसेस के पूरे परिवेशीय अधिकार के साथ मनमाने प्रोग्राम चलाने का एक लॉन्चर है जिसने इसे जन्म दिया — तुम्हारा यूज़र अकाउंट, तुम्हारे एनवायरनमेंट वेरिएबल, तुम्हारा SSH एजेंट, ~/.aws में पड़े तुम्हारे क्लाउड क्रेडेंशियल, तुम्हारा kubeconfig, हर माउंटेड वॉल्यूम, / से नीचे का पूरा पेड़। जब मॉडल curl ... | sh निकालता है, शेल उसे चलाता है। जब वह किसी मतिभ्रमित पाथ के विरुद्ध rm -rf निकालता है, शेल उसे मिटा देता है। जब वह गलत रिमोट के विरुद्ध git push चलाता है, शेल पुश कर देता है। शेल का काम ठीक वही करना है जो उसे कहा गया, तुरंत, बिना इस धारणा के कि "क्या तुम्हारा सचमुच यही मतलब था?"
उस अधिकार के ऊपर मॉडल के फेल होने के तरीके जोड़ दो, और तुम्हें घटनाओं का एक ठोस, बार-बार दोहराने वाला सेट मिलता है:
- पाथ ड्रिफ्ट। एजेंट किसी वेरिएबल, पिछले टूल परिणाम या रिपॉज़िटरी लेआउट की अपनी याद से पाथ बनाता है। वेरिएबल खाली है, परिणाम कट गया था, याद पुरानी है — और पाथ अब कहीं अनचाही जगह पर इशारा कर रहा है। शेल को परवाह नहीं।
- गलत पाथों पर विनाशकारी क्रियाएँ।
rm -rf, किसी मौजूदा फाइल परmv,> fileसे ट्रंकेशन, बिना कमिट किए काम को मिटाताgit checkout -- .। हर एक सौम्य संस्करण से बस एक टोकन दूर है। - जो नहीं पढ़ना चाहिए उसे पढ़ना। एक
cat ~/.ssh/id_ed25519याenvडंप जो सीक्रेट्स को कॉन्टेक्स्ट विंडो में खींच लाता है, जहाँ वे लॉग होते हैं, कैश होते हैं, और शायद किसी मॉडल API को भेज दिए जाते हैं। एक्सफिल्ट्रेशन को दुर्भावना की ज़रूरत नहीं; ज़रूरत एक ऐसे एजेंट की है जो "मददगार बनकर" गलत फाइल शामिल कर ले। - इंटरैक्टिव हैंग। एक कमांड जो पासवर्ड माँगती है या पेजर खोलती है, और जवाब देने के लिए कोई TTY नहीं, और सेशन अटक जाता है।
- अनाथ प्रोसेस। एक बैकग्राउंड सर्वर जिसे एजेंट ने शुरू किया और भूल गया, सेशन खत्म होने के बाद भी एक पोर्ट पकड़े बैठा।
इनमें से किसी को भी जेलब्रेक की ज़रूरत नहीं। ये एक प्रायिकता-आधारित सिस्टम का अपेक्षित व्यवहार हैं जो सीधे एक आदेशात्मक सिस्टम से जुड़ा है। इसका शमन वास्तुशिल्पीय है: खुले लॉन्चर को नामित ऑपरेशनों के एक बंद सेट से बदलो, और उस सतह को सीमित करो जहाँ तक वे ऑपरेशन पहुँच सकते हैं।
क्यों एक सीमित फाइल टूल कच्चे bash से बेहतर है
कच्ची शेल पहुँच के मुकाबले एक समर्पित फाइल सिस्टम MCP सर्वर का तर्क वही है जो हमने कस्टम टूल को अपनी रिपॉज़िटरी में रखने के लिए दिया था: एक संकरा, नामित टूल मॉडल को गलत होने के कम रास्ते देता है और तुम्हें एक ऐसी जगह देता है जहाँ नियम लागू किए जा सकें।
ठोस रूप से, bash को फाइल टूल से बदलने पर एक साथ चार चीज़ें बदलती हैं:
- क्रियाएँ सीमित और नामित हैं। "PATH पर मौजूद कोई भी प्रोग्राम" के बजाय मॉडल देखता है
view,text_editor,batch_edit,extract_lines,shell,workdir। हर एक का एक स्कीमा है।text_editorका ऐसा कोई ऑपरेशन नहीं है जिसका मतलब "किसी ट्री को रिकर्सिवली मिटाओ" हो, क्योंकि वह ऑपरेशन कभी परिभाषित ही नहीं किया गया। उस बंदूक से पैर में गोली नहीं मार सकते जो दराज़ में है ही नहीं। - डिफ़ॉल्ट सतह तुम्हारा प्रोजेक्ट है, तुम्हारी होम डायरेक्टरी नहीं। Octofs एक वर्किंग रूट लेता है और सापेक्ष पाथों को उसी के सापेक्ष रिज़ॉल्व करता है। एजेंट का स्वाभाविक तरीका — "
src/main.rsएडिट करो" — उस रूट से कभी बाहर नहीं जाता। - पठन फ़िल्टर किए जाते हैं। डायरेक्टरी ट्रैवर्सल
.gitignoreका पालन करता है और डिफ़ॉल्ट रूप से dotfiles छोड़ देता है, इसलिए.env,.ssh,node_modulesऔर वह सब जो तुमने पहले ही git को इग्नोर करने को कहा, लिस्टिंग या कॉन्टेंट सर्च में नहीं आते। एजेंट वह नहीं पढ़ता जो वह देख नहीं सकता। - हर ऑपरेशन अवलोकन योग्य और प्रतिवर्ती है। एडिट प्रति फाइल दस अनडू लेवल तक की एटॉमिक राइट से गुज़रते हैं। "फाइल आधी लिखी है और प्रोसेस मर गया" जैसी कोई स्थिति नहीं, और "वह एडिट गलत था" के लिए एक
undo_editहै।
शेल गायब नहीं होता — एजेंट को सचमुच बिल्ड और टेस्ट चलाने पड़ते हैं — पर वह मुख्य फाइल इंटरफ़ेस होना बंद कर देता है, और यही अधिकांश लड़ाई है। जितनी कम फाइल ऑपरेशन कच्चे शेल से होकर गुज़रें, मॉडल के पास किसी पाथ को विनाशकारी चीज़ की ओर बहाने के उतने ही कम मौके।
Octofs असल में क्या उजागर करता है
छह MCP टूल, और बस यही पूरी सतह है। सटीक सूची जानना मायने रखता है, क्योंकि सुरक्षा का तर्क है "यही और इसके अलावा कुछ नहीं।"
| टूल | क्या करता है | शेल समतुल्य से ज़्यादा सुरक्षित क्यों |
|---|---|---|
view |
फाइलें पढ़ना (एकल, लाइन रेंज के साथ), glob पैटर्न से डायरेक्टरी लिस्ट करना, फाइल कॉन्टेंट में खोजना | gitignore का पालन करता है और dotfiles फ़िल्टर करता है — इग्नोर किए पाथ उजागर किए बिना cat/grep/find/ls की जगह लेता है |
text_editor |
किसी फाइल पर create, str_replace, delete, undo_edit |
एटॉमिक राइट, अनडू इतिहास, sed से चुपचाप भ्रष्टाचार के बजाय फ़ज़ी मैच |
batch_edit |
एक फाइल पर कई इन्सर्ट/रिप्लेस ऑपरेशन, एटॉमिक रूप से लागू | कॉन्फ़्लिक्ट डिटेक्शन डिस्क छूने से पहले ओवरलैपिंग या अस्पष्ट एडिट को अस्वीकार कर देता है |
extract_lines |
एक फाइल से लाइन रेंज कॉपी करके दूसरी में जोड़ना | head/tail से हाथ से बने पाइप के बजाय एक सीमित, टाइप की हुई कॉपी |
shell |
कमांड चलाना, फोरग्राउंड या बैकग्राउंड | नॉन-इंटरैक्टिव प्रवर्तन, प्रोसेस-ग्रुप सफाई, गलत उपयोग के संकेत |
workdir |
सेशन वर्किंग डायरेक्टरी पाना, सेट करना, या रीसेट करना | दायरे को cd में अंतर्निहित के बजाय स्पष्ट और निरीक्षण योग्य बनाता है |
दो कॉन्फ़िगरेशन फ्लैग पूरे को आकार देते हैं, जो सर्वर लॉन्च करते समय सेट होते हैं:
# वर्किंग रूट सीमित करें और स्थिर हैश-आधारित लाइन ID उपयोग करें
octofs mcp --path /path/to/your/project --line-mode hash
--path वर्किंग रूट सेट करता है। --line-mode hash लाइन आइडेंटिफ़ायर को क्रमिक संख्याओं से बदलकर कॉन्टेंट-व्युत्पन्न 4-कैरेक्टर हैश में बदल देता है जो एडिट के बीच स्थिर रहते हैं — एक विश्वसनीयता सुविधा, पर सुरक्षा-निकटवर्ती भी, क्योंकि स्थिर संदर्भ का मतलब है कम "नंबर खिसक जाने से गलत लाइन एडिट कर दी" वाली गलतियाँ। जब तुम्हें रिमोट या मल्टी-क्लाइंट सेटअप चाहिए हो तो stdio के बजाय Streamable HTTP पर चलाने के लिए --bind host:port भी है।
Claude Desktop, Cursor या Windsurf कॉन्फ़िग में यह ऐसे दिखता है:
{
"mcpServers": {
"octofs": {
"command": "/path/to/octofs",
"args": ["mcp", "--path", "/path/to/your/project", "--line-mode", "hash"]
}
}
}
वह --path इस टूल के साथ तुम्हारा सबसे महत्वपूर्ण सुरक्षा निर्णय है। यह "एजेंट इस प्रोजेक्ट पर काम करता है" और "एजेंट मेरे लैपटॉप पर काम करता है" के बीच का फर्क है। इसे उस सबसे संकरी डायरेक्टरी पर सेट करो जो काम के लिए ज़रूरी हो।
सुरक्षाएँ, उस क्रम में जिस क्रम में वे तुम्हें बचाती हैं
यह Octofs असल में क्या लागू करता है, कोड में आधारित, ब्रोशर में नहीं।
सीमित वर्किंग रूट
सापेक्ष पाथ --path को दिए गए वर्किंग रूट के सापेक्ष रिज़ॉल्व होते हैं (या यदि तुम नहीं देते तो मौजूदा डायरेक्टरी के)। एजेंट का view src/main.rs कहना <root>/src/main.rs पर रिज़ॉल्व होता है। एजेंट का "प्रोजेक्ट" का पूरा मानसिक मॉडल उस रूट से जुड़ा है, और जब तक वह सापेक्ष पाथ में काम करता है — जो उसका डिफ़ॉल्ट है — वह कभी बाहर नहीं पहुँचता।
gitignore-सचेत, dotfile-फ़िल्टर ट्रैवर्सल
डायरेक्टरी लिस्टिंग और कॉन्टेंट सर्च ignore क्रेट के walker का उपयोग करते हैं git_ignore(true) के साथ और छिपी हुई फाइलें डिफ़ॉल्ट रूप से बाहर रखी जाती हैं। व्यावहारिक प्रभाव: जब एजेंट कोई डायरेक्टरी लिस्ट करता है या कोई स्ट्रिंग खोजता है, तो वह .git/, .env, .ssh/, बिल्ड आउटपुट, node_modules, या तुम्हारे .gitignore में कुछ भी नहीं देखता। जो सीक्रेट्स तुमने पहले ही वर्शन कंट्रोल से बाहर रखे, वे एजेंट की नज़र से भी बाहर रहते हैं। यह सबसे सस्ती और सबसे कम आंकी गई सुरक्षा है — एजेंट उस फाइल को लीक नहीं कर सकता जिसका अस्तित्व उसने कभी जाना ही नहीं।
अनडू इतिहास के साथ एटॉमिक राइट
हर एडिट उसी डायरेक्टरी में एक अस्थायी फाइल में लिखता है, फिर टार्गेट पर रिनेम करता है — फाइल सिस्टम स्तर पर एक एटॉमिक ऑपरेशन। फाइल को कभी आधी लिखी नहीं देखा जाता; अगर प्रोसेस एडिट के बीच मर जाता है, मूल सुरक्षित रहता है। मूल फाइल अनुमतियाँ राइट के दौरान सुरक्षित रहती हैं (0.4.2 में आया एक फ़िक्स, विशेष रूप से इसलिए कि कोई राइट चुपचाप फाइल का मोड चौड़ा न कर दे)। हर राइट से पहले पिछली सामग्री का स्नैपशॉट लिया जाता है, प्रति फाइल दस स्तर गहरा, text_editor के undo_edit के ज़रिए पहुँच योग्य। "एजेंट ने फाइल तोड़ दी" अब कोई रिकवरी ऑपरेशन नहीं रहा, बस एक टूल कॉल है।
बैच कॉन्फ़्लिक्ट और डुप्लिकेट डिटेक्शन
batch_edit हर ऑपरेशन को हर दूसरे के विरुद्ध लिखने से पहले मान्य करता है। ओवरलैपिंग रिप्लेस रेंज अस्वीकार कर दिए जाते हैं। एक ही एंकर पर दो इन्सर्ट अस्पष्ट होने के कारण अस्वीकार। पूरे बैच की 50 ऑपरेशन की सीमा है। और हर रिप्लेसमेंट को बाउंड्री डुप्लिकेशन के लिए जाँचा जाता है — वह क्लासिक विफलता जहाँ मॉडल "संदर्भ" की एक अतिरिक्त लाइन शामिल कर लेता है और उसे चुपचाप फाइल में डुप्लिकेट कर देता है। इनमें से कोई भी डिस्क को तब तक नहीं छूता जब तक योजना आंतरिक रूप से सुसंगत न हो।
नॉन-इंटरैक्टिव शेल प्रवर्तन
जब एजेंट shell का उपयोग करता है, कमांड stdin को null पर सेट करके, अपने ही प्रोसेस ग्रुप में, GIT_TERMINAL_PROMPT=0, DEBIAN_FRONTEND=noninteractive, PAGER=cat, और GIT_PAGER=cat के साथ चलती हैं। कोई कमांड जो क्रेडेंशियल माँगती, सेशन को अटकाने के बजाय तुरंत विफल हो जाती है। कोई कमांड जो आउटपुट पेज करती, अस्तित्वहीन TTY के विरुद्ध less चलाने के बजाय उसे सादा उगल देती है। सेशन उस इंटरैक्टिव प्रॉम्प्ट पर अटक नहीं सकता जिसका मॉडल जवाब नहीं दे सकता।
शटडाउन पर प्रोसेस-ग्रुप सफ़ाई
फोरग्राउंड कमांड अपने ही प्रोसेस ग्रुप में जन्मी होती हैं और PID से ट्रैक की जाती हैं। SIGTERM या EOF पर, Octofs हर ट्रैक किए ग्रुप को SIGKILL भेजता है — पोते-पोतों सहित — ताकि कोई कमांड जो कुछ आधा-अधूरा छोड़ गई, सेशन से आगे न जीवित रहे। बैकग्राउंड कमांड (background: true) जानबूझकर अपवाद हैं: वे इसलिए अलग की जाती हैं ताकि कॉल से आगे जीवित रह सकें, Octofs एजेंट को उनकी PID सौंपता है, और काम पूरा होने पर उन्हें मारना एजेंट का काम है — kill <pid>।
शेल के गलत उपयोग के संकेत
यह एक इशारा है, दीवार नहीं, पर सेशन भर व्यवहार को आकार देता है। जब एजेंट shell के ज़रिए cat, grep, find, ls, sed, या awk चलाता है, Octofs जवाब में एक संकेत जोड़ देता है जो उसे समर्पित टूल की ओर मोड़ता है: पढ़ने या खोजने के लिए view इस्तेमाल करो, एडिट करने के लिए text_editor। सेशन भर एजेंट सीखता है कि फाइल ऑपरेशन को उन टूल्स से रूट करे जिनके पास सुरक्षा जाल है, उस शेल के बजाय जिसके पास नहीं। खुले इंटरफ़ेस से होकर जितने कम विनाशकारी क्रिया बहें, यही लक्ष्य है।
Octofs क्या नहीं करता — और मैं तुम्हें क्यों बता रहा हूँ
एक सुरक्षा पोस्ट जो सिर्फ़ सुरक्षाएँ गिनाए, वह मार्केटिंग है। यहाँ सीमा है, साफ़ कही गई, क्योंकि उसके इर्द-गिर्द सही कॉन्फ़िगर करना इस बात पर निर्भर है कि वह कहाँ है।
Octofs कोई chroot जेल नहीं है। वर्किंग रूट सापेक्ष पाथों को सीमित करता है। पूर्ण पाथों को कैद नहीं करता। resolve_path दो शाखाएँ हैं: एक सापेक्ष पाथ वर्किंग रूट से जुड़ती है; एक पूर्ण पाथ जैसी है वैसी ही इस्तेमाल होती है। .. ट्रैवर्सल का कोई अस्वीकार नहीं, और यह भी कोई जाँच नहीं कि रिज़ॉल्व हुई पाथ रूट के नीचे ही रहे। अगर मॉडल view /etc/passwd या /Users/you/.ssh/config के विरुद्ध text_editor निकालता है, Octofs उस पूर्ण पाथ को रिज़ॉल्व करके उस पर काम करेगा। स्कोपिंग एक मज़बूत डिफ़ॉल्ट और एक मज़बूत सम्मति है — सापेक्ष पाथ में काम करने वाला एजेंट प्रोजेक्ट से कभी बाहर नहीं जाता — पर यह उस पाथ के विरुद्ध सख्त सीमा नहीं है जो जानबूझकर या गलती से पूर्ण बन जाए।
यह जानबूझकर डिज़ाइन का एक बिंदु है, कोई चूक नहीं: Octofs एक सहयोगी एजेंट के लिए उत्पादकता टूल है, किसी शत्रुतापूर्ण एजेंट के लिए कंटेनमेंट लेयर नहीं। पर यह बदलता है कि जब ब्लास्ट रेडियस मायने रखता है तो तुम्हें इसे कैसे तैनात करना चाहिए:
- इसे अपने घर के बजाय किसी समर्पित डायरेक्टरी के विरुद्ध चलाओ। सबसे संकरा
--pathजो तुम दे सकते हो। अगर काम के लिए सिर्फ़ एक रिपो की ज़रूरत है, तो उसे उसी रिपो पर पॉइंट करो। - सख्त अलगाव के लिए, OS इस्तेमाल करो। कोई फाइल सिस्टम टूल कर्नल को उसके अपने सैंडबॉक्सिंग के मैदान में नहीं हरा सकता। अगर तुम सचमुच भरोसा नहीं करते कि एजेंट क्या कर सकता है — अविश्वसनीय कोड, कोई स्वायत्त लूप, कोई CI रनर — Octofs और एजेंट को किसी कंटेनर, VM, या यूज़र अकाउंट के अंदर चलाओ जो शारीरिक रूप से तुम्हारे सीक्रेट्स नहीं देख सकता, सिर्फ़ प्रोजेक्ट डायरेक्टरी माउंट हो। तब पूर्ण-पाथ का अंतर अप्रासंगिक है, क्योंकि माउंट के बाहर पहुँचने को कुछ है ही नहीं। गहराई से रक्षा: सीमित टूल सामान्य मामले को संकरा करता है; OS सैंडबॉक्स उस पाथ को पकड़ता है जो पूर्ण बन जाती है।
- सीक्रेट्स को वर्किंग रूट से बाहर रखो, और git से बाहर। क्योंकि ट्रैवर्सल gitignore-सचेत है, जो सीक्रेट्स तुमने पहले ही gitignore किए, वे लिस्टिंग और सर्च से अदृश्य रहते हैं। यह आकस्मिक एक्सपोज़र का असली कमी है — इस पर भरोसा करो। एक क्रेडेंशियल जिसे एजेंट गिन नहीं सकता, वह क्रेडेंशियल है जिसे वह कॉन्टेक्स्ट विंडो में पेस्ट नहीं कर सकता।
ईमानदार एक-लाइन सारांश: Octofs आकस्मिक फ़ुट-गन हटाता है — खाली-वेरिएबल वाला rm -rf, चुपचाप भ्रष्ट sed, आधी लिखी फाइल, अटका पेजर — और डिफ़ॉल्ट सतह को संकरा करता है। यह अपने आप में, उस दृढ़ या पूरी तरह भ्रमित एजेंट को नहीं रोकता जो पूर्ण पाथ बनाता है। जब तुम्हें वह गारंटी चाहिए, तो इसे OS सैंडबॉक्स के साथ जोड़ो।
इसे कसकर कॉन्फ़िगर करना: एक चेकलिस्ट
अगर तुम इस टूल से मिलने वाली अधिकतम सुरक्षा चाहते हो, तो इसे ऐसे कॉन्फ़िगर करो:
--pathको उस सबसे संकरी प्रोजेक्ट डायरेक्टरी पर सेट करो जो काम के लिए ज़रूरी है। न तुम्हारा घर, न/, न कोई पैरेंट जिसमें पाँच और रिपो हों। एक प्रोजेक्ट, एक रूट।- एजेंट को रिपो पर पॉइंट करने से पहले अपने सीक्रेट्स को gitignore करो।
.env,*.pem, क्रेडेंशियल फाइलें, लोकल कॉन्फ़िग। वेviewलिस्टिंग और सर्च से अदृश्य हो जाते हैं। यह मुफ़्त है और काम करता है। - किसी भी मल्टी-स्टेप एडिटिंग एजेंट के लिए
--line-mode hashइस्तेमाल करो। स्थिर लाइन संदर्भों का मतलब है कम "गलत लाइन एडिट कर दी" वाली गलतियाँ, जो एक साथ विश्वसनीयता और सुरक्षा है। - अपने एजेंट के निर्देशों में
shellके बजाय टाइप किए टूल्स को प्राथमिकता दो। गलत उपयोग के संकेत इस दिशा में धकेलते हैं; इसे मज़बूत करो।catके बजायviewसे पढ़ी हर फाइल वह है जो ignore नियमों का सम्मान करती है। - अपने एजेंट रनटाइम की अनुमति लेयर में विनाशकारी ऑपरेशनों को गेट करो। Octofs टूल्स उजागर करता है; तुम्हारा रनटाइम तय करता है कि किसे अनुमति चाहिए।
viewको ऑटो-अनुमति दो।shellऔरtext_editordeleteके लिए हमेशा पूछो। यहीं इंसान उन क्रियाओं के लूप में रहता है जिन्हेंundo_editसे पूर्ववत नहीं किया जा सकता। - जब ब्लास्ट रेडियस असली हो, पूरी चीज़ को कंटेनर में डालो। सिर्फ़ प्रोजेक्ट डायरेक्टरी माउंट करो। अब पूर्ण-पाथ का अंतर कर्नल से बंद है, उम्मीद से नहीं।
मानसिक बदलाव ही मायने रखता है। तुम मॉडल पर भरोसा नहीं कर रहे कि वह सावधान रहेगा। तुम दुनिया को ऐसे व्यवस्थित कर रहे हो कि लापरवाही का ब्लास्ट रेडियस छोटा हो — एक सीमित रूट, फ़िल्टर किए पठन, प्रतिवर्ती राइट, एक नॉन-इंटरैक्टिव शेल, और एक स्पष्ट वर्किंग डायरेक्टरी।
अक्सर पूछे जाने वाले सवाल
क्या Octofs एजेंट को rm -rf चलाने से रोकता है?
सीधे नहीं — shell अभी भी मनमानी कमांड चलाता है, rm सहित। Octofs जो बदलता है वह यह है कि फाइल एडिटिंग और पठन को अब शेल की ज़रूरत नहीं, इसलिए पहले से ही बहुत कम विनाशकारी शेल कमांड जेनरेट होती हैं; और वर्किंग रूट के साथ gitignore-सचेत ट्रैवर्सल का मतलब है कि एजेंट के स्वाभाविक ऑपरेशन प्रोजेक्ट के अंदर ही रहते हैं। यह सख्त गारंटी के लिए कि rm -rf किसी महत्वपूर्ण चीज़ तक नहीं पहुँच सकता, Octofs को कंटेनर के अंदर चलाओ जिसमें सिर्फ़ प्रोजेक्ट माउंट हो।
क्या वर्किंग रूट एक सैंडबॉक्स है?
यह एक सीमित डिफ़ॉल्ट है, जेल नहीं। सापेक्ष पाथ रूट के विरुद्ध रिज़ॉल्व होती हैं; पूर्ण पाथ जैसी हैं वैसी ही इस्तेमाल होती हैं, बिना .. अस्वीकार के। --path को "एजेंट कहाँ काम करता है" समझो, "एजेंट किसमें कैद है" नहीं। कैद के लिए, OS-स्तर का सैंडबॉक्स इस्तेमाल करो।
यह सीक्रेट्स को कॉन्टेक्स्ट में लीक होने से कैसे रोकता है?
डायरेक्टरी लिस्टिंग और कॉन्टेंट सर्च .gitignore-सचेत हैं और डिफ़ॉल्ट रूप से dotfiles छोड़ देते हैं। जो फाइलें तुमने पहले ही git से बाहर रखीं — .env, की फाइलें, .gitignore में कुछ भी — लिस्टिंग या सर्च में नहीं आतीं, इसलिए एजेंट उन्हें कॉन्टेक्स्ट में नहीं पढ़ सकता। रक्षा उतनी ही अच्छी है जितनी तुम्हारा .gitignore, इसलिए एजेंट को रिपो पर पॉइंट करने से पहले उसे क्यूरेट करो।
अगर प्रोसेस एडिट के बीच क्रैश हो जाए तो आधी लिखी फाइल का क्या?
नहीं हो सकता। राइट उसी डायरेक्टरी में एक temp फाइल में जाती हैं और एटॉमिक रूप से टार्गेट पर रिनेम होती हैं। अगर प्रोसेस मर जाता है, मूल सुरक्षित है। अनुमतियाँ राइट के दौरान सुरक्षित रहती हैं।
फाइल सिस्टम को उजागर करने के बजाय छह टूल क्यों?
ऑपरेशनों का एक सीमित, नामित सेट ही सुरक्षा सुविधा है। मॉडल किसी "ट्री-मिटाओ" क्रिया को नहीं पकड़ सकता जो कभी परिभाषित ही नहीं हुई, और तुम्हें एक ही जगह मिलती है — टूल की सीमा — एटॉमिक राइट, अनडू, कॉन्फ़्लिक्ट डिटेक्शन, और ignore नियम लागू करने के लिए। कम, संकरे टूल मॉडल के लिए सही चुनना भी आसान बनाते हैं।
क्या यह Octomind के बाहर काम करता है?
हाँ। Octofs stdio या Streamable HTTP पर MCP बोलता है और किसी भी MCP क्लाइंट के साथ काम करता है — Claude Desktop, Cursor, Windsurf, Zed — Octomind एजेंट रनटाइम के अलावा।
वह एजेंट जिसने उस स्क्रैच डायरेक्टरी को लगभग मिटा दिया था, अभी भी हमारे सेटअप में हर दिन चलता है। मॉडल उतना ही सावधान है जितना पहले था। बस उसके पास तोड़ने के लिए बहुत कम है।
जो बदला वह उसके आस-पास की दुनिया है: वह view से पढ़ता है, text_editor से एडिट करता है, एक रिपो तक सीमित --path के अंदर काम करता है, और जब दाँव असली होते हैं, तो यह सब एक ऐसे कंटेनर के अंदर बैठा है जो कुछ और नहीं देख सकता।
एजेंट को फाइल सिस्टम दो। बस अपना मत दो।
— Don
Octofs Apache-2.0 के तहत ओपन सोर्स है — एकल Rust बाइनरी, वर्तमान संस्करण 0.5.0। यहाँ वर्णित स्कोपिंग, gitignore-सचेत ट्रैवर्सल, एटॉमिक राइट, और नॉन-इंटरैक्टिव शेल सब सोर्स में हैं; पूर्ण-पाथ की चेतावनी भी। अगर तुम्हें कोई सुरक्षा चाहिए जो वहाँ नहीं है, issue खोलो.
