dsh plugin কী করতে পারে, ইনস্টলের আগে কীভাবে যাচাই করবেন

একটি dsh plugin কী এবং এটি কী করতে পারে?

dsh plugin হলো Node package, যা DeepSeek Harness নিজের process-এর মধ্যে load করে। এটি install করলে আপনার agent-এর permission ব্যবহার করে, agent যে machine-এ ইতিমধ্যে পৌঁছাতে পারে সেই machine-এ অন্য কারও code চালানো হয়। Loaded plugin এবং harness-এর বাকি অংশের মধ্যে কোনো পৃথক সুরক্ষা-স্তর থাকে না। তাই কোনো plugin install করার আগে প্রশ্ন করুন, code-টি কী কী access করতে পারে এবং সেই access কীভাবে সীমিত রাখবেন।

dsh (DeepSeek Harness) হলো DeepSeek AI-এর open-source agent harness, যা Cordis নামের একটি plugin framework-এর ওপর তৈরি। প্রকল্পটির নিজস্ব README-তে বলা হয়েছে, সবকিছুই plugin। Model adapter একটি plugin। আপনি যে web interface-এ লিখে কাজ করেন, সেটিও একটি plugin। প্রকল্পের বাইরে থেকে install করা যেকোনো কিছু একই tree-তে, আগে থেকেই থাকা অংশগুলোর সমান trust level-এ যুক্ত হয়। এখনো সেটি চালু না করে থাকলে, একটি VPS-এ DeepSeek Harness দিয়ে শুরু করুন এবং এতে অন্য কিছু যোগ করার আগে এখানে ফিরে আসুন।

একটি plugin যে extension point-গুলোতে পৌঁছাতে পারে, সেগুলো repository-এর AGENTS.md-এ তালিকাভুক্ত। August 2026 অনুযায়ী এগুলোর মধ্যে রয়েছে:

• LLM (large language model): যে provider-এর জন্য আপনার API key দিয়ে অর্থ পরিশোধ করা হয়
• Shell: bash capability, যেখানে local এবং pwsh provider রয়েছে
• Filesystem: policy-নিয়ন্ত্রিত file access
• Web: search এবং fetch provider
• Subprocess: process-tree provider
• Workflow: worker thread
• Subagent: অতিরিক্ত agent-এ কাজ অর্পণ
• Settings এবং credentials: সংরক্ষিত configuration এবং environment variable

একটি plugin ctx.tools-এ tool-ও register করে। Documentation-এ স্পষ্টভাবে বলা হয়েছে, registered tool-এর schema prompt assembly-তে যুক্ত হয়। মানুষ সাধারণত এই দ্বিতীয় অংশটি উপেক্ষা করে। Plugin-এর নিজের code অস্বাভাবিক কিছু না করেও এটি আপনার agent কী করার সিদ্ধান্ত নেবে তা পরিবর্তন করতে পারে, কারণ plugin যে description যোগ করে তা model যে text পড়ে তার অংশ হয়ে যায়। এটি coding agent-এর বিরুদ্ধে prompt injection-এর মতো একই ধরনের সমস্যা। পার্থক্য হলো, এই text আপনি plugin install করার সময় আসে এবং plugin remove না করা পর্যন্ত থেকে যায়।

dsh কীভাবে plugin খুঁজে লোড করে?

কোনো global plugin directory নেই। চলমান dsh হলো boot-এর সময় ordered layer থেকে তৈরি একটি plugin tree। আপনার পছন্দগুলো যে unit-এ সংরক্ষিত থাকে, সেটি হলো profile। $DSH_HOME-এর default হলো ~/.dsh, এবং প্রতিটি profile থাকে $DSH_HOME/profiles/<name>-এ। web ও headless profile প্রথমবার ব্যবহারের সময় shipped template থেকে স্বয়ংক্রিয়ভাবে তৈরি হয়।

একটি profile directory-তে দুটি file থাকে, যা পুরো প্রক্রিয়া নির্ধারণ করে:

• package.json, যেখানে out-of-tree plugin dependency এবং ordered bundles list-সহ একটি dsh.profile manifest থাকে
• cordis.patch.yml, যা ওই bundle-গুলোর ওপর আপনার নিজস্ব patch layer

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

Boot এই ক্রমে layer প্রয়োগ করে। পরে আসা layer আগের layer-কে অগ্রাধিকার দেয়:

1. একটি খালি root
2. manifest-এ তালিকাভুক্ত ক্রমে profile-এর bundle
3. profile-এর cordis.patch.yml
4. $DSH_HOME/cordis.patch.yml
5. command line-এ দেওয়া যেকোনো --patch <path> overlay

কোনো কিছু start না করেই এই composition-এর ফল দেখানোর জন্য দুটি flag আছে:

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

--dump-default-config শুধু composed tree দেখায়। --dump-config profile এবং home patch layer যোগ করে। তাই পরবর্তী boot-এ কী load হবে, তার সবচেয়ে নির্ভরযোগ্য inventory এটি। উত্তরাধিকারসূত্রে পাওয়া কোনো machine-এর ওপর আস্থা রাখার আগে এটি পড়ুন।

এই patch file-গুলো সম্পর্কে একটি সতর্কতা আছে। এখানে Config নিষ্ক্রিয় data নয়, কারণ format-এ plugin-এর config block-এর অধীনে !!js tagged value থাকতে পারে। কোনো forum post থেকে কপি করা cordis.patch.yml snippet হলো code। তাই একই source থেকে পাওয়া shell script-কে যেভাবে বিবেচনা করতেন, এটিকেও সেভাবেই বিবেচনা করুন।

dsh plugin add আসলে কী চালায়?

dsh plugin --profile <name> <args> তার আর্গুমেন্টগুলো ওই profile-এর directory-র ভিতরে pnpm-এ পাঠায়। তাই pnpm-কে PATH-এ থাকতে হবে। ব্যবহৃত verb-গুলো pnpm-এর verb:

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 করার security model-এর মতো, এর সঙ্গে আরও একটি ধাপ যুক্ত থাকে: ফলাফলটি আপনার agent-এ load করা হয়। Package-টি নিজের dependency tree নিয়ে আসে, এবং সেই tree-র প্রতিটি package একই process-এর মধ্যে চলে। npm supply chain attack কীভাবে server-এ পৌঁছায় সম্পর্কিত সবকিছু এখানে কোনো পরিবর্তন ছাড়াই প্রযোজ্য।

pnpm 10 এবং পরবর্তী সংস্করণগুলো default হিসেবে dependency-এর build script চালায় না। Approval onlyBuiltDependencies বা pnpm approve-builds-এর মাধ্যমে প্রতি package অনুযায়ী দেওয়া হয়। আপনার pnpm version পরীক্ষা করুন:

pnpm --version

এই default রাখা উপযোগী। তবে ecosystem-এ এটিই সবচেয়ে বেশি ভুলভাবে ব্যাখ্যা করা safety feature। Blocked build script install চলাকালে code execution বন্ধ করে। কিন্তু plugin নিজেকে আটকায় না, কারণ plugin-এর মূল উদ্দেশ্যই হলো harness সেটিকে import করে পরবর্তী boot-এ call করবে। Plugin-এর postinstall hook প্রয়োজন হয় না। এটিকে আগেই অনুমতি দিয়ে load করা হয়েছে।

dsh plugin ইনস্টল করার আগে যা পড়বেন

প্রকাশিত tarball ডাউনলোড করে সেটি পড়ুন। কোনো 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-এর চারটি field থেকেই প্রয়োজনীয় অধিকাংশ তথ্য পাওয়া যায়। scripts পড়ে preinstall, install এবং postinstall entry দেখুন। যেসব নাম আপনি চেনেন না, অথবা পরিচিত নামের সঙ্গে মাত্র একটি অক্ষরের পার্থক্য আছে, সেগুলোর জন্য dependencies পড়ুন। package আপনার PATH-এ কী রাখতে চায়, তা জানতে bin পড়ুন। entry file-এর জন্য main বা exports পড়ুন। তারপর ওই file খুলে তার অনুসরণ করুন।

এরপর যে code বাস্তবে load হবে, সেটি পড়ুন। notification tool হিসেবে পরিচয় দেওয়া কোনো plugin-এর ~/.ssh পড়ার, আপনার অচেনা কোনো host-এ সংযোগ করার বা shell চালু করার কারণ নেই। package-এ যদি শুধু bundled বা minified JavaScript থাকে এবং public repository-তে মিলে যায় এমন source না থাকে, তাহলে সেটিই আপনার উত্তর। যেসব plugin-এর source আপনি পড়তে পারেন, সেগুলো অগ্রাধিকার দিন। ছোট plugin-ও অগ্রাধিকার দিন।

কিছু ইনস্টল না করেও registry যাচাই করতে পারেন:

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

গত সপ্তাহে প্রকাশিত, মাত্র একটি version থাকা, repository field না থাকা এবং জনপ্রিয় কোনো নামের অনুকরণ করা নামের package যেকোনো registry-র পুরোনো কৌশল। checksum দিয়ে download যাচাই করা পাশের অভ্যাস: কোনো কিছু run করার আগে ঠিক কী fetch করেছেন, তা নিশ্চিতভাবে জানুন।

সংস্করণ নির্দিষ্ট করুন এবং lockfile সংরক্ষণ করুন

একটি পরিবর্তনশীল version range থাকার অর্থ হলো, আপনার agent-এর process-এর ভেতরের code আপনার সিদ্ধান্ত ছাড়াই যেকোনো install বা update-এর সময় বদলে যেতে পারে। তাই version নির্দিষ্ট করে দিন।

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

pnpm-এর version অনুযায়ী flag-এর অবস্থান ভিন্ন হতে পারে। তাই command-টির ওপর অন্ধভাবে নির্ভর না করে ফলাফল পরীক্ষা করুন। এরপর profile-এর package.json খুলে নিশ্চিত করুন, dependency-টি কোনো ^ বা ~ ছাড়া bare version হিসেবে লেখা আছে। কোন জিনিস install হবে, সেই সিদ্ধান্ত এই file-ই নির্ধারণ করে।

এরপর lockfile-টি সংরক্ষণ করুন। এটি শুধু top-level name নয়, সম্পূর্ণ transitive tree-এর version নির্দিষ্ট করে:

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

এটি profile-এর package.json-এর সঙ্গে এমন জায়গায় copy করুন, যেখানে backup রাখা হয়। নতুন server-এ একই tree পুনর্গঠন করতে এই দুইটি file লাগবে। Version পরিবর্তনের সিদ্ধান্ত নেওয়ার পর dsh plugin --profile web update চালান। নিয়মিত পরিষ্কার-পরিচ্ছন্নতার জন্য এটি চালাবেন না। এরপর lockfile-এর diff পরীক্ষা করুন।

কোনো plugin registry-এর পরিবর্তে git থেকে install করা হলে branch-এর বদলে commit নির্দিষ্ট করুন। github:owner/repo#<full commit sha>-এর মতো একটি spec একটি নির্দিষ্ট tree দেয়। Branch name ব্যবহার করলে pnpm পরেরবার resolve করার সময় ওই branch-এ যা থাকবে, সেটিই নেবে। অর্থাৎ এই সিদ্ধান্ত অন্য কারও ওপর ছেড়ে দেওয়া হয়। harness-এর ক্ষেত্রেও একই নিয়ম প্রযোজ্য। কারণ প্রকাশিত প্রতিটি dsh build একটি release candidate। Unpinned install যেকোনো দিনে ভিন্ন build resolve করতে পারে। অধিকাংশ dsh install ও version সংক্রান্ত error এর কারণ এটাই।

Plugin market এবং “curated” তালিকার মূল্য

dsh-এর একটি marketplace আছে, এবং এটি plugin হিসেবে ইনস্টল হয়। এ থেকে architecture সম্পর্কে একটি বিষয় বোঝা যায়:

dsh plugin --profile web add dshmarket

Restart-এর পরে এটি Settings, তারপর Plugin Market-এর অধীনে দেখা যায়। এর README-তে সীমাবদ্ধতাগুলো স্পষ্টভাবে বলা আছে। ইনস্টল কেবল curated registry-তে তালিকাভুক্ত source থেকে করা যায়। অন্য সব source প্রত্যাখ্যান করা হয়। Build script ডিফল্টভাবে blocked থাকে। কোনো package-এর জন্য এটি সক্রিয় করতে হলে আলাদা অনুমোদন দিতে হয়। Terminal plugin web profile-এ যুক্ত হওয়ার আগে flagged হয়। সবচেয়ে গুরুত্বপূর্ণ বক্তব্য হলো, কোনো plugin তালিকাভুক্ত থাকা endorsement নয়, কারণ plugin-গুলো third-party code।

একটি curated তালিকা ন্যূনতম মান বাড়ায়। তবে এটি আপনার হয়ে code পরীক্ষা করে না। Maintainer account-এর মালিকানা বদলানোর পরে plugin-এর পরবর্তী version কী করবে, সেটিও এটি জানাতে পারে না। একই author-এর curl | bash-এর ক্ষেত্রে যে সতর্কতা নিতেন, one-click install-কেও সেভাবেই বিবেচনা করুন। README-এর আরেকটি বক্তব্য পুনরায় বলা জরুরি: exported backup-এ আপনার profile config-এর credentials থাকতে পারে। তাই এটি কখনো public issue বা paste site-এ attach করবেন না। পদ্ধতির বদলে শুরু করার মতো একটি তালিকা চাইলে ইনস্টল করার মতো dsh plugin এই লেখার companion post।

dsh-কে root হিসেবে নয়, আলাদা user হিসেবে চালান

Vetting খারাপ কিছু সিস্টেমে ঢোকার সম্ভাবনা কমায়। কোনো কিছু ঢুকলে সেটি কী কীতে পৌঁছাতে পারবে, তা least privilege নির্ধারণ করে। VPS-এ দ্বিতীয় ব্যবস্থাটি চালু করা সহজ।

harness-এর জন্য নিজস্ব home-সহ একটি আলাদা unix account তৈরি করুন। এটিকে কখনো root হিসেবে চালাবেন না:

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

সেই session-এর ভেতরে harness চালু করুন, যাতে এটি ওই account-এর home directory-তে data লেখে:

npx @deepseek-ai/dsh web

ডিফল্টভাবে web UI http://127.0.0.1:3080-এ চালু থাকে। এটিই রাখুন। ওই port-এ পৌঁছাতে পারলে shell-সহ একটি agent নিয়ন্ত্রণ করা যায়। তাই 3080 public করা মানে friendly interface-সহ root-বিহীন remote shell public করা। এর বদলে SSH tunnel ব্যবহার করে laptop থেকে এতে পৌঁছান:

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

এরপর নিশ্চিত করুন যে কোনো service public address-এ listening করছে না:

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 দিন। যেসব জিনিস পুনর্নির্মাণ করা যায় না, সেগুলো ওই মেশিনে রাখবেন না। আরও নিরাপদ পদ্ধতি হলো box-টিকে coding agent-এর জন্য disposable VM হিসেবে বিবেচনা করা। কারণ VPS পুনর্নির্মাণ করতে এক ঘণ্টা লাগতে পারে, কিন্তু সেটি audit করতে এক সপ্তাহ লাগতে পারে।

আপনার key কোথায় থাকে এবং file permission কেন সীমিত সুরক্ষা দেয়

dsh API key রাখে $DSH_HOME/.credentials.yaml-এ এবং environment value রাখে $DSH_HOME/.env-এ। Model setting থাকে $DSH_HOME/settings.yaml-এ এবং session history থাকে $DSH_HOME/storages-এর অধীনে। এই file-গুলোর কোনটিতে কোন key রাখা উচিত এবং প্রতিটি mode-এ আসলে কোন তথ্য মেশিনের বাইরে যায়, তা dsh-এর API key, model এবং endpoint configure করা-এ ব্যাখ্যা করা হয়েছে। Plugin যোগ করার আগে এটি নির্ধারণ করা উচিত, কারণ আপনি যে প্রতিটি key সংযুক্ত করেন, plugin সেটি পড়তে পারে। সংবেদনশীল দুটি file-এর permission সীমিত করুন:

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

Mode 600 owner-কে read ও write permission দেয় এবং অন্য সবাইকে কোনো permission দেয় না। দুটি notation-ই জানা দরকার (numeric ও symbolic chmod mode-এর পার্থক্য)। তবে এটি কী সুরক্ষা দেয়, সে বিষয়ে বাস্তবসম্মত থাকুন। File mode একই মেশিনের অন্য account থেকে ওই file-গুলোকে সুরক্ষিত রাখে। Plugin-এর বিরুদ্ধে এটি কোনো সুরক্ষা দেয় না, কারণ plugin file-গুলোর owner user হিসেবেই এবং সেগুলো পড়া process-এর ভেতরেই চলে। তাই AI agent-এর নাগালের বাইরে secret রাখা বলতে secret মেশিনে একেবারেই না রাখাকে বোঝায়। dsh box-এ শুধু প্রয়োজনীয় একটি model key রাখা উচিত। আপনার cloud credential এবং signing key অন্য কোথাও রাখা উচিত।

ওয়েব পড়ে এমন একটি plugin কেন threat model পরিবর্তন করে

Web seam plugin-গুলোকে search এবং fetch provider দেয়। কোনো plugin আপনার session-এ একটি page আনলে, সেটি এমন text-ও আনতে পারে যা attacker লিখেছে। Model prompt instruction এবং data আলাদা করে না। তাই fetch করা page-এ আপনার agent-এর উদ্দেশে লেখা কোনো line থাকতে পারে। Shell capability ধরে রাখা harness সেটি চালানোর এক ধাপ দূরে থাকে।

Control ইতিমধ্যেই harness-এ আছে। dsh-base, প্রতিটি profile-এর প্রথম bundle, sandbox এবং approval policy দেয়। এটি ব্যবহার করুন। যে session untrusted page fetch করতে পারে, সেখানে write বা execute করে এমন যেকোনো কাজের জন্য approval প্রয়োজন হওয়া উচিত। এতে fetch করা instruction নিজে থেকে action-এ পরিণত হতে পারে না। agent action approval-এর মাধ্যমে নিয়ন্ত্রণ করা অংশে এই সীমা কোথায় নির্ধারণ করবেন তা ব্যাখ্যা করা হয়েছে। এই সম্পর্ক দুই দিকেই কাজ করে। আপনার নিজের server-ও এমন একটি page, যা অন্য কারও agent fetch করবে। এই বিষয়টি আপনার server-এ AI crawler block করা অংশে আলোচনা করা হয়েছে।

কোনো plugin কী পরিবর্তন করেছে তা কীভাবে পরীক্ষা করব?

ইনস্টল করার আগে snapshot নিন, তারপর plugin ইনস্টল করে আবার snapshot নিন। এরপর দুই 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 দেখায়, ইনস্টল করার সময় কোন plugin entry composed tree-তে যোগ হয়েছে। একটি ছোট feature-এর জন্য ইনস্টল করা plugin যদি এমন কয়েকটি entry যোগ করে যার কারণ আপনি ব্যাখ্যা করতে না পারেন, তাহলে সেটি boot করার আগে থামুন এবং source পড়ুন। dsh plugin --profile web why <package-name> অন্য প্রশ্নটির উত্তর দেয়: আপনার সরাসরি dependency-গুলোর কোনটি একটি নির্দিষ্ট package-কে dependency হিসেবে যুক্ত করেছে।

ইনস্টল করা package-গুলো $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-এ লেখা entry-গুলো সেখানেই থাকে, কারণ ওই file আপনার এবং harness এটি আপনার হয়ে rewrite করবে না। File-টি খুলে যে package সরিয়েছেন, তার নাম থাকা যেকোনো block মুছে দিন।

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

এরপর সেই অংশটি সামলান, যা কোনো uninstall command ঠিক করতে পারে না। কোনো plugin-কে আর বিশ্বাস না করার কারণে সরিয়ে থাকলে, সেটি যা পড়তে পারত তার সবই ইতিমধ্যে পড়ে থাকতে পারে। Provider console-এ DeepSeek API key rotate করুন। $DSH_HOME-এ থাকা অন্য সব credential-ও rotate করুন। এরপর plugin-টি যে unix account হিসেবে চলত, সেটি আপনার network-এর বাকি অংশে কোন কোন resource-এ পৌঁছাতে পারত তা নির্ধারণ করুন।

সংক্ষেপে

• ইনস্টলের আগে প্রকাশিত tarball পড়ুন। scripts এবং entry file থেকে শুরু করুন।
• নির্দিষ্ট version pin করুন। git spec হলে নির্দিষ্ট commit pin করুন এবং lockfile সংরক্ষণ করুন।
• একটি profile-এ ইনস্টল করুন। কিছু নষ্ট হলে boot করতে পারবেন এমন একটি পরিষ্কার profile রাখুন।
• প্রতিটি ইনস্টলের আগে ও পরে --dump-config-এর diff দেখুন।
• harness-টি নিজস্ব unix user হিসেবে loopback-এ চালান এবং SSH-এর মাধ্যমে এতে সংযোগ করুন।
• সার্ভারে একটি API key রাখুন। আর যে plugin-এর ওপর আর আস্থা নেই, সেটি সরানোর দিন key rotate করুন।

এগুলোর কোনোটিই plugin এড়িয়ে চলার কারণ নয়। plugin model-এর কারণেই dsh কার্যকর, আর যে harness প্রসারিত করা যায় না, সেটি আপনি বদলে ফেলবেন। আসল বিষয় হলো আপনি কী ইনস্টল করেছেন, কার কাছ থেকে নিয়েছেন এবং কোন version ব্যবহার করছেন তা জানা। পুরো ব্যবস্থা এমন জায়গায় চালান, যেখানে প্রয়োজনে পুনর্নির্মাণ করতে পারবেন।

FAQ

dsh কি plugin-গুলোকে একে অপরের থেকে sandbox করে?

না। Cordis-এর মাধ্যমে একটি plugin harness process-এ load হয় এবং shell, filesystem, web, subprocess, subagent ও credentials-সহ নথিভুক্ত capability seam-গুলোতে পৌঁছাতে পারে। dsh-base, যা প্রতিটি profile-এর প্রথম bundle, agent-এর tool-গুলো কী করতে পারবে তা নিয়ন্ত্রণকারী sandbox ও approval policy সরবরাহ করে। আপনার সুরক্ষা এই policy থেকেই আসে। প্রতি-plugin permission boundary নেই। তাই সঠিক মডেল হলো, plugin install করলে আপনি তার author এবং তার dependency tree-র প্রতিটি package-এর ওপরও trust স্থাপন করছেন।

install script চালানো ছাড়া কি dsh plugin install করা যায়?

pnpm 10 এবং পরবর্তী সংস্করণগুলো default-ভাবে dependency build script block করে। dsh plugin ... add pnpm-এ forward করে। তাই বর্তমান pnpm-এ package script চলে না, যতক্ষণ না আপনি সেই package অনুমোদন করেন। pnpm --version দিয়ে আপনার version নিশ্চিত করুন। এতে অপরীক্ষিত plugin নিরাপদ হয় না। পরবর্তী boot-এ plugin-এর নিজস্ব code চলে, কারণ harness ইচ্ছাকৃতভাবে সেটি load করে। install-time restriction এতে কোনো প্রভাব ফেলে না।

dsh plugin এবং তাদের config আসলে কোথায় থাকে?

$DSH_HOME default-ভাবে ~/.dsh-এ থাকে। Profile-গুলো $DSH_HOME/profiles/<name>-এ থাকে। প্রতিটি profile-এ plugin dependency-সহ একটি package.json, ক্রমানুসারে সাজানো bundle-গুলোর dsh.profile manifest এবং একটি cordis.patch.yml patch layer থাকে। Installed package-গুলো $DSH_HOME/profiles/node_modules-এর অধীনে থাকে। Key থাকে $DSH_HOME/.credentials.yaml-এ, environment value থাকে $DSH_HOME/.env-এ, এবং home-level $DSH_HOME/cordis.patch.yml প্রতিটি profile-এর ওপর প্রয়োগ হয়। boot না করেই composed result দেখতে dsh --profile web --dump-config চালান।

dsh plugin market থেকে install করা কি নিরাপদ?

Market install-কে curated registry-র source-এ সীমাবদ্ধ রাখে এবং প্রতি package-এর জন্য অনুমোদন না দেওয়া পর্যন্ত build script block করে। Chat window থেকে কোনো package name copy-paste করার তুলনায় এটি বাস্তব উন্নতি। তবুও market-এর নিজস্ব README-তে বলা আছে, listing endorsement নয়, কারণ plugin-গুলো অন্যদের লেখা third-party code। Source পড়ুন এবং version pin করুন। এমন user account-এ, এবং সম্ভব হলে এমন machine-এ, harness চালান যা হারালে আপনি তা সামলাতে পারবেন।