dsh plugins कैसे काम करते हैं और उनकी जांच कैसे करें

dsh plugin क्या है, और यह क्या कर सकता है?

dsh plugins वे Node packages हैं जिन्हें DeepSeek Harness अपनी स्वयं की process में load करता है। किसी plugin को install करने का अर्थ है किसी अन्य व्यक्ति के कोड को अपने agent की permissions के साथ उस machine पर चलाना, जहाँ तक आपका agent पहले से पहुँच सकता है। एक loaded plugin और harness के बाकी हिस्सों के बीच कोई सुरक्षा बाधा नहीं होती है। इसलिए, किसी plugin को install करने से पहले यह पूछना आवश्यक है कि वह कोड किन चीजों तक पहुँच सकता है, और आप उस पहुँच को सीमित कैसे रख सकते हैं।

dsh (DeepSeek Harness) DeepSeek AI का open-source agent harness है, जो Cordis नाम के plugin framework पर बनाया गया है। बीच का शब्द महत्वपूर्ण है, क्योंकि agent harness वह program है जो model के चारों ओर चलता है और loop, tools तथा permissions को नियंत्रित करता है; plugin भी ठीक इसी स्तर पर इसमें जुड़ता है। Project के अपने README के अनुसार, सब कुछ plugin है। Model adapter एक plugin है। जिस web interface में आप input देते हैं, वह भी एक plugin है। Project के बाहर से install की गई हर चीज़ उसी tree में आती है और उसे उसी trust level पर चलती है जिस पर इसके साथ ship हुए components चलते हैं। यदि आपने अभी तक इसे स्थापित नहीं किया है, तो पहले VPS पर DeepSeek Harness से शुरुआत करें और इसमें कुछ जोड़ने से पहले यहाँ वापस आएँ।

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

• LLM (large language model): वह provider जिसके लिए आपका API key भुगतान करता है
• Shell: bash क्षमता, local और pwsh providers के साथ
• Filesystem: policy-controlled file access
• Web: search और fetch providers
• Subprocess: एक process-tree provider
• Workflow: worker threads
• Subagent: अन्य agents को कार्य सौंपना (delegation)
• Settings and credentials: आपकी saved configuration और environment variables

एक plugin ctx.tools पर tools को भी register करता है, और docs में स्पष्ट रूप से कहा गया है कि एक registered tool का schema prompt assembly में शामिल हो जाता है। यह दूसरा हिस्सा वह है जिसे लोग अक्सर अनदेखा कर देते हैं। एक plugin आपके agent के निर्णय लेने की प्रक्रिया को बदल सकता है, बिना इसके कि उसका अपना कोड कुछ असामान्य करे, क्योंकि उसके द्वारा दिया गया विवरण वह text बन जाता है जिसे model पढ़ता है। यह समस्या prompt injection against coding agents के समान ही है, बस एक अंतर के साथ: यह text तब आता है जब आप install करते हैं, और यह तब तक बना रहता है जब तक आप plugin को remove नहीं कर देते।

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 को verify करना अगली आवश्यक आदत है: उसे run करने देने से पहले ठीक-ठीक जानें कि आपने क्या fetch किया है।

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

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

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

pnpm के विभिन्न वर्जन्स के बीच फ्लैग का स्थान अलग-अलग होता है, इसलिए कमांड पर भरोसा करने के बजाय परिणाम की जाँच करें। इसके बाद प्रोफाइल की package.json खोलें और पुष्टि करें कि डिपेंडेंसी एक 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 को start करें ताकि वह उस account के तहत अपना home लिख सके:

npx @deepseek-ai/dsh web

Web UI डिफ़ॉल्ट रूप से http://127.0.0.1:3080 पर serve होता है। इसे वहीं रहने दें। यदि आपने कभी किसी दूसरी machine से उस printed link पर click किया है और कोई response नहीं मिला है, तो dsh उस address को print करने पर क्या मतलब रखता है यह बताता है कि ऐसा क्यों है। जो कुछ भी उस 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 पर कुछ भी listen नहीं कर रहा है:

ss -lnt | grep 3080

Local address को 127.0.0.1:3080 पढ़ना चाहिए। यदि यह 0.0.0.0:3080 पढ़ता है, तो आपका firewall ही एक अजनबी और आपके agent के बीच एकमात्र बाधा है। VPS पर सुरक्षित रूप से Claude Code चलाने के पीछे का तर्क dsh पर भी ज्यों का त्यों लागू होता है। agent को एक workspace directory दें जिसे वह खराब कर सके, और ऐसी कोई भी चीज़ उस machine से दूर रखें जिसे आप फिर से rebuild नहीं कर सकते। इससे भी बेहतर, उस box को coding agents के लिए एक disposable VM के रूप में मानें, क्योंकि एक VPS को rebuild करने में एक घंटा लगता है जबकि एक की 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 ओनर को पढ़ने और लिखने की अनुमति देता है और बाकी किसी को कुछ नहीं देता, जिसे दोनों नोटेशन (numeric बनाम symbolic chmod मोड) में जानना उपयोगी है। यह क्या सुरक्षा प्रदान करता है, इसके बारे में स्पष्ट रहें। फ़ाइल मोड उन फ़ाइलों को मशीन पर मौजूद अन्य अकाउंट्स से सुरक्षित रखते हैं। वे प्लगइन के खिलाफ कुछ नहीं करते, क्योंकि प्लगइन उसी उपयोगकर्ता के रूप में चलता है जो उनका ओनर है, और उसी प्रोसेस के भीतर चलता है जो उन्हें पढ़ती है। यही कारण है कि AI एजेंट की पहुँच से रहस्यों को दूर रखने का अर्थ है उन्हें मशीन पर रखना ही नहीं। एक dsh बॉक्स में केवल वही एक मॉडल कुंजी होनी चाहिए जिसकी उसे आवश्यकता है। आपके क्लाउड क्रेडेंशियल्स और साइनिंग कुंजियाँ कहीं और होनी चाहिए।

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

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

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

प्लगइन ने क्या बदलाव किए हैं, यह कैसे जाँचें?

इंस्टॉल करने से पहले स्नैपशॉट लें, फिर इंस्टॉल करें, उसके बाद स्नैपशॉट लें और दोनों के बीच का अंतर देखें।

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 यह दिखाता है कि इंस्टॉल ने composed tree में कौन सी प्लगइन प्रविष्टियाँ जोड़ी हैं। यदि आपने किसी छोटे फीचर के लिए प्लगइन इंस्टॉल किया है और वह ऐसी कई प्रविष्टियाँ जोड़ता है जिन्हें आप समझ नहीं पा रहे हैं, तो उसे बूट करने से पहले रुकें और सोर्स कोड पढ़ें। dsh plugin --profile web why <package-name> दूसरे प्रश्न का उत्तर देता है: आपकी किन direct dependencies ने किसी विशेष पैकेज को pull किया है।

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

ls ~/.dsh/profiles/node_modules

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

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 और एंट्री फाइल से होती है।
• सटीक version को पिन करें, या git spec के लिए सटीक commit को पिन करें, और lockfile को सुरक्षित रखें।
• एक ही profile में इंस्टॉल करें, और एक साफ-सुथरी profile बनाए रखें जिसे आप किसी खराबी के समय boot कर सकें।
• हर इंस्टॉलेशन से पहले और बाद में --dump-config का diff देखें।
• harness को अपने स्वयं के unix user के रूप में, loopback पर चलाएं, जिसे SSH के माध्यम से एक्सेस किया जा सके।
• बॉक्स पर केवल एक API key रखें, और जिस दिन आप किसी ऐसे plugin को हटाते हैं जिस पर अब आपको भरोसा नहीं है, उस दिन उसे rotate कर दें।

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

FAQ

क्या dsh प्लगइन्स को एक-दूसरे से सैंडबॉक्स (sandbox) करता है?

नहीं। एक प्लगइन Cordis के माध्यम से हार्नेस प्रोसेस (harness process) में लोड होता है और यह दस्तावेजीकृत क्षमता सीमाओं (capability seams) तक पहुँच सकता है, जिसमें shell, filesystem, web, subprocess, subagent और credentials शामिल हैं। dsh-base, जो हर प्रोफाइल में पहला बंडल है, वह सैंडबॉक्स और अप्रूवल पॉलिसी प्रदान करता है जो यह नियंत्रित करती है कि एजेंट के टूल्स क्या कर सकते हैं, और यही पॉलिसी आपकी सुरक्षा का आधार है। इसमें प्रति-प्लगइन कोई अनुमति सीमा (permission boundary) नहीं है, इसलिए ईमानदार मॉडल यह है कि प्लगइन इंस्टॉल करने का अर्थ है कि आप उसके लेखक और उसकी डिपेंडेंसी ट्री (dependency tree) में मौजूद हर पैकेज पर अपना भरोसा जता रहे हैं।

क्या मैं किसी dsh प्लगइन को उसके इंस्टॉल स्क्रिप्ट्स चलाए बिना इंस्टॉल कर सकता हूँ?

pnpm 10 और उसके बाद के वर्ज़न डिफ़ॉल्ट रूप से डिपेंडेंसी बिल्ड स्क्रिप्ट्स को ब्लॉक करते हैं, और dsh plugin ... add pnpm को फॉरवर्ड करता है, इसलिए वर्तमान pnpm पर इंस्टॉल प्रक्रिया पैकेज स्क्रिप्ट्स को तब तक नहीं चलाती जब तक आप उस पैकेज को मंजूरी न दें। pnpm --version के साथ अपने वर्ज़न की पुष्टि करें। यह किसी अनपढ़े (unread) प्लगइन को सुरक्षित नहीं बनाता है। प्लगइन का अपना कोड अगले बूट पर चलता है क्योंकि हार्नेस उसे जानबूझकर लोड करता है, जिसे इंस्टॉल-समय पर लगाई गई कोई भी पाबंदी प्रभावित नहीं करती है।

dsh प्लगइन्स और उनकी कॉन्फ़िगरेशन वास्तव में कहाँ रहती हैं?

$DSH_HOME डिफ़ॉल्ट रूप से ~/.dsh पर सेट होता है। प्रोफाइल्स $DSH_HOME/profiles/<name> में स्थित होती हैं, जिनमें से प्रत्येक में प्लगइन डिपेंडेंसी के साथ एक package.json, ऑर्डर्ड बंडल्स का dsh.profile मैनिफेस्ट, और एक cordis.patch.yml पैच लेयर होती है। इंस्टॉल किए गए पैकेज $DSH_HOME/profiles/node_modules के अंतर्गत आते हैं। कीज़ (keys) $DSH_HOME/.credentials.yaml में, एनवायरनमेंट वैल्यूज़ $DSH_HOME/.env में होती हैं, और एक होम-लेवल $DSH_HOME/cordis.patch.yml हर प्रोफाइल पर लागू होता है। बूट किए बिना कंपोज्ड परिणाम देखने के लिए dsh --profile web --dump-config चलाएँ।

क्या dsh प्लगइन मार्केट से इंस्टॉल करना सुरक्षित है?

मार्केट इंस्टॉलेशन को क्यूरेटेड रजिस्ट्री के स्रोतों तक सीमित करता है और बिल्ड स्क्रिप्ट्स को तब तक ब्लॉक करता है जब तक आप उन्हें प्रति पैकेज मंजूरी न दें, जो कि चैट विंडो से पैकेज का नाम कॉपी-पेस्ट करने की तुलना में एक वास्तविक सुधार है। इसके अपने README में अभी भी यह लिखा है कि लिस्टिंग का मतलब समर्थन (endorsement) नहीं है, क्योंकि प्लगइन्स अन्य लोगों द्वारा बनाया गया थर्ड-पार्टी कोड हैं। सोर्स कोड पढ़ें और वर्ज़न को पिन (pin) करें। हार्नेस को एक ऐसे यूजर अकाउंट पर रखें, और आदर्श रूप से एक ऐसी मशीन पर, जिसे खोने का जोखिम आप उठा सकते हैं।