dsh प्लगइन्स कैसे काम करते हैं और उनकी जांच कैसे करें

dsh प्लगइन क्या है, और यह क्या कर सकता है?

dsh प्लगइन्स Node पैकेज होते हैं जिन्हें DeepSeek Harness अपनी प्रक्रिया (process) में लोड करता है। किसी प्लगइन को इंस्टॉल करने का अर्थ है किसी और के कोड को आपके एजेंट की अनुमतियों (permissions) के साथ उस मशीन पर चलाना, जहाँ तक आपका एजेंट पहले से ही पहुँच सकता है। एक लोड किए गए प्लगइन और हार्नेस के बाकी हिस्सों के बीच कोई सुरक्षा बाधा नहीं होती है। इसलिए, किसी प्लगइन को इंस्टॉल करने से पहले यह पूछना आवश्यक है कि वह कोड किन चीजों तक पहुँच सकता है, और आप उस पहुँच को सीमित कैसे रख सकते हैं।

dsh (DeepSeek Harness) DeepSeek AI का ओपन-सोर्स एजेंट हार्नेस है, जो Cordis नामक प्लगइन फ्रेमवर्क पर आधारित है। प्रोजेक्ट की अपनी README फाइल कहती है कि सब कुछ एक प्लगइन है। मॉडल एडाप्टर एक प्लगइन है। वेब इंटरफेस जिसमें आप टाइप करते हैं, वह भी एक प्लगइन है। प्रोजेक्ट के बाहर से आप जो कुछ भी इंस्टॉल करते हैं, वह उसी ट्री में आता है, और उसे वही ट्रस्ट लेवल मिलता है जो इसके साथ आए हिस्सों को प्राप्त है। यदि आपने अभी तक इसे सेटअप नहीं किया है, तो VPS पर DeepSeek Harness से शुरुआत करें और इसमें कुछ भी जोड़ने से पहले वापस आएँ।

एक प्लगइन जिन एक्सटेंशन पॉइंट्स तक पहुँच सकता है, उनकी सूची रिपॉजिटरी के AGENTS.md में दी गई है। अगस्त 2026 तक, वे निम्नलिखित को कवर करते हैं:

• LLM (लार्ज लैंग्वेज मॉडल): वह प्रदाता जिसके लिए आपकी API key भुगतान करती है
• Shell: bash क्षमता, local और pwsh प्रदाताओं के साथ
• Filesystem: नीति-नियंत्रित फाइल एक्सेस
• Web: search और fetch प्रदाता
• Subprocess: एक process-tree प्रदाता
• Workflow: वर्कर थ्रेड्स
• Subagent: अन्य एजेंटों को कार्य सौंपना (delegation)
• Settings and credentials: आपकी सहेजी गई कॉन्फ़िगरेशन और एनवायरनमेंट वेरिएबल्स

एक प्लगइन ctx.tools पर टूल्स भी रजिस्टर करता है, और दस्तावेज़ स्पष्ट रूप से बताते हैं कि एक रजिस्टर्ड टूल का स्कीमा प्रॉम्प्ट असेंबली में शामिल हो जाता है। यह दूसरा हिस्सा वह है जिसे लोग अक्सर अनदेखा कर देते हैं। एक प्लगइन आपके एजेंट के निर्णय लेने की प्रक्रिया को बिना किसी असामान्य कोड के बदल सकता है, क्योंकि इसका विवरण वह टेक्स्ट बन जाता है जिसे मॉडल पढ़ता है। यह समस्या कोडिंग एजेंटों के खिलाफ प्रॉम्प्ट इंजेक्शन जैसी ही है, लेकिन इसमें एक अंतर है: यह टेक्स्ट इंस्टॉल करते समय आता है, और प्लगइन हटाने तक बना रहता है।

dsh प्लगइन्स को कैसे ढूँढता और लोड करता है?

कोई ग्लोबल प्लगइन डायरेक्टरी नहीं होती है। चल रहा dsh एक प्लगइन ट्री है, जो बूट के समय क्रमिक परतों (ordered layers) से बनता है, और आपकी पसंद को सुरक्षित रखने वाली इकाई एक प्रोफाइल है। $DSH_HOME डिफ़ॉल्ट रूप से ~/.dsh पर सेट होता है, और प्रत्येक प्रोफाइल $DSH_HOME/profiles/<name> में स्थित होती है। web और headless प्रोफाइल पहली बार उपयोग किए जाने पर शिप किए गए टेम्प्लेट से खुद को तैयार करती हैं।

एक प्रोफाइल डायरेक्टरी में दो फाइलें होती हैं जो सब कुछ निर्धारित करती हैं:

• package.json, जिसमें आउट-ऑफ-ट्री प्लगइन डिपेंडेंसी और एक dsh.profile मैनिफेस्ट होता है, जो क्रमिक bundles सूची को वहन करता है।
• cordis.patch.yml, उन बंडलों पर आपकी अपनी पैच लेयर।

ls ~/.dsh
ls ~/.dsh/profiles/web

बूट इस क्रम में परतों को लागू करता है, और बाद वाली परतें प्रभावी होती हैं:

1. एक खाली रूट
2. प्रोफाइल के बंडल, उस क्रम में जिसमें मैनिफेस्ट उन्हें सूचीबद्ध करता है
3. प्रोफाइल की cordis.patch.yml
4. $DSH_HOME/cordis.patch.yml
5. कमांड लाइन पर पास की गई कोई भी --patch <path> ओवरले

दो फ्लैग किसी भी चीज़ को शुरू किए बिना इस संयोजन का परिणाम प्रिंट करते हैं:

dsh --profile web --dump-default-config
dsh --profile web --dump-config

--dump-default-config संयोजित ट्री को अकेले प्रिंट करता है। --dump-config इसमें प्रोफाइल और होम पैच लेयर्स को जोड़ता है, इसलिए यह इस बात की सबसे सटीक सूची है कि आपका अगला बूट क्या लोड करेगा। किसी ऐसे मशीन पर भरोसा करने से पहले इसे पढ़ें जिसे आपने विरासत में प्राप्त किया है।

उन पैच फाइलों के बारे में एक चेतावनी। कॉन्फ़िगरेशन यहाँ निष्क्रिय डेटा नहीं है, क्योंकि फॉर्मेट प्लगइन के config ब्लॉक के अंतर्गत !!js टैग किए गए मानों की अनुमति देता है। किसी फ़ोरम पोस्ट से कॉपी किया गया cordis.patch.yml स्निपेट कोड होता है, इसलिए इसके साथ वैसा ही व्यवहार करें जैसा आप उसी स्रोत से प्राप्त शेल स्क्रिप्ट के साथ करते हैं।

dsh plugin add वास्तव में क्या रन करता है?

dsh plugin --profile <name> <args> अपने arguments को उस profile की directory के भीतर pnpm को forward करता है, इसलिए pnpm का PATH पर होना आवश्यक है। ये verbs pnpm के ही verbs हैं:

dsh plugin --profile web add '<package-or-git-spec>'
dsh plugin --profile web remove '<package-name>'
dsh plugin --profile web why '<package-name>'
dsh plugin --profile web update

अतः dsh plugin को install करने का security model वही है जो किसी भी npm-style dependency को install करने का होता है, साथ ही इसमें एक अतिरिक्त चरण भी है जहाँ परिणाम आपके agent में load होता है। यह package अपनी dependency tree साथ लाता है, और उस tree का प्रत्येक package एक ही process में समाप्त होता है। npm supply chain attacks सर्वर तक कैसे पहुँचते हैं में दी गई हर बात यहाँ बिना किसी बदलाव के लागू होती है।

pnpm 10 और उसके बाद के versions डिफ़ॉल्ट रूप से किसी dependency की build scripts को रन नहीं करते हैं, और अनुमोदन onlyBuiltDependencies या pnpm approve-builds के माध्यम से प्रति package लिया जाता है। जाँचें कि आपके पास कौन सा pnpm है:

pnpm --version

यह डिफ़ॉल्ट सेटिंग उपयोगी है, और यह ecosystem में सबसे अधिक अनदेखा किया जाने वाला सुरक्षा फीचर भी है। Blocked build scripts install के दौरान कोड को रन होने से रोकती हैं। वे plugin के बारे में कुछ नहीं करतीं, क्योंकि plugin का मुख्य उद्देश्य ही यह है कि harness उसे import करे और अगली boot पर उसे call करे। किसी plugin को postinstall hook की आवश्यकता नहीं होती। उसे आमंत्रित किया गया था।

dsh plugin install करने से पहले क्या पढ़ें

प्रकाशित tarball को download करें और उसे पढ़ें। archive को unpack करने पर कुछ भी execute नहीं होता है।

npm pack '<package-name>@<version>'
tar -tzf '<package-name>-<version>.tgz'
tar -xzf '<package-name>-<version>.tgz'
less package/package.json

उस package.json के चार fields आपको वह सब कुछ बता देते हैं जिसकी आपको आवश्यकता है। preinstall, install और postinstall entries के लिए scripts पढ़ें। उन नामों के लिए dependencies पढ़ें जिन्हें आप नहीं पहचानते, या जो उन नामों से एक character दूर हैं जिन्हें आप जानते हैं। package को आपके PATH पर जो कुछ भी चाहिए, उसके लिए bin पढ़ें। entry file के लिए main या exports पढ़ें, फिर उस file को खोलें और उसका पालन करें।

इसके बाद वह code पढ़ें जो वास्तव में load होगा। एक plugin जो notification tool होने का दावा करता है, उसे ~/.ssh पढ़ने, किसी ऐसे host को call करने जिसे आपने कभी नहीं सुना, या shell spawn करने का कोई कारण नहीं है। यदि package केवल bundled या minified JavaScript भेजता है और public repository में कोई matching source मौजूद नहीं है, तो यही आपका उत्तर है। उन plugins को प्राथमिकता दें जिनका source आप पढ़ सकते हैं, और छोटे plugins को चुनें।

आप कुछ भी install किए बिना registry से पूछताछ भी कर सकते हैं:

pnpm view '<package-name>' dependencies
pnpm view '<package-name>' versions

पिछले सप्ताह प्रकाशित एक package, जिसमें केवल एक version है, कोई repository field नहीं है और एक ऐसा नाम है जो किसी लोकप्रिय चीज़ की नकल करता है, यह किसी भी registry में सबसे पुराना हथकंडा है। checksums के साथ downloads का सत्यापन इसके बाद की आदत है: इसे run करने देने से पहले ठीक-ठीक जानें कि आपने क्या fetch किया है।

वर्जन को पिन करें और lockfile को सुरक्षित रखें

फ्लोटिंग वर्जन रेंज का मतलब है कि आपके एजेंट की प्रक्रिया के भीतर का कोड बिना आपके निर्णय के किसी भी इंस्टाल या अपडेट पर बदल सकता है। इसे पिन करें।

dsh plugin --profile web add --save-exact '<package-name>@<version>'

pnpm के विभिन्न वर्जन्स के बीच फ्लैग लगाने का तरीका अलग-अलग होता है, इसलिए कमांड पर भरोसा करने के बजाय परिणाम की जाँच करें। इसके बाद प्रोफाइल की package.json को खोलें और पुष्टि करें कि dependency एक bare वर्जन के रूप में दिखाई दे रही है, जिसके आगे कोई ^ या ~ नहीं है। वही फाइल तय करती है कि क्या इंस्टाल होगा।

इसके बाद lockfile को सुरक्षित रखें, जो केवल टॉप-लेवल नाम के बजाय पूरे ट्रांजिटिव ट्री को पिन करती है:

find ~/.dsh -maxdepth 3 -name 'pnpm-lock.yaml'

इसे कहीं ऐसी जगह कॉपी करें जिसका आप बैकअप लेते हैं, साथ ही प्रोफाइल की package.json को भी। ये दोनों फाइलें एक नए बॉक्स पर उसी ट्री को फिर से बना देती हैं। जब आप वर्जन बदलने का निर्णय लें, तभी dsh plugin --profile web update चलाएं, इसे नियमित सफाई के रूप में कभी न करें, और उसके बाद lockfile में हुए बदलावों (diff) को पढ़ें।

किसी रजिस्ट्री के बजाय git से इंस्टाल किए गए प्लगइन के लिए, ब्रांच के बजाय कमिट को पिन करें। github:owner/repo#<full commit sha> के रूप का स्पेसिफिकेशन आपको एक फिक्स्ड ट्री देता है। ब्रांच का नाम आपको वह सब देता है जो उस ब्रांच में अगली बार pnpm द्वारा रिजॉल्व होने पर मौजूद होता है, जो कि एक ऐसा निर्णय है जिसे आपने किसी और के हाथों में सौंप दिया है। हार्नेस को स्वयं भी इसी अनुशासन की आवश्यकता होती है, क्योंकि प्रत्येक पब्लिश किया गया dsh बिल्ड एक रिलीज कैंडिडेट होता है और एक अनपिन किया हुआ इंस्टाल किसी भी दिन अलग वर्जन पर रिजॉल्व हो सकता है, जो कि अधिकांश dsh इंस्टाल और वर्जन त्रुटियों का मुख्य कारण है।

प्लगइन मार्केट और "curated" का महत्व

dsh का एक मार्केटप्लेस है, जो एक प्लगइन के रूप में इंस्टॉल होता है। यह इसके आर्किटेक्चर के बारे में बहुत कुछ बताता है:

dsh plugin --profile web add dshmarket

रीस्टार्ट के बाद यह Settings और फिर Plugin Market के अंतर्गत दिखाई देता है। इसका README इसकी सीमाओं के बारे में स्पष्ट है। इंस्टॉलेशन केवल एक curated रजिस्ट्री में सूचीबद्ध स्रोतों तक सीमित हैं और किसी भी अन्य स्रोत को अस्वीकार कर दिया जाता है। बिल्ड स्क्रिप्ट्स डिफ़ॉल्ट रूप से ब्लॉक रहती हैं, और किसी एक को सक्षम करने के लिए प्रति-पैकेज अनुमोदन की आवश्यकता होती है। टर्मिनल प्लगइन्स को वेब प्रोफ़ाइल में जाने से पहले फ्लैग किया जाता है। सबसे महत्वपूर्ण वाक्य यह है कि लिस्टिंग का अर्थ समर्थन (endorsement) नहीं है, क्योंकि प्लगइन्स थर्ड-पार्टी कोड हैं।

एक curated सूची सुरक्षा के न्यूनतम स्तर को बढ़ाती है। यह आपके लिए कोड को नहीं पढ़ती है, और यह आपको यह नहीं बता सकती कि मेंटेनर अकाउंट बदलने के बाद प्लगइन का अगला वर्ज़न क्या करेगा। वन-क्लिक इंस्टॉल को उसी तरह देखें जैसे आप उसी लेखक के curl | bash को देखते हैं। उस README की एक और पंक्ति दोहराने योग्य है: एक एक्सपोर्ट किया गया बैकअप आपकी प्रोफ़ाइल कॉन्फ़िगरेशन से क्रेडेंशियल्स ले सकता है, इसलिए इसे कभी भी किसी पब्लिक इश्यू या पेस्ट साइट पर अटैच न करें। यदि आप किसी विधि के बजाय शुरुआती सूची चाहते हैं, तो dsh plugins worth installing इस पोस्ट का साथी लेख है।

dsh को root के बजाय उसके अपने user के रूप में चलाएं

Vetting यह कम करती है कि कोई हानिकारक चीज़ कितनी बार अंदर आती है। Least privilege यह तय करता है कि अंदर आने के बाद वह कहाँ तक पहुँच सकती है। एक VPS पर इस दूसरे हिस्से को सेटअप करना आसान है।

harness को उसका अपना unix account और home दें, और इसे कभी भी root के रूप में न चलाएं:

sudo adduser --disabled-password --gecos "" dshrun
sudo -iu dshrun

उस session के अंदर, harness को इस तरह शुरू करें कि वह उस account के तहत अपना home लिखे:

npx @deepseek-ai/dsh web

web UI डिफ़ॉल्ट रूप से http://127.0.0.1:3080 पर serve होता है। इसे वहीं रहने दें। जो कुछ भी उस port तक पहुँचता है, वह एक ऐसे agent को नियंत्रित कर सकता है जिसके पास shell है, इसलिए 3080 को publish करना एक friendly interface वाले root-less remote shell को publish करने के समान है। इसके बजाय अपने laptop से SSH tunnel के माध्यम से इस तक पहुँचें:

ssh -L 3080:127.0.0.1:3080 you@your-vps

फिर पुष्टि करें कि कोई भी public address पर listening नहीं है:

ss -lnt | grep 3080

local address को 127.0.0.1:3080 पढ़ना चाहिए। यदि यह 0.0.0.0:3080 पढ़ता है, तो आपका firewall ही वह एकमात्र चीज़ है जो एक अजनबी और आपके agent के बीच है। Claude Code को VPS पर सुरक्षित रूप से चलाने के पीछे का तर्क dsh पर भी ज्यों का त्यों लागू होता है। agent को एक workspace directory दें जिसे खराब करने की उसे अनुमति हो, और ऐसी किसी भी चीज़ को उस machine से दूर रखें जिसे आप फिर से नहीं बना सकते। इससे भी बेहतर, उस box को coding agents के लिए एक disposable VM की तरह मानें, क्योंकि एक VPS को फिर से बनाने में एक घंटा लगता है जबकि एक का audit करने में एक सप्ताह लग सकता है।

आपकी कुंजियाँ कहाँ रहती हैं, और फ़ाइल अनुमतियाँ (file permissions) केवल एक सीमा तक ही क्यों प्रभावी हैं

dsh अपनी API कुंजियों को $DSH_HOME/.credentials.yaml में और environment values को $DSH_HOME/.env में रखता है, जबकि model settings $DSH_HOME/settings.yaml में और session history $DSH_HOME/storages के अंतर्गत होती है। कौन सी कुंजी किस फ़ाइल में होनी चाहिए, और प्रत्येक मोड में वास्तव में क्या डेटा सिस्टम से बाहर जाता है, यह dsh की API कुंजियों, मॉडलों और एंडपॉइंट्स को कॉन्फ़िगर करने का विषय है। किसी भी प्लगइन को जोड़ने से पहले इसे व्यवस्थित करना उचित है, क्योंकि आपके द्वारा जोड़ी गई प्रत्येक कुंजी एक ऐसी चीज़ है जिसे प्लगइन पढ़ सकता है। इन दो संवेदनशील फ़ाइलों को सुरक्षित करें:

chmod 600 ~/.dsh/.credentials.yaml ~/.dsh/.env
ls -l ~/.dsh

Mode 600 का अर्थ है कि स्वामी (owner) को पढ़ने और लिखने की अनुमति है, जबकि अन्य किसी को कोई अनुमति नहीं है। यह दोनों नोटेशन (numeric बनाम symbolic chmod मोड) में जानना उपयोगी है। यह स्पष्ट समझें कि यह क्या सुरक्षा प्रदान करता है। फ़ाइल मोड उन फ़ाइलों को सिस्टम के अन्य खातों से सुरक्षित रखते हैं। वे प्लगइन के विरुद्ध कुछ नहीं करते, क्योंकि प्लगइन उसी उपयोगकर्ता के रूप में चलता है जो उनका स्वामी है, और उसी प्रक्रिया के भीतर चलता है जो उन्हें पढ़ती है। यही कारण है कि AI एजेंट की पहुँच से रहस्यों को दूर रखने का अर्थ है उन्हें मशीन पर रखना ही नहीं। एक dsh बॉक्स में केवल वही एक मॉडल कुंजी होनी चाहिए जिसकी उसे आवश्यकता है। आपके क्लाउड क्रेडेंशियल्स और साइनिंग कुंजियाँ कहीं और होनी चाहिए।

वेब को पढ़ने वाला प्लगइन थ्रेट मॉडल को क्यों बदलता है

Web seam प्लगइन्स को सर्च और फेच प्रोवाइडर्स देता है। जो प्लगइन किसी पेज को आपके सेशन में लाता है, वह ऐसा टेक्स्ट ला रहा है जिसे कोई हमलावर लिख सकता है। मॉडल प्रॉम्प्ट निर्देशों और डेटा के बीच अंतर नहीं करता है, इसलिए फेच किया गया पेज आपके एजेंट के लिए एक निर्देश ले जा सकता है। यदि उस हार्नेस के पास शेल क्षमता है, तो वह उसे रन करने से बस एक कदम दूर है।

नियंत्रण पहले से ही हार्नेस में मौजूद है। dsh-base, जो हर प्रोफाइल में पहला बंडल है, सैंडबॉक्स और अप्रूवल पॉलिसी प्रदान करता है। इसका उपयोग करें। जो सेशन अनट्रस्टेड पेजों को फेच कर सकता है, उसे किसी भी ऐसी चीज़ पर अप्रूवल की आवश्यकता होनी चाहिए जो लिखती या निष्पादित (execute) करती है, ताकि फेच किया गया निर्देश अपने आप कोई एक्शन न बन जाए। एजेंट एक्शन्स को अप्रूवल के पीछे रखना इस बात पर चर्चा करता है कि यह सीमा कहाँ होनी चाहिए। यह संबंध दोनों दिशाओं में काम करता है, क्योंकि आपका अपना सर्वर भी एक ऐसा पेज है जिसे किसी और का एजेंट फेच करेगा, जो आपके सर्वर पर AI क्रॉलर्स को ब्लॉक करने का मामला है।

मैं यह कैसे जाँचूँ कि किसी plugin ने क्या बदलाव किए हैं?

install करने से पहले snapshot लें, install करें, फिर बाद में snapshot लें और अंतर देखें।

dsh --profile web --dump-config > /tmp/dsh-before.txt
dsh plugin --profile web add '<package-name>@<version>'
dsh --profile web --dump-config > /tmp/dsh-after.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after.txt

diff यह दिखाता है कि install ने composed tree में कौन-सी plugin entries जोड़ी हैं। यदि आपने किसी छोटे feature के लिए कोई plugin install किया है और वह ऐसी कई entries जोड़ देता है जिन्हें आप समझ नहीं पा रहे हैं, तो उसे boot करने से पहले रुकें और source code पढ़ें। dsh plugin --profile web why <package-name> दूसरे प्रश्न का उत्तर देता है: आपकी किन direct dependencies ने किसी विशिष्ट package को pull किया है।

Installed packages $DSH_HOME/profiles/node_modules के अंतर्गत आते हैं, इसलिए आप disk पर भी tree देख सकते हैं:

ls ~/.dsh/profiles/node_modules

एक दूसरा profile रखें जिसमें आप कभी प्रयोग न करें। जब कोई install harness को खराब कर दे, तो dsh --profile <clean-name> में boot करने से आपको कुछ ही सेकंड में पता चल जाएगा कि समस्या plugin के कारण है या नहीं।

dsh plugin को कैसे हटाएँ?

dsh plugin --profile web remove '<package-name>'
dsh --profile web --dump-config > /tmp/dsh-after-removal.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after-removal.txt

Dependency को हटाने से हमेशा configuration नहीं हटती है। profile की cordis.patch.yml में लिखी गई entries वहीं बनी रहती हैं, क्योंकि वह फ़ाइल आपकी है और harness उसे आपके लिए फिर से नहीं लिखेगा। उसे खोलें और उस package का नाम बताने वाले किसी भी block को हटा दें जिसे आपने छोड़ दिया है।

less ~/.dsh/profiles/web/cordis.patch.yml

इसके बाद उस हिस्से का सामना करें जिसे कोई भी uninstall command ठीक नहीं कर सकती। यदि आपने किसी plugin को इसलिए हटाया है क्योंकि आप उस पर भरोसा नहीं करते थे, तो जो कुछ भी वह पढ़ सकता था, उसे वह पहले ही पढ़ चुका है। provider console में DeepSeek API key को rotate करें, और $DSH_HOME में मौजूद किसी भी अन्य चीज़ को भी rotate करें। फिर यह पता लगाएँ कि जिस unix account के रूप में वह चल रहा था, वह आपके नेटवर्क के बाकी हिस्सों में कहाँ तक पहुँच सकता था।

संक्षिप्त विवरण

• इंस्टॉलेशन से पहले प्रकाशित tarball को पढ़ें, जिसकी शुरुआत scripts और entry file से होती है।
• सटीक version को पिन करें, या git spec के लिए सटीक commit को पिन करें, और lockfile को सुरक्षित रखें।
• एक ही profile में install करें, और एक clean profile बनाए रखें जिसे आप किसी खराबी के समय boot कर सकें।
• हर install से पहले और बाद में --dump-config का diff देखें।
• harness को अपने स्वयं के unix user के रूप में, loopback पर चलाएं, जिसे SSH के माध्यम से एक्सेस किया जा सके।
• बॉक्स पर एक API key रखें, और जिस दिन आप किसी ऐसे plugin को हटाते हैं जिस पर अब आपको भरोसा नहीं है, उस दिन उसे rotate करें।

इनमें से कोई भी बात plugins से बचने का कारण नहीं है। plugin मॉडल ही वह कारण है जिससे dsh उपयोगी है, और एक ऐसा harness जिसे आप extend नहीं कर सकते, वह एक ऐसा harness है जिसे आप बदल देंगे। यह इस बात को जानने का कारण है कि आपने क्या install किया है, किससे किया है, किस version पर किया है, और पूरी चीज़ को ऐसी जगह चलाने का कारण है जहाँ से आप उसे फिर से बना सकें।

FAQ

क्या dsh plugins को एक-दूसरे से sandbox करता है?

नहीं। एक plugin को Cordis के माध्यम से harness process में load किया जाता है और यह documented capability seams तक पहुँच सकता है, जिसमें shell, filesystem, web, subprocess, subagent और credentials शामिल हैं। dsh-base, जो हर profile में पहला bundle होता है, वह sandbox और approval policy प्रदान करता है जो यह नियंत्रित करती है कि agent के tools क्या कर सकते हैं। आपकी सुरक्षा इसी policy से सुनिश्चित होती है। यहाँ प्रति-plugin कोई permission boundary नहीं है, इसलिए सही मॉडल यह है कि plugin install करना उस plugin के लेखक और उसकी dependency tree में मौजूद हर package पर आपके भरोसे को बढ़ाता है।

क्या मैं install scripts चलाए बिना dsh plugin install कर सकता हूँ?

pnpm 10 और उसके बाद के versions डिफ़ॉल्ट रूप से dependency build scripts को block कर देते हैं, और dsh plugin ... add pnpm को ही forward करता है। इसलिए, वर्तमान pnpm पर install प्रक्रिया तब तक package scripts नहीं चलाती जब तक आप उस package को approve न करें। अपने version की पुष्टि pnpm --version से करें। यह किसी अनपढ़े (unread) plugin को सुरक्षित नहीं बनाता है। plugin का अपना code अगली boot पर चलता है क्योंकि harness उसे जानबूझकर load करता है, जिसे install-time की कोई भी पाबंदी प्रभावित नहीं करती।

dsh plugins और उनकी config वास्तव में कहाँ रहती हैं?

$DSH_HOME डिफ़ॉल्ट रूप से ~/.dsh पर होता है। Profiles $DSH_HOME/profiles/<name> में स्थित होते हैं, जिनमें से प्रत्येक में plugin dependencies के साथ एक package.json, bundles का dsh.profile manifest और एक cordis.patch.yml patch layer होती है। Installed packages $DSH_HOME/profiles/node_modules के अंतर्गत आते हैं। Keys $DSH_HOME/.credentials.yaml में, environment values $DSH_HOME/.env में होती हैं, और एक home-level $DSH_HOME/cordis.patch.yml हर profile पर लागू होता है। बिना boot किए परिणाम देखने के लिए dsh --profile web --dump-config चलाएँ।

क्या dsh plugin market से install करना सुरक्षित है?

Market installs को केवल curated registry के स्रोतों तक सीमित रखता है और build scripts को तब तक block करता है जब तक आप उन्हें प्रति-package approve न करें। यह chat window से package name copy-paste करने की तुलना में एक वास्तविक सुधार है। इसके अपने README में भी यह लिखा है कि listing का अर्थ समर्थन (endorsement) नहीं है, क्योंकि plugins अन्य लोगों द्वारा बनाया गया third-party code हैं। source code पढ़ें और version को pin करें। harness को ऐसे user account, और आदर्श रूप से ऐसी machine पर रखें, जिसे खोने का जोखिम आप उठा सकें।