# AI एजेंट को फाइल सिस्टम दें, पर अपना पूरा फाइल सिस्टम नहीं

> फाइल सिस्टम MCP सर्वर के साथ AI एजेंट की फाइल पहुँच को सैंडबॉक्स करने की सुरक्षा-केंद्रित गाइड। Octofs कैसे एक वर्किंग रूट को सीमित करता है, gitignore का पालन करता है, शेल को नॉन-इंटरैक्टिव बनाता है, और कच्चे bash व rm एजेंट के हाथ में जो पूरी श्रेणियों की गलतियाँ थमा देते हैं उन्हें हटा देता है — साथ ही वे सुरक्षाएँ जो इसमें नहीं हैं और उनके इर्द-गिर्द कैसे कॉन्फ़िगर करें।

जिस लॉग लाइन में इसका कारण लिखा था, उसे किसी के पढ़ने से पहले ही वह डायरेक्टरी गायब हो चुकी थी।

एक स्क्रैच रिपॉज़िटरी पर हम जिस एजेंट को चला रहे थे, उसे कहा गया था कि "बिल्ड आर्टिफैक्ट्स साफ़ कर दो।" उसने तर्क करते-करते `rm -rf` तक पहुँच बनाई, जिसमें पाथ एक ऐसे वेरिएबल से जोड़ा गया जो दो टर्न पहले चुपचाप एक खाली स्ट्रिंग में रिज़ॉल्व हो चुका था। `rm -rf /` इस मज़ाक का किताबी संस्करण है। असली वाला ज़्यादा शांत है: `rm -rf "$BUILD_DIR/"` जहाँ `$BUILD_DIR` है `""`, और अब तुम वर्किंग डायरेक्टरी से ऊपर की ओर मिटा रहे हो। हम भाग्यशाली रहे — यह एक फेंकने लायक क्लोन था, और सबसे बड़ा नुकसान एक दोपहर का था। पर मैंने इतने एजेंट ट्रांसक्रिप्ट देखे हैं कि "इसने हमें नुकसान नहीं पहुँचाया" और "यह हमें नुकसान पहुँचा ही नहीं सकता" के बीच का फर्क जानता हूँ, और कच्चे शेल वाला मॉडल मज़बूती से पहली श्रेणी में आता है।

वही घटना पूरी वजह है कि मुझे इस बात की परवाह है कि एजेंट डिस्क को कैसे छूता है। सबक यह नहीं है कि "मॉडल खतरनाक हैं।" मॉडल दुर्भावनापूर्ण नहीं होते; वे पूरे आत्मविश्वास के साथ गलत होते हैं, और `rm -rf` हाथ में लेकर पूरे आत्मविश्वास से गलत होना एक सुरक्षा समस्या है, चाहे किसी का इरादा नुकसान का हो या न हो। समाधान वही है जो हम पचास साल से अविश्वसनीय कोड के लिए इस्तेमाल करते आए हैं: **उसे पूरी मशीन मत सौंपो।** उसे एक संकरा, टाइप किया हुआ, अवलोकन योग्य इंटरफ़ेस दो, यह सीमित करो कि वह इंटरफ़ेस कहाँ तक पहुँच सकता है, और खतरनाक ऑपरेशनों को या तो असंभव बनाओ या शोरगुल वाला।

फाइलों के लिए वह इंटरफ़ेस एक फाइल सिस्टम MCP सर्वर है। यह पोस्ट [Octofs](/blog/introducing-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 सर्वर का तर्क वही है जो हमने [कस्टम टूल को अपनी रिपॉज़िटरी में रखने](/blog/custom-mcps-belong-in-your-repo) के लिए दिया था: एक संकरा, नामित टूल मॉडल को गलत होने के कम रास्ते देता है और _तुम्हें_ एक ऐसी जगह देता है जहाँ नियम लागू किए जा सकें।

ठोस रूप से, `bash` को फाइल टूल से बदलने पर एक साथ चार चीज़ें बदलती हैं:

1. **क्रियाएँ सीमित और नामित हैं।** "PATH पर मौजूद कोई भी प्रोग्राम" के बजाय मॉडल देखता है `view`, `text_editor`, `batch_edit`, `extract_lines`, `shell`, `workdir`। हर एक का एक स्कीमा है। `text_editor` का ऐसा कोई ऑपरेशन नहीं है जिसका मतलब "किसी ट्री को रिकर्सिवली मिटाओ" हो, क्योंकि वह ऑपरेशन कभी परिभाषित ही नहीं किया गया। उस बंदूक से पैर में गोली नहीं मार सकते जो दराज़ में है ही नहीं।
2. **डिफ़ॉल्ट सतह तुम्हारा प्रोजेक्ट है, तुम्हारी होम डायरेक्टरी नहीं।** Octofs एक वर्किंग रूट लेता है और सापेक्ष पाथों को उसी के सापेक्ष रिज़ॉल्व करता है। एजेंट का स्वाभाविक तरीका — "`src/main.rs` एडिट करो" — उस रूट से कभी बाहर नहीं जाता।
3. **पठन फ़िल्टर किए जाते हैं।** डायरेक्टरी ट्रैवर्सल `.gitignore` का पालन करता है और डिफ़ॉल्ट रूप से dotfiles छोड़ देता है, इसलिए `.env`, `.ssh`, `node_modules` और वह सब जो तुमने पहले ही git को इग्नोर करने को कहा, लिस्टिंग या कॉन्टेंट सर्च में नहीं आते। एजेंट वह नहीं पढ़ता जो वह देख नहीं सकता।
4. **हर ऑपरेशन अवलोकन योग्य और प्रतिवर्ती है।** एडिट प्रति फाइल दस अनडू लेवल तक की एटॉमिक राइट से गुज़रते हैं। "फाइल आधी लिखी है और प्रोसेस मर गया" जैसी कोई स्थिति नहीं, और "वह एडिट गलत था" के लिए एक `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` में अंतर्निहित के बजाय स्पष्ट और निरीक्षण योग्य बनाता है                                                        |

दो कॉन्फ़िगरेशन फ्लैग पूरे को आकार देते हैं, जो सर्वर लॉन्च करते समय सेट होते हैं:

```bash
# वर्किंग रूट सीमित करें और स्थिर हैश-आधारित लाइन 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 कॉन्फ़िग में यह ऐसे दिखता है:

```json
{
	"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 सैंडबॉक्स के साथ जोड़ो।

---

## इसे कसकर कॉन्फ़िगर करना: एक चेकलिस्ट

अगर तुम इस टूल से मिलने वाली अधिकतम सुरक्षा चाहते हो, तो इसे ऐसे कॉन्फ़िगर करो:

1. **`--path` को उस सबसे संकरी प्रोजेक्ट डायरेक्टरी पर सेट करो जो काम के लिए ज़रूरी है।** न तुम्हारा घर, न `/`, न कोई पैरेंट जिसमें पाँच और रिपो हों। एक प्रोजेक्ट, एक रूट।
2. **एजेंट को रिपो पर पॉइंट करने से पहले अपने सीक्रेट्स को gitignore करो।** `.env`, `*.pem`, क्रेडेंशियल फाइलें, लोकल कॉन्फ़िग। वे `view` लिस्टिंग और सर्च से अदृश्य हो जाते हैं। यह मुफ़्त है और काम करता है।
3. **किसी भी मल्टी-स्टेप एडिटिंग एजेंट के लिए `--line-mode hash` इस्तेमाल करो।** स्थिर लाइन संदर्भों का मतलब है कम "गलत लाइन एडिट कर दी" वाली गलतियाँ, जो एक साथ विश्वसनीयता और सुरक्षा है।
4. **अपने एजेंट के निर्देशों में `shell` के बजाय टाइप किए टूल्स को प्राथमिकता दो।** गलत उपयोग के संकेत इस दिशा में धकेलते हैं; इसे मज़बूत करो। `cat` के बजाय `view` से पढ़ी हर फाइल वह है जो ignore नियमों का सम्मान करती है।
5. **अपने एजेंट रनटाइम की अनुमति लेयर में विनाशकारी ऑपरेशनों को गेट करो।** Octofs टूल्स उजागर करता है; तुम्हारा रनटाइम तय करता है कि किसे अनुमति चाहिए। `view` को ऑटो-अनुमति दो। `shell` और `text_editor` `delete` के लिए हमेशा पूछो। यहीं इंसान उन क्रियाओं के लूप में रहता है जिन्हें `undo_edit` से पूर्ववत नहीं किया जा सकता।
6. **जब ब्लास्ट रेडियस असली हो, पूरी चीज़ को कंटेनर में डालो।** सिर्फ़ प्रोजेक्ट डायरेक्टरी माउंट करो। अब पूर्ण-पाथ का अंतर कर्नल से बंद है, उम्मीद से नहीं।

मानसिक बदलाव ही मायने रखता है। तुम मॉडल पर भरोसा नहीं कर रहे कि वह सावधान रहेगा। तुम दुनिया को ऐसे व्यवस्थित कर रहे हो कि लापरवाही का ब्लास्ट रेडियस छोटा हो — एक सीमित रूट, फ़िल्टर किए पठन, प्रतिवर्ती राइट, एक नॉन-इंटरैक्टिव शेल, और एक स्पष्ट वर्किंग डायरेक्टरी।

---

## अक्सर पूछे जाने वाले सवाल

**क्या 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](https://github.com/muvon/octofs) Apache-2.0 के तहत ओपन सोर्स है — एकल Rust बाइनरी, वर्तमान संस्करण 0.5.0। यहाँ वर्णित स्कोपिंग, gitignore-सचेत ट्रैवर्सल, एटॉमिक राइट, और नॉन-इंटरैक्टिव शेल सब सोर्स में हैं; पूर्ण-पाथ की चेतावनी भी। अगर तुम्हें कोई सुरक्षा चाहिए जो वहाँ नहीं है, [issue खोलो](https://github.com/muvon/octofs/issues)._